Un 301 redirect è la risposta con cui un server dice a browser e motori di ricerca che una pagina ha cambiato indirizzo in modo definitivo e che la nuova destinazione va usata al posto della vecchia.
Prima di scrivere una riga di configurazione serve una mappa: vecchio URL, nuovo URL, una riga per pagina, esportata da un crawler o dai log del server. Senza quella lista i reindirizzamenti si improvvisano mentre il traffico scende. La documentazione di Google sulle migrazioni con cambio di URL dice che Googlebot segue fino a 10 salti in una catena e consiglia di restare sotto i tre, perché ogni salto in più è attesa che paga il visitatore. Meglio puntare diretti alla destinazione finale.
Quando serve un 301
Il 301 ha senso quando il vecchio indirizzo non tornerà. I casi che capitano davvero:
- cambio di slug o di struttura degli URL, per esempio da /p?id=441 a /scarpe-trekking-uomo/
- migrazione di dominio, rebranding, fusione di due siti in uno
- passaggio da HTTP a HTTPS e scelta di una sola variante fra esempio.it e www.esempio.it
- consolidamento di due pagine che si contendono la stessa query
- prodotto fuori catalogo con un sostituto equivalente, non con un cugino alla lontana
Fuori da questi casi è lo strumento sbagliato. Una pagina offline per due settimane vuole un codice temporaneo, e di quello si occupa la voce sul redirect 302. Una pagina senza sostituto vuole un errore 404, non un rimbalzo verso la home: chi cercava un modello preciso non trova niente e torna su Google.
Quale codice di reindirizzamento usare
In italiano il confronto si ferma quasi sempre a 301 contro 302, e restano fuori i due codici che la specifica HTTP ha aggiunto per chiudere un’ambiguità. Il riferimento corrente è la RFC 9110, pubblicata a giugno 2022, che ha sostituito la RFC 7231 ancora citata da molti articoli.
| Codice | Nome | Come lo legge Google | Metodo HTTP | Quando usarlo |
|---|---|---|---|---|
| 301 | Moved Permanently | Permanente: la destinazione diventa l’URL canonico e compare nei risultati | Lo user agent può cambiare POST in GET | Cambio di URL definitivo, migrazione di dominio, HTTP verso HTTPS |
| 302 | Found | Temporaneo: nei risultati resta l’URL di partenza | Lo user agent può cambiare POST in GET | Pagina sospesa per poco, test A/B, manutenzione |
| 307 | Temporary Redirect | Temporaneo, come il 302 | Metodo e corpo della richiesta restano invariati | Reindirizzamenti temporanei su form e API, redirect interno di HSTS |
| 308 | Permanent Redirect | Permanente, esattamente come il 301 | Vietato cambiare metodo | Spostamento definitivo di endpoint che ricevono POST |
L’ambiguità è quella della colonna sul metodo. Davanti a un 301 il client può cambiare il metodo della richiesta successiva da POST a GET: la RFC 9110 lo permette per ragioni storiche e MDN Web Docs conferma che è il comportamento previsto dal Fetch Standard. Su una pagina di contenuto non cambia nulla. Su un endpoint che riceve dati da un form o da un’integrazione il 301 trasforma la POST in GET e la richiesta arriva senza payload. Il 308 serve proprio a questo: stessa permanenza, divieto di toccare il metodo. Per i motori di ricerca i due codici sono equivalenti, lo dice la pagina di Google Search Central sui reindirizzamenti.
Come si scrive, ambiente per ambiente
| Ambiente | Dove si scrive | Riga minima | Da sapere |
|---|---|---|---|
| Apache | .htaccess o configurazione del virtual host | Redirect 301 "/vecchia" "https://www.esempio.it/nuova" | Senza l’argomento di stato la direttiva restituisce un 302 |
| Nginx | server block in nginx.conf | return 301 https://www.esempio.it$request_uri; | return accetta 301, 302, 303, 307 e 308 dalla versione 0.8.42 |
| WordPress | plugin dedicato oppure hook PHP | wp_redirect( $url, 301 ); exit; | Ogni richiesta passa per PHP, quindi pesa più di una regola sul server |
| Cloudflare | Rules, poi Redirect Rules o Bulk Redirects | espressione sulla richiesta, URL di destinazione, status 301 | Risponde dal bordo, senza svegliare l’applicazione |
# Apache, singola pagina (mod_alias)
Redirect 301 "/vecchia-pagina" "https://www.esempio.it/nuova-pagina/"
# Apache, tutto il dominio da senza-www a www in HTTPS (mod_rewrite)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^esempio\.it$ [NC]
RewriteRule ^(.*)$ https://www.esempio.it/$1 [R=301,L]
# Nginx, server block dedicato
server {
listen 80;
server_name esempio.it www.esempio.it;
return 301 https://www.esempio.it$request_uri;
}
# WordPress, in un plugin (mai nel file del tema)
add_action( 'template_redirect', function () {
if ( is_404() && untrailingslashit( $_SERVER['REQUEST_URI'] ) === '/vecchio-slug' ) {
wp_redirect( home_url( '/nuovo-slug/' ), 301 );
exit;
}
} );Due trappole. In Apache la direttiva Redirect senza argomento di stato restituisce un 302, non un 301: lo dichiara la documentazione di mod_alias, e sono reindirizzamenti che Google tratta come temporanei senza che nessuno se ne accorga per mesi. Su Nginx la sintassi è documentata nel modulo ngx_http_rewrite_module, dove rewrite ... permanent fa la stessa cosa di return 301 al prezzo di una valutazione regex per richiesta.
Su WordPress il codice a mano serve raramente. Redirection, il plugin di John Godley, ha oltre 2 milioni di installazioni attive e tiene le regole nel database; Rank Math e Yoast SEO hanno un modulo equivalente. Il costo è che ogni richiesta reindirizzata attraversa PHP: oltre il migliaio di regole conviene spostarle a monte, nel vhost o nei Redirect Rules di Cloudflare, dove la risposta esce dal bordo. Se il page speed è già un problema aperto, è una delle poche ottimizzazioni che si vedono subito nel TTFB.
Che cosa passa alla nuova URL
La documentazione di Google è più sobria di quello che si legge in giro. Dice due cose: con un reindirizzamento permanente la destinazione viene usata come indicatore di canonicalizzazione e nei risultati compare il nuovo indirizzo, con uno temporaneo nei risultati resta quello di partenza. Nessuna percentuale, nessun coefficiente di dispersione.
La cifra del 15 per cento di valore perso che circola da anni non ha una fonte primaria verificabile: viene riportata di seconda mano e non compare in nessuna pagina della documentazione di Google. Quello che invece non passa dal redirect, e che viene dimenticato quasi sempre:
- i link interni, che continuano a puntare al vecchio indirizzo finché non li riscrivi nel database: il redirect li fa funzionare, ma aggiunge un salto a ogni clic
- lo storico di Search Console, che resta legato alla proprietà del vecchio dominio
- la continuità dei report in GA4, dove la vecchia pagina smette di raccogliere dati e la nuova parte da zero
- i backlink, che tecnicamente funzionano ma restano puntati altrove: su quelli che portano traffico reale vale la pena chiedere l’aggiornamento all’editore
Quanto ci mette Google a consolidare il segnale
La risposta sta nella documentazione sulle migrazioni: per un sito di medie dimensioni possono servire settimane o più prima che Google cominci a mostrare i nuovi URL al posto dei vecchi, e per i siti grandi anche oltre. Non è un interruttore: nelle prime settimane in Search Console le due versioni convivono, con le impressioni che scivolano gradualmente da una parte all’altra.
Dall’altro lato Google raccomanda di tenere i redirect attivi il più possibile, in genere almeno un anno. È il punto che salta per primo durante un restyling: si cambia hosting, il file delle regole non viene portato dietro e dopo tre mesi mille vecchi indirizzi rispondono 404. Se il traffico organico crolla dopo una migrazione, i redirect vanno controllati prima dei contenuti, e sul resto della diagnosi c’è la voce sul calo di traffico del sito.
Gli errori che costano traffico
- Catene e loop. A verso B verso C funziona, ma va riscritto come A verso C e B verso C. Il loop invece non si apre affatto: il browser si arrende dopo un numero fisso di tentativi.
- Reindirizzamento di massa verso la home. Tecnicamente un 301, nei fatti un muro: chi cercava la scheda di un prodotto atterra su una pagina che non risponde alla sua domanda e torna indietro.
- JavaScript al posto del server. Google indica i redirect JavaScript come ultima scelta, dopo quelli lato server e dopo il meta refresh, perché il rendering può non andare a buon fine.
- Cache del browser. Un 301 viene memorizzato dal client: se la destinazione è sbagliata, chi ha già visitato quella pagina continua a finire nel posto sbagliato anche dopo la correzione. Durante i test si usa un 302 e si passa al 301 quando la destinazione è confermata.
- Slash finale e maiuscole. Per il server /pagina e /pagina/ sono due indirizzi distinti, e lo stesso vale per /Pagina. È la causa più banale dei redirect che non scattano, e la voce sui problemi comuni degli URL entra nel dettaglio.
Il canonical non sostituisce il 301
Sono due segnali con pesi molto diversi. Il 301 toglie la vecchia pagina dalla circolazione: chi la chiede viene spostato e il server non restituisce più quel contenuto. Il tag canonical lascia entrambe le pagine raggiungibili e suggerisce quale indicizzare, cosa utile quando le due versioni devono restare entrambe online, come le varianti con parametri di filtro. Se la vecchia pagina non deve più servire a nessuno, il canonical è la scelta debole: su come impostarlo c’è la voce sull’URL canonico.
Domande frequenti
Il 301 dice che lo spostamento è definitivo: Google usa la destinazione come URL canonico e la mostra nei risultati. Il 302 dice che è temporaneo e nei risultati lascia l'URL di partenza. Se la vecchia pagina non tornerà, il codice corretto è il 301.
Google raccomanda di tenerlo il più a lungo possibile, in genere almeno un anno. In pratica conviene non rimuoverlo finché esistono link esterni che puntano al vecchio indirizzo, perché quel traffico continua ad arrivare anche dopo anni.
Un 301 verso una pagina davvero equivalente non comporta una perdita di posizionamento documentata da Google. I cali che si vedono dopo una migrazione nascono quasi sempre da altro: catene di redirect, destinazioni poco pertinenti, regole mancanti, contenuto riscritto insieme all'URL.
Secondo la documentazione di Google sulle migrazioni con cambio di URL, per un sito di medie dimensioni possono servire settimane o più, per i siti grandi anche oltre. Nel frattempo in Search Console vecchio e nuovo indirizzo convivono.
Con il comando curl -I seguito dall'indirizzo si leggono lo status code e l'header Location senza seguire il salto. Un crawler come Screaming Frog fa lo stesso controllo su tutta la lista e mostra le catene. Il Controllo URL di Search Console dice come lo ha visto Googlebot.
Tecnicamente sì, ma è la scelta che produce i risultati peggiori: chi cercava quel contenuto atterra altrove e torna indietro. Se non esiste una destinazione pertinente, un 404 o un 410 è più onesto verso l'utente e più chiaro per Google.
Una cosa che nel settore si dice poco: il file dei redirect invecchia male e non ha un proprietario. Dopo due migrazioni nessuno sa più quali delle ottocento regole servano ancora, nessuno osa cancellarne una e il file cresce a ogni restyling. L’abitudine che costa cinque secondi e si ripaga due anni dopo è commentare ogni blocco con la data e il motivo, come si fa in un changelog, così che chi riaprirà quel file sappia cosa sta guardando. Se la migrazione è grossa e quel file lo erediti tu, una mano esterna sulla parte SEO costa meno del traffico che si perde a rimetterla in piedi sei mesi dopo.
