Lingue

Reindirizzamenti JavaScript

Cos'è un reindirizzamento JavaScript, come la pipeline di rendering di Google lo tratta diversamente da un 301 lato server, quando è un'ultima risorsa accettabile, e come implementarlo e rilevarlo — oltre a dove si collocano il meta refresh e l'History API.

Prima pubblicazione: 27 giu 2026 · Ultimo aggiornamento: 11 ago 2026 · Advanced
Lingue
AIScritto daAI v2
1 segnale di evidenza in questa pagina

Un reindirizzamento JavaScript invia utenti e crawler a un nuovo URL con codice lato client (window.location.replace() o .href). È il tipo di reindirizzamento meno affidabile perché Google lo vede solo dopo il rendering — che può essere ritardato o fallire del tutto, senza una tempistica fissa in entrambi i casi. L'ordine di preferenza ufficiale di Google è lato server (301/302/307/308) → meta refresh → JavaScript, e la sua documentazione dice chiaramente: usa i reindirizzamenti JS solo se non puoi fare gli altri due. Una volta che Google lo interpreta con successo, la destinazione diventa un segnale di canonicalizzazione — ma non è una garanzia provata di identico PageRank o risultati di ranking rispetto a un 301, quindi trattalo come ultima risorsa piuttosto che come una sostituzione equivalente. Usali su piattaforme limitate senza accesso al server, per pagine di errore SPA che puntano a un vero 404, e poco altro. Se devi usarne uno, usa window.location.replace() nel <head>, rimuovi l'URL sorgente dalla tua sitemap e punta i link interni alla destinazione finale. Il meta refresh è un reindirizzamento separato a livello HTML, e history.pushState()/replaceState() non sono affatto reindirizzamenti.

TL;DR — Un redirect JavaScript è un redirect lato client (window.location.replace(), .href, .assign()) che Google elabora solo dopo il rendering — fase tre di crawl → render → index. Un 301 lato server viene visto al momento del crawl; un redirect JS aspetta nella coda di rendering, e Google non fornisce una tempistica fissa per quell’attesa — può essere rapida o può richiedere molto tempo, e il rendering può fallire del tutto. L’ordine di preferenza documentato da Google è server-side → meta refresh → JavaScript, e la documentazione dice di usare i redirect JS solo quando non puoi fare le altre due cose. Una volta che Google li interpreta con successo, la destinazione diventa un segnale di canonicalizzazione permanente — persino Google li ha usati sul proprio blog quando nient’altro funzionava — ma questa non è una prova documentata di risultati identici in termini di PageRank o ranking rispetto a un 301, quindi sono un’ultima risorsa, non un segnale di spam. Gli usi legittimi sono piattaforme vincolate senza configurazione server e pagine di errore SPA che puntano a un vero 404. Implementa con window.location.replace() nel <head>, rimuovi la sorgente dalla tua sitemap, riorienta i link interni e conferma che Googlebot possa recuperare il JS. Il meta refresh è a livello HTML (0s = permanente, qualsiasi ritardo = temporaneo), e history.pushState()/replaceState() non sono affatto redirect.

Cosa conta come redirect JavaScript

La navigazione tramite script dipende dal rendering e dall’esecuzione, quindi non è equivalente a livello di protocollo ad un redirect HTTP. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript redirects L’elaborazione è possibile, non una garanzia di tempi esatti o di indicizzazione. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search

Un redirect JavaScript naviga il browser verso un nuovo URL con codice lato client. I metodi comuni e come differiscono:

  • window.location.replace("url") — naviga e rimuove l’URL originale dalla cronologia della sessione. Questo è quello da usare: il pulsante indietro salta la sorgente del redirect invece di rimandare l’utente direttamente indietro.
  • window.location.href = "url" — naviga ma mantiene l’originale nella cronologia, quindi il pulsante indietro torna alla pagina che reindirizza (e può creare un loop). document.location.href e window.location.assign("url") si comportano allo stesso modo.
  • history.pushState() / history.replaceState() — non sono redirect. Riscrivono la barra degli indirizzi senza alcuna navigazione o segnale HTTP, quindi i crawler non li trattano come redirect. Le SPA li usano per cambi di URL in-app; hanno bisogno di veri link <a href> (o navigazioni reali) per essere indicizzabili.

La linea di demarcazione che conta: .replace(), .href e .assign() attivano tutti una vera navigazione del documento (la differenza tra loro è solo ciò che accade alla cronologia della sessione), mentre pushState()/replaceState() non navigano mai — toccano lo stato della cronologia e la barra degli indirizzi e nient’altro. Nessuno dei quattro è un HTTP 301; “redirect” qui è un’abbreviazione per navigazione lato client, non un codice di stato.

Il meta refresh (<meta http-equiv="refresh" content="0;url=...">) è spesso raggruppato con i redirect JS, ma è una direttiva HTML analizzata prima che JavaScript venga eseguito — una categoria separata e più affidabile, trattata di seguito.

Come Google elabora un redirect JavaScript

Questo è il punto cruciale. La pipeline di Google funziona a fasi, e un redirect JS e un redirect lato server vengono intercettati in fasi diverse:

  1. Scansione — Googlebot recupera l’URL e legge l’HTML grezzo. Un 301/302/307/308 lato server viene rilevato in questa fase.
  2. Coda di rendering — le pagine che restituiscono 200 aspettano di essere renderizzate. La documentazione di Google nota che la pagina “may stay on this queue for a few seconds, but it can take longer than that.” (traduzione) «può rimanere in questa coda per alcuni secondi, ma l’attesa può essere più lunga.» Google non pubblica una tempistica di servizio fissa oltre a questo, quindi tratta l’attesa come imprevedibile — può essere rapida, o può trascinarsi — piuttosto che assumere un numero specifico di giorni o settimane.
  3. Rendering e indicizzazione — Chromium headless esegue il JavaScript. Questo è il primo momento in cui un redirect JS esiste per quanto riguarda Google.

La stessa idea che presento in Crawling e in JavaScript SEO vale anche qui: il rendering è un passaggio separato dal fetching, e tutto ciò che dipende da esso eredita quel ritardo e quel rischio.

E il rischio è reale. Google: “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (traduzione) «Sebbene Google tenti di eseguire il rendering di ogni URL che Googlebot ha scansionato, il rendering potrebbe fallire per vari motivi. Ciò significa che se imposti un reindirizzamento JavaScript, Google potrebbe non vederlo mai se il rendering del contenuto fallisce.» (Google Search Central) Durante la finestra prima che il reindirizzamento venga elaborato — e per sempre, se il rendering fallisce — Google potrebbe mantenere la pagina sorgente vuota nel suo indice.

L’ordine di preferenza ufficiale di Google

La documentazione sui reindirizzamenti delinea una gerarchia dal più al meno affidabile:

  1. Reindirizzamenti lato server — 301/308 (permanenti), 302/307 (temporanei). I migliori per tutto: visti al momento della scansione, senza ambiguità.
  2. Meta refresh — a livello HTML. Un meta refresh a 0 secondi viene trattato come un reindirizzamento permanente (come un 301); qualsiasi meta refresh ritardato viene trattato come temporaneo.
  3. Reindirizzamenti JavaScript — ultima risorsa.

Le parole di Google: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (traduzione) «Usa i redirect JavaScript soltanto se non puoi usare redirect lato server o meta refresh.» I reindirizzamenti permanenti trasmettono il segnale canonico alla destinazione; quelli temporanei mantengono l’originale nei risultati. (Come questo interagisce con la selezione canonica è trattato in Canonicalizzazione.)

La documentazione ufficiale di Google sui reindirizzamenti elenca la navigazione tramite JavaScript tra i suoi metodi di reindirizzamento permanente e afferma che la destinazione diventa il segnale di canonicalizzazione una volta che Google l’ha interpretata — quindi l’affermazione “JS redirects don’t pass PageRank” (traduzione) «i redirect JS non trasmettono PageRank» è falsa. Ciò che la documentazione non stabilisce è che il risultato sia identico, immediato o affidabile quanto un 301 lato server — descrive il segnale canonico, non una garanzia di un flusso di PageRank, posizionamento o tempistiche equivalenti. L’inquadramento onesto: un 301 trasmette il segnale al momento della scansione con quasi certezza; un reindirizzamento JS lo trasmette solo se e quando il rendering riesce, e Google non promette che il risultato corrisponderà uno a uno a quello di un 301. Quel divario — non l’equity persa — è il costo reale della scelta di JavaScript.

Questo è anche il motivo per cui i reindirizzamenti JS non sono di per sé un fattore di penalizzazione. Diventano un problema di spam solo quando vengono usati per il cloaking — mostrare ai crawler una pagina e reindirizzare gli utenti a qualcosa di diverso, o inviare gli utenti mobile a un dominio non correlato. La policy di Google sui reindirizzamenti ingannevoli riguarda quell’intento, non la tecnica.

Quando un reindirizzamento JavaScript è lo strumento giusto

Ci sono casi legittimi:

  • Piattaforme vincolate. Alcune configurazioni di hosting condiviso, CDN o CMS non ti danno accesso alle regole di reindirizzamento lato server. Un reindirizzamento JS è un fallback valido — e notevolmente, Google ha usato reindirizzamenti JS sul proprio blog Webmaster perché, come ha detto Gary Illyes, “that was the only thing we could use for 1:1 redirects, and it works on Google” (traduzione) «quella era l’unica cosa che potevamo usare per reindirizzamenti 1:1, e funziona su Google» (OnCrawl).
  • Gestione degli errori nelle SPA. Google lo approva esplicitamente: “Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code.” (traduzione) «Usa un reindirizzamento JavaScript verso un URL per cui il server risponde con un codice di stato HTTP 404.» (Google Search Central) Un’app a pagina singola che risolve una rotta non valida può reindirizzare a un endpoint 404 reale così Google elabora l’errore correttamente invece di indicizzare un soft 404.

Per le migrazioni URL permanenti, questo non è lo strumento giusto — usa un 301. Faccio lo stesso punto in migrazioni di siti: i reindirizzamenti JavaScript sono un’ ultima risorsa e Google potrebbe non vederli mai.

Generatori di siti statici: la trappola degli alias di Hugo

Una sorpresa comune: il frontmatter aliases: di Hugo ha storicamente generato pagine HTML con meta refresh, non redirect permanenti lato server — e altri generatori statici hanno fatto cose simili per impostazione predefinita. Le impostazioni predefinite dei generatori cambiano tra le versioni, quindi controlla l’output effettivo della tua versione attualmente distribuita piuttosto che assumere; se aliases: non produce redirect lato server, hai bisogno di regole di reindirizzamento a livello di piattaforma (Netlify _redirects, Cloudflare Workers, Vercel vercel.json) più (su Hugo) disableAliases: true. Tratto questo in dettaglio in Hugo SEO.

Best practice di implementazione

Se un reindirizzamento JavaScript è davvero la tua unica opzione:

  • Usa window.location.replace(), non .href. Come dice Search Engine Journal, “JavaScript redirects typically use window.location.replace() function rather than window.location.href to avoid UX redirect loops.” (traduzione) «I redirect JavaScript usano in genere la funzione window.location.replace() invece di window.location.href, per evitare cicli nell’esperienza di navigazione.» (SEJ).
  • Mettilo nel <head>, non nel <body>. I browser analizzano HTML in sequenza ed eseguono gli script quando li incontrano, quindi “position JavaScript redirects in the <head> tag rather than <body> to minimize delay” (traduzione) «posiziona i redirect JavaScript nel tag <head> anziché nel <body>, per ridurre al minimo il ritardo» (OnCrawl).
  • Reindirizza alla destinazione finale in un unico salto. Un reindirizzamento JS verso una pagina che a sua volta reindirizza altrove crea una catena; le catene sprecano budget di scansione e possono apparire in GSC come un errore di reindirizzamento.
  • Rimuovi l’URL sorgente dalla tua sitemap XML. Le sitemap dovrebbero elencare URL canonici, indicizzabili — non quelli che reindirizzano.
  • Ripunta i link interni verso la destinazione, così non passano attraverso il reindirizzamento.
  • Assicurati che Googlebot possa recuperare il JS. Se il reindirizzamento vive in uno script esterno bloccato da robots.txt, Google non può renderizzarlo e non vedrà il reindirizzamento.

Come rilevare i reindirizzamenti JavaScript

Non si annunciano come un 301 in un header, quindi devi renderizzare:

  • Un crawler con rendering JS attivo. OnCrawl raccomanda di eseguire la scansione con “rendering JavaScript abilitato (timeout minimo di 5 secondi)”; Screaming Frog e Ahrefs Site Audit possono entrambi renderizzare. Senza rendering, una pagina con reindirizzamento JS sembra solo un normale 200.
  • Chrome DevTools. La scheda Network (con “Preserve log”) mostra la navigazione lato client; l’estensione Redirect Path lo segnala anche.
  • In Search Console, un reindirizzamento JS elaborato con successo appare sotto Pagina con reindirizzamento — lo stesso stato di qualsiasi URL reindirizzato, che è normale per fonti non canoniche. Tuttavia, quell’etichetta non è garantita in ogni controllo: riflette ciò che Google ha recuperato, renderizzato, interpretato e canonizzato nel momento campionato, quindi un URL può mostrare uno stato diverso (o nessuno stato di reindirizzamento ancora) tra i controlli senza che sia un errore da parte tua.

Cosa farei davvero

Lato server prima di tutto, ogni volta. Meta refresh (0 secondi) quando puoi modificare l’HTML ma non la configurazione del server. JavaScript solo quando entrambi non sono disponibili — e poi con window.location.replace() nel <head>, una sitemap pulita e un controllo che il reindirizzamento si renderizzi effettivamente per Googlebot. Per qualsiasi cosa permanente o di alto valore, l’affidabilità extra di un 301 vale quasi qualsiasi sforzo per ottenerlo.

Add an expert note

Pin an expert quote

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