Redirect 301 vs 302: la regola pratica che uso per non perdere ranking
Sono Jeansy Sese, consulente SEO e GEO a Pisa. Il redirect è l’istruzione con cui un server dice al browser e al motore di ricerca che un contenuto si trova a un altro indirizzo. I due codici che contano nella pratica sono il 301 (spostamento permanente) e il 302 (spostamento temporaneo), e la differenza tra i due non è un dettaglio tecnico: usare quello sbagliato significa disperdere segnali di ranking accumulati in anni. In questo articolo definisco cosa fanno i due redirect, ti do la regola pratica che applico per scegliere, mostro gli esempi.htaccess pronti da usare e gli errori che incontro più spesso negli audit tecnici.
La regola pratica, subito: se il contenuto non tornerà al vecchio indirizzo, il redirect è 301. Il 302 si usa solo quando il ritorno è previsto e ha una data. Tutto il resto dell’articolo è il contesto che rende questa regola affidabile anche nei casi ambigui.
Indice
- Cosa fa un redirect 301 e cosa fa un 302
- La regola pratica per scegliere tra 301 e 302
- Quando uso il 301: i casi concreti
- Quando uso il 302 (e quando è un errore)
- Esempi.htaccess pronti all’uso
- Gli errori di redirect che vedo negli audit
- Domande frequenti su redirect 301 e 302
Cosa fa un redirect 301 e cosa fa un 302
Il redirect 301 comunica uno spostamento permanente: dice al motore di ricerca che il vecchio URL non esiste più e che il nuovo indirizzo è il suo sostituto definitivo. Google, ricevendo un 301, trasferisce al nuovo URL i segnali accumulati dal vecchio (link in ingresso, storico, rilevanza) e nel tempo sostituisce il vecchio indirizzo nell’indice con il nuovo.
Il redirect 302 comunica uno spostamento temporaneo: dice al motore che il contenuto risponde altrove per ora, ma che il vecchio URL tornerà attivo. Google quindi tende a mantenere il vecchio URL nell’indice e a non consolidare i segnali sul nuovo, perché l’istruzione dichiara che la situazione è provvisoria.
La differenza operativa è tutta qui: il 301 trasferisce e consolida, il 302 conserva e attende. Nessuno dei due “perde” pagerank per definizione, ma il codice sbagliato manda al motore un’informazione falsa sulla natura dello spostamento, e le informazioni false hanno sempre un costo. Da questa differenza nasce la regola che uso per scegliere.
La regola pratica per scegliere tra 301 e 302
La regola che applico è una domanda singola: il vecchio URL tornerà a servire questo contenuto? Se la risposta è no, o “non lo so”, il redirect è 301. Se la risposta è sì, con una scadenza precisa e pianificata, il redirect è 302.
Il punto debole di molte decisioni è il “non lo so”: l’istinto suggerisce il 302 “per prudenza”, per tenersi aperta la porta. È l’istinto sbagliato. Un 302 lasciato in piedi per mesi congela la transizione: il vecchio URL resta in un limbo, il nuovo non riceve il consolidamento pieno, e i segnali restano divisi tra due indirizzi. La prudenza vera è dichiarare la realtà: se non hai una data di ritorno, lo spostamento è permanente, e la dichiarazione corretta è il 301.
Vale anche la direzione inversa della regola: mai usare un 301 per situazioni davvero temporanee, come una promozione o una manutenzione. Il 301 viene messo in cache in modo aggressivo da browser e CDN, e “riportare indietro” un permanente è lento e sporco. Vediamo i casi concreti in cui ciascun codice è quello giusto.
Quando uso il 301: i casi concreti
Il 301 è il redirect di quasi tutti gli scenari SEO reali. Lo uso in questi casi: cambio di dominio (rebrand, migrazione), cambio di slug o di struttura URL, passaggio da HTTP a HTTPS, consolidamento di www e non-www, unione di due pagine che si cannibalizzano, eliminazione di una pagina con un sostituto pertinente.
Il caso più frequente nel mio lavoro è il cambio di slug durante la riscrittura di contenuti datati: il nuovo titolo merita un nuovo URL, e il 301 dal vecchio slug trasferisce lo storico senza ripartire da zero. Il secondo caso più frequente è il consolidamento: due articoli che competono sulla stessa query vengono uniti nel più forte, e il più debole viene rediretto con un 301 verso il superstite.
Una condizione conta più del codice: la pertinenza della destinazione. Un 301 verso una pagina non pertinente (per esempio, tutti i vecchi articoli verso la homepage) viene trattato da Google come un soft 404, cioè come una pagina eliminata, e i segnali non si trasferiscono. Il redirect giusto va alla pagina che risponde allo stesso intento, o alla più vicina possibile. Ci sono poi le situazioni, poche, in cui il temporaneo è la scelta corretta.
Quando uso il 302 (e quando è un errore)
Il 302 è corretto in tre scenari: una promozione o landing stagionale che sostituisce temporaneamente una pagina (con data di fine), un test A/B lato server che smista il traffico per un periodo definito, una manutenzione programmata che reindirizza a una pagina di cortesia. In tutti e tre i casi la caratteristica comune è la scadenza: si sa quando il vecchio URL tornerà a rispondere.
Il 302 diventa un errore quando è la scelta di default: molti plugin e molti sviluppatori impostano 302 perché è il comportamento predefinito di vari framework e del modulo rewrite quando il codice non è specificato. Il risultato è che migrazioni intere viaggiano su redirect temporanei, e la transizione dei segnali non si completa mai in modo pulito.
Il controllo è semplice e va fatto sempre dopo ogni messa in produzione: una richiesta con curl o con un crawler (Screaming Frog) rivela il codice reale restituito dal server, che non sempre coincide con l’intenzione di chi ha scritto la regola. Come si scrivono regole corrette è l’oggetto della prossima sezione.
Esempi.htaccess pronti all’uso
Su Apache (l’ambiente della maggior parte dei siti WordPress italiani) i redirect si gestiscono nel file.htaccess. Questi sono i pattern che uso, pronti da adattare:
Redirect 301 di una singola pagina:
`Redirect 301 /vecchia-pagina/ https://www.tuosito.it/nuova-pagina/`
Redirect 301 di un cambio slug con RewriteRule:
`RewriteRule ^vecchio-slug/?$ /nuovo-slug/ [R=301,L]`
Consolidamento non-www verso www (o viceversa), tutto il dominio:
`RewriteCond %{HTTP_HOST} ^tuosito\.it [NC]`
`RewriteRule ^(.*)$ https://www.tuosito.it/$1 [R=301,L]`
Passaggio da HTTP a HTTPS:
`RewriteCond %{HTTPS} off`
`RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]`
Redirect 302 per una promozione temporanea:
`Redirect 302 /offerta/ https://www.tuosito.it/promo-estate/`
Due avvertenze da esperienza diretta. Prima: nelle RewriteRule il flag R senza codice esplicito produce un 302, quindi `[R=301,L]` va sempre scritto per intero. Seconda: l’ordine delle regole conta, e una regola generica messa prima di una specifica la annulla. Dopo ogni modifica verifico i codici reali con un crawl, perché il file.htaccess non perdona le sviste. Le sviste, appunto: gli errori ricorrenti meritano una sezione dedicata.
Gli errori di redirect che vedo negli audit
Negli audit tecnici gli errori di redirect sono tra i problemi più frequenti e più sottovalutati. Questa tabella riassume i cinque che incontro più spesso, il danno che fanno e la correzione:
| Errore | Danno | Correzione |
|---|---|---|
| 302 usato come permanente | Segnali mai consolidati sul nuovo URL | Sostituire con 301 |
| Catene di redirect (A porta a B che porta a C) | Dispersione di segnali e crawl budget, latenza | Puntare A direttamente a C |
| Redirect loop (A porta a B che riporta ad A) | Pagina irraggiungibile, errore per utenti e bot | Rivedere le regole in conflitto |
| Redirect di massa verso la homepage | Trattato come soft 404, segnali persi | Ogni URL verso la pagina pertinente |
| Redirect dimenticati dopo una migrazione | 404 su URL storici con link in ingresso | Mappa completa vecchio-nuovo prima del cambio |
Le catene meritano un’attenzione particolare perché nascono da sole: ogni migrazione ne aggiunge un anello (HTTP verso HTTPS, poi non-www verso www, poi vecchio slug verso nuovo), e dopo tre ristrutturazioni un URL storico può attraversare quattro salti. Ogni salto costa tempo di caricamento e diluisce il segnale: la pulizia periodica delle catene è manutenzione, come lo è il controllo dei Core Web Vitals su WordPress, e va nel calendario tecnico del sito.
Il monitoraggio continuo chiude il cerchio: i redirect rotti o anomali emergono nel rapporto Indicizzazione di Search Console, che va letto con metodo. Il workflow settimanale che uso è descritto nella guida su Google Search Console.
Domande frequenti su redirect 301 e 302
Il redirect 301 fa perdere pagerank?
No, il 301 è il metodo corretto per trasferire i segnali: Google ha confermato che il 301 non disperde pagerank verso la destinazione pertinente. La perdita avviene con le catene di redirect, con le destinazioni non pertinenti (trattate come soft 404) e con i redirect temporanei usati al posto dei permanenti.
Quanto tempo serve perché un 301 trasferisca il ranking?
Servono settimane, in alcuni casi mesi: Google deve ricrawlare il vecchio URL, registrare il redirect, trasferire i segnali e sostituire l’indirizzo nell’indice. Per una singola pagina il passaggio si completa in genere in poche settimane; per una migrazione di dominio intera i tempi si allungano con la dimensione del sito.
Posso rimuovere un redirect 301 dopo un po’ di tempo?
La regola prudente è mantenerlo il più a lungo possibile, almeno un anno, e per sempre se il vecchio URL ha link in ingresso da altri siti. Rimuovere un 301 troppo presto riapre un 404 su un indirizzo che utenti e siti terzi ancora linkano, e il segnale trasferito non è detto che resti consolidato.
Google tratta il 302 come un 301 se resta attivo a lungo?
Sì, con il tempo Google può interpretare un 302 persistente come uno spostamento di fatto permanente e consolidare i segnali. È però un comportamento correttivo dai tempi non prevedibili: affidarsi a questa tolleranza significa lasciare la transizione in un limbo per mesi. La dichiarazione corretta fin dall’inizio resta il 301.
Che differenza c’è tra redirect 301 e canonical?
Il redirect sposta l’utente e il bot su un altro URL: il vecchio indirizzo smette di essere visitabile. Il tag canonical lascia entrambe le pagine visitabili e suggerisce a Google quale versione indicizzare. Il 301 si usa quando il vecchio URL deve sparire, il canonical quando le due versioni devono coesistere (per esempio con parametri di tracciamento).
I redirect contano anche per la sicurezza del sito?
Sì, e in due direzioni: i redirect corretti (HTTPS forzato) proteggono gli utenti, mentre i redirect malevoli iniettati da un malware dirottano il traffico a insaputa del proprietario. Ho documentato un caso reale di cloaker che reindirizzava i visitatori nel caso studio sulla bonifica security-SEO: il controllo periodico dei redirect è anche una verifica di integrità.
Se hai una migrazione in vista, o il sospetto che i redirect del tuo sito stiano disperdendo segnali accumulati in anni, il punto di partenza è una verifica tecnica reale. Prenota l’Audit di Visibilità, scrivimi su WhatsApp o invia una mail a info@seosese.com.
