In realtà non saprei bene il perché. Scomodità? Disinteresse? Disorganizzazione delle informazioni? Ho idea che l’unico modo per ristuzzicare il mio interesse possa essere l’integrazione di FeedBurner in Google Analytics. Sono l’unico?

Non ho seguito bene le vicende negli ultimi mesi. Per caso c’è qualche remota possibilità che ciò avvenga?

Consigli per la preparazione all’esame

Per chi utilizza Google Analytics quotidianamente, l’esame è abbastanza semplice. Inoltre, la documentazione disponibile sul Conversion University Help è sufficiente a coprire oltre il 90% delle domande. Tuttavia, se desiderate sostenere la certificazione vi consiglio di non prendere l’esame sotto gamba. Alcune domande richiedono un’interpretazione personale e la conoscenza di alcuni dettagli tecnici di una sessione di navigazione di un utente.

Il Conversion University Help è senza dubbio il punto di partenza. Offre una panoramica completa delle funzioni di Google Analytics. Non abbiate fretta a saltare gli argomenti che pensate di conoscere. Alcune domande sono molto specifiche e richiedono, ad esempio, di sapere l’esatta precedenza attribuita a Google Analytics in caso di comportamenti comuni come multipli referer, conversioni con campagne in sovrapposizione o preferenze riguardo ai cookie.

Oltre al Conversion University Help vi consiglio di approfondire i seguenti temi, se ancora non avete avuto modo:

• Site Search
• Integrazione con Google AdWords
• Tracciamento di Conversioni e Goal
• Tracciamento di Transazioni e E-Commerce

Per ciascuno di questi temi assicuratevi di configurare un profilo di Google Analytics per test ed esplorate le funzionalità disponibili prima di affrontare l’esame. Non cancellate il profilo, potrebbe servirvi in fase d’esame.

Sempre in tema di risorse, merita senz’altro una citazione il sito Google Analytics in 30 secondi, una miniera di risorse sapientemente raccolte e pubblicate da Marco, già autore della Guida a Google Analytics per HTML.it. A proposito, complimenti a Marco che, per quanto ne so, è stato uno dei primi italiani a vincere il bollino.

Approfondimenti tecnici necessari

Normalmente è più facile per un tecnico apprendere caratteristiche comportamentali di un prodotto lato marketing che per un utente Marketing apprendere competenze tecniche. Questo perché alcune competenze tecniche richiedono prerequisiti a loro volta di carattere tecnico.

Per questo motivo, agli utenti non tecnici consiglio di approfondire gli argomenti:

• Regular Expression, per una guida base in Italiano consiglio l’articolo di Vincenzo
• Funzionamento e caratteristiche dei cookie: scadenza, first-cookie, last-cookie, possibilità di personalizzazione
• Funzionamento e caratteristiche di una sessione di navigazione di un utente
• Funzionamento e classificazione di una sessione in visitatore, visita unica e pageview

Caratteristiche del test

Il test è composto da 70 domande ed avete a disposizione 90 minuti per rispondere. Le domande sono per la maggior parte scelta singola da una lista di possibilità, in altri casi scelta multipla.

Non abbiate fretta di rispondere subito a tutte le domande. 90 minuti sono tanti, oltre 1 minuto a risposta ed alcune risposte richiedono meno di 10 secondi. Contrassegnate con Mark le risposte delle quali non siete sicuri, riprendetele in seguito. Se dopo 1 minuto non avete ancora assegnato una risposta, andate avanti. Riprenderete la risposta in seguito a test ultimato.

Durante il test è possibile consultare siti, Google Analytics ed altro materiale online. Tuttavia questo richiede tempo e vi consiglio di posticipare alla fine le domande per le quali avete bisogno di approfondimenti. Se avete seguito le indicazioni sopra per la preparazione, il numero di risposte da rivedere sarà molto limitato.

Suggerimenti per il test

Prima di iniziare il test tenete a portata di mano le seguenti risorse:

• Conversion University Help
• L’URL Builder
• Lo strumento per il filtro IP
• Il vostro account di Google Analytics, eventualmente con attivo il profilo indicato ad inizio post
• Se siete un inserzionista AdWords, il vostro account AdWords. Se non lo siete, assicuratevi di conoscere bene il funzionamento di AdWords e Google Analytics

Buon esame!

Inizialmente, quando Urchin era appena stato ribrandizzato in Google Analytics ed il prodotto era poco più che un cambio di nome, ricordo che la documentazione suggeriva di inserire il codice di tracciamento all’interno del tag <head> della pagina. Non ho mai verificato direttamente, ma la motivazione ufficiale era che alcune caratteristiche richiedevano di essere inserite all’interno delle intestazioni per funzionare correttamente.

Poi è arrivato il nuovo codice di tracciamento di Google Analytics, per intenderci quello definito dal file ga.js. La documentazione ufficiale di Google Analytics indica di inserire il codice di tracciamento immediatamente prima la chiusura del tag <body>, ovvero la chiusura della pagina HTML.

Prendendo a campione un centinaio di siti, soprattutto quelli che utilizzando Google Anaytics dai primi tempi, è facile notare come la posizione in cui è inserito il codice di tracciamento è assolutamente arbitraria. Alcuni la tengono a chiusura pagina, altri nell’header.

Le motivazioni sono essenzialmente due. Nel caso in cui il codice di tracciamento sia inserito ad inizio pagina, la probabilità di perdersi per strada dei dati è decisamente inferiore. Con il codice di tracciamento al fondo, infatti, l’utente potrebbe chiudere il browser prima che il tracciamento sia inizializzato.

Viceversa, l’inserimento di un javascript nell’head forza il browser ad attendere il suo caricamento prima di proseguire il rendering completo della pagina. Nel caso in cui Google ritardi a fornire il codice di tracciamento, la nostra pagina cadrà in uno stato di sospensione apparente ed il browser continuerà a mostrare l’avviso di caricamento in corso fino ad un eventuale timeout o ad una risposta del javascript esterno.

Lo screenshot seguente è emblematico: 357ms per restituire la pagina al browser, 35 secondi per eseguire il codice di tracciamento di Google Analytics.

Purtroppo il fenomeno non è così raro. Limitato, certo, ma spesso mi capita di imbattermi in comportamenti simili.

Il dilemma resta. Top della pagina per tutti i visitatori ma rischi al caricamento, fondo della pagina per dati potenzialmente incompleti ma utente felice?

Ecco alcuni screenshot. Il problema si manifesta sia in Italiano sia sulle pagine dei risultati internazionali.

Non so se il fenomeno sia circoscritto o visibile a chiunque. Da alcuni test ho verificato lo stesso problema anche cambiando browser o eseguendo il logout dal mio Google Account.

Capita anche a voi?

Aggiornamento: il problema sembra essere tornato alla normalità. Non si sono fatte attendere reazioni, ad esempio Google Blogoscoped e Twitter. Credo che molte altre seguiranno nelle prossime ore.

Aggiornamento: Google conferma e chiarisce l’accaduto.

Nel caso di WordPress è possibile impostare Google Analytics per tracciare le ricerche sul nostro blog in pochissimi click, senza neanche intervenire sul template del blog. L’unico requisito è che il blog sià già tracciato da Google Analytics. In caso negativo, vi consiglio l’eccellente plugin Google Analytics for WordPress.

Per abilitare Google Analytics Site Search entrate pannello di controllo di Google Analytics ed accedete alla pagina di modifica del profilo selezionando il collegamento Edit.

Selezionate nuovamente Edit per modificare la sezione Main Website Profile Information e, al fondo, assicuratevi di spostare la selezione su Do Track Site Search.

A questo punto si espanderà una una sezione dedicata alle impostazioni della funzionalità Site Search. Inserite il parametro della query string che identifica una ricerca, nel caso di WordPress corrisponde a s, inoltre vi consiglio di selezionare la voce Yes, strip query parameters out of URL per evitare di ottenere dei report sporcati da altri dati come i valori di x e y del bottone di ricerca.

Una volta salvato il profilo Google Analytics comincerà a tracciare immediatamente le ricerche nel vostro blog. Ci vorrà comunque qualche ora prima che i dati siano visibili nei report.

I dati relativi alle ricerche sono consultabili nella sezione Content > Site Search. E’ interessante tracciare le ricerche eseguite da un utente sul blog per diversi motivi. Ad esempio potete individuare i termini di ricerca più frequenti e scrivere degli articoli dedicati o più specifici.

A seconda del tipo di sito o blog le ricerche possono anche rivelare potenziali bug, problemi di reputation management o curiosi aneddoti sui brand. Nel mio caso, da quando sono passato a WordPress ho scoperto che la query più cercata è Enter search keyword: un chiaro segnale che devo rendere quel box di ricerca più user friendly!

Ciao Davide,
come certamente saprai, da qualche mese FeedBurner ha cominciato la transizione dei feed dal proprio sistema al sistema di Google.

Nello specifico, tutti i feed sono in fase di trasferimento da http://feeds.feedburner.com/... a http://feedproxy.google.com/....
La migrazione è in corso. Alcuni account, come il mio, sono già stati migrati. Altri lo saranno nelle prossime settimane.

Puoi avere conferma semplicemente aprendo http://feeds.feedburner.com/simonecarletti. Verrai rendirizzato automaticamente alla nuova destinazione.

Purtroppo il passaggio di FeedBurner a Google ha significato diversi cambiamenti. Uno tra questi l’abbandono, forse definitivo, della funzionalità dei network.
Una conferma ufficiale la puoi trovare direttamente a questo post sul gruppo di supporto.
Come puoi notare, risale addirittura a Marzo. Da quel momento nessuna domanda inerente i network ha più avuto risposta, come

Nessuno degli account con in gestione un network è stato informato di eventuali problemi.
Ho scoperto il problema non più di qualche settimana fa. Inoltre, solo in seguito al passaggio del mio account su Google ho scoperto che nella migrazione avevano rimosso ogni accesso all’area di gestione dei network.

In altre parole, il mio account è stato tagliato fuori dalla funzionalità e poco per volta sta accadendo lo stesso man mano che i partecipanti al network vengono migrati al nuovo sistema.
Allo stesso tempo, sembra che i loro post vengano rimossi dal feed del network che poco alla volta sta mostrando solamente… i superstiti!

Mi spiace per quanto accaduto ma purtroppo sono anche io come te uno spettatore passivo.

Se non ricordo male, il numero di iscritti al feed era abbastanza rilevante.
Per evitare di sparire poco alla volta nel nulla senza una comunicazione, vorrei approfittare della tua email per pubblicare questa risposta anche sul blog.

Ci sono alcuni account che ancora non sono stati migrati su Google e che quindi ancora sono visibili nel feed del network come ad esempio Altura, TSW e Petro.
Chi lo volesse può scrivere due righe invitando gli utenti interessati ad iscriversi ai singoli blog… prima che sia troppo tardi! ;)

Un saluto,
– Simone

In conclusione, mano a mano che gli account saranno migrati da FeedBurner a Google Account, tutti i Network FeedBurner risulteranno irraggiungibili e/o vuoti. Invito tutti gli iscritti al Network FeedBurner sui Motori di Ricerca e ad eventuali altri network di cominciare ad iscriversi ai singoli feed di loro interesse.

Ma allora, come mai frasi come Google non legge i JavaScript o Yahoo! non capisce i CSS sono così diffuse? Come in ogni leggenda che si rispetti, anche in questa c’è un fondo di verità. In questo articolo cercherò di dimostrare entrambi i punti di vista.

I motori di ricerca leggono JavaScript e CSS

Cominciamo dalla parte più facile, ovvero dimostrare che i motori di ricerca leggono i file JavaScript e CSS. Per fugare definitivamente ogni dubbio possiamo analizzare i log di accesso di un comune sito web.

I motori di ricerca ed i file CSS

Proviamo, ad esempio, a controllare tutti gli accessi ai un file CSS di questo blog.

$ grep '.css' access.log
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:31 -0700] "GET /blog/styles.css HTTP/1.1" 200 720 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:31 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.1" 200 9767 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:31 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.1" 200 13665 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/stylesheets/blog.css HTTP/1.1" 200 5559 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/stylesheets/alignments.css HTTP/1.1" 200 1815 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/stylesheets/messages.css HTTP/1.1" 200 3198 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
85-18-66-25.ip.fastwebnet.it - - [20/Sep/2008:13:03:32 -0700] "GET /static/mt4/SyntaxHighlighter/Styles/SyntaxHighlighter.css HTTP/1.1" 200 4352 "http://www.simonecarletti.com/blog/2006/02/perche_ho_scelto_feeddemon.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)"
crawl-66-249-70-72.googlebot.com - - [20/Sep/2008:13:06:07 -0700] "GET /static/tools/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
host64-86-dynamic.61-82-r.retail.telecomitalia.it - - [20/Sep/2008:13:10:22 -0700] "GET /blog/styles.css HTTP/1.1" 200 721 "http://www.simonecarletti.com/blog/2007/03/individuare-cloni-fake.php" "Opera/9.52 (Windows NT 5.1; U; it)"
host64-86-dynamic.61-82-r.retail.telecomitalia.it - - [20/Sep/2008:13:10:22 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.1" 200 9767 "http://www.simonecarletti.com/blog/2007/03/individuare-cloni-fake.php" "Opera/9.52 (Windows NT 5.1; U; it)"
host64-86-dynamic.61-82-r.retail.telecomitalia.it - - [20/Sep/2008:13:10:22 -0700] "GET /static/stylesheets/blog.css HTTP/1.1" 200 5560 "http://www.simonecarletti.com/blog/2007/03/individuare-cloni-fake.php" "Opera/9.52 (Windows NT 5.1; U; it)"

Non notate nulla di strano? Alla riga numero 8 è presente un accesso da un client con useragent Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html): il crawler di Google!

La user agent è facilmente modificabile e chiunque può spacciarsi, senza troppa fatica, per il crawler di Google. Per rendere il test ancora più affidabile è quindi necessario eseguire un reverse DNS dell’indirizzo IP. Per semplicità ho delegato ad Apache questo lavoro, così che il log contenga direttamente il nome dell’host al posto del corrispondente IP.

Come potete vedere, l’host associato a quella richiesta corrisponde a crawl-66-249-70-72.googlebot.com, un host di proprietà di Google. A questo punto, vale la pena eseguire una ricerca mirata nei log solo per questo host, limitando ovviamente i risultati ai soli file CSS.

$ zgrep '.css ' access.* | egrep '^.*?.googlebot.com'
crawl-66-249-70-72.googlebot.com - - [20/Sep/2008:01:44:17 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.1" 200 13666 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [20/Sep/2008:13:06:07 -0700] "GET /static/tools/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [22/Sep/2008:12:00:41 -0700] "GET /static/stylesheets/messages.css HTTP/1.1" 200 3199 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [22/Sep/2008:16:28:17 -0700] "GET /static/stylesheets/messages.css HTTP/1.1" 304 256 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [24/Sep/2008:21:32:38 -0700] "GET /mt4/mt-search.cgi?IncludeBlogs=1&search=css HTTP/1.1" 200 18391 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [25/Sep/2008:09:11:06 -0700] "GET /static/stylesheets/blog.css HTTP/1.1" 200 5560 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [25/Sep/2008:12:09:48 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.1" 200 9768 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [03/Oct/2008:17:09:31 -0700] "GET /static/toolsdesign/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
crawl-66-249-70-72.googlebot.com - - [04/Oct/2008:11:06:55 -0700] "GET /static/tools/style.css HTTP/1.1" 200 10046 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

In modo del tutto analogo, andiamo alla ricerca di tracce del bot di MSN e Yahoo!.

Il primo si identifica normalmente con un host che termina per search.msn.com.

$ zgrep '.css ' access.* | egrep '^.*?.search.msn.com'
msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:26 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.0" 200 9767 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/stylesheets/blog.css HTTP/1.0" 200 5535 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/stylesheets/alignments.css HTTP/1.0" 200 1815 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/stylesheets/messages.css HTTP/1.0" 200 3198 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.0" 200 13666 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
msnbot-65-55-110-231.search.msn.com - - [06/Oct/2008:23:09:27 -0700] "GET /static/mt4/SyntaxHighlighter/Styles/SyntaxHighlighter.css HTTP/1.0" 200 4352 "http://www.simonecarletti.com/mt4/mt-search.cgi?tag=luca conti&blog_id=1" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"

Il secondo, invece, utilizza un host tipo *.crawl.yahoo.net.

$ zgrep '.css ' access.* | egrep '^.*?.crawl.yahoo.net'
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:22 -0700] "GET /blog/styles.css HTTP/1.0" 304 218 "http://www.simonecarletti.com/blog/2006/05/piu_trackback_per_tutti.php" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:25 -0700] "GET /static/mt4/themes-base/blog.css HTTP/1.0" 304 220 "http://www.simonecarletti.com/blog/styles.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:25 -0700] "GET /static/stylesheets/blog.css HTTP/1.0" 304 219 "http://www.simonecarletti.com/blog/styles.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:27 -0700] "GET /static/stylesheets/alignments.css HTTP/1.0" 304 218 "http://www.simonecarletti.com/static/stylesheets/blog.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:27 -0700] "GET /static/stylesheets/messages.css HTTP/1.0" 304 219 "http://www.simonecarletti.com/static/stylesheets/blog.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:35 -0700] "GET /static/mt4/support/themes/professional-blue/professional-blue.css HTTP/1.0" 304 220 "http://www.simonecarletti.com/blog/styles.css" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"
llf320045.crawl.yahoo.net - - [07/Oct/2008:00:02:35 -0700] "GET /static/mt4/SyntaxHighlighter/Styles/SyntaxHighlighter.css HTTP/1.0" 304 219 "http://www.simonecarletti.com/blog/2006/05/piu_trackback_per_tutti.php" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)"

Fermi tutti, abbiamo dimenticato Ask.com! Quest’ultimo si identifica normalmente con un host tipo *.ask.com.

$ zgrep '.css ' access.* | egrep '^.*?.ask.com'

$ zgrep '.css ' access.* | egrep '^.*?.ask.com' | wc -l
0
$ egrep '^.*?.ask.com' access.* | wc -l
29

Niente da fare! Una ricerca per Ask.com non fornisce alcun risultato per i file CSS, mentre fornisce 29 risultati per richieste a normali pagine del blog. Possiamo quindi affermare che, tra Google, Yahoo, MSN ed Ask, Ask è l’unico motore di ricerca a non leggere alcun file .css.

I motori di ricerca ed i file JavaScript

Fino ad ora abbiamo parlato soltanto dei file CSS. Possiamo affermare che i motori di ricerca leggono anche i file JavaScript? Proviamo!

$ zgrep '.js ' access.* | egrep '^.*?.googlebot.com' | wc -l
26
$ zgrep '.js ' access.* | egrep '^.*?.search.msn.com' | wc -l
2485
$ zgrep '.js ' access.* | egrep '^.*?.crawl.yahoo.net' | wc -l
1
$ zgrep '.js ' access.* | egrep '^.*?.ask.com' | wc -l
79

Per i file JavaScript lo scenario è nettamente differente. Ask.com legge i file JavaScript mentre, così come Google e MSN che, nello specifico, non sembra preoccuparsi che file identici linkati da documenti differenti… sono identici!

La sorpresa, in questo caso, è Yahoo! che sembra aver letto 1 solo file in 30 giorni. Come se non bastasse, questo file non è in alcun modo collegato alle pagine del blog ma si tratta di un file che avevo creato per eseguire la registrazione di un nuovo handler di feed con Firefox 2.0.

llf520133.crawl.yahoo.net - - [23/Sep/2008:01:54:53 -0700] "GET /blog/public/2006/11/firefox_new_feed_handler/firefox2-registerFeedHandler.js HTTP/1.0" 200 1623 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"

Frequenza di accesso

Per i più curiosi, ecco la frequenza di accesso ai file JavaScript e CSS calcolata negli ultimi 30 giorni, suddivisa per motori.

Scaricare non vuol dire leggere!

A questo punto qualcuno potrebbe obiettare che, analizzando i log, non è dato sapere se il crawler abbia realmente letto il contenuto file o se si è limitato a richiederlo. E’ vero, ma è illogico pensare che un crawler decida di sua spontanea volontà di scaricare un file JavaScript collegato esternamente da un tag script… solo per generare accessi al server!

Inoltre ci sono diversi modi per dimostrare come il file, in seguito, in effetti venga letto. Non mi dilungo ulteriormente, alcuni di questi sono contenuti leggendo tra le righe nei paragrafi seguenti.

Leggere vs Interpretare vs Eseguire

Fermi, dove scappate… non è mica ancora finito l’articolo! Prima di tornare al menu di navigazione con link in JavaScript è importante essere a conoscenza della sottile differenza tra leggere, interpretare ed eseguire. Questi tre verbi potrebbero sembrare sinonimi, ma non è così.

I crawler normalmente leggono i file JavaScript e CSS ma, come scrissi un anno fa nell’articolo Cosa gli spider dei motori di ricerca non sanno fare, questo non significa necessariamente che intendano eseguirlo.

In altre parole. I crawler scaricano il contenuto dei file, i sorgenti all’interno vengono normalmente interpretati (soprattutto nel caso di JavaScript) ma quasi mai eseguiti. Questo significa, ad esempio, che un crawler può facilmente scoprire il significato della funzione seguente ma non vuol dire che il dominio paradise.god sarà indicizzato.

function redirect_me_to_paradise {
document.location.href = 'http://paradise.god';
}

Per questo motivo spesso si tende ad affermare, in modo improprio, che i crawler non leggono JavaScript o CSS indicando che il loro contenuto non viene eseguito come ci si potrebbe aspettare e come avviene invece con un normale browser.

Perché i motori di ricerca leggono i file JavaScript e CSS?

L’esempio precedente dovrebbe cominciare a chiarire alcune delle motivazioni per le quali i motori di ricerca hanno cominciato a leggere ed interpretare il contenuto di file JavaScript e CSS. In passato entrambi i linguaggi sono stati largamente utilizzati per nascondere agli occhi degli utenti contenuti realizzati esclusivamente per i motori di ricerca, all’unico scopo di sfruttarne il posizionamento a favore di terze pagine. Per approfondimenti sul tema vi consiglio l’articolo Testo Nascosto, scritto da Vincenzo.

Tecniche come redirect in javascript, doorway page, blocchi di testo nascosto sono oggi nel mirino dei filtri antispam di quasi i motori di ricerca. Per individuarle è necessario analizzare ed interpretare il contenuto di questi file, spesso inseriti esterni alla pagina nella (vana) speranza di eludere il crawler del motore di ricerca.

Per calcare ulteriormente la mano su questo punto vi consiglio alcune letture direttamente dal blog di Matt Cutts:

1. SEO Mistakes: sneaky JavaScript
2. SEO Mistakes: crappy doorway pages
3. SEO Mistakes: Spam in other languages
4. Ramping up on international webspam
5. SEO Advice: clean house before press releases
6. “Undetectable” spam

In conclusione

Webmaster, SEO, spammer ed utenti siete avvisati! Qualunque sia il vostro scopo finale, siate consapevoli del fatto che i motori di ricerca leggono JavaScript e CSS, normalmente li interpretano, raramente li eseguono. Ovviamente non è escluso che il comportamento possa variare in futuro.

vs

Come spiegato nell’articolo che cosa sono i Google Sitelinks, l’assegnazione di questi risultati aggiuntivi è frutto di un algoritmo automatico di Google.
Fino ad oggi si è quasi sempre sentito parlare di siti che hanno ricevuto in omaggio Sitelinks, molto più rari sono gli interventi in merito alla rimozione dei Google Sitelinks ad un sito.

I Google Sitelink possono essere disattivati… fidati!

Questo ha generato in molti utenti la falsa credenza che i Google Sitelinks una volta attribuiti non possano essere rimossi. In realtà non è così: come possono essere attribuiti, allo stesso modo possono essere rimossi ancora una volta dall’algoritmo di Google. Anche se si tratta di un caso più raro, si può verificare.

L’esempio pratico l’ho sperimentato proprio su questo blog, la settimana scorsa. Fino ad inizio agosto una ricerca per simone carletti restituiva come primo risultato questo blog, con 4 Google Sitelinks attivi che puntavano rispettivamente a:

1. HTTP Headers Status Checker
2. HTTP Headers Analyzer
3. Apache Log Analyzer 2 Feed
4. … il quarto non lo ricordo

Ad oggi, se provate la stessa ricerca noterete che i Google Sitelinks sono completamente scomparsi, come dimostra lo screenshot seguente.

Molti vivrebbero questa situazione come un dramma esistenziale e, probabilmente, sarebbe stato lo stesso anche per me se si fosse trattato di un cliente.
In realtà, sperimentando ancora una volta un’esperienza anomala sulla propria pelle ho potuto analizzare la vicenda con obiettività ma, soprattutto, con la perfetta consapevolezza di quali erano stati i miei movimenti negli ultimi tempi che avrebbero potuto causare questo problema.

Quest’ultimo passo è fondamentale. Chi si è trovato, anche solo una volta, ad affrontare una situazione anomala per risolvere un problema di terzi ha ben presente cosa significhi dover giocare a Sherlock Holmes per tentare di scoprire ogni mossa che il cliente può aver compiuto, volontariamente o involontariamente.

Possibili motivi per la rimozione dei Google Sitelinks

Poiché l’algoritmo per l’assegnazione dei Google Sitelinks non è pubblico non ho certezza che la mia analisi sia del tutto infallibile, tuttavia sono abbastanza certo di aver individuato l’origine del problema.

Le cause che possono portare alla rimozione dei Google Sitelinks sono essenzialmente due: perdita della prima posizione o numero insufficiente di sitelinks.

Perdita della prima posizione

Questa ipotesi è la più semplice da comprendere. Poiché, al momento, l’algoritmo assegna i Google Sitelinks solo al sito in prima posizione nei risultati per una determinata keyword, la perdita della prima posizione comporta inevitabilmente la perdita dei Google Sitelinks. Il “premio” passa quindi, di norma, a colui che ha conquistato la vetta ammesso che il sito abbia i requisiti necessari.

Questa situazione è più frequente per keyword generiche che non corrispondono a brand o nomi propri. Di norma, è difficile che il sito ufficiale di un marchio citato nella ricerca possa essere scavalcato da un qualsiasi altro sito. Ad esempio, difficile che il sito di Prada possa essere scalzato per la keyword prada da un rivenditore, anche se il primo è completamente in flash e non offre alcun deeplink utile.

Numero insufficiente di Sitelinks

Questa è, quasi certamente, la causa che ha decretato la perdita dei Google Sitelinks per questo sito.

Come vi sarete accorti, il numero di Sitelinks normalmente varia da un minimo di 4 ad un massimo di 8 per risultato. Questo significa che il crawler di Google deve essere in grado di identificare almeno 4 candidati link possibili. Nel caso in cui Google non riesca a raccogliere un numero di link sufficienti, automaticamente i Sitelink non vengono attribuiti.

La conferma arriva direttamente dalla documentazione di Google che aggiunge un altro ingrediente importante alla ricetta: il numero minimo di link richiesti.

Note that we only display sitelinks when a site has a minimum of three sitelinks available. If you have two or fewer unblocked sitelinks, no sitelinks at all will appear in Google search results for your site.

Dati questi elementi, è ragionevole pensare che i requisiti minimi siano applicabili non solo per l’attribuzione ma anche per il mantenimento dei Google Sitelinks. Nel momento in cui un sito non dispone più di un numero di collegamenti sufficienti, automaticamente i Google Sitelinks vengono rimossi dalla pagina dei risultati a patto che Google non riesca ad individuare delle risorse aggiuntive da utilizzare.

Come anticipato ad inizio post, il mio sito disponeva esclusivamente di 4 sitelink. In preparazione allo sviluppo del nuovo sito, ho spostato la sezione code su code.simonecarletti.com privando così il sito di due dei quattro sitelink. Al momento questo sito non dispone di altre sezioni di rilievo, di conseguenza a Google non è rimasto altro che disattivare la funzionalità.
La conferma arriva anche da Google Webmaster Tools, dove la lista dei Google Sitelinks è inesorabilmente vuota.

Leggendo tra le righe, sembrerebbe confermato anche un altro aspetto dell’algoritmo: i link su terzi livelli non contribuiscono al numero totale dei Google Sitelinks.

I test sono l’anima del SEO

E’ incredibile quanto si possa apprendere semplicemente soffermandosi a studiare ed analizzare un fenomeno. A volte è necessario anche qualche sacrificio (in genere involontario) ma, a mio avviso, è proprio questo uno degli aspetti più intriganti in questo campo.

In compenso, più che una traduzione inglese, a Google ora come ora servirebbe una correzione italiana. Il testo del collegamento sembra scritto da Yoda.