-
Questa opera di Enrico Altavilla è concessa in licenza sotto la Licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.
Quiz SEO bastardo numero 6: indicizzazione impossibile
NOTA IMPORTANTE: questo post era stato cancellato per errore e l’ho quindi ricreato manualmente. Purtroppo si son persi i commenti e me ne scuso con gli autori. Potete leggere una copia di questo post comprensiva dei commenti su Archive.org
Il quiz SEO che mi appresto a presentarvi è davvero subdolo e se non siete abituati a questo genere di quiz bastardi vi suggerisco prima di farvi un po’ le ossa con i quiz precedenti.
A differenza dei quiz del passato, stavolta ho pensato di creare una risorsa da usare appositamente come cavia per il quiz e che potrà essere quindi oggetto del vostro studio.
Il quiz
Si afferma che è impossibile che la risorsa all’URL https://www.lowlevel.it/quiz-6/ venga indicizzata da Google Web (l’indice generico web, quindi). In altre parole, la risorsa non verrà aggiunta a tale indice nemmeno in forma parziale e di conseguenza non potrà essere estratta da esso per essere presentata all’utente come risultato di una ricerca. Si chiede al partecipante di determinare se la suddetta affermazione è vera o falsa e, a prescindere dalla risposta data, motivarla.
Le risposte al quiz sono aperte e possono essere date semplicemente commentando questo post. L’obiettivo del quiz è quello di indurre i partecipanti a svolgere un po’ di analisi, che potrebbero costituire un buon ripasso delle tecniche di indicizzazione di Google.
Come di consueto, tra alcuni giorni il quiz verrà chiuso e questo post verrà modificato aggiungendo la risposta esatta e il nome del vincitore/trice.
Buona analisi a tutti! 🙂
La risposta è…
In base ai protocolli esistenti e in particolare al Robots Exclusion Standard e a come e quanto Google vi aderisce, è vero che la risorsa all’URL www.lowlevel.it/quiz-6/ non verrà indicizzata da Google e che non apparirà nelle SERP nemmeno in forma parziale grazie ad una semplice direttiva noindex presente nelle intestazioni HTTP, che viene inviata a tutti i client che mostrano un user-agent contenente il testo “googlebot”.
Ho creato la risorsa in modo che solo i client che si dichiarano Googlebot ricevano il noindex. Si tratta quindi di una forma di erogazione condizionale che si basa sull’user-agent, ovvero una forma di cloaking (che può essere usato anche per finalità diverse dallo spam).
Ecco un esempio di intestazioni HTTP di richiesta della risorsa e di risposta del server:
GET /quiz-6/ HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Host: www.lowlevel.it
Accept: */*
HTTP/1.1 200 OK
Date: Mon, 09 Jul 2012 01:11:32 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
X-Robots-Tag: noindex
Cache-Control: max-age=3600
Expires: Mon, 09 Jul 2012 02:11:32 GMT
Vary: User-Agent,Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html
N.B.: l’indicizzazione è un processo complesso e le fasi in cui si divide sono molteplici e variano da motore a motore. In funzione di ciò, una definizione di “indicizzazione” applicabile a tutti i motori di ricerca non esiste e sarebbe anche corretto fare una distinzione tra “indicizzare i contenuti di una risorsa” e “indicizzare i riferimenti ad una risorsa”, che sono due cose diverse. Per semplicità di cose, il quiz ha usato l’espressione “indicizzare una risorsa” nella sua accezione letterale e generica, ovvero inserire i suoi contenuti in un indice.
Depistaggi
Considero il cloaking la prima forma di depistaggio di questo quiz, in quanto la direttiva noindex non è percepibile se non richiedendo la risorsa con user-agent Googleblot.
Il riferimento ad unavailable_after all’interno di un commento nel codice HTML della pagina è ovviamente ininfluente ai fini del processo di indicizzazione e quindi del quiz, perché non si tratta di una vera direttiva unavailable_after ma solo di un commento. Anche in questo caso, la documentazione ufficiale di Google spiega come erogare correttamente un’informazione unavailable_after.
Francamente non mi aspettavo che una percentuale così alta di risposte facessero riferimento ad unavailable_after, pensavo che la natura di commento, la sintassi errata e la data farlocca inducessero l’esaminatore/trice ad un immediato scarto di quel codice. Nei quiz passati i depistaggi sono stati sicuramente più bastardi, almeno dal mio punto di vista.
Come ci si poteva arrivare
Penso che il raggiungimento della risposta corretta sia stato ottenuto solo da coloro che hanno svolto le proprie analisi cercando di simulare il più possibile uno spider di Google, prendendo atto di quello che viene effettivamente erogato al motore di ricerca.
Simulare uno spider di Google è un’attività che mi è capitato di svolgere abbastanza frequentemente nelle analisi di siti web, perché a volte capita che un IT abbia implementato soluzioni dedicate agli spider senza però mantenere una traccia formale di tali implementazioni. Col passare del tempo e l’avvicendarsi di dipendenti diversi, è possibile che si perda traccia di come un sito/CMS gestisce le richieste degli spider e quindi può essere opportuno svolgere analisi in tal senso.
Per richiedere una risorsa presentando un user-agent diverso da quello del proprio browser, si possono usare estensioni e plugin per i propri browser (cercando, ne troverete a bizzeffe) oppure dei tool online che consentono di effettuare richieste HTTP specificandone le caratteristiche. Le intestazioni HTTP riportate nella sezione precedente sono state ottenute usando questo tool di SearchBrain ma ne esistono moltissimi altri e nei commenti al presente articolo è venuto fuori anche questo.
Note su indicizzazione e altro
Al di là dell’unavailable_after, nelle risposte sono emersi alcuni temi che vorrei commentare.
Expires
Le intestazioni Expires non influiscono sulla presenza o assenza di una risorsa in un indice di un motore, al massimo possono influire su quanto aggiornata è la versione che il motore ha indicizzato. Uno dei documenti che in passato mi ha aiutato a fare chiarezza sul funzionamento dei sistemi di caching è questo e vi invito a leggerlo. Ma ricordate che niente batte per dettaglio e completezza le relative RFC.
Direttiva noindex
Il noindex è una direttiva che viene seguita da tutti i motori di ricerca e che induce Google a non presentare la risorsa nelle SERP. Se una risorsa con noindex è presente nelle SERP di Google, i casi sono due: 1) il motore non si è (ancora) reso conto del noindex oppure 2) il processo di indicizzazione è buggato.
Per farvi una veloce statistica, sappiate che tutte le perplessità che ho letto in oltre dieci anni riguardo il mancato rispetto della direttiva noindex da parte di un qualsiasi motore di ricerca erano riconducibili al fatto che il webmaster 1) credeva erroneamente di aver erogato correttamente tale direttiva agli spider oppure 2) credeva che la risorsa fosse indicizzata in quanto appariva nelle SERP.
Un errore comunissimo è un errore di tipo logico: si chiede agli spider di non scaricare la risorsa attraverso un Disallow nel robots.txt, impedendogli in questo modo di rendersi conto dell’esistenza del noindex. Ho discusso questo errore di logica in un precedente articolo.
Esiste anche la diffusa convinzione che “se una risorsa appare nelle SERP allora è indicizzata“, assunzione in realtà errata perché non è strettamente necessario indicizzare i contenuti di una risorsa per poter mostrare un suo riferimento nelle SERP: il riferimento può apparire anche in funzione di informazioni esterne alla risorsa stessa.
And the winner should be…
La prima persona a beccare la causa dell’impossibilità di indicizzazione è stata Yagni, la prima persona che ha evidenziato l’esistenza di un cloaking è stata Francesco (Boschian) e la prima persona che ha risposto formalmente (“vero o falso”) dandone motivazione è stata Vanny Rosso.
Li cito tutti e tre e vi invito a ripartire il merito tra loro a seconda di quanto volete premiare la velocità di risposta o il rispetto formale della domanda. 🙂 Dal prossimo quiz darò priorità alla presenza di una risposta formale e completa oltre che corretta.
Il 55% delle risposte è stato errato, di queste un 54,55% è stato fuorviato dal commento sull’unavailable_after. Il 5% dei partecipanti non ha capito la domanda (nel senso che ha dato una risposta su un argomento completamente diverso dall’indicizzazione).
Congratulazioni a chi ha risposto correttamente! Ci si rivede ad un prossimo quiz. 🙂
P.S.
Pensavo che sarebbe interessante parlare di argomenti simili in qualche evento. Giusto per dire.
La svolta semantica di Google tra bufale e verità
Ultimamente si è fatto un gran parlare di semantica applicata all’information retrieval ed in particolare a Google.
La semantica è un argomento che periodicamente torna ad essere protagonista delle news dedicate ai motori di ricerca. Durante una decina di anni di osservazione e tenendo conto degli sviluppi concreti in questo ambito, la mia impressione è che il più delle volte la parola “semantica” venga usata prevalentemente come specchietto per le allodole.
Da un lato mi sorge il dubbio che per i motori di ricerca si tratti di una carta jolly da tirar fuori in periodi di magra e di penuria di significative evoluzioni della tecnologia.
Dall’altro noto che molte volte gli utenti (SEO compresi) tendano a confondere per semantica dei risultati che possono essere prodotti senza scomodare tale concetto.
Vale dunque la pena di fare il punto della situazione e di cercare di capire che cosa ci si può aspettare realmente per il futuro.
Cosa non fare col rel=canonical
Ho scoperto con un po’ di ritardo che le specifiche del rel=canonical sono state pubblicate in una RFC, la numero 6596.
Per chi non fosse pratico di Internet, basti sapere che le RFC sono i documenti che, tra le altre cose, definiscono il funzionamento di protocolli e standard usati sulla rete.
Nel caso del canonical, non si è arrivati a considerarlo un vero e proprio standard ma la RFC pubblicata di recente è la cosa che si avvicina di più ad un documento di linee guida ufficiali/ufficiose.
Io vi invito a leggere l’intero documento e mi limiterò ad evidenziare in questo breve post solo alcune delle cose che la RFC suggerisce di non fare col canonical.
Per comodità userò l’espressione informale “rel=canonical”, do per scontato che sappiate bene di che si tratta e di come tale relazione va esplicitata nel codice delle pagine HTML o nelle intestazioni HTTP.
Niente redirezioni permanenti
L’URL indicato come canonico non dovrebbe restituire un codice HTTP 301 o 300, in altre parole non dovrebbe essere una redirezione di tipo permanente.
Niente catene di rel=canonical
L’URL indicato come canonico non dovrebbe a sua volta presentare un altro rel=canonical indicante un URL diverso.
Nota mia: i rel=canonical non sono redirezioni lato server e quindi è sconsigliato creare catene di rel=canonical così come invece accade di creare catene di redirezioni.
Niente status di errore
L’URL indicato come canonico non deve restituire uno status HTTP della famiglia 4xx. Ovvero, la risorsa indicata non deve essere un errore 404 o di altro genere.
Paginazione
In caso di paginazioni, le pagine successive alla prima non dovrebbero presentare nel proprio rel=canonical l’URL della prima pagina dell’elenco.
La ragione è che l’URL indicato come canonico dovrebbe ospitare i contenuti degli URL che lo indicano come canonico.
Nota mia: per le paginazioni è corretto usare le relazioni di tipo “next” e “prev”.
P.S.
Pensavo che sarebbe interessante parlare di argomenti simili in qualche evento. Giusto per dire.
Velocizzare un sito con prefetch/prerender: dall’analisi ad un plugin WordPress
I SEO sono probabilmente tra i soggetti che conoscono meglio la necessità di ottimizzare la reattività di un sito web. Siti più reattivi soddisfano meglio gli utenti e tale soddisfazione ha benefici anche sulle conversioni.
L’approccio all’ottimizzazione della velocità dei siti, tuttavia, è spesso legato all’implementazione di linee guida suggerite da strumenti quali GTmetrix e WebPageTest.
Se da un lato è vero che per ogni suggerimento ricevuto dagli strumenti viene poi valutato il rapporto costi/benefici della sua implementazione, tali considerazioni di opportunità rimangono spesso circoscritte ad un contesto tecnico, senza essere estese a valutazioni delle abitudini delle diverse tipologie di visitatori del sito.
Scrivo questo articolo per proporre un esempio di un’ottimizzazione della velocità di un sito che si può ottenere attraverso l’implementazione delle relazioni prefetch e prerender, sfruttando una semplice analisi del comportamento degli utenti su un sito.
L’obiettivo dell’articolo è mostrare il filo logico che ho seguito per arrivare al risultato finale. Il sito usato come cavia è, per mia comodità, LowLevel.it
Opinion spam: un nuovo algoritmo becca le recensioni false
Alla recente conferenza WWW tenutasi a fine aprile sono state presentate, come ogni anno, una nutrita serie di documenti e studi che proponevano nuove metodologie per meglio comprendere e analizzare il web.
Una parte delle paper presentate alle conferenze WWW riguardano spesso nuovi algoritmi per classificare informazioni, fare il ranking di risorse o individuare lo spam. In altre parole, algoritmi di information retrieval, la disciplina su cui si basa la tecnologia dei motori di ricerca.
Leggere i documenti presentati ad ogni conferenza è un buon modo per capire di che cosa sono teoricamente capaci gli ingegneri dei motori di ricerca o di altri servizi web che gestiscono grandi quantità di dati. Io ritengo che le informazioni acquisite leggendo questi documenti siano molto più significative di quelle che si acquisiscono leggendo i brevetti degli algoritmi di Google.
Quest’anno, un documento in particolare ha attratto la mia attenzione e vi linko anche il PDF: “Spotting Fake Reviewer Groups in Consumer Reviews“.
Si tratta di una nuova metodologia chiamata GSRank, nata per individuare attività di opinion spamming e in particolare gruppi di recensori falsi tra quelli veri e genuini che scrivono recensioni o opinioni sui portali di prodotti o servizi.
Il documento non è scritto in inglese molto scorrevole e rutta anche un po’ di matematica; il presente articolo ha l’obiettivo spiegarvi questa nuova metodologia in modo che chiunque possa capirla.