Molti giornali hanno citato il fatto dicendo che la causa del fenomeno era da ricondursi ad attacchi Hacker, di Google Bombing, di bug/glitch di Google, e chi più ne ha più ne metta:

• http://www.repubblica.it/tecnologia/2010/07/17/news/cerchi_vaticano_esce_pedofilo_google_beffa_sui_risultati-5649746/
• http://www.corriere.it/cronache/10_luglio_17/google-vatican_d0b51b26-91bb-11df-8c13-00144f02aabe.shtml

In realtà a prima vista, al di là dello stupore per la forza dell’azione, sono rimasto un po’ perplesso per come i media hanno descritto il fenomeno: il Google Bombing a detta degli ingegneri di Google è stato sistemato, quindi potrebbe anche non trattarsi di un problema di questo tipo. (o non solo di questo)

Qualcun altro in rete ha manifestato qualche dubbio, ad esempio Giacomo Pelagatti su Twitter, il blog “L’interno dell’agnello“, il forum GT, Taller SEO (from Spain),

Per far sì che si tratti di Google Bombing è necessario che si abbia a disposizione un numero elevatissimo di risorse che linkino una pagina con degli specifici termini, come nel caso di miserable failure per George Bush, merda per italia.it, ecc.

In questo caso, però mi pare che il problema sia diverso, le attività di Google Bombing solitamente servono per associare un dominio noto ed affermato a temi diversi dal normale: in poche parole molti link con la parola “merda” portano Google a pensare che il portale turistico italia.it, sia associato non a temi turistici, ma a deiezioni umane.

Il risultato di questa azione, invece, è stato sostituire una pagina storicamente rilevante per un termine con un’altra pagina. Quindi che l’home page di pedofilo.com fosse ritenuta più rilevante dell’home page di www.vatican.va per parole chiave tipo vaticano, vatican, ecc.

Come è possibile che sia avvenuto tutto ciò? Facciamo un po’ di chiarezza per quanto possibile…Prima di tutto escludiamo fenomeni di hacking subiti dal Vaticano, in quanto non sono dimostrabili.

1) il sito pedofilo.com conteneva una copia del sito vatican.va (o parte di esso)

Partiamo da una premessa, il dominio pedofilo.com che ora redirige al dominio dell’agenzia che ha svolto quest’attività, possedeva moltissimi contenuti clonati del dominio vatican.va. Non è possibile parlare di sito clone integralmente poiché non è più verificabile tale ipotesi.

Ecco la situazione dell’archivio di Google con il comando site:

In sostanza pare che il sito del vaticano sia stato clonato copiando nel dominio pedofilo.com i documenti e sostituendo tutte le occorrenze del testo www.vatican.va presenti in pagina con quelle del dominio www.pedofilo.com.

Eccone qui un esempio (notare i link in basso dei due documenti):

2) il sito del Vaticano ha una miriade di contenuti/domini duplicati e un ottimizzazione SEO scadente

Questa copia però non giustifica il fenomeno in quanto il sito della Santa Sede è da sempre fonte di attacchi di hacker e che ha uno svariato numero di domini che copiano-riportano integralmente dei contenuti.

Ecco alcuni esempi di siti reperiti che non sembrano molto trusted a prima vista…

• http://www.0100101110101101.org/home/vaticano.org/spoof/index.html
• http://www.jesus.2000.years.de/
• http://ev6.org
• http://lgrd.info

Parrebbe inoltre che gli ultimi due siano associati all’IP della Santa Sede attraverso DNS.

Inoltre anche la Santa Sede ci mette del suo con un numero sterminato di domini da loro in possesso che contengono gli stessi contenuti:

• http://www.vatican.edu/
• http://www.va
• http://benedictumxvi.va/
• http://www.vatican.net/
• http://benedettoxvi.va/

Ed una gestione degli errori 404 con un 302 verso l’homepage ed una pessima struttura del sito per i motori di ricerca (e per gli utenti )

3) Google sembra aver fatto un po’ di confusione con le diverse copie dei domini

Nelle copie cache, ho notato una piccola stranezza che non so quanto possa essere utile a trarre conclusioni.
Il dominio di riferimento della copia cache dei documenti di pedofilo.com è spesso diverso:  non solo pedofilo.com o quello “canonico” (passatemi la battuta) vatican.va .

Ecco una copia cache di pedofilo.com con il dominio corretto:

Qui una copia riferita però al dominio www.vatican.va:

Qui un’altra riferita a www.va:

Qui una riferita a www.vatican.edu:

Qui una riferita a http://www.jesus.2000.years.de/:

Ed infine una riferita a www.lgrd.info:

In alcuni casi, ricercando dei documenti si può notare come Google restituisca i risultati dei domini “clonati” ma non del sito principale.

Insomma pare che Google, per qualche ragione, abbia delle difficoltà a capire qual’è il dominio che “comanda” ovvero potrebbe essere afflitto da gravi problemi di canonizzazione dei documenti.

Aggiungo inoltre che Google sembra quasi associare il dominio vatican.va ai testi dei nomi dei domini duplicati “pedofilo.com”, “lgrd.info”, “vatican.edu”, ecc.

4) Conclusioni

Da una prima analisi, quindi, il motivo principale di questo inconveniente pare da ricondursi maggiormente a problemi di canonizzazione dei domini più che a fenomeni di Google Bombing. Facilitati in prima istanza dalla scarsissima ottimizzazione Seo del sito del Vaticano e alla presenza di moltissimi contenuti duplicati.
Tuttavia alcuni pezzettini di questo bizzarro episodio restano parzialmente fumosi. Allo scenario potremmo anche aggiungere la possibilità che possano essere avvenuti fenomeni di “intrusione” nei sistemi del Vaticano come:

• intrusione nel DNS che gestisce il puntamento dei domini del vaticano;
• un temporaneo redirect dal dominio vatican.va verso il sito pedofilo.com;
• una fraudolenta validazione del Google Webmaster Tool del dominio vatican.va.

Si tratta di ipotesi da non escludere, purtroppo però non più verificabili e difficilmente lo verremo a scoprire. Quindi non mi va di gridare al lupo al lupo.

Voi che cosa ne pensate in merito? Vi trovate d’accordo su alcuni punti della mia analisi?Avete qualcosa da aggiungere?

Vi riporto il video dove Matt Cutts risponde su YouTube ad un’interessante domanda dell’importante SEO italiano Giacomo Pelagatti, di Search Brain.

La domanda è:

Quali sono i benefici dell’utilizzo dello strumento del cambio di indirizzo del Google Webmaster Tool rispetto all’utilizzo del semplice redirect 301?

La risposta interessante di Matt Cutts in questo video!

Buona visione!

Lato SEO questo CMS di default non ha una grandissima ottimizzazione, come la gran parte dei CMS per .NET, ma fortunatamente la folta community ci ha messo una pezza sistemando le macrocriticità e facendo di DNN un CMS dalle buone potenzialità per la visibilità nei motori di ricerca.

• Parte 1: Menù vincolato da Javascript con cloaking sullo user-agent
• Parte 2: Gestione URL
• Parte 3: Pesantezza del codice
• Parte 4: Sitemap.xml
• Parte 5: Contenuto duplicato e URL canonical
• Parte 6: Gestione flessibile e automatizzata dei link

1- Menù vincolato da Javascript con cloaking sullo user-agent

Il menù di navigazione principale, generalmente disposto in posizione orizzontale nella parte alta della pagina, ha un meccanismo di cloaking sullo user-agent:

• gli utenti che utilizzano browser vedono il menù solo se hanno il supporto Javascript attivo

[screenshot pagina www.dotnetnuke.it con js attivo]

[screenshot pagina www.dotnetnuke.it con js non attivo]

• gli user-agent, come ad esempio gli spider, visualizzano lo stesso menù senza supporto Javascript, ma senza stile CSS:

[screenshot pagina www.dotnetnuke.it con user-agent Googlebot]

Una prima criticità di questo meccanismo è che se gli spider cambiano nome, come ogni tanto accade, bisogna ricordarsi di modificare la configurazione di Don Net Nuke aggiornandola in modo corretto, come indicato nel dettaglio in questo post.

Questo meccanismo di cloaking, lo vedo un punto abbastanza critico sia per ragioni SEO ma soprattutto per l’accessibilità: non credo ci sia bisogno di vincolare un menù via Javascript per avere una buona resa grafica: HTML e CSS credo siano più che sufficienti!

Per quanto riguarda, invece, il capitolo penalizzazioni per cloaking non ci dovrebbero essere grossi problemi poiché i link nel menù per i due differenti user-agent sono identici, cambiano solo le modalità di visualizzazione.

Una valida alternativa per eliminare il meccanismo di cloaking ed utilizzare una semplice gestione del menù via HTML e CSS è l’adozione di un componente aggiuntivo, come ad esempio quello di Sinapsi.

2- Gestione URL

Le URL sono da sempre un capitolo molto doloroso per molti CMS, tra i quali Dot Net Nuke. Le URL che vengono assegnate di default alle risorse sono spesso prolisse e migliorabili.

• http://www.miosito.com/tabid/81/Default.aspx
• http://www.miosito.com/Default.aspx?tabid=81

Anche in questo caso la community ha tentato di mettere una pezza: sono infatti disponibili alcuni componenti che permettono la produzione di URL sicuramente più brevi e piacevoli sia agli utenti che ai motori di ricerca (anche se non sono proprio come Jakob Nielsen comanda….)

Lo standard più utilizzato è il componente di iFinity, chiamato URL Master, che in poco tempo permette di ottenere URL corte e completamente customizzabili.

Va detto che la configurazione del modulo è abbastanza pesante poiché dovrà essere specificata per ciascuna pagina l’URL di destinazione.

Il modulo, inoltre, è in grado di gestire anche le redirezioni HTTP.

3- Pesantezza del codice

Il problema del codice pesante dipende molto spesso dalla capacità di sviluppare un buon codice HTML di front-end minimale accompagnato da un foglio di stile.

Certo è che il campo nascosto “__VIEWSTATE”, id degli elementi distribuiti lautamente non contribuiscono a creare un codice HTML leggero e che piaccia ai motori di ricerca.

4- Sitemap.xml

Anche la creazione della sitemap non sembra essere supportato con un aggiornamento automatico.

Anche in questo caso c’è un modulo esterno che ci viene in aiuto. La soluzione attualmente più utilizzata è sviluppata ancora una volta da iFinity, si chiama Google Sitemap Provider.

5- Contenuto duplicato e URL canonical

Per quanto riguarda il capitolo contenuto duplicato, non sembrano esserci grandi criticità, ma si consiglia l’utilizzo di un modulo per l’inserimento del tag rel=”canonical”, chiamato Canonical links for DNN

6- Gestione flessibile e automatizzata dei link

Nel caso in cui si desideri, invece, inserire il nofollow per determinati pattern di link (ad esempio link esterni) è possibile utilizzare un modulo chiamato Inline Link Master.

Il modulo permette di definire delle regular expression per i diversi link, creando dei filtri e potendo eseguire delle azioni su di essi.

Il modulo permette, ad esempio, di cercare le occorrenza di un testo in pagina (nell’immagine sopra il testo da intercettare è “DotNetNuke”) e di creare automaticamente dei link verso una pagina (nell’immagine un link verso una pagina interna del dominio dotnetnuke.com).

E voi avete esperienze di ottimizzzione con Dot Net Nuke? Che tool avete utilizzato per risolvere i problemi SEO?

Ora però l’entrata dirompente di nuovi player nel settore sta cambiando un po’ le carte in tavola: mi riferisco alla presenza sempre più massiccia dei comparatori di assicurazioni che da qualche mese a questa parte stanno un po’ cambiando la fisionomia delle pagine dei risultati di ricerca di Google.

Il caso emblematico più grande è stato quello di assicurazione.it, che nel giro di qualche mese si è ritagliato uno spazio davvero importante, con un’azione SEO particolarmente aggressiva che lo ha portato ad avere buoni risultati.

Piano piano ne stanno sorgendo degli altri che potranno avere destini diversi: ultimo il  preventivatore dell’Isvap che IMHO per il momento sembra un po’ arretrato rispetto allo standard attuale sul web.

Dal mio punto di vista, sono convinto che i comparatori nel futuro saranno destinati a dare più di qualche grattacapo alle direzioni web marketing delle aziende assicurative.

Tutta colpa di Google e del suo algoritmo, che amo definire democratico: esso infatti è in grado di mettere al primo posto il sito di un’aziendina sconosciuta formata da un manipolo nerd, ma che lavora bene e fornisce uno strumento assai gradito agli utenti, relegando nei posti più bassi anche siti web di grandi aziende… Ebbene sì con Google, Davide può battere e spesso batte Golia!

L’argomentazione fin qui potrebbe essere al quanto semplicistica e opinabile: è evidente che i siti web delle aziende di assicurazioni abbiano una natura e delle prerogative completamente diverse rispetto a quelli dei comparatori. Tuttavia sono convinto che i comparatori abbiano paradossalmente notevoli vantaggi rispetto alle compagnie assicurative nell’ambito del SEO e nella lotta nelle SERP.

1. Organizzazione e burocrazia aziendale

Nel caso delle compagnie assicurative, c’è un’organizzazione e un organigramma complesso alle spalle: paradossalmente una struttura di azienda più piccola può essere un vantaggio. Organizzazioni ampie e complesse, richiedono approvazioni da molti responsabili per la pubblicazione di qualsiasi nuovo contenuto/elemento nel sito web, dilatando i tempi per interventi di ottimizzazione o pubblicazione di contenuti. Questo va un po’ in controtendenza con il SEO e il web: i tempi morti o l’impossibilità a muoversi agilmente può rappresentare una grande, se non grandissima, limitazione.

Viceversa una medio/piccola azienda web oriented che gestisce un comparatore di prodotti assicurativi, può permettersi il lusso di pubblicare contenuti e modificarli agilmente: garantendo dei tempi di sviluppo veloci e con risultati raggiungibili in tempi inferiori.

2. Soluzioni tecniche

Soluzioni tecniche ereditate nel tempo: i siti web di molte compagnie assicurative potrebbero avere un’infrastruttura tecnica di base non recentissima che a volte può rappresentare un punto a sfavore rispetto ai nuovi player. Essi spesso si affacciano sul mercato con CMS agili e di ultima generazione con standard qualitativi elevati e molto orientati al SEO.

3. Contenuti

La natura contenutistica dei siti web è molto diversa: da un lato il sito di una compagnia assicurativa ha come esigenza quella di dare informazioni relative al prodotto e di supporto al cliente. Viceversa un comparatore di assicurazioni può parlare di tutte le compagnie assicurative (mirando ai posizionamenti sui vari brand), dei loro prodotti, può dare notizie del settore indistintamente dall’azienda citata, ecc. Inoltre, essendo spesso un’organizzazione molto web-oriented, può prendersi la libertà di assumere dei copywriter al solo scopo di produrre dei contenuti a tema di qualità, cosa meno usuale in organizzazioni old site come quelle di alcune compagnie assicurative.

Hanno, quindi, grande libertà nella produzione di contenuti e possono dare fastidio alle compagnie assicurative anche nelle SERP relative al brand o al prodotto.

4. Reputazione on line e brand

Inoltre, dietro al sito di una compagnia assicurativa c’è un brand da difendere e tenere a riparo da eventuali problemi con gli utenti: ogni scheda prodotto dev’essere minuziosamente controllata per non incappare in indagini da parte delle autorità. Inoltre non ci si può esporre troppo ad esperimenti social e interazioni con gli utenti: in alcuni casi tali attività potrebbero essere considerate rischiose in quanto aprirebbero il fianco a critiche verso la compagnia scatenando effetti negativi indesiderati dalla dirigenza. Viceversa un comparatore di assicurazioni che dialoga con i clienti verrebbe visto come un’utile supporto agli utenti, più che una valvola di sfogo per clienti insoddisfatti (che di fatto non esistono).

5. Utilità del servizio

Ciò non bastasse in alcune fasi cruciali del processo di acquisto, il servizio fornito da un comparatore potrebbe essere considerato più utile di quello di un sito di assicurazioni perché permette il confronto di diversi prodotti contemporaneamente. Certo, si tratta di informazioni limitate che richiedono maggiori approfondimenti da parte dell’utente, ma in fase di valutazione e scelta di una compagnia assicurativa rispetto ad un’altra è davvero molto utile e preferibile rispetto alla compilazione di 10 lunghissime form on line per la comparazione dei prezzi.

6. Mentalità SEO e Web

Il ruolo e la consapevolezza del SEO e del Web in generale nelle due aziende è diametralmente opposto: mentre da un lato i comparatori hanno come obiettivo numero uno aziendale il SEO perché è grazie a quello (oltre ad altre azioni tattiche sul web) che il loro modello di business può diventare davvero redditizio, dall’altro il SEO nelle compagnie assicurative rappresenta solo un piccolo tassello e non gode ovviamente della stessa importanza.

I processi, quindi, sono diversi. Da un lato per i comparatori una proposta rivolta a migliorare il SEO può essere vista come un’occasione per l’intera azienda e considerabile come attività ad alto ROI. Viceversa dal lato delle compagnie assicurative certe attività potrebbero anche essere considerate come poco comprensibili, da tutti gli attori coinvolti e, visti i tempi lunghi dei processi aziendali, anche meno redditizie e troppo ‘a lungo termine’.

Conclusione

Per concludere, credo che l’entrata di questi nuovi player nel settore delle assicurazioni sicuramente avrà delle importanti ripercussioni per le compagnie assicurative, specialmente per i vantaggi sopraelencati di cui godono i comparatori. Sono convinto, però, che nel prossimo periodo i cambiamenti in corso porteranno molte compagnie assicurative ad effettuare dei processi di rinnovamento, cambi di strategie e budget.

Chissà magari una pioggia di in-House SEO affiancati da agenzie di consulenza in affiancamento?

Lo scopriremo solo vivendo…:-)

Voi che ne pensate?Siete d’accordo con la mia teoria?

Vi sono casi di CMS che, a causa della loro gestione delle URL, rendono i siti sviluppati su di essi impromuovibili o quasi (un modo lo si trova sempre … ).

Ora però ci sono delle novità interessanti che probabilmente hanno cambiato l’approccio alla risoluzione del problema.

I due classici problemi delle URL su CMS

I due fattori che fanno spesso storcere il naso ai SEO sono:

1- URL che generano contenuto duplicato: molto spesso, infatti, i CMS fanno corrispondere più URL (query string comprese) allo stesso contenuto.

Casi classici di questa gestione possono essere:

• generazione dell’id di sessione;
• generazione dell’URL sulla base del percorso di navigazione;
• presenza incontrollata di redirect HTTP;
• pagine con listati di elementi ordinabili in modo diversi;
• Versioni stampabili delle pagine web;

Questo aspetto ha delle gravi conseguenza sul posizionamento, come ad esempio il crollo dei fattori qualitativi dei contenuti del sito, difficoltà del motore di ricerca di comprendere la struttura del sito e di estrarne poi l’ambito semantico dei contenuti, ecc.

2- URL troppo lunghe e prolisse: molti CMS generano un numero consistente di cartelle (in realtà solo cartelle virtuali), come ad esempio:

www.sito.com/nomesito/lingua/applicazione/controller/categoria/variante/nomeprodotto.html.

Le URL lunghe sono considerate un aspetto negativo per due ragioni:

• presentano maggiore rischio di non avere la parola chiave pertinente con il contenuto grassettata nella SERP, con un conseguente calo del CTR;
• possono fungere da deterrente per il click dell’utente, come dimostra una famosa ricerca di Marketing Sherpa.

Come si risolvevano questi problemi?

Fino all’anno scorso per poter risolvere questi due problemi si doveva intervenire alla radice: ovvero andando a impostare un percorso di navigazione per lo spider che fosse contraddistinto da URL corte e che identificassero univocamente i contenuti.

Tralasciando certe tecniche di SEO di basso profilo, come ad esempio i famigerati link sul footer a pagine SEO, il modo di approcciare il problema spesso necessitava di interventi massivi nel CMS andando in qualche modo a forzare la gestione delle URL, talvolta senza possibilità di successo: molto soldi spesi nello sviluppo, snervanti incontri e scontri gli sviluppatori dei CMS…insomma un lavoro davvero faticoso, con un ROI in molti casi davvero poco soddisfacente.

Le novità da parte di Google

In questo ultimo periodo Google ha fatto registrare più di qualche novità, che ha cambiato le carte in tavola, dando vita ad un possibile approccio diverso al problema della gestione delle URL.

1- rel=canonical:  la prima novità datata febbraio, permette di poter indicare a Google, l’URL principale associata ad un contenuto attraverso il tag link, inserendo come proprietà del documento l’URL desiderata.

(image credit)

Questa novità, assieme ad altri piccoli opportuni accorgimenti, possono considerarsi una buona soluzione per poter risolvere, o limitare il fenomeno del contenuto duplicato causato dalle URL con un impatto sui costi di gran lunga inferiore rispetto alle soluzioni che si adottavano in precedenza.

2- accorciamento delle URL: l’altra novità, notata da qualche blog già qualche giorno fa, mostra come Google in questi ultimi giorni stia iniziando a troncare le URL lunghe, mostrando agli utenti nella SERP la porzione di URL più rilevante per la ricerca effettuata dall’utente.

Questo aspetto permette in qualche modo di limare e di attutire gli effetti negativi di URL lunghe nella SERP. Il motivo principale di questa novità è da ricondurre principalmente alla user experience: nelle nuove SERP viene evidenziato ciò che gli utenti ritengono più rilevante aumentando i CTR dei risultati potenzialmente più pertinenti.

Concludendo…

Grazie a queste ultime due novità di Google, con c’è la possibilità di poter limitare gli effetti di una cattiva gestione delle URL da parte del CMS. Ci tengo a sottolineare, però, che questi strumenti sono dei workaround ed in quanto tali dal mio punto di vista non rappresentano la soluzione ottimale.

Non bisogna solo prendere in considerazione la SEO in quanto tale per battezzare queste novità come la risoluzione dei problemi della gestione delle URL, ma bisognerebbe pensare anche alla User Experience.

URL prolisse, o duplicate, che non rientrano nel caso della classica struttura consigliata, ad esempio:

www.sito.com/categoria-1°livello/

www.sito.com/categoria-1°livello/categoria-2°livello/

www.sito.com/categoria-1°livello/categoria-2°livello/pagina-foglia.html

rappresentano un ostacolo per l’usabilità (vi consiglio questo alert-box “URL as UI” di Jakob Nielsen datato 1999 ma sempre molto attuale).

…insomma…Google ci sta dando una mano ma nella scelta o sviluppo di un CMS valutate ancora molto attentamente la gestione delle URL per avere il prodotto migliore