301 redirect: guida ai redirect permanenti

TL;DR — Un redirect 301 invia in modo permanente chiunque (o qualunque bot) visiti un vecchio URL verso uno nuovo. È lo strumento giusto quando una pagina si sposta definitivamente: nuovo dominio, nuovo URL, passaggio da HTTP a HTTPS o fusione di due pagine in una. Configuralo sul server, punta ogni vecchio URL alla sua sostituzione reale (non soltanto alla home page) e lascialo attivo. Google dice che un 301 non fa perdere valore di ranking, quindi non c’è nulla da temere.

Che cos’è un redirect 301

Quando un browser o un motore di ricerca chiede una pagina, il server risponde con un codice di stato HTTP a tre cifre. 200 significa “ecco la pagina”. 404 significa “non trovata”. Un 301 significa “Moved Permanently” (Spostata in modo permanente): questo URL ha una nuova destinazione, usa quella.

Quindi un redirect 301 è il server che dice a tutti: l’elemento che hai richiesto ora si trova a un indirizzo diverso e il cambiamento è permanente. I visitatori vengono inviati automaticamente alla nuova pagina e i motori di ricerca aggiornano i propri dati per puntare al nuovo URL.

Quando usarne uno

Ricorri a un 301 ogni volta che l’indirizzo di una pagina cambia in modo permanente:

• Hai cambiato URL: hai rinominato una pagina, ristrutturato il sito o ripulito un URL disordinato.
• Ti sei spostato su un nuovo dominio: per un rebranding o una migrazione di sito.
• Sei passato a HTTPS: ogni URL http:// dovrebbe ricevere un 301 verso il proprio equivalente https://.
• Hai unito delle pagine: due articoli simili sono diventati uno; reindirizza quelli vecchi verso la pagina superstite.
• Hai ritirato una pagina con una sostituzione chiara: inviala all’equivalente più vicino, non a un vicolo cieco.

Il consiglio di Google è chiaro: se devi cambiare l’URL di una pagina così come viene mostrato nei risultati dei motori di ricerca, usa quando possibile un redirect permanente lato server.

L’unico numero da ignorare

Sentirai dire che un 301 “perde il 10–15 % del link juice”. È un vecchio mito. Google è esplicito: “301 and other permanent redirects don’t cause a loss in PageRank.” (traduzione) «I redirect permanenti 301 e gli altri non causano una perdita di PageRank». Non evitare quindi di reindirizzare una pagina per paura di “disperdere” valore: un 301 corretto consegna alla destinazione i segnali accumulati dal vecchio URL.

(Vedrai anche affermazioni dal tono sicuro secondo cui un 301 “passes 90–99% of link equity” (trasferisce dal 90 al 99% dell’equità dei link). Ignora anche quelle: Google non pubblica alcuna percentuale del genere e il numero è inventato.)

Tre cose da fare bene

1. Punta ogni vecchio URL alla sostituzione reale, non alla home page. Se mandi ogni pagina ritirata alla home, Google può trattarla come un errore (un “soft 404”) e non trasferire il valore. Crea una corrispondenza uno a uno tra vecchio e nuovo.
2. Usa un 301 reale, non uno falso. Un redirect eseguito esclusivamente in JavaScript o un link “fai clic qui se non vieni reindirizzato” non sono la stessa cosa: Google potrebbe non vederli. Eseguilo sul server.
3. Lascialo attivo. Google dice di mantenere i redirect in genere per almeno un anno, così tutto ha il tempo di trasferirsi. Onestamente, se puoi, mantienili per sempre.

E un 302?

Un 302 è la versione temporanea: “questa pagina si è spostata per ora, ma quella originale è ancora quella vera”. Se usi un 302 quando intendevi un 301, Google potrebbe mantenere il vecchio URL nei risultati invece del nuovo. Quando lo spostamento è permanente, usa un 301. (Esiste un confronto completo tra 301 e 302 che vale la pena leggere separatamente.)

Vuoi le configurazioni del server, i dettagli sulle tempistiche, le regole sulle catene di redirect e il modo per scovare un 301 “falso” che fallisce in silenzio? Passa alla scheda Advanced.

TL;DR — Un 301 (HTTP “301 Moved Permanently”) è una risposta lato server che sposta permanentemente un URL ed è il segnale più forte per consolidare il ranking sulla destinazione. Google dice esplicitamente che i redirect permanenti non causano una perdita in PageRank: la regola della “perdita di circa il 15% a ogni hop” è superata e non esiste una percentuale pubblicata dell’equità trasferita, quindi non inventarne una. Implementalo sul server (Apache, nginx, codice dell’applicazione) o sull’edge (Cloudflare), non con JavaScript né con un meta refresh ritardato. Reindirizza i vecchi URL al loro equivalente pertinente uno a uno, non tutti alla home, che Google potrebbe riclassificare come soft 404. Mantieni corte le catene (Google segue fino a 10 hop ma raccomanda di restare sotto circa 5; Mueller ha parlato di circa 5 per crawl). Sul server è istantaneo; il consolidamento completo di indice e segnali richiede da settimane a in genere almeno un anno.

Che cos’è davvero un 301

Un 301 è un codice di stato HTTP, “301 Moved Permanently”, restituito dal server (o dall’edge della CDN) negli header della risposta, prima di qualsiasi corpo della pagina. È questo il punto importante: un 301 reale avviene a livello di protocollo, nella risposta alla richiesta. Non è una funzione di plugin, un tag <meta> o uno snippet JavaScript: sono soluzioni alternative per i casi in cui non puoi agire sul server e si comportano in modo diverso (ne parleremo sotto).

Google dà una definizione semplice: i codici di stato 301 e 308 significano che una pagina è stata spostata permanentemente in una nuova posizione. (308 è il codice più recente per un redirect permanente e preserva anche il metodo della richiesta; ai fini SEO Google tratta 301 e 308 allo stesso modo e consiglia di usare, se possibile, redirect permanenti HTTP come 301 e 308.)

Prima di implementarne uno conviene conoscere alcuni dettagli di protocollo: una risposta 301 è memorizzabile in cache per euristica per impostazione predefinita, quindi un browser o una cache intermedia può conservarla; è proprio per questo che un redirect “corretto” può continuare a mandare i tester alla vecchia destinazione finché la cache non viene svuotata. Inoltre, poiché il 301 esiste dai tempi di HTTP/1.0, uno user agent può trasformare una richiesta POST in GET quando lo segue: non dare per scontato che un 301 preservi il metodo originale in un invio di modulo; usa invece un 308 se è importante. L’header Location deve essere soltanto un riferimento URI (tecnicamente può essere relativo), anche se in pratica puntare a un URL assoluto evita ambiguità.

Come Google elabora un 301 (canonicalizzazione e indicizzazione)

Un redirect permanente è uno dei segnali di canonicalizzazione più forti che Google possiede. Quando Googlebot segue un 301, la pipeline di indicizzazione usa il redirect come segnale che la destinazione dovrebbe essere l’URL canonico. Google conserva una registrazione di entrambe le estremità: quando reindirizzi un URL, Google tiene traccia sia della fonte del redirect, il vecchio URL, sia della destinazione, il nuovo URL. Uno degli URL sarà quello canonico; l’altro diventerà un nome alternativo dell’URL canonico.

Ecco perché a volte continui a vedere un vecchio URL nei risultati per un po’ dopo uno spostamento: Google lo conserva come “alternate name” (nome alternativo). Google dice di non farsi prendere dal panico: per uno spostamento di dominio, “it’s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal… the alternate names will fade away without you doing anything.” (traduzione) «è molto probabile che Google continui a mostrare occasionalmente i vecchi URL nei risultati, anche se i nuovi URL sono già indicizzati. È normale… i nomi alternativi scompariranno senza che tu debba fare nulla.»

Un redirect prevale su segnali di canonicalizzazione più deboli. Gary Illyes ha espresso così la gerarchia: un redirect dovrebbe avere un peso molto maggiore del fatto che la pagina sia su un URL http o https. Quindi un 301 imprevisto può sostituire in silenzio un canonical tag o una preferenza HTTPS che puntano dall’altra parte. (Approfondimento completo in canonicalization.)

Vale la pena essere precisi su ciò che questo segnale promette e non promette: un 301 è un forte segnale per la destinazione canonica, non una garanzia. Dice a Google quale URL dovrebbe essere canonico; non garantisce che quell’URL venga indicizzato, che si posizioni, che il traffico lo segua o che ogni altro segnale (link, qualità dei contenuti, autorevolezza del sito) venga trasferito automaticamente. Tratta “scelta canonica” e “risultati di indicizzazione, ranking e traffico” come domande separate: un 301 risponde direttamente solo alla prima.

Il mito del PageRank: capirlo esattamente

Questo è il fatto sui 301 che viene deformato più di tutti, quindi ecco la versione precisa.

La formulazione esatta di Google è: i redirect permanenti 301 e gli altri non causano una perdita in PageRank. Tutto qui. Non “conservi l’85%”, non “perdi il 10–15% a ogni hop”. Nessuna perdita.

La regola della “perdita di circa il 15% a ogni hop” risale a vecchie dichiarazioni, precedenti al 2016, sul damping del PageRank attraverso i redirect (attribuite comunemente a Matt Cutts). Google l’ha smentita pubblicamente intorno al 2016: secondo quanto riportato allora, Google ha smesso di applicare la diluizione del PageRank attraverso i redirect 30x e la destinazione riceve l’autorevolezza.

Il corollario che manda in confusione nella direzione opposta è questo: non affermare che un 301 trasferisca dal 90 al 99% dell’equità dei link. Google non pubblica alcun numero del genere. «Non causa una perdita in PageRank» è un’affermazione direzionale, non una percentuale: ogni percentuale precisa che trovi è folklore, non qualcosa che Google abbia mai confermato. Cita la formulazione «nessuna perdita»; non inventare mai una cifra.

Aggiungo una mia nota di cautela. Ho testato davvero l’affermazione secondo cui i “signals stick after a year” (i segnali restano dopo un anno), rimuovendo i 301 da quattro post Ahrefs con molti link e osservando il risultato (È corretto rimuovere i redirect 301 dopo un anno? Lo abbiamo testato). I domini referenti sono diminuiti sensibilmente dopo la rimozione dei redirect e il traffico organico è stato misto: un post è salito, uno è sceso, due sono rimasti più o meno stabili e un apparente “calo” in realtà precedeva la rimozione. La mia conclusione onesta è: non sono disposto ad affermare in modo conclusivo che i redirect permanenti trasferiscano valore anche dopo un anno, ma ciò che ha detto Gary sembra essere per lo più vero. Il campione è piccolo, quindi resto prudente; la conseguenza pratica è quella noiosa: non rimuovere i redirect.

Le tempistiche: tre orologi diversi

“Quanto tempo impiega un 301 a funzionare?” dipende da quale orologio intendi:

• Il server: istantaneo. Appena la regola è attiva, ogni richiesta riceve un 301 e gli utenti arrivano al nuovo URL. Nessuna attesa.
• L’indice: da giorni a settimane. Google deve rieseguire il crawl del vecchio URL, vedere il redirect ed elaborare la destinazione. La formulazione di Google è che un sito piccolo o medio può richiedere alcune settimane per spostare la maggior parte delle pagine, mentre i siti grandi richiedono più tempo; la visibilità dei contenuti nella Ricerca può oscillare temporaneamente durante lo spostamento. È normale.
• Il consolidamento completo dei segnali: in genere almeno un anno. Google consiglia di mantenere i redirect il più a lungo possibile, in genere almeno 1 anno: questo periodo permette di trasferire tutti i segnali ai nuovi URL e, dal punto di vista degli utenti, vale la pena valutarne il mantenimento indefinito. È la stessa cifra di un anno indicata da Illyes quando ha detto che ai segnali serve circa un anno per passare completamente dalla fonte alla destinazione.

Regola pratica: mantieni i 301 per almeno un anno e, se gli URL non ti costano nulla, in realtà conservali per sempre.

Implementare un 301

Fallo il più vicino possibile al server. Ecco i quattro percorsi che coprono quasi tutti i casi. (Sono illustrativi: adatta percorsi e hostname alla tua configurazione; la scheda Scripts contiene versioni da copiare e incollare e spiega anche come testarle.)

Esegui un backup del tuo .htaccess o della configurazione nginx prima di modificarla: una regola malformata può mandare offline l’intero sito, non solo l’URL che stai reindirizzando.

Apache (.htaccess)

Per un singolo URL con mod_alias:

Redirect permanent "/old-page" "https://example.com/new-page"

Per regole basate su pattern con mod_rewrite:

RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301,L]

nginx

location = /service {
  return 301 https://example.com/about/service;
}

WordPress

WordPress non ha un redirect manager integrato, quindi devi aggiungerne uno:

• Il plugin Redirection (gratuito): la scelta più comune; aggiungi fonte → destinazione in un’interfaccia, senza codice.
• Yoast SEO Premium: il suo Redirect Manager può creare automaticamente un redirect quando elimini o cambi lo slug di un URL. Nota che la versione gratuita di Yoast non ha un redirect manager (molti tutorial saltano questo dettaglio).
• A livello server: se puoi modificare direttamente .htaccess/nginx, una regola server è più veloce di un plugin basato su PHP, che viene eseguito a ogni richiesta.

Cloudflare

Se usi Cloudflare, puoi reindirizzare sull’edge, prima che la richiesta raggiunga l’origine:

• Single Redirects: regole singole nella dashboard.
• Bulk Redirects: un elenco di redirect (migliaia di coppie fonte → destinazione) applicato a livello di account. È davvero utile per una migrazione completa, perché non devi toccare affatto la configurazione dell’origine, una comodità quando il vecchio server viene dismesso.

Codice dell’applicazione (esempio PHP)

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/new-url');
exit();

I 301 “falsi”: il modo di fallire che nessuno controlla

Ecco un caso controintuitivo da comprendere bene: un URL può restituire 200 OK e continuare a reindirizzare. Come ho scritto in 11 tipi di redirect e il loro impatto SEO, un redirect può essere in corso usando qualsiasi codice di stato: una pagina può mostrare un codice di stato 200 OK ma in realtà stare ancora reindirizzando tramite JavaScript dopo il caricamento. Questo “redirect” è invisibile a un controllo rapido del codice di stato e non offre nessuna delle garanzie di un 301.

Le indicazioni di Google ordinano i metodi in questo modo:

• Lato server (301/308): la scelta migliore. Usalo ogni volta che è tecnicamente possibile.
• Meta refresh: dipende dalla tempistica. Google: un meta refresh istantaneo viene interpretato come redirect permanente; un meta refresh ritardato (che scatta dopo N secondi) viene interpretato come temporaneo. Quindi un refresh content="5;url=…" non è un sostituto del 301.
• JavaScript: ultima risorsa. Google consiglia di usare i redirect JavaScript solo se non puoi fare un redirect lato server o meta refresh; se il rendering del contenuto fallisce, Google potrebbe non vederli. Se il rendering non termina, per Google il redirect di fatto non esiste.
• Pseudo-redirect “Crypto”/solo link: da evitare. Una pagina che si limita a collegare al nuovo URL senza codice di stato né refresh potrebbe non essere riconosciuta dai motori di ricerca come redirect ufficiale. Non farci affidamento.

La lezione è questa: se ti importa della SEO, verifica che il redirect sia un vero 301 lato server, non un 200 che reindirizza nel browser. La scheda Scripts mostra come controllarlo con curl.

Errori comuni con i 301

• Reindirizzare tutto alla home page. Il classico errore. Google avverte di non reindirizzare molti vecchi URL verso un’unica destinazione irrilevante, come la home page: questo può confondere gli utenti e potrebbe essere trattato come un errore soft 404. Un soft 404 non consoliderà il segnale in modo affidabile. Reindirizza alla sostituzione pertinente; se hai davvero consolidato diverse pagine in una, va bene reindirizzarle tutte alla nuova pagina combinata.
• Catene di redirect lunghe. Google seguirà “up to 10 hops” (fino a 10 hop), ma consiglia di andare direttamente alla destinazione finale, “ideally no more than 3 and fewer than 5.” (idealmente non più di 3 e meno di 5.) Mueller ha detto che Google segue circa 5 hop per tentativo di crawl sugli URL esplorati di frequente. Anche la mia soglia pratica coincide: non mi preoccupano le catene sotto circa 5 hop, ma oltre 5 ho visto problemi. Le catene aggiungono anche latenza per gli utenti reali. Quando aggiungi un nuovo redirect, aggiorna le vecchie regole per puntare all’URL finale, non all’hop precedente.
• Usare un 302 quando intendi un 301. Un 302 dice a Google che l’URL originale dovrebbe restare quello canonico, quindi uno spostamento permanente eseguito con un 302 può lasciare indicizzato l’URL sbagliato. Google può reinterpretare alla fine un 302 di lunga durata come permanente, ma la tempistica è indefinita: come ho scritto, nessuno sa davvero quanto ci voglia, “usually a few weeks to a few months” (di solito da alcune settimane ad alcuni mesi). Usa semplicemente il codice di stato che corrisponde al tuo intento.
• Rimuovere i redirect troppo presto. Meno di un anno rischia di lasciare il valore sul vecchio URL morto. Mantienili almeno un anno, idealmente per sempre.
• Regole wildcard troppo ampie. Un catch-all per un’intera cartella spesso manda gli URL nel posto sbagliato. Mappa vecchio → nuovo uno a uno per quanto possibile.
• Dimenticare gli asset non HTML. In una migrazione reindirizza anche immagini e PDF; non è necessario reindirizzare file JS/CSS/font.
• Lasciare il vecchio host offline troppo presto. Una regola di redirect non può gestire una richiesta che non lo raggiunge: se dismetti il DNS del vecchio dominio, lasci scadere il certificato TLS o spegni il vecchio server prima che i redirect abbiano terminato il lavoro, visitatori e bot riceveranno un errore di connessione invece di un 301. Mantieni attivi DNS, certificato e regole di redirect del vecchio host per tutto il tempo in cui mantieni i redirect.

Bing

Bing tratta un 301 come un segnale forte per consolidare il ranking sul target e rimuovere il vecchio URL dal proprio indice, secondo lo stesso modello di base di Google. Le indicazioni di lunga data di Bing raccomandano di mantenere un redirect permanente per un minimo più breve (nell’ordine di alcuni mesi) rispetto all’anno circa indicato da Google e le sue indicazioni sulla migrazione dicono che normalmente i 301 sono sufficienti: il suo Site Move tool non li sostituisce. Se servi entrambi i motori (e lo fai), la scelta sicura è seguire l’indicazione più severa: veri 301 lato server, mantenuti per almeno un anno.

Dove si colloca

Un 301 è un codice di stato all’interno di una famiglia. Si abbina soprattutto al redirect 302 (la controparte temporanea): la decisione 301 vs. 302 in realtà è “lo spostamento è permanente oppure no?” È un parente stretto della canonicalizzazione (un 301 è un segnale canonico forte, ma per spostare una pagina, non per consolidare duplicati che restano entrambi attivi; per quelli serve rel="canonical"). Ed è la struttura portante di ogni migrazione del sito. Per l’insieme più ampio di codici, 302/307 temporanei, 308 permanente, 404/410 pagina rimossa, errori 5xx, consulta il cluster dei codici di stato HTTP in cui rientra questa pagina.

Riepilogo IA

Una sintesi della versione Advanced:

• 301 = HTTP “301 Moved Permanently”: una risposta lato server che sposta permanentemente un URL ed è uno dei segnali più forti di destinazione canonica che Google possiede. È un segnale, non una garanzia: da solo non promette indicizzazione, ranking o traffico. Per la SEO Google tratta 301 e 308 allo stesso modo, ma un 301 può trasformare POST in GET ed è memorizzabile per euristica per impostazione predefinita; usa 308 se devi preservare il metodo.
• Nessuna perdita di PageRank. La formulazione esatta di Google è che i redirect permanenti 301 e gli altri non causano una perdita in PageRank. La vecchia regola della “perdita di circa il 15% a ogni hop” è superata e Google pubblica nessuna percentuale dell’equità trasferita, quindi non citare mai “90–99%”.
• Tre orologi per le tempistiche: server = istantaneo; migrazione nell’indice = da giorni a settimane (più a lungo per i siti grandi); consolidamento completo dei segnali = in genere almeno un anno. Mantieni i redirect almeno un anno, idealmente per sempre.
• Implementa sul server/edge: Apache .htaccess (Redirect permanent/mod_rewrite [R=301]), nginx (return 301), WordPress (plugin Redirection o Yoast Premium; Yoast gratuito non ha un redirect manager), Single/Bulk Redirects di Cloudflare (a livello edge, senza configurazione dell’origine) o codice dell’app.
• 301 “falsi”: una pagina può restituire 200 e reindirizzare comunque tramite JavaScript (invisibile a un controllo dello stato). Meta refresh istantaneo ≈ permanente; meta refresh ritardato ≈ temporaneo; JS come ultima risorsa (Google potrebbe non vederlo se il rendering fallisce); i redirect “crypto” solo-link sono inaffidabili.
• Errori principali: reindirizzare tutto alla home (rischia un soft 404); catene lunghe (resta sotto circa 5 hop); usare un 302 per uno spostamento permanente; rimuovere i redirect troppo presto; wildcard ampie invece di una mappa uno a uno.
• Caveat di Patrick: il suo test di rimozione dei 301 dopo un anno ha mostrato risultati reali più disordinati e misti rispetto alla storia pulita “un anno e sei al sicuro”; quindi mantieni i redirect.

Documentazione ufficiale

Documentazione di fonte primaria dei motori di ricerca.

Google

• Redirect e Ricerca Google — che cos’è un 301, redirect lato server rispetto a meta refresh e JavaScript, regole temporali del meta refresh ed esempi di codice per l’implementazione (PHP, Apache, nginx).
• Spostamento del sito con modifica degli URL — l’affermazione sull’assenza di perdita di PageRank, l’indicazione di mantenere i redirect in genere almeno 1 anno, i limiti delle catene, l’avviso sul soft 404 e lo spostamento di siti piccoli e grandi.
• How to specify a canonical URL — il ruolo dei redirect come segnale di canonicalizzazione.
• Crawling and Indexing — l’hub principale per redirect, canonicalizzazione e controlli del crawl.

Bing / Microsoft

• Bing Webmaster Guidelines — la posizione di Bing su redirect e spostamenti permanenti.
• Website Migration with Bing (dicembre 2020) — il Site Move tool di Bing e la nota secondo cui normalmente i 301 sono sufficienti e lo strumento non li sostituisce.

Implementazione sulle piattaforme

• Cloudflare — Bulk Redirects — elenchi di redirect a livello di account applicati sull’edge.
• Cloudflare — URL forwarding (Redirects) overview — differenza tra Single e Bulk Redirects.
• Yoast — How to create a 301 redirect in WordPress — i percorsi specifici per WordPress, compreso il fatto che la gestione dei redirect è una funzione Premium.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google. Ogni link è un deep link che porta direttamente al passaggio citato nella pagina fonte.

Google: che cos’è un 301 e quando usarlo

• “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (traduzione) «I codici di stato 301 e 308 significano che una pagina è stata spostata permanentemente in una nuova posizione». — Google Search Central, Redirect e Ricerca Google. Vai alla citazione
• “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (traduzione) «Se devi cambiare l’URL di una pagina così come appare nei risultati dei motori di ricerca, ti consigliamo di usare quando possibile un redirect permanente lato server». Vai alla citazione
• “Use server side permanent redirects if technically possible… we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.” (traduzione) «Usa redirect permanenti lato server se tecnicamente possibile; ti consigliamo di usare, se possibile, redirect permanenti HTTP come 301 e 308». — Documentazione Google Search Central, Spostamento del sito con modifica degli URL. Vai alla citazione

Google: PageRank/consolidamento (la colonna vertebrale dell’accuratezza)

• “301 and other permanent redirects don’t cause a loss in PageRank.” (traduzione) «I redirect permanenti 301 e gli altri non causano una perdita di PageRank». — Fonte Google Search Central: Spostamento del sito con modifica degli URL. Vai alla citazione
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (traduzione) «Google registra sia l’URL di origine sia la destinazione: uno viene scelto come canonico, mentre l’altro resta un nome alternativo del canonico». — Google Search Central, Redirect e Ricerca Google. Vai alla citazione

Google: tempistiche

• “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” (traduzione) «Mantieni i redirect il più a lungo possibile, in genere almeno 1 anno. Questo periodo permette a Google di trasferire tutti i segnali ai nuovi URL; dal punto di vista degli utenti, valuta di mantenerli indefinitamente». — Google Search Central, guida Spostamento del sito con modifica degli URL. Vai alla citazione
• “A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer… the visibility of your content in Search may fluctuate temporarily during the move. This is normal.” (traduzione) «Un sito piccolo o medio può richiedere alcune settimane per spostare la maggior parte delle pagine e i siti grandi richiedono più tempo; la visibilità dei contenuti nella Ricerca può oscillare temporaneamente durante lo spostamento. È normale». Vai alla citazione

Google: catene di redirect, soft 404 e redirect falsi

• “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects… we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (traduzione) «Sebbene Googlebot possa seguire fino a 10 hop in una catena di più redirect, consigliamo di reindirizzare direttamente alla destinazione finale. Se non è possibile, mantieni basso il numero di redirect nella catena, idealmente non più di 3 e meno di 5». Vai alla citazione
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” (traduzione) «Non reindirizzare molti vecchi URL verso un’unica destinazione irrilevante, come la home del nuovo sito. Questo può confondere gli utenti e potrebbe essere trattato come un errore soft 404». Vai alla citazione
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (traduzione) «Usa i redirect JavaScript solo se non puoi usare redirect lato server o meta refresh; se imposti un redirect JavaScript, Google potrebbe non vederlo mai se il rendering del contenuto fallisce». — Google Search Central, Redirect e Ricerca Google. Vai alla citazione
• “Google differentiates between two kinds of meta refresh redirects.” (traduzione) «Google distingue tra due tipi di redirect meta refresh». “Google Search interprets instant meta refresh redirects as permanent redirects… Google Search interprets delayed meta refresh redirects as temporary redirects.” (traduzione) «Google Search interpreta i redirect meta refresh istantanei come redirect permanenti; interpreta quelli ritardati come redirect temporanei». Vai alla citazione

Checklist per implementare un redirect 301

Un passaggio da eseguire prima, durante e dopo aver attivato un redirect permanente (o un gruppo di redirect):

Prima

• Conferma che lo spostamento sia davvero permanente: se è temporaneo, ti serve un 302, non un 301.
• Crea una mappa uno a uno dal vecchio URL → al nuovo URL più pertinente (non dal vecchio URL → alla home page).
• Per i consolidamenti, decidi l’URL unico superstite verso cui reindirizzare ogni gruppo.
• Pianifica di reindirizzare anche immagini e PDF (escludi file JS/CSS/font).

Implementazione

• Fallo lato server (Apache/nginx/app) o sull’edge (Cloudflare), non tramite JavaScript o meta refresh ritardato.
• Preferisci regole uno a uno ai wildcard generici di cartella che possono mandare gli URL nel posto sbagliato.
• Punta ogni regola alla destinazione finale, così non crei catene.
• Su WordPress usa il plugin Redirection o Yoast Premium (Yoast gratuito non ha un redirect manager), oppure una regola server.

Verifica

• Controlla che ogni vecchio URL restituisca un vero 301 (non 200, non 302, non un redirect JS): consulta la scheda Scripts per i controlli con curl.
• Conferma che non ci siano catene oltre circa 5 hop; riduci quelle presenti a un unico hop.
• Controlla che il target restituisca 200, non un altro redirect o un 404.
• Prova un URL con query string, frammento, slash finale o maiuscole/minuscole miste: le regole possono eliminarli o alterarli in silenzio invece di trasferirli.
• Controlla a campione gli URL reindirizzati in GSC URL Inspection per vedere come li risolve Google.
• Per una migrazione, esegui un crawl del sito (Ahrefs Site Audit/Screaming Frog) per trovare loop e catene di redirect, link interni dimenticati, vecchi URL rimasti nella sitemap e asset reindirizzati.

Dopo

• Lascia i redirect attivi in genere per almeno un anno, idealmente per sempre.
• Aspettati che il vecchio URL rimanga nei risultati per un po’ (“alternate name” (nome alternativo)): è normale, non rimuovere il redirect per forzarlo a sparire.

Rilevare e testare i 301

Controllalo con il Redirect Checker:

1. Incolla l’URL che stai testando nel campo per un singolo URL (oppure passa alla modalità batch per un massimo di 20 URL alla volta).
2. Fai clic su Check redirects per tracciare l’intera catena.
3. Leggi il codice di stato del primo hop e il punto del verdetto: un redirect permanente reale mostra 301 (o 308) lungo il percorso; un 302/307 intermedio o una gravità “chain” sopra il verde significa che non è un 301 pulito a un solo hop.

Il punto di questi controlli è rispondere a una domanda: questo URL restituisce davvero un 301 lato server o qualcosa mi sta mentendo? (Ricorda: una pagina può restituire 200 OK e reindirizzare comunque nel browser tramite JavaScript.)

Non testare soltanto l’URL nudo: ripeti il controllo su una versione con query string, un #fragment, slash finale o maiuscole/minuscole diverse. Nessuna disposizione della specifica HTTP garantisce che una regola di riscrittura li trasferisca: è un dettaglio dell’implementazione della regola specifica e una RewriteRule o una corrispondenza di pattern può eliminare in silenzio query string o frammento presenti nell’URL originale.

Vedere il codice di stato grezzo e la catena di redirect (curl)

macOS/Linux/WSL

# Show response headers only — look for "HTTP/… 301" and the "location:" target
curl -sI https://example.com/old-page

# Follow the whole chain and print each hop's status + final URL
curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

# Print every status code in the chain (catches multi-hop chains)
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

Un redirect permanente pulito ha questo aspetto: HTTP/1.1 301 Moved Permanently (oppure HTTP/2 301) with a single location: header pointing at the final URL. If you see 302, è temporaneo. Se vedi 200 ma il browser finisce comunque altrove, è un redirect “falso” in JavaScript/meta refresh.

Windows (PowerShell)

# MaximumRedirection 0 stops at the first hop so you can read its status code
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 0 -SkipHttpErrorCheck
$r.StatusCode              # 301 for a permanent redirect
$r.Headers.Location        # the target URL

Intercettare un redirect “falso” in JavaScript

curl vede solo la risposta del server, non JavaScript. Se curl dice 200 ma la pagina sposta comunque l’utente in un browser reale, il redirect è lato client. Confermalo in Chrome DevTools:

1. Apri DevTools → Network e seleziona Preserve log.
2. Carica il vecchio URL.
3. Se la richiesta principale mostra Status 301 (o 308), è un redirect reale del server. Se la prima richiesta è 200 e compare una voce di navigazione successiva, è un redirect JS/meta refresh, non un vero 301.

Apache .htaccess

# Single URL (mod_alias)
Redirect permanent "/old-page" "https://example.com/new-page"

# Pattern / regex rule (mod_rewrite) — R=301 makes it permanent, L stops processing
RewriteEngine on
RewriteRule "^old-section/(.*)$" "https://example.com/new-section/$1" [R=301,L]

# Force HTTP → HTTPS for the whole site
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

nginx

# Single URL
location = /old-page {
  return 301 https://example.com/new-page;
}

# Whole-path prefix
location /old-section/ {
  return 301 https://example.com/new-section/;
}

# Force HTTP → HTTPS
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

WordPress (senza plugin: functions.php, usare con cautela)

// Runs on every request; a server rule or the Redirection plugin scales better.
add_action( 'template_redirect', function () {
    if ( is_page() && get_query_var( 'name' ) === 'old-page' ) {
        wp_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

Per la maggior parte dei siti WordPress, il plugin Redirection o il Redirect Manager di Yoast Premium sono la scelta pratica: niente codice e Yoast Premium può creare automaticamente un 301 quando cambi o elimini un URL.

Cloudflare (edge, senza configurazione dell’origine)

I Single Redirects di Cloudflare sono integrati nella dashboard (Rules → Redirect Rules). Per una migrazione, un elenco di Bulk Redirects prende un CSV a due colonne fonte → destinazione e lo applica a livello di account sull’edge: è il modo più veloce per spostare migliaia di URL senza toccare la configurazione del server d’origine.

Errori con i 301 che trasformano uno spostamento pulito in un pasticcio

Reindirizzare ogni vecchio URL alla home page

Un catch-all irrilevante confonde gli utenti e può essere trattato come un soft 404. Mappa ogni vecchio URL verso la sostituzione reale più vicina; restituisci 404 o 410 quando non esiste una sostituzione.

Aggiungere la nuova destinazione alla fine di una vecchia catena

La catena vecchio → precedente → attuale aggiunge latenza e altri punti di possibile errore. Aggiorna la regola più vecchia in modo che punti direttamente alla destinazione finale 200.

Lasciare un 302 su uno spostamento permanente

Un codice temporaneo chiede ai motori di ricerca di preferire l’URL fonte. Usa un vero 301 o 308 lato server quando lo spostamento è permanente, poi verifica lo stato sul filo.

Rimuovere il redirect appena compare il nuovo URL

Il movimento nell’indice non equivale al consolidamento completo dei segnali. Google raccomanda di mantenere i redirect il più a lungo possibile, in genere almeno un anno; conservarli a tempo indefinito è meglio per gli utenti e per i vecchi link quando il costo operativo è basso.

Fidarsi di una wildcard ampia senza testare le destinazioni

Una regola per un’intera cartella può mandare URL non correlati alla pagina sbagliata. Inizia con una mappa uno a uno, testa i casi limite e usa i pattern solo per strutture URL in cui la trasformazione fonte-destinazione è davvero coerente.

Dimenticare le risorse non HTML

Anche immagini e PDF possono avere link e traffico. Includi nella mappa gli asset spostati quando hanno sostituzioni pertinenti; non reindirizzare alla cieca ogni richiesta JS, CSS o font.

Verificare una mappa di redirect prima del deploy

Incolla un CSV che contenga almeno source_url e target_url. Quando disponibili, aggiungi stato attuale di fonte e destinazione, tipo di contenuto, titolo della pagina e categoria tematica.

Audit this proposed permanent redirect map.

For each row:
1. Flag homepage or other catch-all targets that are not demonstrably relevant.
2. Flag duplicate sources, missing targets, source=target loops, and likely chains where a
   target also appears as a source.
3. Compare source and target titles/categories only from the supplied data and label the
   mapping relevant, questionable, or insufficient evidence.
4. Recommend one action: keep the 1:1 mapping, map to a closer replacement, return 404/410,
   or investigate manually.

Do not invent replacement URLs or assume a target returns 200 unless the data says so.
Return: critical blockers, row-by-row findings, then the exact URLs to test after launch.

PASTE REDIRECT CSV HERE

Il modello dei tre orologi per un 301

“Quanto tempo impiega un 301?” non ha una risposta unica perché tre sistemi avanzano secondo orologi diversi. Nomina l’orologio prima di interpretare il risultato.

Il modello evita due comuni errori di categoria: trattare una regola server funzionante come prova che l’indicizzazione sia terminata e trattare un risultato di ricerca cambiato come permesso di eliminare la regola. Valida ogni orologio con le sue prove.

Strumenti per implementare e controllare i 301

Strumenti gratuiti di Patrick

• Redirect Checker: controlla un URL o un batch rapido e mostra il primo stato, ogni hop e la destinazione finale. Usalo per la verifica veloce “è un vero 301 a un solo hop?”.
• Redirect Chain Mapper: diagnostica che cosa cambia a ogni hop ed esporta regole di pulizia per Cloudflare, Apache o nginx. Usalo quando è la catena stessa a dover essere ridotta.
• Bulk HTTP Status Code Checker: testa fino a 500 URL mappati, filtra le fonti non-301 e le destinazioni non-200 ed esporta il set QA del lancio.

Controlli di ricerca e infrastruttura

• Google Search Console URL Inspection: conferma che Google abbia recuperato il vecchio URL come redirect e controlla la selezione canonica sulla destinazione.
• Log del server/CDN: verifica che le richieste reali di Googlebot ricevano la stessa regola degli utenti.
• Crawler dell’intero sito: trova link interni dimenticati, vecchie voci della sitemap, loop, catene e asset reindirizzati dopo una migrazione.

Mettiti alla prova: redirect 301

Cinque domande rapide sui redirect permanenti. Scegli una risposta per ciascuna domanda, poi controlla.

Dimostrare che il redirect ha funzionato davvero

Hai attivato il 301. Questi sono i controlli che separano “la regola è nel file di configurazione” da “Google sta consolidando il vecchio URL sul nuovo”. Eseguili in ordine: il primo è istantaneo, l’ultimo richiede settimane.

Test 1 — Il vecchio URL restituisce un vero 301 del server

• Test da eseguire: incolla il vecchio URL nel Redirect Checker (oppure esegui curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-url).
• Risultato atteso: il primo hop è 301 (o 308) con un header location: e l’URL finale restituisce 200. Un hop, pulito.
• Interpretazione del fallimento: un 200 sul vecchio URL significa che è un redirect “falso” JavaScript/meta refresh, non un 301 del server; un 302/307 significa che per errore hai pubblicato il codice temporaneo.
• Finestra di monitoraggio: immediata: il server risponde appena la regola è attiva.
• Trigger di rollback: il checker mostra una catena oltre circa 5 hop o un loop: rimuovi la regola e ricollega vecchio → destinazione finale uno a uno prima di ripubblicare.

Test 2 — Google ha visto il redirect e scelto il nuovo URL

• Test da eseguire: esegui URL Inspection in Google Search Console sul vecchio URL.
• Risultato atteso: lo stato mostra “Page with redirect” (traduzione) «Pagina con redirect» e l’ispezione del nuovo URL mostra che è indicizzato con se stesso come canonico scelto da Google.
• Interpretazione del fallimento: se settimane dopo il vecchio URL è ancora “Submitted and indexed” (traduzione) «Inviata e indicizzata» con se stesso come canonico, Google non riesce a recuperare il redirect oppure un segnale in conflitto (canonical tag, sitemap, link interni) punta ancora a quello.
• Finestra di monitoraggio: da giorni ad alcune settimane per un sito piccolo/medio, più a lungo per quelli grandi. Google dice che la visibilità può oscillare durante lo spostamento: è normale.
• Trigger di rollback: non rimuovere il redirect per “correggere” un vecchio URL persistente: Google lo conserva come nome alternativo e svanirà da solo. Riesamina solo se il nuovo URL non viene mai indicizzato.

Test 3 — La migrazione non ha lasciato il traffico senza destinazione

• Test da eseguire: passa i vecchi URL mappati in batch attraverso il Redirect Checker (fino a 20 alla volta) o un crawl completo del sito e osserva le pagine migrate nel rapporto Performance di GSC.
• Risultato atteso: ogni URL mappato è un singolo hop verso un 200 e clic e impression sulla destinazione recuperano entro alcune settimane verso i livelli precedenti dei vecchi URL.
• Interpretazione del fallimento: un calo persistente di solito indica una mappa difettosa (vecchio URL → pagina sbagliata o irrilevante, che Google può trattare come soft 404), non una “dispersione” di PageRank da parte del redirect: un 301 corretto non causa una perdita di PageRank.
• Finestra di monitoraggio: 2–4 settimane di dati GSC prima che il trend sia affidabile; confronta una finestra prima/dopo omogenea, non il rumore giorno per giorno.
• Trigger di rollback: un calo chiaro e persistente delle impression sull’insieme migrato che coincide con la data del lancio: riesamina la mappa uno a uno prima di attribuire il problema al redirect.

Cronologia modifiche