Hijack 302 dopo il Big Daddy: a volte ritornano

Le ragioni per le quali Google ha dato vita al Big Daddy sono state diverse. Una tra le più importanti è stata porre fine ai problemi delle redirezioni, in modo particolare al famigerato hijack 302.

Così Matt Cutts ai primi di Gennaio
“…the new infrastructure at the Bigdaddy data center will let us tackle canonicalization, dupes, and redirects in a much better way going forward compared to the current Google infrastructure…”

Fin dai primi anni del millennio infatti questo fastidioso e temibile effetto ha iniziato ciclicamente ad affliggere le SERP di Google. Tra lo sconcerto dei webmaster cominciava a diventare evidente che colleghi più o meno maliziosi potevano agevolmente modificare le SERP e dirottare traffico da un sito verso il proprio o verso altre destinazioni. Il tutto con poco sforzo da parte dell'”attaccante” e senza possibilità di rimedio rapido da parte dell'”attaccato”. Le virgolette sono d’obbligo poichè, come vedremo, nella maggior parte dei casi non vi era e non vi è alcun intento di danneggiamento, semplicemente il problema si presentava, e si presenta, come un effetto preterintenzionale, senza movente, senza cioè l’intenzione di fare danno. In breve: un bug di Google.

Il problema era serio sia per chi ne era colpito e sia per la qualità generale delle SERP del principale motore.

Big Daddy ha risolto questo problema? Non sembra, il problema continua a rimanere serio.

Al SES di Milano a fine Aprile ho avuto modo di esporre alcuni degli effetti del redirect 302 in un caso particolare: Google aveva equivocato il dominio canonico di un sito, interpretando i link provenienti da affiliazioni (con 302) come naturali, elevando a principale il dominio di terzo livello a cui puntavano e provocando uno smottamento nei posizionamenti, probabilmente per deficit di fattori off-the-page (link popularity in primis) che continuavano ad insistere sul vecchio ed effettivo dominio principale.

Approfondiamo la questione da un altro punto di vista: le SERP.

Cos’è in definitiva un hijack 302?

Ci sono moltissimi documenti in rete che illustrano questo vero e proprio baco di google. Ve ne segnalo uno che, anche se datato, mi è particolarmente piaciuto per il taglio e la chiarezza, nonostante il focus sia sugli usi consapevoli e maliziosi dell’exploit che ritengo siano i meno diffusi.
http://clsc.net/research/google-302-page-hijack.htm
In realtà, a quello che si vede attualmente nelle SERP, la gran parte degli hijack è inconsapevole ed è determinata da pratiche legittime quali le affiliazioni, che fanno largo uso della redirezione 302 secondo lo schema:

affiliato ==> script di tracciamento con redirezione 302 ==> merchant

Come si manifesta un Hijack? Vediamolo in pratica simulando una ricerca.
Supponiamo di voler usare Google per trovare e prenotare un volo da, poniamo, Napoli a Parigi.
http://www.google.it/search?q=volo+napoli+parigi

Dopo le prime due coppie di risultati legittimi (kelkoo e edreams, noti player del ramo), al quinto posto abbiamo:

Che pagina è questa al quinto posto, con url atipica e title del merchant?
Semplicemente non è una pagina, non esiste in quanto documento. E’ un semplice script che traccia la provenienza del click e lo instrada via 302 verso il sito del merchant (in questo esempio edreams), il quale pagherà una fee per il servizio, variabile da pochi centesimi a qualche decina di euro a seconda del tipo di accordo (per click o per conversion). Da notare che tutto il meccanismo è studiato per funzionare coi lettori umani dentro il sito affiliato, non con gli spider che naturalmente non convertono (e non portano referrer) e tantomeno per lavorare nelle SERP.

Tecnicamente, semplificando, avviene che il primo spider che vede quel link in un sito affiliato crea un record nel db di google con l’url dello script (script.circuitoaffiliazione.com/click?somenumber). Un successivo spider che tenta di visitare l’url dello script viene rediretto via 302 sulla vera pagina (www.merchant.it/somepage) e inserisce quindi nel record i veri dati della pagina di arrivo, associati alla url creata dal primo spider. Altri spider avranno comunque la possibilità di aprire un record con il vero indirizzo della pagina di arrivo, in attesa che il filtro anti-duplicazione si incarichi a questo punto, visti i contenuti uguali, di dirimere la questione su quale sia la pagina che merita di restare in vita. Se la pagina soccombente è lo script tutto fila liscio, se invece per qualche ragione soccombe la pagina naturale ecco che si manifesta l’hijack 302.
Da questo momento la pagina naturale è persa e avremo un risultato, di fatto a pagamento, incastonato nei risultati organici/naturali. Una pagina virtuale, uno script, nato a scopo di tracciamento, si troverà inopinatamente nelle SERP ed entrerà in competizione con pagine vere, spesso scalzandole, ma sempre eliminando almeno una pagina del merchant dal db del motore e quindi dalle SERP. Forse il risultato in termini di traffico non si perderà, ma certamente si pagherà per cosi’ dire due volte: una come organico e una come affiliazione. Soprattutto, se per qualche ragione dovesse cessare l’affiliazione il risultato sarà perso.

Da rilevare tre cose:

1. la pagina che produce l’hijack va a sommarsi alle due mostrate tipicamente in SERP per dominio e NON le sostituisce. In molti casi si è notato come per alcune ricerche vengano mostrati nella stessa pagina una coppia di risultati legittimi e una coppia di risultati-hijack che puntano allo stesso dominio, con risultati antipatici (per i competitori) visto l’effetto saturazione della pagina SERP.
2. più è specifica la ricerca e più appare presente l’effetto hijack.
   http://www.google.it/search?hl=it&q=volo+napoli
   prima coppia di snippet al dominio legittimo, hijack in settima posizione
   http://www.google.it/search?hl=it&q=volo+napoli+parigi
   terza e quarta posizione per il sito legittimo, quinta per l’hijack
   http://www.google.it/search?hl=it&q=volo+napoli+parigi+edreams
   prima e seconda posizione per l’hijack, terza e quarta per il sito legittimo, chiaramente evocato nella query.
3. Non sono affatto chiari i criteri che il filtro anti-duplicazione usa per dirimere la prevalenza di una delle due pagine. Il page-rank pare non c’entrare, almeno non da solo. E’ probabile che il numero di link abbia un ruolo importante, visto che gli annunci a volte si ripetono identici in tutte le pagine del sito affiliato, incarnati nel template.

In ogni caso il risultato è preoccupante per la qualità generale delle SERP e anche per la salute del sito merchant. Le pagine “perse” sostituite dallo script possono diventare molte in poco tempo e produrre guasti nel posizionamento organico anche di notevole portata, svuotando una promozione dal di dentro senza che vi siano ripercussioni apparenti nel traffico da motori (molla che generalmente attiva gli interventi di troubleshooting). In pratica quando ci si accorge del problema è quasi sempre tardi per porvi rimedio, gli sforzi saranno necessariamente lunghi e gli esiti incerti.
Non solo.
Vi è un notevole rischio di perdita di rilevanza all’aumentare oltre una certa soglia del numero di pagine sostituite da script ma, soprattutto, vi è un fattore non pilotato e non pilotabile da SEO/webmaster che va a interferire con lo sviluppo degli interventi.
Non sappiamo cosa potrà succedere ad un sito eroso dall’interno dall’effetto hijack 302, al mutare dell’algoritmo. Quali che siano i risultati nel breve periodo la risultante complessiva sarà comunque una certa perdita del controllo della promozione.
Come evitare l’Hijack 302?

Ribadito che, nel caso specifico di hijack 302 da affiliazioni, non vi è nessuna colpa da parte del circuito di affiliazione e tantomeno del sito affiliato, vi sono alcuni interventi che possono evitarlo o comunque ridurre grandemente il rischio, in attesa che Google, unico responsabile di questa situazione, affronti alla radice il problema.

• Stare alla larga dal redirect 302. Se gestite un sito merchant chiedete al circuito di affiliazione di usare il redirect 301 invece del 302. Nel frattempo fate in modo che gli annunci vengano indirizzati in landing pages sterilizzate per gli spider con noindex, nofollow.
• Il circuito di affiliazione, benchè non direttamente responsabile della situazione, puo’ tuttavia risolverla agevolmente sterilizzando tutti gli script di redirezione via robots.txt.
• Inserire il metatag base in tutte le pagine del vostro sito e usate, se possibile, url assolute e non relative.

Questi interventi dovrebbero ridurre in modo significativo il rischio.

Una volta che una pagina è vittima di un hijack non vi sono molte soluzioni: una buona dose di pazienza, un 404 not found sullo script di redirezione e una richiesta di rimozione della pagina direttamente a Google.

Come spesso accade la prevenzione è la politica migliore.