Il sito mostra a un utente anglofono degli Stati Uniti una pagina, mentre Googlebot, che si trova fisicamente nel data center di Mountain View, ne vede un'altra completamente diversa. Formalmente, questo è già cloaking, anche se volevi semplicemente adattare il contenuto per la regione. Analizziamo 6 errori tipici nei geo-redirects che portano i siti a perdere posizioni, ricevere sanzioni manuali e bannare interi domini nelle reti partner.
Che cos'è un geo-redirect e perché è necessario per le aziende
Un geo-redirect è un meccanismo che reindirizza automaticamente l'utente a una versione del sito adattata al suo paese: un'altra lingua, valuta, prezzi, offerte. I negozi online lo utilizzano affinché un acquirente dalla Germania venga indirizzato immediatamente alla versione tedesca con prezzi in euro, piuttosto che sfogliare un catalogo in dollari. Gli arbitraggisti usano i geo-redirects in combinazione per mostrare offerte diverse a seconda del traffico geo — ad esempio, un landing page per gli utenti dei paesi di Tier-1 e un'altra per gli altri, o una pagina di sostituzione.
Il problema è che la stessa logica che determina il paese dell'utente in base all'IP si applica anche a Googlebot. Gli indirizzi IP dei bot di Google si trovano fisicamente negli Stati Uniti, indipendentemente dal fatto che stiano indicizzando una pagina per i risultati russi, kazaki o tedeschi. Se il sistema di geo-redirect non distingue il crawler da una persona reale, il risultato è uno solo: Google vede una pagina diversa rispetto a quella che vedono i visitatori reali. Questa è la definizione formale di cloaking secondo le raccomandazioni di Google Search Central, e la punizione per questo va dalla diminuzione nella classifica fino all'esclusione totale del dominio dall'indice.
Perché Googlebot e un umano vedono pagine diverse
La discrepanza si verifica per tre motivi contemporaneamente, e di solito si sovrappongono. In primo luogo, Googlebot esegue la scansione del sito da indirizzi IP appartenenti a Google, e questi indirizzi sono identificati dai servizi geo (MaxMind, IP2Location e simili) come americani nel 100% dei casi. In secondo luogo, Googlebot invia il proprio User-Agent, che spesso viene elaborato da un ramo di codice separato — a volte intenzionalmente, per non compromettere l'indicizzazione, e altre volte semplicemente per errore dello sviluppatore. In terzo luogo, il comportamento di Googlebot durante il rendering JS è diverso da quello del browser: il crawler potrebbe non eseguire il redirect legato al JavaScript client-side, e quindi indicizza una versione completamente diversa della pagina rispetto a quella che vede una persona con JS attivato.
Aggiungi a questo la cache CDN, che può "incastrarsi" sulla versione per un paese e distribuirla a tutti, e ottieni una situazione in cui, anche senza cattive intenzioni da parte del proprietario del sito, il motore di ricerca indicizza contenuti che non corrispondono a ciò che vede il pubblico. Di seguito sono riportati sei scenari specifici in cui ciò accade più frequentemente.
Errore 1: redirect per IP senza verifica dell'User-Agent del bot
L'errore più comune è che la logica del redirect si basa esclusivamente sulla determinazione del paese tramite IP, senza alcuna verifica di chi stia effettuando la richiesta: una persona o un crawler. Di conseguenza, Googlebot, che accede da un intervallo di IP americano, finisce automaticamente sulla versione US del sito, anche se la pagina era originariamente ottimizzata per le ricerche dalla Russia o dal Kazakistan. Dopo alcune settimane di scansione, l'indice di Google si riempie di una versione "sbagliata" del contenuto, e le posizioni nei paesi target iniziano a calare senza una ragione apparente.
La soluzione è sempre escludere gli User-Agent e gli intervalli di IP noti dei bot di ricerca (Googlebot, Bingbot, YandexBot) dalla logica di geo-redirect, fornendo loro la versione canonica della pagina indipendentemente dal paese specificato. La verifica dell'User-Agent è una barriera necessaria, ma non sufficiente, perché è facile da falsificare, quindi i progetti seri verificano ulteriormente l'IP tramite una ricerca DNS inversa (reverse DNS lookup), come raccomanda la stessa documentazione di Google per la verifica di Googlebot.
Errore 2: test con IP di data center invece di quelli reali degli utenti
Il secondo errore si verifica già nella fase di verifica. Lo sviluppatore o il marketer testa il geo-redirect tramite un normale proxy di data center o VPN, e la logica si attiva come se fosse un utente reale del paese desiderato. Ma gli IP di data center sono facilmente distinguibili dal traffico domestico: molti CDN e sistemi antifrode li contrassegnano con un flag separato, e parte della logica di geo-targeting può comportarsi diversamente per tali indirizzi rispetto a un normale IP domestico.
Di conseguenza, il test "passa", il redirect sul server di sviluppo funziona perfettamente, mentre in produzione gli utenti reali del paese target ricevono una versione sbagliata, perché il database di geolocalizzazione del provider o la regola CDN interpreta il loro IP diversamente rispetto all'indirizzo di test del data center. Per una verifica corretta, è consigliabile utilizzare proxy residenziali — hanno IP di veri provider domestici nel paese desiderato, e i servizi geo li identificano proprio come farebbero con un utente reale. Questo fornisce un quadro onesto di ciò che vedrà un vero visitatore del sito, e non una versione semplificata per un "tipico" IP di data center.
Errore 3: cache e assenza di intestazioni Vary
Se il sito è gestito da un CDN (Cloudflare, Fastly, Akamai) e il geo-redirect è implementato a livello di server di origine, e non del CDN stesso, è facile trovarsi nella situazione in cui il CDN memorizza nella cache la prima versione della pagina restituita e la distribuisce a tutti, indipendentemente dal paese del visitatore successivo. Questo accade quando nella risposta del server non è presente l'intestazione corretta Vary: Accept-Language o una chiave di caching simile basata su criteri geo.
In questo caso, Googlebot potrebbe trovare la versione "corretta" al primo accesso, memorizzarla nei propri sistemi di indicizzazione, e poi ricevere la stessa versione per settimane durante i successivi accessi, anche se il contenuto per altri paesi è cambiato da tempo. Nel frattempo, gli utenti vedono una versione attuale, ma diversa — la desincronizzazione cresce gradualmente ed è difficile diagnosticarla senza un confronto diretto delle risposte del server per diverse geo tramite strumenti come curl con modifica delle intestazioni o tramite proxy con la geolocalizzazione desiderata.
Errore 4: JS-redirect che il bot interpreta diversamente
Googlebot è in grado di eseguire JavaScript, ma lo fa con un notevole ritardo (la seconda ondata di rendering può richiedere giorni) e non sempre in modo identico al browser dell'utente. Se il redirect geo è implementato tramite JS client-side — ad esempio, tramite window.location dopo una richiesta fetch al geo-API — c'è il rischio che al primo passaggio il crawler indicizzi la pagina prima che il redirect si attivi, cioè la versione "sbagliata" per una specifica regione del contenuto.
Questo è particolarmente critico per le landing page a pagina singola (SPA), dove tutta la logica di personalizzazione è gestita sul lato client. L'approccio corretto è eseguire la geo-determinazione e il redirect sul lato server (funzione edge del CDN, middleware su Node.js, regola in Nginx), in modo che Googlebot e l'utente ricevano un redirect HTTP 302 prima che la pagina inizi a essere renderizzata nel browser. Questo elimina la dipendenza da come esattamente il crawler elaborerà il JS in un dato momento.
Errore 5: un URL senza hreflang per diverse versioni linguistiche
Il quinto errore è il tentativo di servire più versioni linguistiche allo stesso URL senza markup hreflang. Google raccomanda esplicitamente: se il contenuto su un URL è diverso a seconda della località dell'utente, è necessario fornire URL diversi per ogni versione (subdomini, sottocartelle o domini separati) con markup hreflang incrociato, oppure mostrare onestamente la stessa versione a tutti, compresi i bot, aggiungendo la possibilità di cambiare manualmente la lingua.
Senza hreflang, Google non può fisicamente capire che /product in russo e /product in inglese sono contenuti intenzionalmente diversi per pubblici diversi, e non un tentativo di nascondere un versione dall'indice a favore di un'altra. Il risultato è che viene indicizzata una versione casuale (di solito quella disponibile al bot durante l'ultimo crawling), e questa inizia a essere classificata in tutte le regioni contemporaneamente, il che influisce negativamente sulla pertinenza dei risultati e sulla conversione.
Errore 6: nessun fallback per utenti con VPN e proxy mobili
Il sesto errore riguarda non tanto Googlebot, quanto gli utenti reali — ma è direttamente collegato al tema dei geo-redirects, perché spesso è proprio il tentativo di "aggiustare" il comportamento per i bot a romperlo per le persone reali con VPN o internet mobile. Gli utenti dei provider mobili accedono spesso alla rete tramite CGNAT (Carrier-Grade NAT), quando decine di migliaia di abbonati utilizzano lo stesso IP esterno, e la base geo può identificare tale IP come appartenente a un paese vicino o addirittura erroneamente.
Se il sito non ha un interruttore manuale per paese/language come fallback, un utente con un IP "sbagliato" rimane bloccato su una versione non pertinente senza possibilità di cambiarla — e semplicemente se ne va. Per testare proprio questo scenario, è utile controllare il comportamento del sito tramite proxy mobili, che emulano IP di veri operatori di telefonia mobile con un comportamento di geolocalizzazione tipico per CGNAT — questo aiuta a vedere il problema in anticipo, prima che lo scoprano gli utenti reali e scrivano al supporto.
Come controllare il geo-redirect agli occhi di Google da diversi paesi
Il principale strumento per la diagnosi iniziale è la funzione "Visualizza come Googlebot" in Google Search Console (strumento di verifica URL), che mostra quale HTML riceve realmente il crawler di Google. Se lì viene visualizzata una versione diversa rispetto a quella che vedi tu nel browser dal tuo paese, il problema è confermato. Ma la Search Console esegue sempre la scansione da IP americani, quindi per confrontare il comportamento del sito tra le regioni è necessario un ulteriore strato di test.
Nella pratica, i marketer e gli specialisti SEO creano diversi profili in un browser anti-detect — Dolphin Anty, AdsPower, Multilogin o GoLogin — e collegano a ciascun profilo un proxy del paese desiderato, per seguire manualmente il percorso dell'utente: aprire il sito, vedere quale versione si carica, quale intestazione Accept-Language è stata inviata, se il redirect ha funzionato e a quale URL. Per tali verifiche sono comodi proxy residenziali con selezione precisa della città o dell'operatore — forniscono la simulazione più onesta di un visitatore reale, a differenza degli indirizzi di data center, che alcuni servizi possono contrassegnare come sospetti anche prima della valutazione geo.
| Tipo di proxy | Per quale verifica è adatto | Rischio di risultato errato |
|---|---|---|
| Proxy residenziali | Simulazione di un normale utente domestico nel paese/città desiderata | Basso |
| Proxy mobili | Verifica del comportamento con CGNAT e geolocalizzazione mobile | Basso |
| Proxy di data center | Verifica rapida del fatto che il redirect per paese funzioni | Maggiore: parte delle basi geo contrassegna IP in modo diverso rispetto a quelli domestici |
Per controllare il comportamento della logica del server (e non il rendering visivo) è utile anche osservare la risposta grezza del server tramite curl, modificando l'User-Agent su Googlebot e l'intestazione X-Forwarded-For sull'IP del paese desiderato — questo mostrerà quale stato HTTP e Location restituisce il server prima di qualsiasi rendering JS, e permetterà di catturare l'errore 4 e l'errore 1 dall'elenco sopra con un solo comando.
Checklist per una configurazione sicura dei geo-redirects
- Googlebot, Bingbot e YandexBot esclusi dalla logica di geo-redirect per User-Agent e confermati tramite DNS inverso
- Redirect implementato sul lato server (302/307), e non solo tramite JavaScript client-side
- Intestazione
Varyconfigurata per un corretto caching CDN basato su geo/language - Per ogni versione linguistica esiste un URL separato con markup hreflang incrociato
- Esiste un interruttore manuale visibile per paese/language come fallback per IP erroneamente identificati
- I test vengono eseguiti tramite proxy residenziali e mobili dai paesi desiderati, e non solo tramite indirizzi di data center
- Una volta al trimestre si verifica cosa mostra Google Search Console — la versione corrisponde a ciò che vedono gli utenti reali
Conclusione
La discrepanza tra ciò che vede Googlebot e ciò che vede un utente raramente è un inganno intenzionale del motore di ricerca — più spesso è un debito tecnico accumulato: redirect per IP senza verifica del bot, cache senza intestazione Vary, redirect JS che il crawler non riesce a eseguire, e assenza di hreflang per le versioni linguistiche. Ognuno di questi errori, preso singolarmente, può sembrare insignificante, ma insieme creano un classico quadro di cloaking agli occhi di Google — con le relative sanzioni.
L'unico modo affidabile per assicurarsi che il sito si comporti in modo equo sia per i bot che per le persone è controllarlo regolarmente con IP reali dei paesi desiderati. Per tale diagnosi, raccomandiamo di utilizzare proxy residenziali per simulare un tipico utente domestico e proxy mobili per verificare gli scenari con CGNAT — questo fornisce il quadro più onesto di ciò che vede realmente il tuo pubblico in ogni regione, e aiuta a catturare il problema prima che lo trovi l'algoritmo di Google.