Meta refresh e redirect JavaScript: come li tratta Google

Se non puoi configurare un 301 sul server, hai due alternative che funzionano ancora: il meta refresh e il redirect JavaScript. Google li segue entrambi e, nella maggior parte dei casi, trasferisce i segnali verso la nuova pagina. Ma lo fa con più lentezza, con meno certezze e con un costo che il 301 non ha.

Questo articolo parte da un presupposto preciso: il redirect lato server non è disponibile, per ragioni tecniche o organizzative. Non parleremo quindi della scelta tra 301 e 302, né dei redirect per lingua. Vedremo come Google elabora questi due meccanismi di ripiego, cosa perdi usandoli, come scriverli in modo corretto e come capire se stanno funzionando.

Perché il redirect lato server resta la prima scelta

Un redirect HTTP è una risposta del server: la richiesta arriva, il server risponde con un codice 301 o 302 e un header Location, e il client passa all'indirizzo nuovo senza scaricare alcun contenuto della vecchia pagina. Per Googlebot l'informazione è disponibile già alla fase di scansione, prima di qualsiasi elaborazione successiva. Con un meta refresh o con JavaScript la situazione è diversa. Il server risponde con un 200 e con una pagina HTML completa. Il redirect è una istruzione contenuta nel documento, e prima di poterla applicare il crawler deve scaricare la pagina, leggerla e, nel caso di JavaScript, anche eseguirla. Questa differenza di fase è la radice di tutti i problemi che seguono.

In pratica, ogni redirect non HTTP comporta tre costi. Il primo è il tempo: il segnale arriva dopo e non subito. Il secondo è l'affidabilità: dipende da come un certo crawler interpreta il markup o dal fatto che esegua o meno gli script. Il terzo è l'ambiguità: un 200 che contiene un redirect è, agli occhi di un sistema automatico, una pagina viva che per caso rimanda altrove.

Come Google tratta il meta refresh

Il meta refresh è un tag nell'head, nella forma meta http-equiv="refresh" content="0; url=https://esempio.it/nuova-pagina/". Il primo numero è il ritardo in secondi, il secondo è la destinazione. Google lo legge direttamente dall'HTML, quindi non serve il rendering: è il meccanismo non HTTP più semplice da interpretare per un crawler.

La documentazione di Google sui redirect distingue due casi. Un refresh istantaneo, con ritardo zero, viene trattato come un redirect permanente. Un refresh con ritardo, per esempio cinque secondi, viene trattato come temporaneo. Questa distinzione è l'unica ragione sensata per scegliere un valore diverso da zero: se vuoi trasferire i segnali in modo duraturo, il ritardo deve essere nullo.

C'è un secondo motivo per evitare i ritardi: l'esperienza utente. Un visitatore che vede una pagina vuota o un messaggio del tipo "verrai reindirizzato tra cinque secondi" spesso torna indietro, e il pulsante indietro del browser in molti casi riporta alla pagina che fa subito ripartire il redirect, creando un ciclo frustrante. Anche i requisiti di accessibilità sconsigliano i refresh temporizzati, perché tolgono all'utente il controllo sul tempo di lettura.

Il meta refresh ha però un vantaggio reale rispetto a JavaScript: funziona in qualunque client che legga l'HTML, compresi molti strumenti che non eseguono script. Se la scelta è tra i due e non ci sono vincoli particolari, il meta refresh istantaneo è quasi sempre il più prevedibile.

Come Google tratta il redirect JavaScript

Un redirect JavaScript è una riga come window.location.replace("https://esempio.it/nuova-pagina/") oppure un'assegnazione a window.location.href. Googlebot scarica l'HTML, lo passa al sistema di rendering, che esegue gli script con una versione recente di Chromium, e solo a quel punto vede che la pagina cambia indirizzo. Google dichiara di seguire i redirect JavaScript e di considerarli, ma li indica come ultima risorsa, da usare quando non è possibile nient'altro.

Le condizioni perché funzioni sono concrete. Il file JavaScript che contiene il redirect non deve essere bloccato dal robots.txt, altrimenti Google non lo esegue e vede soltanto una pagina normale con status 200. Il redirect deve scattare senza interazione dell'utente: un redirect dentro un gestore di click o dentro un evento di scroll non verrà mai attivato dal crawler. E deve avvenire in tempi ragionevoli, perché il rendering ha un budget di tempo e non aspetta all'infinito timer lunghi.

Il costo principale è la coda di rendering. Tra la scansione dell'HTML e l'esecuzione degli script può passare un intervallo non prevedibile, e fino a quel momento l'URL di partenza resta quello noto. Per una singola pagina è un dettaglio; per una migrazione di migliaia di URL significa un passaggio lento e disomogeneo, con la vecchia e la nuova versione che convivono nei risultati per un periodo più lungo di quanto accadrebbe con un 301.

Va aggiunto un punto che spesso si trascura: Google non è l'unico lettore della tua pagina. Altri motori di ricerca, strumenti di anteprima dei social, servizi di monitoraggio e molti crawler legati all'intelligenza artificiale non eseguono JavaScript, o lo fanno in modo parziale. Per loro una pagina con redirect JavaScript è semplicemente una pagina che non porta da nessuna parte. Se il traffico da questi canali ti interessa, è un argomento contro questo meccanismo.

Cosa perdi davvero rispetto a un 301

Non esiste un numero affidabile che dica quanto segnale si perde con un meta refresh o con JavaScript, e chi lo indica inventa. Quello che si può descrivere sono i meccanismi che rendono il risultato meno sicuro:

• Velocità di trasferimento: il 301 viene recepito alla scansione, il redirect JavaScript dopo il rendering. La vecchia URL può restare indicizzata più a lungo.
• Certezza dell'interpretazione: il 301 ha un significato univoco definito dal protocollo HTTP. Un redirect nel documento può essere letto in modo diverso da client diversi, e dalla stessa Google in momenti diversi.
• Dipendenza da risorse esterne: se lo script è bloccato, va in errore o viene caricato da un dominio lento, il redirect non avviene e nessuno se ne accorge.
• Ambiguità sulla pagina canonica: la pagina di partenza risponde 200 e ha un proprio contenuto, un proprio titolo e magari un proprio canonical. Google deve decidere quale delle due versioni conservare, e può non scegliere quella che volevi.
• Assenza di semantica per i client non browser: librerie, verificatori di link e strumenti di audit vedono un 200 e non segnalano nessun redirect, per cui i link interni obsoleti restano nascosti.

Come scriverli bene quando non hai alternative

Se devi usarli, la qualità dell'implementazione fa la differenza. Per il meta refresh: ritardo zero, URL di destinazione assoluto, tag posizionato il più in alto possibile nell'head e nessun altro contenuto rilevante nella pagina di partenza. Un documento minimale, con titolo e un link testuale verso la destinazione, è la forma più pulita.

Per JavaScript conviene usare window.location.replace e non l'assegnazione a href. Il metodo replace sostituisce la voce corrente nella cronologia, quindi il pulsante indietro non riporta alla pagina di partenza e non innesca un nuovo redirect. Lo script va inserito inline nell'head o in un file non bloccato dal robots.txt, senza attendere il caricamento completo della pagina e senza condizioni legate a cookie o a interazioni.

In entrambi i casi aggiungi sempre un link normale nel corpo della pagina, con anchor chiara, che punti alla destinazione. Serve a chi ha JavaScript disattivato, a chi usa un client che non segue il refresh e ai crawler che scoprono comunque la nuova URL attraverso un collegamento classico. Nel caso JavaScript, un blocco noscript con un meta refresh o con questo link è una rete di sicurezza ragionevole.

Un ultimo accorgimento riguarda il canonical. Sulla pagina di partenza puoi indicare la destinazione come URL canonica: è un suggerimento e non un ordine, ma va nella stessa direzione del redirect e riduce l'ambiguità di cui abbiamo parlato. Non indicare mai come canonical la pagina di partenza stessa se il suo scopo è rimandare altrove.

Dove servono davvero: ospitalità statica e casi limite

I casi in cui il 301 non è disponibile sono meno numerosi di quanto si creda, ma esistono. Il più frequente è un sito statico su un servizio di hosting che non permette di configurare regole del server, né file di configurazione né header personalizzati. Un secondo caso è una piattaforma chiusa, dove puoi modificare il contenuto delle pagine ma non la configurazione dell'infrastruttura. Un terzo è un'organizzazione in cui il team che gestisce il server ha tempi di risposta di settimane, mentre la pagina va spostata oggi.

Prima di rassegnarti, verifica però tre alternative. Molte piattaforme offrono una funzione di redirect nel pannello, che produce un vero 301 senza toccare il codice. Se hai un CDN o un livello di edge davanti al sito, spesso puoi definire regole di redirect a quel livello, indipendentemente dal server di origine. E se il dominio è gestito da un fornitore, potresti avere a disposizione un inoltro HTTP nelle impostazioni DNS.

Un caso particolare sono le applicazioni a pagina singola, dove il cambio di route avviene nel browser. Qui il redirect JavaScript è inevitabile per la navigazione interna, ma per le URL che devono essere indicizzate conviene che il server risponda con lo status corretto, per esempio attraverso il rendering lato server. Un redirect lato client verso una pagina di errore, inoltre, produce un classico problema di soft 404: il server dice 200, il contenuto dice che la pagina non esiste, e Google è costretto a indovinare.

Infine, una regola pratica per le migrazioni: usa questi meccanismi per poche URL di importanza limitata, mai per il grosso di un cambio di dominio o di struttura. Più URL coinvolgi, più il ritardo di rendering e l'incertezza si sommano.

Come verificare che Google lo stia seguendo

Il controllo migliore è lo strumento di ispezione URL di Search Console, in particolare la prova sull'URL attiva. Guarda l'HTML renderizzato e lo screenshot: se il redirect JavaScript ha funzionato, vedrai la pagina di destinazione. Se vedi la pagina di partenza o un documento vuoto, lo script non è stato eseguito o è stato bloccato.

Nello stesso strumento, controlla quale URL Google ha scelto come canonica. Se la canonica dichiarata da Google è la destinazione, il segnale è stato recepito. Se è ancora la pagina di partenza dopo un tempo ragionevole, c'è un problema di esecuzione o di ambiguità. Controlla anche il robots.txt per assicurarti che nessuna risorsa necessaria al redirect sia bloccata.

Fuori da Google, un test semplice è una richiesta con un client a riga di comando, per esempio curl, che non esegue JavaScript: se ricevi un 200 con la pagina di partenza, sai esattamente cosa vede un crawler privo di rendering. Un crawler di audit configurato con e senza rendering JavaScript mostra la stessa differenza su tutto il sito e permette di individuare i redirect non HTTP che nessuno ricordava di aver inserito.

Un errore comune da cercare: catene e cicli. Un meta refresh che punta a una pagina con un redirect JavaScript che a sua volta punta a un 301 è un percorso lento e fragile. Ogni passaggio aggiunge un punto di rottura, e Google abbandona le catene troppo lunghe. Accorcia sempre il percorso fino alla destinazione finale.

Un criterio di decisione in quattro domande

Per scegliere con metodo, ti bastano quattro domande in quest'ordine. Puoi ottenere un 301 vero, dal server, dal CDN o dalla piattaforma? Se sì, fallo e lascia perdere il resto. Se no, la pagina di partenza può essere un documento minimale? Allora usa un meta refresh istantaneo con link testuale e canonical verso la destinazione.

La terza domanda: serve una logica che il meta refresh non può esprimere, per esempio una destinazione calcolata in base a un parametro? In quel caso il redirect JavaScript con window.location.replace è giustificato, a patto che lo script sia accessibile a Google e che resti un link di riserva. La quarta: stai spostando molte URL? Se sì, torna alla prima domanda e cerca con più insistenza una soluzione lato server, perché è il caso in cui il costo dei meccanismi di ripiego si paga di più.

Documenta ogni redirect non HTTP che inserisci, con data e motivo, e fissa una scadenza per sostituirlo con un 301 quando l'infrastruttura lo permetterà. Sono soluzioni temporanee per natura, e il rischio maggiore è che restino in produzione per anni senza che nessuno ricordi perché.