Un redirect è un reindirizzamento che porta automaticamente un utente o un crawler da un URL a un altro. Serve quando una pagina cambia indirizzo, un contenuto viene spostato, un dominio viene migrato oppure più versioni dello stesso URL devono convergere verso una destinazione preferita.
La parte delicata non è impostare lo spostamento: è scegliere quello corretto e indirizzarlo verso la pagina giusta. Un reindirizzamento permanente usato per una situazione temporanea comunica qualcosa di diverso da ciò che realmente sta accadendo; allo stesso modo, inviare tutte le pagine eliminate verso la homepage non è una soluzione SEO universale.
I codici più comuni sono 301, 302, 303, 307 e 308. Per la maggior parte dei normali spostamenti di pagine web incontrerai soprattutto 301 e 302, ma conoscere anche 307 e 308 diventa importante quando vuoi capire cosa succede realmente a livello HTTP.
In questa guida vediamo come funzionano questi meccanismi, quale tipo scegliere, come interpretarli in ottica SEO, quando non usarli e come controllare che l’implementazione sia corretta.
Cos’è un redirect e cosa succede quando un URL viene reindirizzato
Quando digiti un indirizzo nel browser o fai clic su un link, il client invia una richiesta al server che ospita quella risorsa.
In condizioni normali il server restituisce la pagina richiesta, spesso con uno status HTTP 200 OK. Se invece quell’URL è stato reindirizzato, il server può rispondere con un codice della famiglia 3xx e indicare una nuova destinazione attraverso l’header HTTP Location.
Il flusso, semplificando, diventa:
URL A → risposta 301 → Location: URL B → richiesta URL B → risposta 200
Il browser segue quindi il nuovo indirizzo e mostra la pagina B. Anche i crawler dei motori di ricerca possono seguire il reindirizzamento e utilizzare quell’informazione per comprendere cosa è successo alla vecchia risorsa.
La documentazione di Google sui redirect distingue esplicitamente tra spostamenti permanenti e temporanei e raccomanda, quando possibile, le soluzioni lato server.
Redirect, reindirizzamento URL e URL forwarding indicano la stessa cosa?
Nel linguaggio comune, espressioni come redirect, reindirizzamento URL, URL redirect e URL forwarding vengono spesso utilizzate per descrivere lo stesso meccanismo generale: una richiesta rivolta a un indirizzo viene inoltrata verso un altro.
Tecnicamente, però, è più utile chiedersi come viene realizzato il reindirizzamento e quale semantica comunica.
Una risposta HTTP lato server non è la stessa cosa di uno spostamento eseguito tramite JavaScript. Un 301 non comunica la stessa intenzione di un 302. E un redirect verso una pagina sostitutiva pertinente è molto diverso da un inoltro generico alla homepage.
Questa distinzione conta soprattutto quando lo spostamento deve accompagnare una modifica strutturale del sito.
Perché un redirect non è semplicemente un link
Un link lascia all’utente la scelta di fare clic. Il documento originale viene comunque caricato.
Il meccanismo interviene invece prima che la destinazione originale venga normalmente mostrata: il client riceve l’indicazione di raggiungere un altro URL.
Per questo i due strumenti risolvono problemi differenti. Se hai cambiato definitivamente lo slug di un articolo, aggiungere semplicemente un link dalla vecchia pagina alla nuova non equivale a comunicare che la vecchia risorsa si è spostata.
Tipi di redirect: differenze tra 301, 302, 303, 307 e 308
I codici di reindirizzamento non sono intercambiabili.
La prima distinzione da fare è tra spostamento permanente e temporaneo; la seconda riguarda il comportamento della richiesta HTTP quando entrano in gioco metodi diversi da GET, per esempio POST.
| Codice | Significato | Permanente? | Metodo della richiesta | Uso tipico |
|---|---|---|---|---|
301 | Moved Permanently | Sì | In alcuni casi POST può diventare GET | URL spostato definitivamente |
302 | Found | No | In alcuni casi POST può diventare GET | Spostamento temporaneo |
303 | See Other | No | La nuova risorsa viene normalmente richiesta con GET/HEAD | Risultato di un’operazione, pattern POST/Redirect/GET |
307 | Temporary Redirect | No | Viene preservato | Redirect temporaneo quando il metodo deve restare invariato |
308 | Permanent Redirect | Sì | Viene preservato | Redirect permanente quando il metodo deve restare invariato |
La distinzione tra questi codici deriva dalla semantica HTTP definita nell’RFC 9110.
Redirect 301: spostamento permanente
Il redirect 301 comunica che la risorsa richiesta ha una nuova posizione permanente.
È la scelta più comune quando:
- modifichi definitivamente l’URL di una pagina;
- cambi la struttura dei permalink;
- fondi due contenuti e ne mantieni uno;
- sposti pagine da un vecchio dominio a uno nuovo;
- sostituisci definitivamente un URL con un altro equivalente.
Per Google, un 301 o un 308 rappresenta un forte segnale che la destinazione deve essere trattata come la nuova posizione.
Se vuoi approfondire specificamente implementazione, casi d’uso e implicazioni del codice permanente, trovi una guida dedicata al redirect 301.
Redirect 302: spostamento temporaneo
Il 302 Found indica che la risorsa è disponibile temporaneamente a un indirizzo diverso.
Ha senso quando la deviazione è realmente provvisoria e vuoi mantenere l’URL originale come riferimento per il futuro.
Un caso tipico può essere una pagina temporaneamente sostituita durante un test o una situazione in cui il contenuto originale tornerà a essere disponibile.
Sul piano SEO, la distinzione importante non è che “il 302 non passa valore”, formula troppo semplicistica, ma che Google tratta il redirect temporaneo in modo diverso da quello permanente per quanto riguarda la scelta dell’URL principale.
Per il confronto specifico puoi consultare anche la guida su redirect 301 e 302.
Redirect 303: See Other
Il codice 303 See Other ha uno scopo più specifico.
Indica che la risposta a una richiesta può essere recuperata da un’altra risorsa. Nelle applicazioni web è particolarmente utile dopo un’operazione eseguita con POST.
Immagina l’invio di un modulo:
POST /ordine → elaborazione → 303 → GET /ordine-confermato
Il browser viene indirizzato verso una pagina consultabile normalmente, evitando di ripetere accidentalmente la richiesta POST quando l’utente aggiorna la pagina.
Per un normale cambio di URL editoriale non è generalmente il codice che devi scegliere.
Redirect 307: temporaneo mantenendo il metodo HTTP
Il 307 Temporary Redirect è temporaneo come il 302, ma introduce una garanzia importante: il client non deve modificare il metodo della richiesta durante il redirect automatico.
Se la richiesta originale è POST, la richiesta verso la nuova destinazione resta POST.
Questa differenza conta soprattutto nelle applicazioni, API, form e flussi transazionali. Per la normale navigazione di pagine richieste con GET, la differenza pratica è spesso meno evidente.
Redirect 308: permanente mantenendo il metodo HTTP
Il 308 Permanent Redirect rappresenta uno spostamento permanente e mantiene il metodo HTTP.
Puoi pensarlo come il corrispettivo permanente del 307.
Per Google, 308 e 301 vengono trattati entrambi come redirect permanenti. Questo non significa però che siano identici a livello di protocollo: 308 è esplicitamente method-preserving, mentre con 301 esiste una compatibilità storica che può consentire la trasformazione di POST in GET.
Per un blog o un normale sito aziendale il 301 resta diffusissimo. In sistemi applicativi, API o flussi dove il metodo HTTP è rilevante, la differenza può diventare decisiva.
Redirect permanente o temporaneo: quale scegliere
Il codice corretto deriva da una domanda semplice:
l’URL originale deve tornare a essere la destinazione principale oppure no?
Se la risposta è no e lo spostamento è definitivo, usa normalmente una soluzione permanente. Se prevedi di ripristinare l’URL originario, ha più senso una soluzione temporanea.
| Scenario | Scelta più comune | Motivo |
|---|---|---|
| Cambio definitivo dello slug | 301 o 308 | La vecchia posizione viene sostituita |
| Migrazione permanente a nuovo dominio | 301 o 308 | Il nuovo dominio diventa la destinazione |
| Pagina spostata solo per un periodo | 302 o 307 | L’URL originale resta quello di riferimento |
| Test temporaneo con URL alternativo | 302 | Lo spostamento non è definitivo |
| POST da preservare durante uno spostamento temporaneo | 307 | Mantiene il metodo |
| POST da preservare durante uno spostamento permanente | 308 | Mantiene il metodo e comunica permanenza |
| Risultato successivo a un POST | 303 | Porta normalmente a una richiesta GET |
URL o contenuto spostato definitivamente
Se cambi per sempre:
/vecchia-guida/
in:
/nuova-guida/
il vecchio URL non deve più essere considerato la posizione principale. Un 301 è normalmente la scelta più naturale.
È però importante che /nuova-guida/ rappresenti realmente il contenuto che l’utente cercava.
La scelta non dovrebbe essere decisa soltanto perché “esiste un URL nuovo”: deve esserci una corrispondenza sostanziale fra vecchia e nuova risorsa.
Pagina temporaneamente non disponibile
Se devi deviare temporaneamente gli utenti verso una pagina alternativa e prevedi di riattivare l’URL originale, un 302 o un 307 comunica meglio questa situazione.
È un caso diverso dall’eliminazione definitiva.
Se la risorsa non tornerà più e dispone di un sostituto pertinente, una soluzione permanente è più coerente.
Cambio dominio, CMS o struttura degli URL
Una migrazione può modificare migliaia di indirizzi contemporaneamente.
Qui il lavoro non consiste nel creare un’unica regola generica e sperare che ogni URL trovi una destinazione adeguata. Serve una mappa vecchio URL → nuovo URL che conservi la corrispondenza fra le risorse.
Per un progetto di questo tipo puoi approfondire l’intero processo nella guida alla migrazione di un sito web.
Richieste POST e applicazioni: quando 307 e 308 diventano rilevanti
Nei normali articoli SEO, 307 e 308 vengono spesso liquidati come semplici alternative a 302 e 301.
Non è abbastanza.
La loro caratteristica distintiva è la preservazione del metodo della richiesta. Se un’applicazione riceve dati via POST e deve inoltrarli senza trasformare la richiesta in GET, questa differenza può evitare comportamenti inattesi.
Per un sito editoriale può essere un dettaglio marginale. Per un checkout, un endpoint API o un’applicazione può essere il motivo principale per preferire 307 o 308.
Come Google interpreta i redirect e cosa cambia per la SEO
Dal punto di vista SEO, questo meccanismo serve soprattutto a comunicare la relazione tra il vecchio URL e quello nuovo.
Google distingue gli spostamenti permanenti da quelli temporanei e utilizza questa informazione insieme ad altri segnali per stabilire quale URL considerare principale.
Redirect permanenti e canonicalizzazione
Google considera 301 e 308 redirect permanenti.
Quando una pagina viene spostata definitivamente, il passaggio rappresenta un segnale forte che la nuova destinazione deve sostituire la precedente.
È quindi scorretto pensare al 301 soltanto come a un sistema che “manda il traffico altrove”. Il meccanismo contribuisce anche a descrivere quale URL dovrebbe rappresentare quella risorsa dopo lo spostamento.
Google può comunque conservare informazioni sul vecchio URL e, in determinate circostanze, considerarlo un nome alternativo della destinazione canonica.
Cosa succede con i redirect temporanei
302 e 307 comunicano invece una situazione temporanea.
La destinazione viene raggiunta, ma il segnale non equivale a dichiarare che il vecchio URL è stato sostituito definitivamente.
Questo è il motivo per cui usare un 302 per mesi o anni su una pagina che in realtà non tornerà più non è una scelta semanticamente pulita: l’implementazione tecnica racconta una storia diversa dalla realtà del sito.
I redirect trasferiscono il “100% del link juice”?
È meglio evitare percentuali rigide.
Nella documentazione corrente Google non prescrive un modello operativo del tipo:
“301 = trasferimento garantito del 100% del valore SEO”.
I sistemi di ranking e canonicalizzazione sono più complessi di una percentuale applicata meccanicamente a ogni spostamento.
La decisione utile è un’altra: se una risorsa è stata davvero spostata, indirizzala correttamente verso la destinazione più equivalente e pertinente, aggiorna i link interni e mantieni coerenti sitemap, canonical e architettura.
Quanto tempo serve perché Google elabori un redirect
Non esiste un tempo fisso valido per ogni sito.
Google deve scansionare gli URL, osservare lo spostamento, elaborare i segnali e aggiornare progressivamente i propri sistemi. Numero di pagine, frequenza di scansione e capacità del server possono influire sui tempi.
Nelle migrazioni importanti è quindi normale che vecchi e nuovi URL non vengano sostituiti simultaneamente nei risultati.
Redirect, canonical, 404 e 410: quale soluzione usare
Una delle decisioni più importanti nella gestione degli URL è capire quando non forzare uno spostamento.
Redirect, rel="canonical", 404 e 410 non sono quattro modi diversi per fare la stessa cosa.
Usa un redirect quando esiste una vera destinazione sostitutiva
Se una pagina si è spostata o un nuovo contenuto soddisfa sostanzialmente lo stesso bisogno del precedente, una soluzione permanente è appropriata.
Esempio:
/scarpe-running-modello-x/
viene sostituito da:
/scarpe-running-modello-x-nuovo/
Se la nuova pagina rappresenta davvero lo stesso prodotto o una sostituzione coerente, il passaggio ha una logica comprensibile per utenti e motori.
Usa canonical quando più URL devono continuare a esistere
Il canonical non inoltra automaticamente il visitatore.
Serve a indicare una preferenza fra URL duplicati o molto simili che possono restare raggiungibili.
Esempio:
/prodotto?colore=rosso
e:
/prodotto/
potrebbero rappresentare varianti della stessa risorsa.
Se entrambi devono continuare a essere disponibili, lo spostamento automatico potrebbe non essere la soluzione corretta. Il canonical risolve un problema differente: indica quale versione dovrebbe essere considerata principale.
Usa 404 o 410 quando non esiste una sostituzione pertinente
Una pagina eliminata non deve essere automaticamente reindirizzata.
Se la risorsa non esiste più e non hai sul sito una pagina capace di soddisfare sostanzialmente lo stesso intento, Google indica come appropriata una risposta 404 Not Found o 410 Gone.
È una scelta spesso migliore di un inoltro artificiale verso una pagina solo vagamente correlata.
La documentazione Google sugli errori di scansione chiarisce proprio questo punto: se il contenuto è stato eliminato e non ha un sostituto simile, 404 o 410 sono risposte corrette.
Perché reindirizzare tutte le pagine eliminate alla homepage è un errore
Il redirect:
vecchia-pagina → homepage
può sembrare preferibile a un 404 perché “almeno l’utente arriva sul sito”.
Il problema è l’intento.
Chi apre un vecchio URL dedicato a un prodotto, un servizio o un tutorial si aspetta quella risorsa o qualcosa di realmente equivalente. La homepage raramente soddisfa quella richiesta.
Durante una migrazione Google raccomanda esplicitamente di evitare grandi quantità di vecchi URL reindirizzati tutti verso un’unica destinazione irrilevante: questi casi possono anche essere interpretati come soft 404.
La regola pratica è quindi:
non chiederti dove puoi mandare l’URL eliminato; chiediti se esiste davvero una pagina che sostituisce ciò che l’utente stava cercando.
Quando usare un redirect: gli scenari più comuni
Cambiare lo slug o l’URL di una pagina
È uno dei casi più semplici.
Se:
/guida-seo-vecchia/
diventa definitivamente:
/guida-seo/
imposta uno spostamento permanente dal primo URL al secondo.
Poi aggiorna anche i link interni. Lasciare il sito pieno di collegamenti che passano inutilmente attraverso vecchi passaggi significa creare hop evitabili.
Unire due o più contenuti
Supponiamo di avere:
/seo-base/
/guida-seo-principianti/
e di decidere che entrambi debbano confluire in una nuova risorsa completa:
/guida-seo/
Se il nuovo contenuto sostituisce realmente entrambi, i vecchi URL possono essere reindirizzati verso quello consolidato.
Qui lo spostamento accompagna una vera operazione editoriale: non nasconde semplicemente la cancellazione delle pagine.
Migrare un sito o cambiare dominio
Nelle migrazioni queste regole diventano parte della struttura del progetto.
Ogni vecchio URL importante dovrebbe essere mappato verso il proprio equivalente sul nuovo sito.
Un mapping corretto:
vecchiosito.it/servizi/seo/ → nuovosito.it/servizi/seo/
è preferibile a:
vecchiosito.it/servizi/seo/ → nuovosito.it/
se la pagina specifica continua a esistere.
Google raccomanda inoltre di evitare catene durante gli spostamenti e di puntare direttamente alla destinazione finale.
Passare da HTTP a HTTPS o uniformare www/non-www
Queste regole vengono utilizzate anche per consolidare versioni differenti dello stesso sito:
http://esempio.it/ → https://esempio.it/
oppure:
https://www.esempio.it/ → https://esempio.it/
L’obiettivo è fare in modo che utenti e crawler raggiungano la versione scelta come destinazione definitiva.
Prima di introdurre regole a livello server, verifica però che SSL, virtual host, CDN e configurazione del CMS siano coerenti: regole sovrapposte sono una causa frequente dei loop di redirect.
Eliminare prodotti e pagine di un ecommerce
Qui bisogna evitare gli automatismi.
Un prodotto fuori catalogo può avere scenari diversi:
- esiste un modello che lo sostituisce realmente;
- il prodotto tornerà disponibile;
- esiste una categoria molto pertinente;
- il prodotto è stato eliminato e non c’è alcun sostituto.
Soltanto il primo scenario giustifica automaticamente uno spostamento permanente verso il prodotto sostitutivo.
Reindirizzare ogni SKU eliminato alla categoria principale o alla homepage può produrre destinazioni poco utili.
Gestire contenuti temporaneamente indisponibili
Se la pagina tornerà disponibile allo stesso URL, valuta attentamente se serva realmente spostarla.
Quando il reindirizzamento temporaneo è necessario, usa una risposta coerente con la natura provvisoria dello spostamento.
Il criterio resta sempre lo stesso: il codice HTTP dovrebbe descrivere ciò che sta realmente accadendo alla risorsa.
Come creare un redirect
Il metodo migliore dipende dal server, dal CMS e dal livello a cui vuoi controllare il reindirizzamento.
Quando possibile, Google consiglia le soluzioni lato server.
Redirect lato server: la soluzione da preferire
La risposta lato server viene restituita direttamente nella risposta HTTP prima che la pagina originale venga caricata.
È generalmente più robusto di una soluzione realizzata tramite JavaScript e comunica in modo esplicito il codice di stato.
I due ambienti più comuni sono Apache e Nginx.
Redirect con Apache e .htaccess
Su server Apache puoi gestire molte regole tramite .htaccess.
Per una singola pagina, con mod_alias, un esempio semplice è:
Redirect 301 /vecchia-pagina/ https://www.esempio.it/nuova-pagina/
Per configurazioni più articolate può essere necessario mod_rewrite.
Prima di modificare .htaccess, crea sempre una copia del file: una direttiva errata può rendere il sito irraggiungibile o generare loop.
Per esempi più estesi su HTTP/HTTPS, www/non-www e regole Apache, consulta la guida al file .htaccess.
Redirect con Nginx
Su Nginx queste regole vengono normalmente configurate nei blocchi server.
Un esempio per spostare un dominio mantenendo il percorso richiesto è:
server {
listen 80;
server_name vecchiosito.it www.vecchiosito.it;
return 301 https://nuovosito.it$request_uri;
}
Dopo una modifica alla configurazione conviene verificare la sintassi e ricaricare il server soltanto se il test non segnala errori.
Redirect su WordPress
Su WordPress puoi intervenire:
- a livello server;
- tramite configurazione dell’hosting;
- con un plugin dedicato;
- in alcuni casi tramite codice applicativo.
Per una gestione editoriale quotidiana, un plugin può essere più pratico perché consente di aggiungere e monitorare i reindirizzamenti senza modificare manualmente la configurazione del server.
La scelta va però fatta in funzione del sito: una regola globale HTTP→HTTPS o di dominio ha normalmente più senso a un livello infrastrutturale, mentre quelli di singoli articoli possono essere gestiti comodamente nel CMS.
Per la procedura specifica rimando alla guida ai redirect WordPress; se vuoi scegliere lo strumento, trovi anche il confronto dei plugin per redirect WordPress.
Redirect con PHP
PHP può inviare un header Location e uno status HTTP.
Per esempio:
<?php
header('Location: https://www.esempio.it/nuova-pagina/', true, 301);
exit;
L’header deve essere inviato prima dell’output della pagina e il flusso dello script dovrebbe essere interrotto subito dopo.
Per casi applicativi e precauzioni specifiche puoi approfondire i redirect PHP.
Meta refresh e redirect JavaScript
Quando una soluzione lato server non è disponibile, esistono alternative lato client.
Un meta refresh può reindirizzare il browser da HTML, mentre JavaScript può modificare window.location.
Sono però soluzioni che, quando hai il controllo del server, non rappresentano normalmente la prima scelta per uno spostamento strutturale.
Google dichiara esplicitamente di preferire le soluzioni server-side; JavaScript viene considerato una soluzione da utilizzare quando non è possibile implementare metodi migliori.
Redirect chain e redirect loop: cosa sono e perché evitarli
Non tutti i problemi di questo tipo derivano dalla scelta sbagliata tra 301 e 302.
Due errori molto comuni sono redirect chain e redirect loop.
Come nasce una redirect chain
Una catena compare quando una richiesta attraversa più reindirizzamenti prima di raggiungere la pagina finale:
A → B → C → D
Può capitare dopo anni di modifiche agli URL.
Prima:
/servizi-seo/ → /seo/
poi:
/seo/ → /consulenza-seo/
Il vecchio URL continua così a passare attraverso una destinazione intermedia.
Se /consulenza-seo/ è ormai il target definitivo, la configurazione più pulita diventa:
/servizi-seo/ → /consulenza-seo/
Perché conviene puntare direttamente alla destinazione finale
Ogni hop richiede un’altra risposta e un’altra richiesta.
Googlebot è in grado di seguire più passaggi, ma Google raccomanda comunque di evitare catene e di inviare direttamente alla destinazione finale.
Nelle migrazioni la documentazione Google indica che Googlebot può seguire fino a dieci hop, ma raccomanda catene molto più brevi quando non possono essere evitate.
Questo è un buon esempio di distinzione tra limite tecnico e best practice: sapere che un crawler può seguire una lunga catena non significa che convenga crearla.
Come nasce un redirect loop
Un loop non è semplicemente una catena lunga.
È un ciclo che impedisce di raggiungere una destinazione finale:
A → B → A → B → ...
oppure:
HTTP → HTTPS → HTTP
Il browser interrompe la sequenza e può mostrare un errore come ERR_TOO_MANY_REDIRECTS.
Se il problema riguarda WordPress, configurazione HTTPS, plugin o CDN, trovi la procedura dedicata per risolvere ERR_TOO_MANY_REDIRECTS.
Gli errori di redirect che possono creare problemi SEO
Una regola tecnicamente funzionante può essere comunque sbagliata dal punto di vista editoriale o architetturale.
| Errore | Cosa succede | Correzione |
|---|---|---|
| Redirect verso una pagina irrilevante | L’utente non trova ciò che cercava; Google può interpretare alcuni casi come soft 404 | Scegli una destinazione realmente equivalente o usa 404/410 |
| Catena A → B → C evitabile | Aumentano hop e latenza | Reindirizza A direttamente verso C |
| Loop A → B → A | La destinazione non viene mai raggiunta | Elimina le regole in conflitto |
| 302 mantenuto per uno spostamento definitivo | Il codice comunica temporaneità | Usa un redirect permanente quando lo spostamento lo è realmente |
| Redirect creato ma link interni ancora vecchi | Ogni clic interno passa inutilmente dal redirect | Aggiorna gli href al nuovo URL |
| Vecchi URL nella nuova sitemap | La sitemap continua a segnalare indirizzi non finali | Inserisci URL canonici e destinazioni finali |
| Tutte le pagine eliminate → homepage | La destinazione spesso non soddisfa l’intento | Mappa una vera alternativa oppure restituisci 404/410 |
| Regole duplicate tra CMS, server e CDN | Possono nascere catene e loop difficili da diagnosticare | Definisci quale layer deve gestire ogni redirect |
La parte più importante è l’ultima colonna. Un audit tecnico non dovrebbe limitarsi a chiedere “restituisce 301?”, ma verificare “il comportamento finale è quello corretto per questa risorsa?”.
Come controllare se un redirect funziona correttamente
Aprire l’URL nel browser è un primo test, ma non basta.
Il browser ti mostra la destinazione finale; spesso non rende evidente quali status code e quanti passaggi siano avvenuti prima.
Controllare status code e header Location
Dal terminale puoi usare curl:
curl -I https://www.esempio.it/vecchia-pagina/
Una risposta potrebbe contenere:
HTTP/2 301 location: https://www.esempio.it/nuova-pagina/
Per seguire l’intera sequenza:
curl -IL https://www.esempio.it/vecchia-pagina/
In questo modo puoi vedere gli hop intermedi e verificare che l’ultimo URL restituisca lo status previsto, normalmente 200 per una pagina raggiungibile.
Verificare l’intera catena
Il controllo dovrebbe rispondere almeno a queste domande:
- Lo status iniziale è quello previsto?
- Il valore di
Locationpunta al target corretto? - Esistono hop intermedi evitabili?
- La destinazione finale risponde correttamente?
- Il protocollo e l’hostname finali sono quelli canonici?
- Il redirect conserva query string e percorso quando è necessario?
- Esistono loop o regole che si comportano diversamente su HTTP/HTTPS o www/non-www?
Su siti grandi non conviene svolgere questo lavoro URL per URL.
Audit dei redirect con Screaming Frog
Un crawler permette di identificare in massa status code, catene, URL interni che puntano ancora a URL intermedi ed errori 4xx.
Con Screaming Frog, per esempio, la sezione dedicata ai response code consente di separare risposte 3xx, 4xx e altre anomalie.
Un controllo particolarmente utile consiste nel trovare link interni che puntano ancora a URL reindirizzati. Correggere il link originale permette a utenti e crawler di raggiungere direttamente la destinazione definitiva.
Controllare il comportamento in Google Search Console
Dopo una modifica importante puoi utilizzare lo strumento Controllo URL di Google Search Console per analizzare come Google vede una risorsa.
La guida a Google Search Console approfondisce il monitoraggio dell’indicizzazione e dei problemi di scansione.
Per migrazioni o cambiamenti estesi, però, non basarti sul controllo di pochi URL campione: prepara una mappa completa e verifica sistematicamente gli spostamenti, la sitemap, i canonical e i link interni.
Quanto tempo mantenere un redirect
Una regola permanente non dovrebbe essere eliminata appena Google mostra il nuovo URL nei risultati.
Nelle proprie indicazioni sulle migrazioni, Google raccomanda di mantenere queste regole il più a lungo possibile e generalmente almeno un anno, così da consentire ai sistemi di elaborare i nuovi indirizzi e i segnali collegati.
Non interpretare però “un anno” come una data di scadenza automatica.
Un vecchio URL può continuare a ricevere:
- backlink;
- bookmark;
- traffico diretto;
- visite da documenti e newsletter;
- richieste da applicazioni o sistemi esterni.
Se mantenerlo non crea problemi tecnici, può avere senso conservarlo molto più a lungo.
Parallelamente conviene aggiornare i link sotto il tuo controllo affinché puntino direttamente alle nuove destinazioni. La regola deve proteggere il traffico residuo, non diventare il percorso normale della navigazione interna.
Conclusione
Una gestione efficace non è semplicemente un modo per evitare una pagina 404. È una dichiarazione sullo stato di una risorsa.
Se l’URL si è spostato definitivamente, 301 o 308 sono le scelte permanenti. Se lo spostamento è realmente temporaneo, 302 o 307 descrivono meglio la situazione. Se devi preservare il metodo HTTP, 307 e 308 offrono una semantica più precisa; il 303 risolve invece casi applicativi differenti, spesso legati alla risposta successiva a una richiesta POST.
Ma la decisione che incide di più sulla qualità del sito viene prima del codice: esiste davvero una destinazione che sostituisce il vecchio URL?
Se sì, reindirizzala direttamente alla pagina più pertinente, evita catene inutili e aggiorna i link interni. Se no, non forzare uno spostamento solo per far scomparire un 404: una risposta 404 o 410 può essere tecnicamente ed editorialmente più corretta.
È questa coerenza tra contenuto, architettura e comportamento HTTP che rende il meccanismo utile per l’utente e comprensibile ai motori di ricerca.