Cosa gli spider dei motori di ricerca non sanno fare

Search Engine Strategies, forum SEO e blog sul posizionamento: non c'è un'occasione dove non si senta parlare, o non si legga, delle caratteristiche dei motori di ricerca, delle regole da seguire per una corretta indicizzazione e dei suggerimenti da tenere in considerazione.

Sebbene questi elementi siano in realtà la sostanza di un corretto posizionamento, è bene considerare che si tratta del risultato dell'interpretazione delle capacità dei crawler dei motori di ricerca.
Mi spiego meglio.

Si sente spesso che è importante limitare il numero di parametri in querystring al fine di garantire la corretta indicizzazione della pagina web. Perchè?
La risposta è tutto sommato semplice e deriva da alcune limitazioni dei crawler meno evoluti che potrebbero incappare in loop o duplicazioni automatiche a causa di eccessivi parametri o una configurazione errata del sito web. Risultato? Le pagine non verranno indicizzate.

Insomma, praticamente ogni buona regola per una corretta indicizzazione deriva da quello che i crawler dei motori di ricerca sanno e non sanno fare.
Giusto! Ma allora, cosa non sanno fare i motori di ricerca, oggi?
Andiamo a scoprire alcune limitazioni, desiderate o indesiderate, dei crawler. Conoscerle ci aiuterà a progettare meglio un sito web ed agevolare l'indicizzazione.

Gestire i Cookie

I motori di ricerca non sanno gestire i cookie o, più semplicemente, gestirli potrebbe non risultare così interessante agli occhi dei motori di ricerca.

Ogni qual volta che il crawler accede ad una pagina del vostro sito ogni cookie inviato scade nell'esatto momento in cui termina la richiesta del crawler, indipendentemente che si tratti di un cookie di sessione o di un cookie datato.
Ogni successiva richiesta del crawler non conterrà traccia dei cookie precedentemente inviati e quindi sono sarà possibile risalire a proprietà precedentemente impostate.

In pratica, i crawler non potranno quindi portare avanti un processo di acquisto in un e-commerse se il carrello è gestito via cookie (beh, dubito comunque che sia di vostro interesse un acquisto da GoogleBot), così come non potranno seguire percorsi di navigazione alternativi basati sull'ultima connessione dell'utente, ovviamente se salvata nei cookie.

In sintesi

Data questa limitazione è bene non affidare ai cookie dati che possano limitare la navigazione del sito.
Ad esempio, implementare un controllo sulla capacità di gestire i cookie ed inviare il client ad una pagina di errore se il controllo fallisce non è certo una soluzione utile. Qualsiasi crawler di un motore di ricerca finirà sempre, inesorabilmente, nella pagina di errore ed il vostro fantastico sito da 10.000.000 di pagine non verrà neanche visto di striscio!

Gestire le Sessioni

L'argomento sessioni è tutt'altro che banale. Prima di procedere è bene chiarire brevemente il valore delle sessioni ed il loro funzionamento.

Il funzionamento della sessione

Poiché il protocollo HTTP è senza stato, ovvero non conserva alcuna informazione tra una richiesta e l'altra, per poter garantire interazioni avanzate tra utenti e siti web, come una transazione di commercio elettronico, è stato neceessario introdurre il concetto di sessione.
Ogni qual volta vi connettete ad un sito web, il web server che lo gestisce genera un identificativo univoco chiamato ID di sessione che vi rappresenterà per un limitato periodo di tempo.
In questo modo, sarà possibile associare alla vostra sessione una serie di dati caratterizzanti, come ad esempio il vostro nome utente se siete autenticati nel sito, oppure la lingua preferita per permettervi di navigare agevolmente su un sito tradotto in più versioni.

Ora arriviamo al punto cruciale: nella maggior parte dei casi, anzi praticamente sempre, i crawler non sanno gestire le sessioni.
Il motivo è sostanzialmente una conseguenza dell'incapacità di usare i cookie e della natura multi-threading dei crawler.
Vediamo insieme cosa significa.

L'ID di sessione, generato dal server, deve essere salvato dal client in qualche modo.
Il modo predefinito è un cookie, un semplice cookie che contiene l'ID univoco e scade al termine della sessione stessa, in genere 20 minuti.
Poiché abbiamo appena visto che i crawler non sanno gestire i cookie, la sessione non può essere salvata e di conseguenza i crawler non sanno gestire le sessioni.

Esiste un'alternativa. Nel caso in cui il web server si accorga che il client non è in grado di gestire i cookie, può essere configurato in modo da appendere l'identificativo di sessione ad ogni URL richiamata nel sito. Ecco alcuni esempi di session ID generata in Java:

Ed ecco un esempio per PHP:

Problema risolto? Al contrario!
Passare la Session ID via querystring è uno degli errori più grandi che possono penalizzare un sito web nella fase di indicizzazione.
Vediamo perché.

Passare l'ID di sessione in querystring è pericoloso!

La SessionID è univoca per ogni sessione utente, giusto? Quindi se io mi connetto 5 volte in 5 giorni avrò 5 session ID differenti.
Se un crawler si connette 10 volte a questo indirizzo

gli verranno assegnate 10 session ID differenti, a meno di non conservarne una arrivando da un link con una session ID in querystring.
Andiamo avanti nel ragionamento.

I crawler supportano il multi threading. Ovvero, potreste trovarvi sul vostro sito un singolo crawler così come 15 crawler contemporaneamente che analizzano 15 aree differenti.

Ora è il momento dei conti. Se io ho 15 istanze di GoogleBot contemporaneamente sul mio sito, ognuna delle quali genera una media di 10 sessioni id differenti ipotizzando che non arrivi da una pagina con id di sessione, avrò che il web server genererà ben 150 id di sessione differenti solo per Google e solo in pochi minuti.

Ma a questo punto, ecco che la mia pagina

se io passo in querystring il valore della sessione potrebbe trasformarsi in

ed altre 145 versioni differenti!
Una pagina per 145 (ed oltre) indirizzi: è un attimo che un crawler non evoluto identifichi (erroneamente) il sito come contenuti duplicati ed escluda le pagine dal processo di indicizzazione.

Potrei portarvi almeno una decina di esempi che vi dimostrano quest'affermazione ma trattandosi di clienti ho qualche limitazione.
Ad ogni modo fate una prova. Scegliete dei siti che passano la session id in querystring e dei quali conoscete precisamente il numero di pagine da cui sono composti.
Eseguite una ricerca in Google per identificare il numero di pagine indicizzate e confrontatelo con il numero di pagine totali. Quasi sicuramente sarà minore!

In Sintesi

Nella quasi totalità dei casi, per un motivo o per l'altro, i crawler non supportano le sessioni e dunque qualsiasi valore salvato in una sessione precedente viene perso È bene non affidare alle sessioni, così come ai cookie, elementi determinanti per la navigazione del sito.

Ad esempio, salvare la lingua scelta in una sessione e portare l'utente sempre sulla stessa pagina modellandola in base alle preferenze è un comportamento che può causare l'impossibilità del crawler di analizzare la pagina.

Interpretare JavaScript

Arriviamo alla fatidica domanda: i crawler leggono JavaScript?

Consapevole che generalizzare è difficile, ad ogni modo la risposta è SI.
Avete letto bene, la risposta è sì soprattutto se si parla di crawler più evoluti come quello di Google.
Attenzione bene però, ho scritto che i crawler leggono JavaScript ma questo non significa che lo interpretino e lo eseguano.

Sebbene questi 3 termini vengano usati troppo spesso come sinonimi, in realtà non lo sono per nulla.
Chiariamo dunque una volta per tutte la questione, ripeto, consapevoli che ogni crawer ha nel suo piccolo caratteristiche differenti.

I crawler leggono JavaScript

I crawler, in particolare quelli più evoluti come Google, leggono JavaScript molto spesso appositamente.
Sono in grado di leggere i file JavaScript e seguire le relazioni esterne indicate nel tag <script>.

I crawler interpretano JavaScript

Se la lettura di un contenuto JavaScript è prerogativa di un crawler evoluto, la sua interpretazione è caratteristica di un crawler molto evoluto e ad oggi mi risulta che solo Google sappia farlo.
Il motivo alla base di questa scelta è la necessità di individuare tecniche di SPAM, come ad esempio doorway con redirect o l'uso di JavaScript per nascondere testo aggiuntivo agli utenti.

I crawler non eseguono JavaScript

Perché tanta fatica per nulla, direte voi! Leggerlo, interpretarlo ma non eseguirlo.
I crawler non eseguono JavaScript perché nella maggior parte dei casi di tratta di interazioni specificatamente disegnate per un utente che non avrebbero alcuna utilità per il crawler.

In sintesi

Se state cercando di adottare JavaScript per tecniche di SPAM attenzione, potreste non essere così al sicuro.
In alternativa, ricordatevi che qualsiasi funzione deleghiate a JavaScript è probabile che il comportamento non venga eseguito da un crawler di un motore di ricerca.

Leggere Flash

Quante se ne leggono su Flash.
Questo motore lo legge, quel motore lo capisce, quel motore lo desidera... e via dicendo.

Vediamo di sistemare un po' le idee.

Macromedia Flash è un'ottima tecnologia, tuttavia non andrebbe usata per realizzare interi siti web.
Esistono esperimenti più o meno ufficiali da parte dei crawler dei principali motori di ricerca per leggere ed interpretare i file Flash.
Ad esempio, la ricerca su Google per filetype:swf restituisce circa 39.000 risultati.

Analizzando la qualità dei risultati ottenuti è possibile verificare come una parte limitata dei contenuti viene letta, tuttavia subentrano complicazioni come

1. difficoltà nel distinguere i livelli
2. difficoltà nel seguire siti costruiti in un unico filmato
3. difficoltà a separare le informazioni importanti da elementi di navigazione, come ad esempio i bottoni

Le recenti versioni di Flash a partire dalla 8 integrano alcuni accorgimenti utili per agevolare l'analisi da parte dei crawler dei motori di ricerca, tuttavia siamo ben lontati dall'ottenere risultati paragonabili ai classici siti in HTML.

In sintesi

Sebbene la problematica dei filmati Flash sia un aspetto sul quale si stanno concentrando gli sforzi per lo sviluppo di crawler più intelligenti, è bene non creare siti completamente in Flash così come non racchiudere all'interno di file .swf paragrafi di testo o altri contenuti testuali.

Gestire i Frame

Non potevo concludere questa panoramica sulle mancate (o non volute) capacità di un crawler senza citare i frame. Rispetto alle caratteristiche prima citate, i frame non causano particolari problemi ai crawler. Gli spider sono in grado di leggere i frame e, in molti casi, di leggere parte delle pagine collegate.
La vera problematica di quest'architettura è rappresentata dall'esperienza dell'utente.

Ipotizziamo il seguente frameset, salvato nella pagina X.

Il frame carica, in modo predefinito, la pagina PAG.asp associata al menu MENU.html.
Poiché i motori di ricerca difficilmente indicizzano il frameset ma di norma la pagina del corpo, ipotiziamo di essere stati abbastanza fortunati e che PAG.asp sia nelle SERP per qualche parola chiave.
Un utente arriva sulla pagina PAG.asp, senza menu di navigazione... ed ora?

Ebbene sì, l'utente si trova in una pagina, sperduto, senza menu.
Ci sono soluzioni JavaScript in grado di ricaricare automaticamente il frameset in qualsiasi situazione venga aperta una singola pagina, tuttavia la scelta ideale è quella di evitare soluzioni basate su frame.

In Sintesi

Utilizzare pagine con frame è una scelta poco opportuna se l'obiettivo è una corretta indicizzazione del sito ed una positiva esperienza di navigazione dell'utente.
Ci sono tecniche che consentono di ricostruire il frameset anche se vengono aperte pagine interne, tuttavia non tutte le pagine potrebbero essere correttamente indicizzate dai crawler dei motori di ricerca.

In conclusione

Cookie, sessioni, JavaScript, frame e Flash: abbiamo analizzato alcuni degli elementi che i motori di ricerca non sono in grado di gestire o non desiderano gestire.
Sebbene le problematiche prima esposte potrebbero non interessare tutti i crawler, è bene non sfidare la sorte e prepararsi a progettare siti che possano convivere con le limitazioni dei crawler.