La piattaforma su cui si basa Search Marketing Arena è uno dei punti di forza del progetto. Si tratta allo stesso tempo di un forum, wiki, blog e digg, senza essere nessuno dei quattro.
La piattaforma infatti integra alcune delle caratteristiche essenziali di questi 4 sistemi tentando di esaltarne esclusivamente i pregi.

L’accesso a Search Marketing Arena è assolutamente gratuito. Non esistono aree premium e la registrazione è del tutto facoltativa. Registrandosi è possibile guadagnare reputazione rispondendo alle domande degli utenti o inserendo nuove domande. La reputazione compare nel nostro profilo, accanto ai badge accumulati.

User list with badges and reputation

I badge sono come delle medaglie e, come tali, si dividono in bronzo, argento ed oro. I badge sono attribuiti in automatico dal sistema a seconda di determinate azioni. Ad esempio, potete vincere il badge Student alla prima domanda con almeno un voto positivo, oppure Supporter al vostro primo voto.

La lista completa dei badge è disponibile sul sito.

The list of available badges

L’attribuzione dei badge è assolutamente meritocratica e dipende esclusivamente dalla vostra abilità e dalle competenze dimostrate nelle domande e nelle risposte, oltre che alla partecipazione alla community.

Ad esempio, potrà vantarsi di avere una medaglia d’oro chi ha pubblicato una risposta ricevendo almeno 100 voti positivi. Difficile? Un po’… ma d’altronde le medaglie d’oro mica le regalano!

Così come i badge, anche la reputazione è meritocratica e dipende esclusivamente da voi e dai voti che riceverete. Ogni voto ricevuto ad una vostra domanda o risposta vale 10 punti. Ogni risposta accettata 15 punti. Ovviamente, anche i voti negativi hanno un peso sulla vostra reputazione.

List of upvotes and downvotes

La reputazione è importante perché vi abilita a nuove funzionalità. Ad esempio, a partire da 100 punti è possibile modificare i post community wiki di chiunque. Con 2000 punti avete accesso all’area di editing di qualsiasi post, con 10000 punti avete accesso all’area di moderazione.

Esatto! Anche i privilegi di moderazione, modifica e gestione sono meritocratici.

Ma Search Marketing Arena è molto altro. Non mi dilungo ulteriormente, vi invito a visitare il sito e cominciare a scrivere le vostre domande o pubblicare risposte a quelle esistenti.

A proposito di scrivere… la lingua ufficiale del sito è l’inglese. E’ stata una scelta discussa ma essenziale dato che il progetto ha come target una utenza internazionale. Siamo consapevoli che molti utenti italiani hanno difficoltà o disagio nello scrivere in inglese, ma non lasciate che questo diventi un ostacolo ad intervenire. Nessuno vi chiederà mai un inglese accademico e ci sarà sempre qualcuno della community pronto a migliorare o correggere le vostre domande.

A nome mio e di Simone, spero che Search Marketing Arena vi appassioni esattamente come lui ed altri progetti simili hanno appassionato noi!

Che aspettate? Siete pronti ad entrare nell’arena?

Related posts:

1. Search Marketing Standard Magazine
2. Blog italiani sul marketing
3. The Search Engine Marketing Weblog va in pensione

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

Il risultato? E’ opinione diffusa che inserire qualche meta tag nelle pagine web qui e là possa far scalare le posizioni dei risultati di una ricerca. Ma è veramente così?

Che cosa sono i meta tag

Prima di addentrarci nello specifico vorrei assicurarmi che tutti abbiate ben presente che cosa sono i meta tag HTML ma, soprattutto, abbiate ben chiaro il loro scopo e le loro specifiche.

Il capitolo Meta data delle specifiche HTML recita

HTML lets authors specify meta data — information about a document rather than document content — in a variety of ways.

For example, to specify the author of a document, one may use the META element as follows:

<META name="Author" content="Dave Raggett">

The META element specifies a property (here “Author”) and assigns a value to it (here “Dave Raggett”).

In altre parole, è possibile descrivere una pagina con dei metadati utilizzando il tag META. Sempre continuando nella lettura, le specifiche indicano la composizione di questo tag ed il suo contenuto.

Semplificando quanto riportato, possiamo affermare che un tag META (aka meta tag) è composto essenzialmente da una coppia di chiave/valore, specificata come attributi del tag. La chiave è contenuta nell’attributo name, il valore corrispondente nell’attributo obbligatorio content.

<META name="Chiave" content="Valore">

Anche se non ci sono particolari restrizioni per quanto riguarda il nome del meta, esistono alcuni nomi oramai standard come Author, Description, Keyword, Copyright…

<META name="Author"      content="Simone Carletti">
<META name="Keyword"     content="keyword, keyword, keyword">
<META name="Description" content="A description.">

Ecco un esempio di meta tag reali, tratti dal codice HTML di una pagina web.

HTTP Equivalent meta tag

Esiste un particolare tipo di meta tag identificato dall’attributo http-equiv. Questo meta, come indicato dalle specifiche, è adottato da client e server per raccogliere informazioni da utilizzare al posto dei rispettivi header HTTP in una richiesta/risposta HTTP.

Ad esempio, il meta tag seguente contiene l’indicazione del charset e della codifica della pagina e può essere utilizzato dal server per impostare l’opportuno header HTTP, in mancanza o in sostituzione ad eventuali header già presenti nell’intestazione di una risposta.

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

Vediamo un altro esempio. L’inserimento del codice seguente all’interno della sezione HEAD di una pagina web provoca il reindirizzamento del browser all’URL indicato dopo il numero di secondi stabilito.

<META http-equiv="refresh" content="5; URL=http://www.simonecarletti.com/directory">

Anche in questo caso, il meta tag non ha lo scopo di descrivere la pagina bensì di istruire un particolare comportamento specifico per la singola richiesta/risposta HTTP.

Specifiche tag META e motori di ricerca

Curiosamente, anche le specifiche HTML menzionano l’uso dei tag meta rispetto ai motori di ricerca. Ecco un estratto.

A common use for META is to specify keywords that a search engine may use to improve the quality of search results. When several META elements provide language-dependent information about a document, search engines may filter on the lang attribute to display search results using the language preferences of the user.

Un lettore distratto potrebbe, preso dall’entusiasmo, affermare quindi che i motori di ricerca calcolino il posizionamento di un sito basandosi sui meta tag. In realtà, è importante notare l’uso del verbo may (NdR. che in italiano significa potrebbero) proprio per indicare che non necessariamente questa è la strategia adottata.

Tag TITLE

Il tag TITLE non corrisponde ad un vero e proprio meta tag, tuttavia vale la pena menzionarlo in questo articolo poiché la sua presenza, come vedremo in seguito, è rilevante in una strategia di search engine optimization.

Il tag TITLE indica il titolo della pagina web e va inserito nella sezione HEAD di una pagina HTML. Normalmente il suo contenuto viene inserito come titolo della finestra del browser.

I meta tag non sono uno strumento magico

Già nel 2007 Danny Sullivan scriveva che i meta tag non sono una soluzione magica. Pensare che le keyword inserite nel meta tag keywords possano farci balzare nelle prime posizioni è errato e controproducente. Nella maggior parte dei casi i meta tag possono aiutarci a controllare come una pagina viene indicizzata dai motori di ricerca, in altri casi possono addirittura prevenirne l’indicizzazione.

I primi algoritmi dei motori di ricerca erano estremamente semplici. Per comodità, o mancanza di alternative, i meta tag erano uno dei primi elementi a disposizione per analizzare e descrivere il contenuto di una pagina. Non è un segreto che i primi algoritmi attribuissero una forte rilevanza a questi elementi.

Ben presto i programmatori si scontrarono con la realtà dei fatti. Dare troppa libertà ai webmaster, affidarsi ciecamente a quanto inserito all’interno delle pagine, soprattutto se nascosto agli occhi dei normali utenti, non garantiva una qualità dei risultati.
Per questo motivo, il peso dei meta tag negli algoritmi di posizionamento cominciò a diminuire fino ad arrivare, nella maggior parte dei casi, ad essere completamente inutile.

Ma è bene non fare di tutta l’erba un fascio. Mentre da una parte meta tag storici hanno perso utilità, come il meta tag keywords, dall’altra gli stessi motori di ricerca hanno introdotto meta tag a loro discrezione per specifici scopi. E’ altrettanto importante ricordare che non tutti gli algoritmi ragionano in ugual modo: ciò che vale per alcuni motori di ricerca potrebbe non essere valido per altri, come dimostra la tabella pubblicata su Search Engine Watch qualche anno fa o il più recente articolo sul supporto all’attributo nofollow.

Vediamo allora quali sono i meta tag che ancora contano e quelli che, invece, hanno perso valore.

I meta tag che (ancora) contano

Tag title

Il tag TITLE (non è un meta, vedi paragrafo ad inizio post) è probabilmente il tag più influente sul posizionamento tra tutti quelli citati in questo contesto. Spesso è possibile scalare posizioni semplicemente studiando un titolo adeguato per la pagina, in tema con i contenuti e correttamente inserito nel contesto del sito.

Il tag TITLE non è l’unico fattore che incide sul posizionamento. Non si pensi dunque che il solo inserimento di keyword ad alta competitività nel titolo di una pagina possa garantire il posizionamento della pagina stessa.
Tuttavia, per siti che godono di una buona visibilità è particolarmente facile sfruttare il contenuto di questo tag per posizionare specifiche keyword.

Inizialmente era fondamentale l’ordine nel quale i termini comparivano all’interno di questo tag. Scrivere un titolo come Analisi dei motori di ricerca non aveva la stessa rilevanza di Simonecarletti.com - Analisi nuda e cruda senza fronzoli del funzionamento di un motore di ricerca. I motivi sono facilmente intuibili:

• Posizione dei termini all’interno della frase
• Prossimità dei termini tra loro
• Uso di preposizioni e termini ignorati (stopwords)

L’evoluzione di motori di ricerca ha profondamente modificato il comportamento alla base del tag TITLE. Molti algoritmi ora considerano sinomini, termini correlati e la posizione o prossimità non sono più fattori determinanti.
Non è raro, ad esempio, che alcune pagine siano posizionate con termini solo parzialmente presenti nel titolo, anche se si tratta di keyword molto competitive.

Il contenuto del tag title non è utile solo ai motori di ricerca ma anche (e soprattutto) agli utenti. Il suo contenuto è visualizzato nelle finestre dei browser. Inserire un titolo come loading..., homepage o peggio ancora ignorarlo limita l’usabilità della pagina.
Inoltre, un titolo adeguato può influenzare la scelta di un utente e motivarlo a selezionare il nostro sito tra i risultati di ricerca anche se la nostra posizione è successiva ad altri risultati meno accattivanti. Ad esempio, quale risultato secondo voi cattura maggiormente l’attenzione nello screenshot seguente?

Data l’importanza di questo elemento ritengo opportuno citare l’ottimo articolo Ottimizzare il Title tag: tecniche avanzate scritto da Maurizio, contenente consigli e suggerimenti per ottimizzare il tag TITLE.

Meta tag description

Il meta tag description è un altro meta tag che merita attenzione. Per molti corrisponde all’unico meta tag influente, insieme al tag TITLE, se si escludono i meta specifici introdotti dai motori di ricerca.

Questo elemento svolge un ruolo spesso fondamentale: quando presente ed in tema con il resto della pagina, il suo contenuto è utilizzato dai principali motori di ricerca per generare la mini descrizione mostrata per ogni sito nella pagina dei risultati di una ricerca. In gergo, questa descrizione è chiamata snippet.

E’ opinione diffusa che anche il meta tag description possa favorire il posizionamento. L’origine di questa supposizione deriva dalla presenza di numerose pagine ben posizionate per termini di ricerca non contenuti nel title ma nella description. In realtà, questo comportamento è conseguenza dell’evoluzione degli algoritmi dei motori di ricerca già discussa nella sezione precedente.
Solo Google ad oggi ha ufficialmente smentito una qualche influenza del meta tag description nel posizionamento.

Torniamo alla descrizione nella pagina dei risultati. Un buon snippet ha una lunghezza massima, in genere consigliata intorno ai 160 caratteri, termina con un punto e costituisce una descrizione semplice e concisa del contenuto della pagina.

I motori di ricerca adottano diverse strategie per selezionare il contenuto di uno snippet. Candidati per questo processo sono, in ordine di priorità:

1. Il contenuto del meta tag description
2. Il contenuto della descrizione del sito in Dmoz
3. Un’elaborazione automatica del contenuto della pagina

Come per il tag TITLE, online è possibile trovare numerose risorse su come ottenere una buona descrizione. Ecco ad esempio un valido contributo da Google: Improve snippets with a meta description makeover.

A conferma dell’importanza di una buona description segnalo due approfondimenti interessanti scritti da Francesco de Francesco (fradefra), dal titolo Una buona description aumenta le visite e Comunicazione SERP/Sito/Articolo.

Meta tag robots

Il meta tag robots è uno di quei meta specifici per i crawler dei motori di ricerca. A differenza di altri, questo meta tag non solo è considerato dagli algoritmi di indicizzazione ma può anche modificare radicalmente il comportamento e la presenza di una pagina nei risultati di una ricerca.

Il suo contenuto è una lista di termini separata da virgola, di norma minuscoli, ciascuno corrispondente ad uno specifico comportamento.

noindex

indica di non indicizzare la pagina.

nofollow

indica di non seguire i collegamenti all’interno della pagina.

nosnippet

indica di non mostrare una descrizione per la pagina nei risultati delle ricerche.

noarchive

indica di non salvare una copia cache della pagina.

noodp

indica di non utilizzare la descrizione di Dmoz nei risultati delle ricerche, anche se presente.

I principali motori di ricerca — Google, Microsoft e Yahoo! — hanno siglato un accordo per supportare le direttive sopra indicate. Tuttavia, in alcuni casi il risultato sui motori di ricerca potrebbe variare leggermente.

Il comando noodp è stato l’ultimo ad essere approvato. Proposto da Microsoft, è poi stato adottato da Yahoo! ed infine da Google, come descritto da Matt Cutts.

Ecco un esempio di singola direttiva

<META name="robots" content="noindex">

ed uno con più direttive.

<META name="robots" content="noindex, nofollow">

L’impostazione predefinita per ciascun tag è il comportamento inverso di quanto indicato sopra. In alcuni casi potreste vedere meta tag come il seguente.

<META name="robots" content="index, follow">

Quest’ultimo è del tutto inutile poiché, salvo diversa indicazione, i crawler seguiranno ed indicizzeranno ogni pagina disponibile.

Meta tag Speciali

Rientrano in questa categoria alcuni meta tag con funzioni specifiche, spesso supportate da un solo motore di ricerca o servizio.

E’ questo il caso del meta tag verification, nome di battesimo verify-v1, introdotto nel 2006 da Google per permettere ai webmaster di validare un sito web nel pannello di controllo Google Webmaster Tools senza ricorrere all’apposito file di verifica.

<META name="verify-v1" content="unique-string">

Il contenuto di unique-string è una stringa fornita da Google, unica per ogni Google Account.

Il mito del meta tag keywords

Il meta tag keywords è senza dubbio uno dei più discussi in ambito SEO. In principio, lo scopo di questo meta tag era contenere una lista di parole chiave identificative per la pagina. I primi motori di ricerca testuali, parliamo degli anni tra il 1996 ed il 2000, utilizzavano il contenuto di questo tag per attribuire una correlazione tra le ricerche degli utenti ed i risultati mostrati.

Ad oggi questo meta tag è ignorato dalla maggior parte dei motori di ricerca evoluti. Gli algoritmi di posizionamento si basano infatti sull’analisi del testo delle pagine e di altri fattori, normalmente meno soggetti a falsificazioni. Non è un mistero che Google da tempo ignori questo tag, come confermato recentemente proprio sul blog dedicato ai webmaster. Curiosamente, le linee guida di Yahoo! contengono invece un riferimento a questo meta.

Tra tutte le risorse disponibili, particolarmente significativi sono gli articoli Death Of A Meta Tag e Revisiting Meta Tags dove, già nel lontano 2001, Danny Sullivan testimoniava la morte di questo meta tag.

Concludo questa sezione dedicata al meta tag keyword con una citazione, ancora una volta da un articolo di Danny Sullivan, che da sola vale l’intero articolo:

I’m using all these capital letters on purpose. Far too many people new to search engine optimization obsess with the meta keywords tag. FEW crawlers support it. For those that do, it MIGHT! MAYBE! PERHAPS! POSSIBLY! BUT WITH NO GUARANTEE! help improve the ranking of your page. It also may very well do nothing for your page at all. In fact, repeat a particular word too often in a meta keywords tag and you could actually harm your page’s chances of ranking well. Because of this, I strongly suggest that those new to search engine optimization not even worry about the tag at all.

Even those who are experienced in search engine optimization may decide it is no longer worth using the tags. Search Engine Watch doesn’t. Any meta keywords tags you find in the site were written in the past, when the keywords tag was more important. There’s no harm in leaving up existing tags you may have written, but going forward, writing new tags probably isn’t worth the trouble.

La truffa dei meta tag

In questo articolo non potevo ignorare il recente fenomeno che ha visto la crescita e lo sviluppo di decine di agenzie SEO che offrono sedicenti (e seducenti) attività di Search Engine Optimization a prezzi stracciati, per non dire assurdi.

In molti casi, il prezzo è talmente basso che dovrebbe far riflettere. Se un idraulico che viene a casa mia prende 100€ all’ora, come è possibile realizzare un’attività SEO di qualità con 10€, 20€ o 50€? Come è possibile promuovere un sito in 30 minuti?!?

Purtroppo la realtà dei fatti è che sempre maggior utenti cadono in queste bufale mostruose che promettono attività SEO mirate al posizionamento miracoloso di una serie di keyword.
In molti casi, l’attività si riduce a qualcosa di più che una segnalazione del sito ai motori di ricerca (NdR. Il classico “add URL” che potete fare voi stessi manualmente e gratis) e all’inserimento di qualche meta tag farcito di keyword. Si va dalla modifica dell’homepage per le offerte più basse fino alla generazione, in molti casi automatica, dei meta tag per un gruppo di pagine del sito indicate dal webmaster come le più importanti.

In questi anni ho assistito alle scene più assurde. Piattaforme che, come dei distributori automatici, richiedono un pagamento per poi fornire in tempo reale codice HTML da incollare nelle pagine del sito costituito unicamente da meta tag keywords. Oltre al danno anche la beffa, considerando che quasi sempre non viene suggerito il tag description o quest’ultimo è una frase presa a caso dalla pagina.

Diffidate di questi servizi! In molti casi, per non dire sempre, si tratta di bufale, raggiri o truffe.

Sindrome da meta tag

Il numero di miti e domande più o meno inutili sui meta tag credo che sia secondo solo a quelle sull’argomento PageRank. Anche in questo caso, qualche ricerca online può facilmente restituire dubbi esistenziali come Can a META Description Kill Your Rankings? o What’s the Cutoff Length for Meta Tags?, per poi arrivare ad affermazioni come Sicuramente i metatag servono per il posizionamento visto che alla fine sono un posto in più dove scrivere parole chiave.

Molti di questi dubbi non hanno mai avuto una risposta ufficiale e mai l’avranno. Ma ce n’è veramente bisogno? Per chi in cuor suo ha risposto di sì, credo che la motivazione possa risiedere esclusivamente nella volontà di spingersi sempre oltre, arrivando in alcuni casi a scrivere orrori simili a questo.
La decenza e la naturalezza sarebbero spesso due limiti più che adeguati nel campo della search engine optimization ma chi è disposto a rinunciare a due lettere in più… quando si possono avere?!? Quasi come se due lettere potessero fare la differenza, quando guardando bene il sito spesso si trovano altri errori macroscopici il cui effetto è tanto devastante quanto ignorato.

In altri casi, la risposta proprio non c’è come se qualsiasi cosa dovesse per forza avere un risvolto. E’ come quando, davanti ai tentativi di interpretazione del mistico sorriso di Monna Lisa, mi chiedo se veramente Leonardo si fosse fatto tutte queste seghe mentali prima di dipingere il quadro. (*)

La sete di conoscenza è parte della natura umana e non mi sento nella posizione di criticarla. Tuttavia, ritengo che qualche volta sia utile chiedersi se veramente una domanda ha motivo di avere una risposta e, soprattutto, quale siano il reale valore e la priorità di questa risposta.

(*) A tal proposito ho un aneddoto di vita reale molto calzante ma per questo dovrete aspettare un prossimo post.

Approfondimenti

Il materiale disponibile online riguardo ai meta tag è sterminato. Tra le tonnellate di link ed articoli raccolti nel tempo, ve ne segnalo alcuni che credo possano offrire altri spunti interessanti… se a questo punto dell’articolo ancora ve ne mancano!

Si comincia da Is Your Search Result Sexy? dove Aaron Wall analizza alcune buone abitudini da tenere in considerazione per rendere la nostra posizione nei motori di ricerca… più accattivante!

Passiamo alle curiosità. Recentemente, una corte di giustizia americana ha emesso una sentenza decretando che l’uso di termini protetti da copyright nei meta tag può costituire una violazione delle leggi in materia di marchi registrati. La vicenda si è poi conclusa con un contrordine, decretando che il contenuto del meta tag keyword non è rilevante.

Non poteva mancare Matt Cutts, il suo blog è una miniera d’oro in questo campo. Questa volta mi limito a citare un solo articolo, dal titolo What should NOINDEX do?, contenente un’analisi del comportamento dei motori di ricerca in caso di meta tag NOINDEX.

In conclusione

Ora che siamo più consapevoli dell’utilità dei meta tag, resta da decidere come comportarci con le nostre pagine. Inutile a dirlo, anche a questa domanda esistono decine di risposte differenti.

Basta farsi un giro tra i principali forum SEO per imbattersi in discussioni come questa, dove esponenti di spicco del mondo SEO si presentano con opinioni completamente differenti. Che chi si limita ad inserire solo quelli essenziali, chi per scrupolo li inserisce tutti, chi ne esclude appositamente qualcuno (spesso keywords) per evitare di dare l’impressione che sul sito avvengano attività SEO.

Una delle conclusioni che più apprezzo su questo argomento è quella scritta da Andrea Vit qualche settimana fa nel suo post Meta tag keywords: SEO troppo paranoici, non abbiate paura.

Sebbene sono in molti a pensare che il meta tag keywords non debba essere inserito nelle pagine poichè potrebbe ‘insospettire’ il motore per il possibile utilizzo di tecniche ‘spammose’ o di keywords stuffing, io ritengo invece che avrebbe ancora ragione d’esistere, anche se non direttamente per scopi SEO.

Pensiamo, ad esempio, agli strumenti di ricerca interna di un sito. Potrebbe essere utilizzare le parole chiave inserite nel meta tag per raffinare le ricerche e renderle maggiormente puntuali.

Al di là del riferimento diretto all’uso del meta tag keyword, del quale onestamente ho scelto di disinteressarmi da tempo, condivido con Andrea la considerazione sull’importanza di adottare uno strumento prima di tutto per la sua utilità, indipendentemente da eventuali miti o preconcetti..

In altre parole, qualsiasi sia la vostra scelta siate consapevoli quando utilizzate un meta tag del suo vero compito e delle sue reali potenzialità, diffidate dai falsi miti e dalle credenze popolari.

Related posts:

1. Miti e leggende SEO #1 – Google ama le pagine statiche
2. Miti e leggende SEO #3 – I motori di ricerca non leggono JavaScript e CSS
3. Influenza degli include nel posizionamento

Che cosa significa che un motore di ricerca ama le pagine HTML? Rispetto a cosa? L’affermazione potrebbe essere interpretata in molti modi:

1. Il motore di ricerca preferisce pagine con codice HTML, rispetto a quelle con codice PHP o ASP.
2. Il motore di ricerca preferisce pagine con contenuto HTML, rispetto a contenuti immagini o Flash.
3. Il motore di ricerca preferisce pagine che sembrano scritte in HTML, rispetto a pagine dinamiche.
4. … altro?

Da sola, un’affermazione con più interpretazioni è destinata a diventare un mito. Nel momento stesso in cui ci si esprime in un modo non chiaramente interpretabile, ecco che chiunque ascolterà l’intervento confezionerà l’affermazione con una sfumatura personale che non necessariamente corrisponde esattamente a quello che si intendeva dire.

Prima di proseguire nell’articolo ritengo utile una precisazione, doverosa a seguito del commento di Libero Guerra e dell’articolo Google preferisce le pagine HTML pubblicato da Jonnie come promesso.
In questo articolo utilizzerò i termini pagine HTML e pagine statiche quasi come sinonimo, in contrapposizione alle pagine dinamiche scritte con un linguaggio server side. E’ indubbio che i crawler web preferiscano le pagine HTML intese come quelle servite con content type text/html, nonché a seguire eventuali derivati di content type di natura testuale rispetto a rich content type come audio, video e multimedia in genere. Diverso è il focus di questo articolo, che analizza invece l’affermazione comune che mette a confronto pagine statiche e pagine dinamiche, a parità di content type utilizzato.

Pagine dinamiche vs Pagine statiche

Comunemente, l’affermazione Google ama le pagine HTML è utilizzata per indicare una ipotetica preferenza dei motori di ricerca per le pagine statiche, scritte in puro HTML, senza l’introduzione di linguaggi server side come PHP, Ruby o ASP.
L’ipotesi che i motori di ricerca preferiscano una pagina statica “classica” è figlia di un altro importante mito che vorrei discutere più avanti. Per ora, ci basti essere consapevoli che agli occhi di un crawler una pagina statica non ha particolare preferenza rispetto ad una dinamica.

Linguaggi server side vs HTML

Proseguendo sul mito client side vs server side, l’affermazione i motori di ricerca amano le pagine HTML è spesso sintomo di una scarsa conoscenza del funzionamento di interpretazione di una pagina web.
E’ infatti diffusa la credenza che una pagina scritta con un linguaggio server side possa in qualche modo essere meno digeribile rispetto al classico HTML.

In realtà, non vi è alcuna differenza. Ogni pagina web, sia essa scritta in qualsiasi linguaggio server side, restituisce come output codice HTML o, al massimo, markup equivalente come XML o XHTML. Le istruzioni server side sono tali poiché vengono elaborate dal server prima che la pagina sia restituita all’utente e al client arriva esclusivamente l’output dell’elaborazione.

L’uso di un linguaggio come ASP o PHP, dunque, non influisce in alcun modo sul codice HTML restituito. Semplicemente, l’utilizzo di una tecnologia server side estende la possibilità di creare pagine web ad elevata interazione, con una memoria e la capacità di reagire in modo differente a seconda della richiesta inviata.

Lo screenshot seguente dimostra come una pagina HTML ed una PHP producano esattamente lo stesso output.

Poiché, in fin dei conti, una pagina “dinamica” produce lo stesso output di una pagina “statica”, sotto questo punto di vista non ha ragione di esistere alcuna preferenza.

E’ possibile individuare con precisione una pagina statica?

Se ancora non foste convinti di quanto discusso nei paragrafi precedenti, cerchiamo ora di immedesimarci in un motore di ricerca e ipotizziamo di voler attribuire una preferenza ad una pagina statica.
Per procedere dobbiamo innanzi tutto riconoscere una pagina statica, al fine di poterla premiare. Ma è possibile?

Con i moderni web server, la possibilità di stabilire se la pagina richiesta sia statica o dinamica è pressoché inesistente, a meno di non aver accesso fisico alla macchina e verificare con mano la presenza del file.
Ci sono elementi indicatori in grado di offrirci un qualche suggerimento, ma ognuno di questi può essere falsato o invalidato.

L’estensione della pagina

Partiamo dall’estensione del file. Sebbene siamo abituati a pensare all’estensione come elemento rappresentativo del tipo e contenuto del file, l’estensione è solamente indicativa.
Ci sono siti dove la condigurazione del server nasconde completamente l’estensione. Ne sono un esempio i blog PHP basati su WordPress come Edit dove il permalink di ogni post, ad esempio questo, non ha estensione.

Un altro esempio è il sito del programma ASP Stats, scritto in Ruby. Eppure, nessuna pagina ha estensione .rb.

Ci sono poi i casi in cui l’estensione c’è ma non corrisponde ad alcun linguaggio o, addirittura, ad un linguaggio differente. Proprio a causa del mito prima descritto, in passato ci sono stati migliaia di siti le cui pagine contenevano l’estensione .html pur essendo scritti in linguaggi server side come PHP.

L’estensione non è vincolante.

Header HTTP

L’analisi degli header HTTP di una pagina costituisce un altro indizio fondamentale per tentare di individuare una pagina statica ma, ancora una volta, non offrono alcuna garanzia.
Alcuni header sono più “complessi” da manipolare e spesso la loro presenza indica una pagina statica, ma questo non significa che non sia possibile inserirli volutamente restituendo una pagina con un linguaggio server-side.

Prendiamo ad esempio la seguente risposta HTTP, restituita in richiesta ad una pagina statica (ne sono certo, l’ho scritta io!).

Date: Sat, 20 Sep 2008 14:37:34 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 Phusion_Passenger/2.0.3 DAV/2 SVN/1.4.2
Last-Modified: Sat, 16 Feb 2008 22:14:45 GMT
Etag: "2524778-134a-d9a8ff40"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2025
Content-Type: text/html

200 OK

Le chiavi più significative sono quelle che ho formattato in grassetto. Per il significato di ciascun header consiglio la lettura delle specifiche del protocollo HTTP.

Content-Length e Etag sono soliti indicare un’alta probabilità che una pagina sia statica. Questo perché, di norma, in presenza di una pagina statica il web server ne conosce il peso in byte con assoluta certezza e lo può indicare: la pagina esiste, al contrario di una server side non subirà modifiche prima di essere restituita al client.
Ad ogni modo, questo non mi impedisce di calcolare il peso di una pagina server side in fase di elaborazione e falsare l’header.
In PHP è possibile catturare l’output usando un buffer e la funzione ob_start per poi scrivere l’header con header.

L’header Etag è un altro elemento indicativo. Rappresenta univocamente una determinata risorsa all’interno del sito e, anche in questo caso, è normalmente aggiunta in automatico dai web server in quanto una pagina statica è facilmente rappresentabile in modo univoco.
Rappresentare una pagina dinamica richiede la generazione di un hash univoco per il suo contenuto, ma questo non è un problema così insormontabile.
Rails, ad esempio, permette di generare l’Etag per una risposta in modo quasi banale, assegnando un oggetto di riferimento all’oggetto Response.

>class ArticlesController < ApplicationController

def show
@article = Article.find(params[:id])

# Set the response headers to accurately reflect the state of the
# requested object(s)
response.last_modified = @article.published_at.utc
response.etag = @article

# .. continue
end
end

Come potete vedere, in questo esempio l’Etag è generato in automatico a partire da un array di oggetti Article. Fin tanto che quella pagina conterrà lo stesso array di elementi, il valore di Etag rimarrà inviariato.

Backlist vs Whitelist

Poichè, come dimostrato, non ci sono elementi certi (whitelist) per definire una pagina statica, in questo caso è più comune adottare il processo inverso (blacklist): possiamo isolare i comportamenti certamente non riconducibili ad una pagina statica ed ottenere con maggiore precisione una lista di pagine verosimilmente statiche.

Ancora una volta si tratta però di un’analisi empirica, particolarmente soggetta a falsi positivi.

In conclusione

Abbiamo dimostrato come l’affermazione che i motori di ricerca preferiscono le pagine HTML sia priva di fontamento per due motivi. Innanzi tutto perché ad oggi non c’è una ragione reale per un comportamento simile, in secondo luogo perché sarebbe difficile stabilire con certezza se la risorsa sia una pagina HTML statica o scritta in un linguaggio server side.

Related posts:

1. Miti e leggende SEO #2 – Meta Tag, Ottimizzazione e Posizionamento
2. Miti e leggende SEO #3 – I motori di ricerca non leggono JavaScript e CSS
3. Influenza degli include nel posizionamento

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

Osservate lo screenshot seguente.

Google indicizza sempre più rapidamente, anche risultati ordinari

In effetti questa non è una vera e propria scoperta, è da tempo che si verifica questo comportamento. Ricordo anche un post molto interessante, intitolato Google Artificially Promotes Recent Web Pages, dove Ionut Alex Chitu metteva in discussione le ultime caratteristiche dell’algoritmo di Google che sembrerebbero addirittura preferire e promuovere i contenuti recenti rispetto a quelli più datati.

Ne è un esempio eclatante il blog che comparve al primo posto il primo gennaio per la ricerca January 1 tcp/ip, come documentato nel post stesso.

Lo screenshot precedente dimostra come un mio post in meno di 3 ore (non ho controllato prima) sia comparso nelle SERP e ben al 3 posto prima di Google stesso. E’ vero, questo blog gode di una particolare popolarità ma si tratta ugualmente di una situazione particolare quella appena descritta.

Ricordo che una volta una certa rapidità nell’indicizzazione era prerogativa solo di Google Blog Search e qualche altro sistema di ricerca specifico, oggi la capacità sembra essere stata estesa anche alla ricerca classica.

Che cos’è un ottimizzatore per motori di ricerca (SEO)?

Scendete di un risultato, dalla terza posizione, nello screenshot precedente. Non notate nulla di strano? Non so voi, ma io non mi ero mai accorto della FAQ Che cos’è un ottimizzatore per motori di ricerca (SEO)? pubblicata nientemeno che sul sito di Google!

Questa pagina da sola risponde e smentisce alcuni dei miti che da tempo circolano negli scantinati dei SEO di quartiere.

Ad esempio, dalla FAQ si evince che Google non sconsiglia ai webmaster di rivolgersi ad agenzie SEO, tantomeno disprezza l’attività di chi svolge questa professione per lavoro. Al contrario, Google suggerisce esclusivamente di diffidare da chi promette risultati in modo poco chiaro, con stratagemmi o peggio ancora, truffe.

Google ribadisce che non è possibile assicurare posizioni e riporta alcune delle tecniche e richieste meno ortodosse che agenzie SEO più o meno quotate hanno rivolto ai propri clienti. Non illudetevi, diverse ancora non hanno cambiato abitudini!

Confesso che mi ha piacevolmente colpito questo consiglio:

Contatta diversi SEO e chiedi se consiglierebbero la società che stai prendendo in considerazione.

Le referenze sono un buon inizio, ma non dicono tutta la verità. Chiedi alla società da quanto tempo è in affari e quanti collaboratori a tempo pieno conta. Se ti vengono fatte pressioni o non ti senti a tuo agio, dai retta alle tue sensazioni e vai sul sicuro: rimanda qualsiasi decisione fino a quando non avrai trovato un’azienda di cui fidarti. Chiedi all’azienda SEO se segnala a Google tutti gli abusi rilevati utilizzando il nostro modulo di reclamo contro lo spamming all’indirizzo http://www.google.com/contact/spamreport.html. Le aziende SEO oneste riportano i siti ingannevoli che rappresentano una violazione delle norme anti-spam di Google.

Tralascio per ovvie ragioni le ultime due frasi. Parliamoci chiaro, le agenzie SEO utilizzano sì il modulo SPAM report di Google, ma nella maggior parte dei casi per segnalare competitor… e non venitemela a raccontare!

A parte questo eccesso di perbuonismo, è ugualmente curioso notare come Google consigli ai clienti di informarsi sull’agenzia alla quale ci si sta rivolgendo. Non solo, Google consiglia di chiedere referenze e di informarsi su quali siano i professionisti che verranno affidati al progetto.

Non più di qualche giorno fa leggevo un articolo sull’argomento, che ribadiva ed ampliava sostanzialmente proprio questi concetti. Un’ottima referenza per scegliere e giudicare una SEO agency… peccato che non riesca a trovare dove cavolo l’abbia salvato! Mamma mia, tra feed, delicious, digg ed amenità varie sono più le volte che mi perdo i link che quella che riesco a trovarli… capita anche a voi?!?

Ad ogni modo, direi che con questa FAQ ufficiale dal sito Google si sfatano altri miti e si punta su un aspetto fondamentale: lasciate da parte gli improvvisati, preferite dei veri professionisti. D’altra parte l’ho sottolineato anche in conclusione del mio video sul SEO:

Seguo il mondo dei motori di ricerca da diversi anni, quando serviva poco per potersi definire un SEO. Oggi l’attività del SEO è molto cambiata ma rimane un lavoro affascinante. Il pericolo, sempre in agguato, è che qualcuno tenti di trasformarla in una moda, improvvisando competenze e professionalità.

Related posts:

1. Anomalie dei motori di ricerca: A Google piace Gigablast
2. Anomalie dei motori di ricerca: Google vs Netscape Search
3. Miti e leggende SEO #3 – I motori di ricerca non leggono JavaScript e CSS

Non aspettatevi (in questo video) ore di interminabili spiegazioni su quale sia la tecnica migliore per comparire ai primi posti.
Obiettivo di questo video è invece fornire in modo chiaro e sintetico, una breve panoramica su cosa consistono le attività di un SEO.

E’ utile sia per gli addetti ai lavori che desiderano offrire ai propri clienti vergini di conoscenza una panoramica sul proprio lavoro, sia a quanti hanno ancora la necessità di chiarirsi le idee.

Non per ultimo, cari colleghi SEO, finalmente avete a disposizione una risposta alla tragica domanda: ma tu, cosa fai esattamente di lavoro?
Invece di lanciarvi in una impresa epica che, nella maggior parte dei casi, fallisce inesorabilmente da oggi in poi potrete rispondere: thò, guardati ‘sto video, faccio questo per campare.

Related posts:

1. Introduzione a ActiveRecord (video)
2. Symfony (video)
3. Versioning: Subversion, CSV, Git e Mercurial (video)

Fermo restando che il progetto di Fabio, che potremmo definire lo Sphinn all’italiana, è molto interessante e credo di averlo già detto o qui o là, ci sono un paio di cosette che potrebbero, a mio modesto parere, essere riviste.

Confesso di non seguire quotidianamente Seo Tribù, in realtà i feed svolgono egregiamente il loro lavoro, ma recentemente ho preso parte ad una discussione. Per far fronte ad alcuni tentativi più o meno palesi di guadagnare un po’ di popolarità, la proposta di Maurizio è stata quella di inibire i commenti anonimi. Proposta immediatamente approvata e messa sul campo.

Non entro nel merito di questa soluzione, che condivido, quello che vorrei discutere è l’argomento autopromozione. Con dispiacere ho notato che un buon 80% dei post pubblicati su Seo Tribù sono in realtà scritti dall’utente stesso. Insomma, post dopo post Seo Tribù rischia di diventare un sito autopromozionale, una bacheca annunci, una succursale dei vari pseudo blog dove chiunque abbia scritto un post è libero di pubblicizzarlo nel web come l’ultima press release delux.

Chi mi conosce da un po’ di tempo sà che, oramai da qualche anno, sono moderatore del forum Web Marketing di HTML.it dove da sempre vige una regola molto ferrea sull’autopromozione che vieta a chiunque, moderatori compresi, di postare link a siti personali anche se in tema. Sebbene in alcuni casi confesso che questa regola sia stata stretta anche a me, ritengo che fino ad oggi abbia risolto molti problemi.

Alla mia proposta di vietare dunque agli utenti di segnalare i propri link c’è chi ha espresso pareri favorevoli e chi è in disaccordo. Vorrei approfittare, tanto non ho stretti limiti su disco, per fornire un po’ di risposte.

Dag scrive:

L’idea è DAVVERO buona, ma come metterla in atto senza stravolgere completamente il cuore di SEO tribu ?
Io credo che se si trattasse di “autopromozione onesta” (utopia?) potrebbe andar bene ugualmente…

Semplicemente basterebbe fornirla come regola ed affidare ad alcuni moderatori il compito di agevolare il rispetto delle regole. Dubito che la piattaforma venga in aiuto in questo senso.

La mia domanda per dag è: qual è l’autopromozione onesta? ;)
Ovviamente ho compreso il senso, ma più avanti c’è una considerazione che aiuterà meglio a comprendere la mia posizione.

seotopic, che ringrazio per il corposo intervento, scrive:

Credo che il vantaggio più importante consiste nel fatto che anche i piccoli blog e quelli meno noti hanno modo di raggiungere determinate fasce di utenti che normalmente non potebbero avere.
Se fosse vietato agli autori di auto segnalare i propri post, i piccoli resterebbero ancora più piccoli e invisibili a vantaggio di chi è più conosciuto.

Questo è il punto cruciale della mia proposta, o meglio, del motivo principale che potrebbe indurre ad escluderla. In realtà io non sono d’accordo. Il movimento SEO in Italia è molto più attivo di tanti altri paesi e, chi più chi meno, ci si conosce e ci si legge e non credo esista un blog minore che non sia letto da qualcuno che goda di maggiore popolarità.

E se così fosse, a questo punto, mi verrebbe da chiedermi… perché! Voglio dire, se voglio parlare di SEO e nessuno sa che esisto mi sa che devo rivedere le mie doti sull’argomento o pensare prima ad imparare piuttosto che apparire.

Non mi pare che del.icio.us abbia avuto successo poiché ognuno segnalava i suoi siti, anzi! Solo ad oggi qualcuno ha capito che forse usarlo (anche) per questo poteva avere un senso, ma vi assicuro che ancora oggi ho scoperto centinaia di siti e meno dell’1% erano autopromozioni.

Non sono molto esperto, ma spesso leggo post su sphin e mi pare che li siano gli stessi autori a segnalare i propri post.

In realtà no, Sphinn punta su un numero estremamente vasto di utenti.

Poi dovrebbero essere gli utenti della community a far si che post spazzatura scompaiano a favore di post interessanti.
Il problema è che siamo in una nicchia; siamo pochi utenti e mancano numeri e automatismi tali da poter equilibrare il sistema

Non mi resta altro da aggiungere, all’affermazione è susseguita direttamente la motivazione che esprime il mio pensiero.

Alla discussione interviene anche Marco, che scrive:

All’inizio di quest’avventura (nascita di SEOtribu) mi sono chiesto per parecchio tempo se fosse etico autosegnalarsi.
Alla fine l’ho fatto con la convinzione che tanto, se il post segnalato non fosse stato importante, non sarebbe mai stato quotato/votato! [...]

E poi guardatela da un altro verso: ci si assume anche un rischio. Se segnalo un mio post tanto per farlo mi sono contemporaneamente sputtanto e col tempo ne paghero’ le conseguenze. Insomma MI segnalo solo perche’ ne sono convinto prendendomi il rischio che non saro’ mai votato e, quindi, anche un po’ danneggiato al livello di immagine.

Il problema a mio avviso, Marco, non è la reale qualità dell’essere presenti o meno, è il link!
Citando qualcuno (non ricordo chi), ci sono pseudo marketers che venderebbero la madre per un link, figuriamoci se si tirerebbero indietro dall’averne pacchi così, gratuitamente. E se poi qualcuno li affonda poco male, tanto hanno un link in più!

Purtroppo ne ho le prove. Se raccontassi tutte le situazioni che ho scovato da quando ho rimosso i nofollow, potrei quasi rischiare di chiedermi se realmente ci sono ancora professionisti nel campo!

E purtroppo non basta un nofollow o qualche richiamo, il rischio è dietro l’angolo.

Per motivare come questo modello senza autopromozione può esistere vi invito a curiosare ad esempio Dzone o reddit. In questi ambiti, meno markettari dove gli utenti della link popularity “se ne infischiano”, come vedete la quantità di autosegnalazioni è molto limitata.

Insomma questo sistema, è possibile anche senza che tu, caro webmaster, sia così “gentile” da propinarmi ogni tuo link. Cosa ne pensate? I commenti sono a vostra disposizione, non vi preoccupate, non vi faccio pagare lo spazio su server.

No related posts.

Il primo si chiama La composizione di un URL. Si tratta di una panoramica dettagliata su tutti gli elementi che compongono una URL, dall’host all’ancora.
All’interno troverete anche alcuni approfondimenti interessanti sulla distinzione tra primo, secondo e terzo livello in un dominio e… sì, www.example.com è un terzo livello!

Il secondo si intitola invece URL statici vs. URL dinamici. Questo post è nato un po’ dalla frustrazione nel continuare a sentire “che ai motori di ricerca non piacciono i siti dinamici“.

La conclusione dell’articolo direi che è sufficiente ad anticiparvi il suo contenuto e solleticarvi l’interesse:

Ah, un’ultima cosa. Se sentite qualcun altro affermare che ai motori di ricerca non piacciono i siti dinamici, per favore, segnalategli questo articolo!

Buona lettura!

PS. la coincidenza vuole che, causa sovrapposizione di pensieri (ergo la pensiamo allo stesso modo), Johnnie abbia pubblicato recentemente alcuni articoli simili come orientamento. Che dire… two is meglio che one!

Related posts:

1. Che cosa gli spider dei motori di ricerca non sanno fare
2. Anomalie dei motori di ricerca: Hotbot ed i domini
3. MSN ha capito che adoro i feed

Obiettivo di questo post non è rispondere a queste domande — cosa? pensavate di sì? — bensì segnalarvi una simpatica proposta di Rhea Drysdale, ovvero quella di riflettere sul vostro Team SEO ideale, il SEO Dream Team.

Detesto i meme (si chiamano così?) ma mi piaciono le idee simpatiche, creative e quelle originali.

Non sono stato taggato (ma questo non è un meme, giusto?), non dovete sentirvi taggati per intervenire, ma poiché mi piace conoscere i colleghi (qualcuno li chiama competitor) in questo campo vorrei rigirare la frittata all’italiana e proporre il mio Italian SEO Dream Team.
Per autoregolarmi, prenderò a modello i parametri imposti da Rhea che includono

• Puoi includere fino a sette persone, ma non è necessario averne sette
• Puoi semplicemente elencare i nomi o assegnare loro una posizione
• — (Nrd. Questa è da meme, la autoescludo)
• — (Ndr. Vedi sopra)

Il mio team SEO ideale

Non è facile scegliere un team SEO ideale, posso assicurarvi di averci provato e di potervelo testimoniare.
I veri SEO in Italia non sono molti, ma quanto si tratta di scegliere rischiano anche di essere troppi! :P

Così, il team che segue è il mio SEO Dream Team basato su quelle che oggigiorno vedo come necessità reali data l’evoluzione dei motori di ricerca.

Enrico Altavilla, Research and Development

Chi mi conosce sa bene che ho per Enrico stima ed ammirazione.
Lo ritengo una delle persone in assoluto più preparate nel nostro settore, qualcuno che parla per ricerca e non per sentito dire.

Certo, anche lui ha i suoi aspetti negativi… ad esempio, gli piace Milano!

Simone Rinzivillo, SEO Specialist & Developer

Ho lavorato con Simone per oltre un anno ed è stato un vero piacere.
Simone ha un’ottima propensione per il lavoro in team, giusto senso critico e sa anche tirare fuori idee e spunti di riflessioni intelligenti… anche troppo, qualche volta mi sono anche chiesto se quello che bevevamo insieme al mattino fosse caffé o altro!

Johnnie Maneiro, SEO Evangelist & Creative Director

Dopo la sua presentazione al SES di Milano, quest’anno, non ho più dubbi sulle capacità di Johhnie.

Mi piace la sua capacità di chiacchierare suscitando argomenti discussione, così come la sua originalità ed il gusto creativo. Ammiro la capacità di infilare assieme 4 direttive CSS e creare un layout semplice ma accattivante.

Benedetto Colicci, Analytics & Search Engine Marketing

Benedetto è una mix interessante per un team SEO poiché le sue conoscente nell’ambiente lo rendono capace di intervenire in modo coerente nelle attività di ottimizzazione, tuttavia le sue competenze abbracciano più facilmente i temi della Web Analytics, Keyword Advertising ed altri rami del Search Engine Marketing.

In aggiunta, un apporto di competenze di programmazione e sviluppo fanno sempre comodo, soprattutto se legate a servizi come API o Bid Management.

Maurizio Petrone, Social Media Manager

Qualcuno lo ha definito “una delle ultime vere new entry del SEO” e devo dire che non aveva tutti i torti.
Particolarmente interessanti i suoi interventi sul tema dei social media, dall’analisi dell’algoritmo di Digg ad alcune interessanti riflessioni sui social network.

Piersante Paneghel, Free player

Di certo Free Player non rende la stessa idea come Battitore Libero, ma direi che il senso è sufficiente.

Piersante è uno di quelli che io definisco “un personaggio”. SEO tradizionale (o tradizionalista), sviluppatore e ricercatore.
E, per finire, il giusto spirito gogliardico che non fa mai male!

NewBie

Poiché il SEO non è una professione che si impara a scuola, ma la vera scuola è il lavoro (come sono filosofico…), ritengo fondamentale che le aziende concedano l’opportunità, a chi vuole crescere ed ha le caratteristiche per farlo, di imparare sul campo.

Così, la settima figura non è definita, mi piace pensarla come un posto disponibile a tutti gli aspiranti SEO con le competenze e le caratteristiche per crescere in questo settore.
E se nessun aspirante è in vista, la lista di persone che inserirei in questo team comprende ancora almeno una decina di figure. :)

Il tuo SEO Dream Team?

Come detto in apertura, non mi piaciono i meme, tuttavia questo non mi esula dalla possibilità di rilanciare ad altri l’invito di pubblicare il proprio (Italian) SEO Dream Team!

No related posts.