Redirect automatico per lingua o IP: rischi per la SEO

Sì, un redirect automatico basato sulla lingua del browser o sulla posizione dell'utente può nascondere parte del sito a Google, e spesso lo fa senza che nessuno se ne accorga. Il motivo è semplice: Googlebot non è un visitatore italiano, tedesco o francese. Nella maggior parte dei casi scansiona da indirizzi IP statunitensi e non invia una preferenza di lingua come farebbe un browser configurato da una persona. Se il server decide dove mandare il visitatore in base a questi due segnali, il crawler finisce quasi sempre nello stesso posto, di solito la versione predefinita, e non raggiunge mai le altre.

Questo articolo si concentra su un solo problema: cosa succede quando il redirect è automatico e cosa fare al posto suo. Non è una guida a hreflang né alla struttura degli URL internazionali. Vedremo la meccanica del fallimento, i casi tipici in cui si manifesta, come verificare in dieci minuti se il tuo sito ne soffre e come sostituire il redirect con un suggerimento non invasivo che lascia all'utente, e al crawler, la scelta.

Come ragiona il server e come ragiona Googlebot

Un redirect automatico per lingua funziona in due modi, spesso combinati. Il primo legge l'intestazione HTTP Accept-Language, con cui il browser dichiara le lingue preferite dall'utente, per esempio it-IT,it;q=0.9,en;q=0.5. Il secondo interroga un database di geolocalizzazione IP per capire da quale paese arriva la richiesta. In base al risultato, il server risponde con un 301 o un 302 verso la sottocartella, il sottodominio o il dominio locale, oppure serve direttamente contenuti diversi sullo stesso indirizzo.

Per un visitatore umano il meccanismo sembra comodo. Per un crawler è una trappola, perché entrambi i segnali sono falsati in partenza. La documentazione di Google sulle pagine adattive a lingua e paese lo dice apertamente: Googlebot scansiona di norma da indirizzi IP con sede negli Stati Uniti e le sue richieste non dichiarano una preferenza di lingua. Esistono scansioni con IP locali in alcuni casi, ma non puoi contarci e non puoi prevederle, quindi la regola di progettazione è presumere il caso peggiore.

Il risultato pratico è che il crawler vede sempre la stessa risposta. Se la logica dice che chi non ha preferenze va sul sito inglese, Googlebot entra da qualunque URL e atterra sulla versione inglese. Le pagine italiane, tedesche o francesi restano raggiungibili solo a chi arriva con il segnale giusto, cioè quasi nessuno dei crawler. Dal punto di vista di Google, quelle pagine possono non esistere.

Cosa perdi davvero quando il redirect nasconde una versione

Il danno non è un singolo errore visibile, ma una somma di effetti che si leggono male nei report. Il più grave è l'assenza di indicizzazione: se Googlebot non riesce a raggiungere gli URL di una lingua, quei contenuti non entrano nell'indice e non possono posizionarsi per nessuna ricerca in quella lingua. Il sito sembra funzionare, perché chi lo apre da browser vede tutto, ma nei risultati compare una sola versione.

C'è poi il problema dei segnali. I link che altri siti fanno verso una pagina localizzata passano prima da un redirect, e se il crawler viene rimandato altrove quel valore si accumula sull'URL di destinazione invece che sulla pagina a cui il link era destinato. Anche la valutazione dei contenuti si sposta: Google giudica la pagina che riceve, e se riceve sempre la versione di ripiego ignora la qualità del lavoro fatto sulle altre.

Infine ci sono i sintomi indiretti, che spesso sono i primi a comparire:

• In Search Console compaiono URL segnalati come pagina con redirect o come duplicato, con canonical scelta da Google diversa da quella dichiarata.
• Le pagine locali non compaiono nel rapporto Indicizzazione delle pagine oppure risultano scoperte ma non indicizzate.
• Cercando site: con il nome del sito, i risultati mostrano una sola lingua.
• Nei risultati italiani appare la pagina in inglese, perché è l'unica che Google conosce.

I casi tipici in cui il problema si presenta

Il caso più frequente è la home page sulla radice del dominio che reindirizza in base alla lingua. Chi digita il dominio viene mandato a /it/, /de/ o /en/. Se la regola è scritta pensando all'utente e non al crawler, Googlebot viene sempre mandato a una sola destinazione. Per la home il danno si vede subito, ma è contenuto se le sottocartelle restano raggiungibili con un link diretto.

Il secondo caso è più insidioso: il redirect si applica a ogni URL, non solo alla radice. Un utente italiano che apre un indirizzo di /en/ viene riportato a /it/, e un utente inglese fa il percorso opposto. Ogni versione diventa inaccessibile a chi ha una preferenza diversa, e quindi anche al crawler che preferenza non ne ha. Gli URL esistono, sono nella sitemap, ma quando li si richiede rispondono con un 302 verso un'altra lingua.

Il terzo caso è quello del geoblocco travestito da localizzazione. Il sito serve sullo stesso URL contenuti, prezzi e valuta diversi in base al paese, senza alcun indirizzo distinto per ognuno. Non c'è nemmeno un redirect da osservare, ma il principio è lo stesso: Google vede la variante degli Stati Uniti e nessun'altra. Qui la soluzione è sempre la stessa, dare a ogni variante un proprio URL.

Un quarto caso riguarda le CDN e le cache. Se il server varia la risposta in base a Accept-Language o a un cookie ma non lo dichiara con l'intestazione Vary, la cache può servire a tutti la prima versione che ha memorizzato. A quel punto anche utenti reali vedono la lingua sbagliata, e il crawler trova una risposta che dipende da chi ha richiesto la pagina per primo.

Il falso rimedio: lasciare passare Googlebot senza redirect

La scorciatoia che molti team tentano è escludere i crawler dalla regola: se lo user agent contiene Googlebot, nessun redirect. Sembra risolvere tutto, ma sposta il problema su un terreno peggiore. Le linee guida di Google chiedono di mostrare al crawler gli stessi contenuti che si mostrano agli utenti, e servire una risposta diversa a seconda di chi richiede la pagina è la definizione di cloaking. La differenza tra il redirect dell'utente e la pagina servita al bot è esattamente il tipo di incoerenza che quelle linee guida vogliono evitare.

Esiste anche un rischio operativo. Lo user agent si falsifica facilmente, quindi la regola va accompagnata da una verifica dell'IP tramite DNS inverso, altrimenti diventa un modo per aggirare la logica del sito. E poi coprirebbe solo Googlebot: Bing, gli strumenti di audit e i crawler di altre piattaforme restano intrappolati nel redirect.

Il ragionamento corretto è opposto. Non si tratta di scegliere chi escludere, ma di togliere la decisione automatica dal percorso di accesso. Se ogni versione linguistica ha un proprio URL che risponde sempre con 200 a chiunque lo richieda, il crawler e l'utente vedono lo stesso, e il problema sparisce senza eccezioni da mantenere.

Come verificare se il tuo sito è esposto

Bastano pochi controlli, nessuno dei quali richiede strumenti a pagamento. Il primo è una richiesta da riga di comando che simula un client senza preferenze: con curl -I su un URL localizzato, senza intestazione Accept-Language, leggi codice di stato e intestazione Location. Un 200 è quello che vuoi; un 301 o un 302 verso un'altra lingua è il problema. Ripeti con Accept-Language impostato su una lingua diversa da quella dell'URL e confronta.

Il secondo controllo è lo strumento Controllo URL di Search Console, con il test dell'URL attivo. Mostra la pagina come la recupera Google e l'URL finale dopo eventuali redirect. Se chiedi una pagina italiana e il test restituisce la pagina inglese, hai la conferma. Il terzo è il rapporto delle statistiche di scansione, che mostra la distribuzione dei codici di risposta: una quota anomala di 301 e 302 su URL che dovrebbero rispondere 200 è un segnale forte.

Il quarto è controllare i log del server, filtrando le richieste dei crawler verificati. Se le richieste verso /it/ o /de/ ricevono quasi tutte una risposta 3xx, il redirect sta lavorando contro di te. Conta anche la prova negativa: se nei log non compare mai una richiesta di Googlebot verso certi URL di una lingua, il crawler potrebbe non averli mai scoperti, perché i link interni che li collegano passano da una pagina che lo rimanda altrove.

Un ultimo controllo, spesso dimenticato, è provare con una VPN o con un servizio di test da posizioni diverse. Se la risposta cambia in base al paese e non esiste un URL distinto per ogni variante, hai una pagina adattiva senza indirizzi separati.

L'alternativa: suggerire senza imporre

Il rimedio standard è sostituire il redirect con un suggerimento. La pagina richiesta si carica sempre, nella lingua dell'URL, e se il sistema ritiene che l'utente preferisca un'altra versione mostra un banner discreto: Stai visitando il sito in inglese. Vuoi passare alla versione italiana? Il link porta all'URL corrispondente, e l'utente decide. Dal punto di vista tecnico il crawler riceve sempre un 200 con il contenuto dell'URL richiesto e non incontra nessuna decisione da prendere.

Il banner funziona bene solo se rispetta alcune regole di implementazione:

• Il rilevamento avviene lato client, dopo il caricamento, e non cambia né il contenuto principale né il codice di stato della pagina.
• Il banner non copre il contenuto principale. Google penalizza gli interstitial invasivi su mobile, quindi meglio una fascia sottile in alto o in basso, facile da chiudere.
• La scelta dell'utente viene memorizzata in un cookie o nel browser, così il suggerimento non ricompare a ogni pagina.
• Il link di cambio lingua punta alla pagina equivalente nell'altra lingua, non alla home, altrimenti l'utente perde il contesto.
• Il banner non è l'unico modo di cambiare lingua: nel menu resta un selettore con link veri, scansionabili, e non un menu a tendina che naviga solo via JavaScript.

I segnali che sostituiscono la decisione automatica

Togliere il redirect non lascia Google senza indicazioni. Il canale giusto per dichiarare la relazione tra le versioni è l'annotazione hreflang, che va reciproca: ogni versione elenca se stessa e tutte le altre, con la stessa coppia di URL dichiarata da entrambe le parti. Qui serve solo ricordare il ruolo di x-default, che indica la pagina da mostrare a chi non corrisponde a nessuna lingua dichiarata. È il posto giusto per una pagina di scelta della lingua, o per la versione predefinita.

Una pagina di scelta della lingua, con link testuali a ogni versione, può stare sulla radice del dominio e risolvere il problema della home. L'utente vede un elenco di lingue, il crawler segue i link e trova tutte le versioni in un passaggio. È meno elegante di un redirect, ma ha il vantaggio di essere trasparente per entrambi.

Conviene infine curare i link interni e la sitemap. Ogni versione linguistica deve essere raggiungibile con link normali e comparire in sitemap con il proprio URL finale, quello che risponde 200 e non quello che poi viene rimandato. La sitemap che elenca URL soggetti a redirect è un segnale contraddittorio che Google dovrà risolvere da solo.

Se per ragioni commerciali vuoi comunque un redirect, per esempio verso un sito nazionale con catalogo e fiscalità diversi, limitalo al primo accesso alla radice, usa un 302 e non un 301, e non applicarlo mai agli URL profondi. Un 301 può essere memorizzato dal browser e dalle cache, e rimanda a lungo l'utente nello stesso posto anche quando la sua situazione cambia.

Errori ricorrenti da evitare

Dopo aver visto come si costruisce la soluzione, vale la pena elencare gli errori che riportano il problema. Il primo è il 301 permanente per una decisione che dipende dall'utente: un redirect permanente dice che la destinazione è la nuova posizione stabile della risorsa, ma qui la destinazione cambia con chi richiede. Usarlo trasmette un segnale falso e fa memorizzare la scelta.

Il secondo è affidarsi solo all'IP. L'indirizzo dice dove si trova la connessione, non quale lingua parla la persona. Chi viaggia, chi lavora da una rete aziendale con uscita in un altro paese, chi usa una VPN, un expat a Milano con browser in inglese: per tutti questi l'IP dà la risposta sbagliata. L'intestazione Accept-Language è più affidabile, ma resta una preferenza di sistema e non sempre esprime ciò che l'utente vuole su quel sito.

Il terzo è il redirect che non tiene conto della scelta esplicita. Se un utente ha cliccato sul selettore per passare all'inglese, il sito deve ricordarlo e non rimandarlo all'italiano al clic successivo. Senza questa memoria nasce un ciclo frustrante, e nei casi peggiori un ciclo di redirect vero e proprio, che per il crawler è un errore.

Il quarto è dimenticare di testare dopo ogni modifica dell'infrastruttura. Un cambio di CDN, di plugin di traduzione o di regole del server può reintrodurre una logica di redirect che era stata tolta. Conviene inserire nei controlli di rilascio una richiesta di prova per ogni lingua e verificare che risponda 200 senza intestazioni speciali.