Lingue

Reindirizzamento Meta Refresh

Cos'è un reindirizzamento meta refresh, perché si colloca tra i reindirizzamenti lato server e quelli JavaScript nell'ordine di preferenza di Google, i refresh istantanei rispetto a quelli ritardati, e perché è sconsigliato.

Prima pubblicazione: 28 giu 2026 · Ultimo aggiornamento: 20 ago 2026 · Advanced
Lingue
AIScritto daAI v2

Un reindirizzamento meta refresh è un tag HTML <meta http-equiv="refresh"> (o l'equivalente header HTTP Refresh) — non un codice di stato HTTP. Il server restituisce un normale 200 e il browser agisce sul reindirizzamento solo quando la pagina è considerata caricata, secondo lo standard HTML, ed è esattamente per questo che è più debole di un reindirizzamento lato server. Uno istantaneo (content="0") viene letto da Google come permanente, simile a un 301; uno ritardato (content maggiore di 0) come temporaneo, e il ritardo è la caratteristica associata al vecchio spam di doorway page. John Mueller dice che 'dovrebbe semplicemente funzionare' ma non è raccomandato per due motivi: mantiene la pagina nella cronologia del browser 'afaik' (parole sue), e Google deve caricare e analizzare la pagina prima di poter vedere il reindirizzamento. Usalo solo come ultima risorsa quando non hai davvero accesso al server, preferisci la versione a 0 secondi, e sostituiscilo con un vero 301 appena puoi.

TL;DR — Un meta refresh è un tag HTML <meta http-equiv="refresh"> (o l’header Refresh iniettato dal server), non un codice di stato 3xx — il server restituisce 200 e il browser naviga solo dopo che la pagina è completamente caricata. Istantaneo (content="0") viene letto come permanente da Google, come un 301/308; ritardato (> 0) viene letto come temporaneo. Si trova tra i redirect lato server e quelli JavaScript nell’ordine di affidabilità di Google a causa di quella dipendenza dal caricamento completo della pagina. Mueller: “should just work,” (traduzione) «dovrebbe semplicemente funzionare», ma non è raccomandato (storico del pulsante indietro + costo di parse-time). Usalo solo quando non hai davvero accesso al server, preferisci 0, abbinalo a rel=canonical e a un link di fallback visibile, e sostituiscilo con un vero 301 appena puoi.

Evidence for this claim Google supports instant and delayed meta refresh redirects but recommends server-side permanent redirects when possible. Scope: Google redirect processing and implementation preference. Confidence: high · Verified: Google Search Central: Redirects Evidence for this claim Timed redirects can create accessibility problems, particularly when users cannot control the time limit. Scope: WCAG timing guidance; not a search-ranking claim. Confidence: high · Verified: W3C WCAG: Timing Adjustable

Non è un codice di stato

Questa è l’unica cosa da capire bene. Un meta refresh non è una risposta HTTP 3xx. Il server restituisce un normale 200 OK con un corpo di pagina completo; nel <head> di quella pagina c’è una direttiva HTML che il browser esegue dopo il caricamento della pagina:

<!-- Instant: treated by Google as permanent -->
<meta http-equiv="refresh" content="0;url=https://example.com/newlocation">

Esiste un equivalente lato server — l’header HTTP Refresh — che fa la stessa cosa ma viene iniettato dal codice del server invece di trovarsi nel markup:

HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocation

Nota che anche la versione header restituisce 200, non un 3xx. In ogni caso, questo è un redirect lato client: è il browser a eseguire la navigazione, non il server.

Istantaneo vs. ritardato — la distinzione di Google

Google traccia la linea sul numero di secondi. Nella sua documentazione su Redirect e Ricerca Google dice che “differentiates between two kinds of meta refresh redirects” (traduzione) «distingue tra due tipi di redirect meta refresh»:

  • Istantaneo (content="0") — “Triggers as soon as the page is loaded… Google Search interprets instant meta refresh redirects as permanent redirects.” (traduzione) «Si attiva non appena la pagina viene caricata… Google Search interpreta i redirect meta refresh istantanei come redirect permanenti.» Quindi per la canonicalizzazione è nella stessa categoria di un 301/308: Google lo segue e lo usa come segnale che il target dovrebbe essere canonico.
  • Ritardato (content maggiore di 0) — “Triggers only after an arbitrary number of seconds… Google Search interprets delayed meta refresh redirects as temporary redirects.” (traduzione) «Si attiva solo dopo un numero arbitrario di secondi… Google Search interpreta i redirect meta refresh ritardati come redirect temporanei.» Come un 302/303/307, il target potrebbe essere ancora indicizzato tramite altri segnali, ma il redirect stesso non viene considerato un segnale di spostamento permanente.

Il mio stesso ordine di redirect nella guida Ahrefs sugli 11 tipi di redirect riflette questo: per gli spostamenti permanenti li classifico come 308 / 301 → meta refresh 0 → JavaScript → crypto, e il meta refresh ritardato scende al livello temporaneo insieme a 302/303/307.

Dove si colloca nell’ordine di preferenza di Google

La documentazione sui redirect di Google pubblica letteralmente una tabella di preferenza, “ordinata in base alla probabilità che Google sia in grado di interpretare correttamente [il redirect].” Per i redirect permanenti l’ordine è: HTTP 301 → HTTP 308 → meta refresh (0 seconds) → JavaScript location → crypto. Il meta refresh è il gradino intermedio — sotto il lato server, sopra JavaScript.

Google è esplicito su entrambi i confini. Sul confine superiore: “Se i redirect lato server non sono implementabili sulla tua piattaforma, i redirect meta refresh possono essere un’alternativa valida.” Sul confine inferiore: “Usa i redirect JavaScript solo se non puoi fare redirect lato server o meta refresh.” Questa è l’intera scala in due frasi — e corrisponde alla struttura già presente nell’hub dei redirect, che nota che JS e i meta refresh ritardati sono più deboli perché dipendono dal rendering.

Due “ordini” diversi — non confonderli

Ecco una sottigliezza che mette in difficoltà gli sviluppatori. MDN pubblica un ordinamento diverso per i redirect — ma riguarda l’ordine di esecuzione del browser quando più meccanismi di redirect sono impilati su una pagina, non l’affidabilità SEO. L’ordine di MDN è: redirect HTTP prima, poi JavaScript, e infine meta refresh — perché “il redirect <meta> avviene dopo che la pagina è completamente caricata, cioè dopo che tutti gli script sono stati eseguiti.”

Quindi JavaScript “batte” il meta refresh nell’ordine temporale di MDN, ma il meta refresh “batte” JavaScript nell’ordine di affidabilità di Google. Entrambi sono corretti — rispondono a domande diverse. MDN chiede “cosa si attiva per primo nel browser?” (il JS sincrono viene eseguito durante il caricamento, prima del timer post-caricamento del meta refresh). Google chiede “cosa sono più propenso a interpretare correttamente per la ricerca?” (un meta refresh viene letto direttamente dall’HTML analizzato; un redirect JS richiede che il passaggio di rendering separato di Google abbia successo). Tieni separati questi assi e l’apparente contraddizione scompare.

Perché dipende dal caricamento della pagina — e perché questo lo rende più debole

Un meta refresh non può scattare finché la pagina non è completamente caricata. Secondo il riferimento di MDN <meta http-equiv>, “the timer starts when the page is completely loaded, which is after the load and pageshow events have both fired.” (traduzione) «Il timer parte quando la pagina è completamente caricata, cioè dopo che gli eventi load e pageshow sono entrambi stati attivati.» Questo vale anche per content="0" — “istantaneo” significa zero ritardo aggiuntivo dopo il caricamento, non zero tempo trascorso. Una pagina lenta ritarda anche un refresh di 0 secondi in un modo che un 3xx lato server non potrebbe mai fare, perché il server invia il redirect prima che qualsiasi pagina venga caricata.

Vale la pena essere precisi: un meta refresh non viene elaborato nella fase di rendering (esecuzione JS) di Google come un redirect window.location — viene letto direttamente dall’HTML <head> analizzato. La sua debolezza non è la pipeline di rendering; è la dipendenza dal caricamento completo della pagina (completamento della rete, risorse che bloccano il rendering) più, per le varianti ritardate, un’attesa arbitraria.

Cosa specifica effettivamente lo standard HTML

L’algoritmo di refresh dichiarativo dello standard HTML è più preciso di “aspetta che la pagina si carichi”, e alcuni dei suoi dettagli contano per l’audit e la risoluzione dei problemi:

  • Tempo di scadenza. Il refresh diventa dovuto dopo il tempo di caricamento completo del documento e, per un elemento <meta> specificamente, il suo tempo di inserimento — a seconda di quale sia successivo — aggiustato per le preferenze dell’utente. Questa è la versione a livello di specifica di “dopo che la pagina si carica”; esattamente quali eventi di rete/rendering contano come “caricati” in un dato browser è un dettaglio di implementazione, non qualcosa che lo standard elenca come una sequenza universale di fetch e paint.
  • URL relativi. La destinazione del refresh viene analizzata in relazione all’URL del documento stesso, quindi quando ne fai un audit, risolvi la destinazione assoluta piuttosto che fidarti della stringa letterale url= — un percorso relativo può puntare da qualche parte diversa da come sembra a prima vista.
  • Il primo vince. Una volta che un documento è già marcato per un refresh dichiarativo, l’algoritmo ignora qualsiasi successiva istruzione di refresh su quella pagina. Due tag <meta refresh> in conflitto (o un tag più un header Refresh) non sono un piano di fallback — è un difetto di authoring, e solo il primo ha effetto.
  • Le destinazioni javascript: vengono rifiutate. Se la destinazione analizzata usa lo schema javascript:, l’algoritmo ritorna senza navigare.
  • Non è garantito che scatti. Lo standard consente esplicitamente che la navigazione venga cancellata, aggiustata dalle preferenze dell’utente o dell’user agent, bloccata dalla restrizione delle funzionalità automatiche di un documento sandboxed, esposta attraverso l’interfaccia del browser stesso, o semplicemente non eseguita. Non trattare “reindirizzerà” come un assoluto.
  • Gestione della cronologia. Lo standard specifica la gestione della cronologia replace per la navigazione di refresh — il che significa che il testo della specifica fa sì che il browser sostituisca la voce di cronologia corrente piuttosto che aggiungerne una nuova. Vale la pena segnalarlo rispetto alla cornice “mantiene la vecchia pagina nella cronologia del browser” qui sotto: è ciò che un portavoce nominato di Google ha riportato sul comportamento reale nel 2018, e potrebbe ancora valere in pratica, ma non è ciò che il testo attuale della specifica descrive. Tratta “meta refresh always leaves the source page in history” (traduzione) «il meta refresh lascia sempre la pagina sorgente nella cronologia» come folklore non confermato piuttosto che comportamento consolidato — verificarlo richiederebbe test specifici per browser/versione, che è al di fuori di ciò che queste fonti stabiliscono.
Evidence for this claim The HTML Standard's declarative refresh algorithm returns without navigating when the parsed target uses the javascript scheme. Scope: meta refresh and Refresh header processing Confidence: high · Verified: HTML Standard: Refresh state

John Mueller ha sintetizzato in modo conciso il caso del “perché non raccomandato” (riportato da Search Engine Roundtable, 2018): un meta refresh “should just work,” (traduzione) «dovrebbe semplicemente funzionare», ma Google non lo raccomanda per due motivi — UX (“it keeps the page in browser history, afaik” (traduzione) «mantiene la pagina nella cronologia del browser, per quanto ne so» — la sua stessa riserva) e tempo di elaborazione (Google deve analizzare la pagina per persino vedere il redirect). “Once processed, it’s just like a redirect.” (traduzione) «Una volta elaborato, è proprio come un redirect.» Questa è una spiegazione più utile del solito “è vecchio e spam,” perché nomina costi concreti e non spam — anche se la parte sulla cronologia è un’osservazione riportata piuttosto che una garanzia documentata dalle specifiche (vedi sopra).

Perché è sconsigliato — il bagaglio storico

A parte le ragioni di UX/tempo di analisi di Mueller, il meta refresh si porta dietro una reputazione. Nell’era dello spam web degli anni 2000 era un veicolo comune per le doorway page: una pagina si posiziona per una query, poi quasi istantaneamente reindirizza il visitatore tramite meta refresh a una destinazione diversa e meno rilevante — mostrando a motori di ricerca e utenti risultati effettivamente diversi. Questa è l’origine dell’etichetta “spammy”. Vale la pena essere precisi qui: nessuna pagina attuale delle policy anti-spam di Google nomina esplicitamente “meta refresh”; le policy definiscono “redirect ingannevoli” e abuso “doorway” come categorie generali di cui il meta refresh storicamente è stato un meccanismo. Tratta questo come contesto storico/di settore, non come una citazione esplicita di una policy attuale.

C’è anche una modalità di errore concreta e non spam che Mueller ha segnalato in una hangout del 2018 (via Search Engine Journal): un sito che reindirizzava tramite meta refresh le pagine di elenco a una pagina di pagamento condivisa. “So if you do this across your pages there’s a big chance we’ll follow this redirect and think ‘Oh, this payment page is actually what you want to have indexed and not the actual content.’” (traduzione) «Se fai questo sulle tue pagine, c’è una grande probabilità che seguiamo questo redirect e pensiamo: “Oh, questa pagina di pagamento è in realtà ciò che vuoi far indicizzare e non il contenuto reale”.» Reindirizzare in massa molte pagine sorgente a una destinazione generica può far indicizzare la destinazione invece del tuo contenuto.

Niente di tutto ciò rende un meta refresh isolato e legittimo un rischio di penalizzazione. La documentazione attuale di Google lo chiama “a viable alternative” (traduzione) «un’alternativa valida» quando i redirect lato server non sono possibili. Il rischio è il pattern e l’intento, non il meccanismo.

Evidence for this claim Google says meta refresh can be a viable alternative when server-side redirects are not possible, while permanent server-side redirects are recommended whenever possible for a URL move. Scope: meta refresh and HTTP Refresh interpretation Confidence: high · Verified: Redirects and Google Search

Accessibilità: la stessa divisione tra immediato e ritardato

L’inquadramento SEO ha un gemello quasi identico nelle linee guida sull’accessibilità — con una precisazione che vale la pena dichiarare subito: le tecniche WAI del W3C sono, secondo le loro stesse parole, esempi di modi per soddisfare i criteri di successo WCAG, non regole di conformità obbligatorie. Soddisfare o mancare una tecnica specifica non è di per sé un passaggio o un fallimento automatico; il requisito effettivo è il criterio di successo (qui, 2.2.1 Timing Adjustable). Detto questo, la preferenza del W3C coincide con le indicazioni SEO sopra: raccomanda prima di tutto un redirect lato server, e dove un redirect lato client è effettivamente necessario, le sue tecniche sufficienti (H76, G110) richiedono nessun ritardo (content="0") e una pagina sorgente il cui contenuto sia limitato a informazioni relative al redirect più un link visibile alla destinazione. Questo è uno standard più restrittivo di “qualsiasi refresh a 0 secondi passa automaticamente” — è “zero ritardo, contenuto solo di redirect e un link di fallback” come pattern sufficiente documentato. Un meta refresh ritardato senza modo di mettere in pausa, estendere o disabilitarlo rischia di fallire il criterio 2.2.1, perché può navigare via prima che un utente di screen reader o qualcuno con bassa visione abbia finito di leggere — ma se un refresh ritardato specifico fallisca effettivamente il criterio è una valutazione WCAG caso per caso, non qualcosa che un numero di tecnica da solo risolve. La nota sull’accessibilità di MDN descrive lo stesso rischio di fondo: intervalli di refresh troppo brevi significano che le persone che usano tecnologie assistive “may be unable to read through and understand the page’s content before being automatically redirected.” (traduzione) «potrebbero non essere in grado di leggere e comprendere il contenuto della pagina prima di essere reindirizzati automaticamente.»

Quindi sia un motore di ricerca che un organismo di standardizzazione arrivano alla stessa regola: istantaneo è ok, ritardato è rischioso. È un bel rinforzo — e un motivo in più per preferire content="0" se usi il meta refresh.

Quando è un’ultima risorsa legittima

Usa il meta refresh solo quando non puoi davvero fare un redirect lato server. Casi reali in cui succede:

  • Host statici senza configurazione server — es. GitHub Pages, dove non puoi aggiungere regole .htaccess/nginx.
  • Generatori di siti statici la cui funzione “aliases” produce meta refresh, non 301. Hugo è un esempio noto — il suo front-matter aliases: genera piccoli file HTML con meta refresh, non veri redirect server. (Maggiori dettagli in Hugo SEO.)
  • Esportazioni no-code / website-builder e alcuni generatori di documentazione che ti permettono solo di emettere HTML statico.

Se devi usarlo, fallo bene:

  • Preferisci l’istantaneo (content="0") a qualsiasi ritardo — segnale permanente, e supera la soglia di accessibilità.
  • Abbinalo a rel="canonical" che punta alla destinazione, così l’intento di canonicalizzazione è esplicito anche prima che Google elabori il refresh.
  • Includi un link di fallback visibile e cliccabile nel corpo per il raro browser o impostazione di tecnologia assistiva in cui l’auto-refresh è disabilitato.
  • Non impilarlo in una catena di redirect — se l’URL della pagina con meta refresh in seguito riceve anche un redirect lato server sovrapposto, hai creato una catena (vedi catene di redirect).
  • Sostituiscilo con un vero 301 appena hai accesso al server. Il meta refresh è un ponte, non una destinazione.

Rilevare il meta refresh sul tuo sito

I crawler lo segnalano, di solito come un flag di gravità da bassa a media piuttosto che un errore critico — Screaming Frog, Sitebulb, Ahrefs Site Audit e Semrush lo segnalano tutti. Per un pugno isolato di URL è un elemento “sistemalo quando comodo”, non un’emergenza; l’uso a livello di sito su pagine importanti è dove diventa degno di priorità. Per controllare un singolo URL a mano, visualizza il sorgente o fai curl alla pagina e cerca http-equiv="refresh" nel <head> (ci sono snippet pronti nella lente Scripts).

Fai attenzione alle affermazioni in entrambe le direzioni sull’equity dei link. La riga del centro assistenza di Ahrefs secondo cui il meta refresh “does not pass much or any link juice” (traduzione) «non trasmette molto link juice, o non ne trasmette affatto» è degna di essere messa in discussione — la tabella dei redirect di Google classifica un meta refresh istantaneo nello stesso bucket di interpretazione del redirect permanente di un 301, il che è un segnale su come Google legge e canonicalizza il redirect, non una promessa dichiarata su un identico PageRank, equity dei link o trasferimento di ranking. Né la documentazione sui redirect di Google né lo standard HTML fanno un’affermazione esplicita sulla parità di equity tra un meta refresh e un 301 — quindi tratta “passa lo stesso valore di un 301” e “passa poco o niente” come ugualmente non verificati oltre a ciò che è effettivamente documentato: Google lo classifica come permanente e lo elabora dopo aver caricato la pagina.

Una pagina sorgente con meta refresh ha comunque la propria risposta HTTP e il proprio documento HTML — l’audit di una non dovrebbe fermarsi alla lettura del tag di refresh. Controlla, in ordine: lo stato HTTP e le intestazioni di risposta dell’URL sorgente (incluso un possibile header Refresh); l’HTML grezzo rispetto a ciò che un browser effettivamente analizza; quale direttiva di refresh è la prima (e quindi efficace) e il suo target assoluto risolto; come la tabella dei redirect di Google la classificherebbe (istantaneo/permanente vs. ritardato/temporaneo); il tag canonical della pagina sorgente, le direttive robots e l’indicizzabilità; la risposta della destinazione finale; se il redirect è annullabile, controllabile o saltato dalle preferenze utente/browser; il comportamento di cache e cronologia nel browser e nella versione specifici che stai testando (non come affermazione universale); i link interni che puntano ancora alla sorgente; e, infine, il tuo piano per sostituirlo con un redirect lato server. Le lenti Checklists e Scripts in questa pagina suddividono questi passaggi in comandi e azioni concrete.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.