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!

Related posts:

1. Google Analytics apre le porte a tutti
2. Google Analytics
3. Invito Google Analytics: li invia solo Google!

Che cos’è lo status HTTP 410?

Come ben saprà chi legge abitualmente questo blog o si interessa di server, un server può restituire diversi status code in risposta ad una richiesta di una pagina web. Tra gli status code pià famosi troviamo

• HTTP 200 in caso di risposta completata con successo
• HTTP 404 in caso di risorsa non trovata
• HTTP 403 in caso di accesso non consentito

Lo status code restituito da un server è fondamentale e determina il risultato di una risposta HTTP. Parlando di motori di ricerca, lo status code influenza il posizionamento di una pagina così come la sua indicizzazione.

Lo status code 410 rappresenta la risposta in caso di risorsa non più disponibile. La sua definizione tecnica è HTTP 410 Gone. Per certi versi è molto simile al 404 poiché entrambi identificano una risorsa irraggiungibile, tuttavia esiste una differenza non banale:

• lo status code 404 indica una risorsa non disponibile.
• lo status code 410 indica una risorsa non più disponibile.

In altre parole, lo status code 410 implica che a quell’indirizzo prima fosse disponibile una risorsa che, al momento, è stata rimossa. Al contrario, lo status code 404 non fornisce questo dettaglio: l’indirizzo richiesto forse non ha mai ospitato una risorsa, forse sì… non si sa.

Agli occhi della maggior parte dei client ciò che conta è il risultato. In entrambi i casi ci troviamo di fronte ad una risorsa non disponibile e l’errore va gestito. Alcuni software rimuovono la risorsa dai propri indici, altri la nascondono, altri ancora mettono in atto azioni correttive per verificare un’eventuale collocazione alternativa.

La maggior parte dei motori di ricerca afferma di gestire lo status code 410 allo stesso modo del 404. Obiettivo del mio test era verificare quest’affermazione sfruttando la necessità di voler rimuovere un feed non più disponibile.

Numero di richieste HTTP

Il grafico seguente riassume le richieste HTTP inviate alla pagina /atom.xml prima e dopo l’impostazione dello status code HTTP 410, il 5 Ottobre 2008.

Nota. Per ingrandire i valori potete con il mouse selezionare una porzione del grafico. Lo script provvederà ad ingrandire a schermo solo il range che avete evidenziato.

I risultati

Analizzando i risultati dell’esperimento è possibile osservare diversi comportamenti curiosi. Ecco alcune mie considerazioni, in ordine sparso.

1. Contrariamente ad ogni mia aspettativa, lo status HTTP 410 è supportato da una buona fetta dei client web: crawler, motori di ricerca, parser… E’ possibile notare come, nel giro di qualche giorno, le richieste alla pagina sono diminuite sensibilmente.
2. A differenza dello status HTTP 404, lo status HTTP 410 ha un effetto quasi immediato. Teoricamente parlando questo ha un senso ma, anche in questo caso, non mi sarei aspettato una così concreta aderenza alle specifiche. Il motivo per il quale l’HTTP 410 è così immediato è da ricercare nel suo significato: la volontà di azione. A differenza del 404 che potrebbe essere casuale o involontario, l’HTTP 410 non è uno status code predefinito e viene impostato deliberatamente. Questa sottile differenza autorizza il client ad agire senza eccessivi controlli aggiuntivi, come avviene invece nel caso di un HTTP 404.
3. A differenza dello status HTTP 404, buona parte dei client mette in atto un processo di rimozione irreversibile. In altre parole, una volta appurata la non disponibilità della risorsa, i client limitano i controlli periodici ad una frequenza inferiore a quella normalmente prevista per un HTTP 404.

In conclusione, direi che è possibile affermare con una discreta certezza che l’HTTP 410 è efficace. Inoltre, sembra essere dimostrato che per rimuovere velocemente una pagina dalla rete questo status code rappresenta una soluzione più efficace rispetto alla semplice cancellazione del file dal server e conseguente HTTP 404.

Related posts:

1. Come restituire HTTP Status Code specifici con Apache e .htaccess
2. Importanti aggiornamenti al tool HTTP Headers Status Checker
3. Strumenti SEO: HTTP Headers Status Checker

Nel primo caso Twingly è in qualche modo paragonabile al funzionamento di Google Blog Search o altre vecchie conoscenze come Technorati. A differenza di quest’ultimo però, Twingly sembra passarsela meglio. Nel secondo caso Twingly permette ricerche tra i dati di Twitter ed altri servizi dei quali non conoscevo neppure l’esistenza. Non c’è da stupirsi, dato che sono diametralmente opposto a questi prodotti.

Il bot di Twingly si presenta con la seguente user agent

Mozilla/5.0 (compatible; Twingly Recon; twingly.com)

Analizzando i log ho avuto modo di notare che si ciba sia di feed sia di pagine del blog.

Twingly sembra un progetto ben studiato. E’ pieno di widget ripubblicabili, offre una top100 per la gioia dei classifica-dipendenti e, molto interessante, permette di interagire attraverso un sistema di API. Quest’ultima funzione, dal mio punto di vista, è forse la parte più attraente.

Related posts:

1. Leggendo i log ho scoperto… #10 – PDF Search Engine
2. Leggendo i log ho scoperto… #5
3. Leggendo i log ho scoperto… #8 – iearthworm

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.

Related posts:

1. Google Maps integrato nelle SERP
2. Google SERP & Gadget: Blogger tip
3. Ancora nuovi look (in test) alle SERP di Google

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.

Related posts:

1. Leggendo i log ho scoperto… #4
2. Leggendo i log ho scoperto… #5
3. Leggendo i log ho scoperto… #6

vs

Related posts:

1. Ancora nuovi look (in test) alle SERP di Google
2. Google, indietro nel tempo…
3. Calcolo dei tempi di indicizzazione

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.

Related posts:

1. Che cosa sono i Google Sitelinks
2. Versione evoluta dei Google Sitelinks: sitelinks e form di ricerca
3. HTML.it: l’articolo sui Google Sitelinks è piaciuto, altre proposte?

Immediatamente è scattata la rimozione, l’analisi dei log per risalire alla provenienza e qualche contromisura per prevenire il crossposting dei commenti SPAM altrove.

Finita la bonifica, ho dedicato un paio di minuti alla ricerca online per scoprire dove altro avesse colpito il commentatore ed ecco il risultato.

In meno di cinque ore il mio blog compariva già in prima posizione per questo scomodo commento, seguito da un illustre compagno di sventura. Fortunatamente, il blog sembra essere particolarmente sotto i riflettori. Già in giornata la stessa ricerca mostrava risultati più confortanti per il sottoscritto.

Curioso notare come il blog di Davide figuri ancora nelle SERP, nonostante nel suo caso si tratti della homepage. Notoriamente questa pagina speciale gode di una rilevanza maggiore.

Related posts:

1. Pingare su Technorati chi ti cita? Ecco come ottenere ranking
2. Microsoft Webmaster Tools… a quando? Forse presto?
3. Apache Log Analyzer 2 Feed: i feed a vantaggio dei SEO

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

Related posts:

1. Sei alla ricerca di un modo per disabilitare i risultati personalizzati di Google?
2. 38 FAQ su Google e la censura dei risultati
3. Google restituisce i risultati in 0 secondi

La novità della settimana è che Live Search ha migliorato il pannello Webmaster Tools. Non potevo farmi sfuggire l’occasione di curiosare le novità, dopo essere stato profondamente deluso dall’inusabilità dello strumento fino ad oggi, già espressa nel recente aggiornamento della Guida Sitemap per HTML.it.

Impressioni sul nuovo Webmaster Center

Cominciamo dal nome. Ma si chiama Webmaster Center o Webmaster Tools?
Non che sia un problema esistenziale ma sono già confuso prima ancora di cominciare. Il blog italiano ed internazionale preferiscono Tools ma il blog ufficiale si dichiara Center così come il sito stesso (che però dichiara Signup to use the tools).
Ok, ci rinuncio. Sappiate che indipentemente da Center o Tools, sto parlando di lui.

Passiamo alle cose meno frivole. La mia prima impressione è che, riguardo a Webmaster Tools, Microsoft stia tentando di continuare ad inseguire Google.
Nulla di male in realtà, il pannello di controllo di Google per Webmaster è senza dubbio uno strumento eccellente e sarei ben felice di poter disporre di funzionalità simili anche per Live.
Purtroppo, come in tutti i casi dove si rincorre qualcuno, si rischia di lasciare indietro dei pezzi riducendo di gran lunga la qualità del risultato.

Cominciamo dall’usabilità. Poco o nulla è cambiato dalla prima release ed il pannello non è certo un esempio di usabilità.

Oltre ad un layout discutibile, sarebbe utile poter disporre della lista dei domini registrati sempre a portata di mano per saltare rapidamente da uno all’altro. Se proprio vogliamo fare le cose per bene, cambiare dominio dovrebbe portarmi nella stessa sezione in cui mi trovo per il dominio corrispondente.

Carino il nuovo HTTP verifier. Semplice, essenziale ma funzionale.
Anche in questo caso lo strumento non brilla certo di intuitività e qualcosa mi dice che continuerò ad utilizzare prodotti casalinghi. Inutile sottolineare come sarebbe bello che i due nuovi tool HTTP verifier e Keyword research tool fossero integrati un po’ meglio invece di spedire l’utente a spasso per siti Microsoft facendogli abbandonare l’interfaccia di Webmaster Center. La sensazione che ne deriva è quasi come se quegli strumenti fossero stati messi lì per sport, giusto per riempire quella desolata barra laterale che in un monitor > 1024×768 appare vuota come Riccione a novembre.

Mi sbaglierò, ma ancora non ho un posto dove trovare la lista delle Sitemap segnalate. E se l’intendo è quello di usare il campo Sitemap address allora non mi è chiaro come fare ad infilare in quell’input text più di un URL senza dover per forza ricorrere ad una Sitemap Index.

Finalmente è disponibile la sezione Crawl issue. I dati possono essere consultati e scaricati in formato CSV.
Irrazionale il pannello Sitemaps disponibile come ultima voce. La sezione (apparentemente) non è stata modificata dalla precedente release e questo mi convince ancora di più dell’inusabilità del sistema.
Perché mai il campo Sitemap address prima menzionato si trova sotto Profile e non sotto Sitemaps. Non che sotto Profile non ci possa stare, ma a questo punto proporrei di re-organizzare un po’ meglio la gestione delle informazioni.

In conclusione

Ci sono un paio di altre considerazioni degne di nota ma vedrò di dedicargli due righe in qualche altro post.
Nel frattempo, concludo confermando la mia sensazione iniziale di delusione. In sei mesi circa, periodo dall’ultimo aggiornamento di Webmaster Center, le novità sono poco più che una confusione di strumenti messi a disposizione con un limitato ordine logico.

La sensazione che questo pannello mi trasmette è quella di uno sviluppo confusionario dove manca un’attenzione verso l’utilizzatore finale.
Manca una visione d’insieme degli strumenti, manca una capacità di relazionarli tra loro in modo utile, come se l’obiettivo fosse solo far vedere che si offre qualcosa senza conoscere il cliente al quale si va ad offrire il prodotto e senza essersi mai seduto a tavolino con il cliente (che per inciso sono i SEO) per sincerarsi che il team di sviluppo fosse sulla strada giusta.

Mi auguro un’inversione di rotta nel futuro e spero che Microsoft decida di investire maggiormente nello sviluppo di questo strumento. Non posso che notare, da un paio d’anni a questa parte, una straordinaria tendenza di alcuni rami di quest’azienda all’apertura ed al confronto (si pensi ad esempio all’evoluzione di Internet Explorer). Questo è un segnale positivo, tuttavia senza gli adeguati investimenti c’è il rischio che molti buoni propositi cadano nel dimenticatoio.
Nel frattempo, credo che continuerò a non utilizzare Webmaster Center dato che per ora non ne vedo un reale valore aggiunto.

Related posts:

1. Microsoft Webmaster Tools… a quando? Forse presto?
2. Google Webmaster Central rimuove il post “non-English domain names”
3. Live Search Webmaster Portal Beta