Reindirizzamenti: 301 vs 302, catene e migrazioni

I reindirizzamenti sono un argomento apparentemente semplice fino al momento di una migrazione di sito, quando diventano il fattore determinante che stabilisce se manterrete il vostro traffico organico o dovrete ripartire da zero.

Le regole sono poche. Gli errori sono molto costosi e quasi sempre evitabili.

I codici di stato HTTP

301 — Spostato permanentemente (Moved Permanently). I motori di ricerca trasferiscono i segnali di posizionamento alla nuova destinazione e sostituiscono gradualmente il vecchio URL nel loro indice. I browser lo memorizzano nella cache in modo molto aggressivo, spesso a tempo indefinito: ecco perché un 301 rilasciato per errore è difficile da revocare, poiché i visitatori ricorrenti continueranno a seguirlo dalla cache locale.

308 — Reindirizzamento permanente (Permanent Redirect). Identico al 301 tranne per il fatto che preserva il metodo HTTP originale. Una richiesta POST rimane POST anziché essere convertita in GET. È ideale per gli endpoint API; per le normali pagine web, il 301 rimane la scelta standard e meglio interpretata dai vari strumenti.

302 — Trovato / Temporaneo (Found). I segnali SEO rimangono associati all'URL di origine e la pagina di destinazione non viene indicizzata al suo posto. È corretto per test A/B, pagine di manutenzione temporanea e reindirizzamenti basati sull'header Accept-Language — situazioni in cui la destinazione dipende dalla singola richiesta e non rappresenta un cambio definitivo.

307 — Reindirizzamento temporaneo (Temporary Redirect). La variante del 302 che preserva il metodo HTTP originale.

L'errore comune e costoso consiste nell'utilizzare un 302 per uno spostamento permanente. Google alla fine lo comprenderà e lo tratterà come un 301, ma quel "alla fine" può richiedere mesi durante i quali il vecchio URL conserva il posizionamento mentre la nuova pagina rimane non indicizzata.

Catene di reindirizzamento

Una catena si crea quando un reindirizzamento punta a un altro reindirizzamento. Si accumulano progressivamente nel tempo:

http://example.com/vecchia-pagina
  → 301 → https://example.com/vecchia-pagina
  → 301 → https://www.example.com/vecchia-pagina
  → 301 → https://www.example.com/nuova-pagina/
  → 200

Quattro richieste HTTP prima che il browser possa visualizzare qualsiasi contenuto. Ognuna di esse era probabilmente una regola legittima aggiunta in momenti diversi da persone diverse: forzare HTTPS, impostare il canonical sul www, aggiornare il percorso dell'URL.

Qual è il costo reale di queste catene?

Non la perdita di link equity. Google ha confermato già nel 2016 che i redirect 301 trasferiscono l'intero PageRank, superando la vecchia regola del "15% perso per ogni passaggio".

Il vero costo risiede nella velocità di caricamento. Su una connessione mobile, ogni passaggio comporta un round-trip di rete completo — il DNS è già risolto, ma gli handshake TCP e TLS possono non esserlo, aggiungendo 200–400ms prima di qualsiasi rendering. Questo impatta direttamente sul Largest Contentful Paint (LCP), che è un segnale di ranking confermato e, soprattutto, un fattore primario di abbandono da parte degli utenti.

Google segue fino a circa dieci passaggi prima di interrompere la scansione. Ma i vostri utenti abbandoneranno la pagina molto prima.

La soluzione è linearizzare i percorsi: fate puntare il primo URL direttamente alla destinazione finale senza passare attraverso regole intermedie.

Il vantaggio di HSTS

Se reindirizzate da http:// a https://, ogni nuovo visitatore deve attendere quel passaggio aggiuntivo.

L'adozione di HSTS elimina questo passaggio per tutti i visitatori ricorrenti:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Il browser si collegherà direttamente via HTTPS a ogni visita successiva, senza interrogare prima la versione HTTP. Un intero round-trip eliminato su ogni caricamento di pagina per gli utenti abituali — un singolo header, guadagno tangibile.

Loop di reindirizzamento

Un ciclo infinito di redirect rende l'URL del tutto inaccessibile. Le cause più comuni:

• Un conflitto tra la regola dello slash finale (/) e una regola canonical
• Un redirect HTTPS a livello applicativo che entra in conflitto con quello del CDN
• Un reindirizzamento linguistico che rimanda alla pagina della lingua da cui è appena partito

I loop rimangono spesso nascosti finché un utente non digita l'esatto URL difettoso, che talvolta compare solo nei risultati di ricerca o in vecchi backlink. Testate gli URL specifici, non solo la homepage.

Potete tracciare qualsiasi URL passaggio per passaggio con il nostro free redirect checker — analizza ciascun salto singolarmente mostrando l'intera catena e il costo temporale associato.

L'errore di migrazione che distrugge il traffico organico

Ogni vecchio URL che riceveva traffico o backlink necessita di un 301 diretto verso il suo equivalente più affine.

Non verso la homepage generica.

Google interpreta i reindirizzamenti massivi di pagine eterogenee verso la homepage come un soft 404, azzerando quasi totalmente il passaggio di autorità. Questo è il modo più comune con cui una migrazione distrugge la visibilità organica, e si verifica perché mappare ogni singolo URL richiede precisione mentre reindirizzare tutto a / richiede una sola riga di codice.

Il procedimento rigoroso è l'unico che salvaguarda il posizionamento:

1. Effettuate una scansione completa del vecchio sito prima di toccare qualsiasi impostazione (con Screaming Frog, Sitebulb o tramite sitemap).
2. Estraete gli URL rilevanti — quelli che registrano traffico organico su Analytics e quelli che ricevono backlink su Search Console o Ahrefs.
3. Mappate ciascun URL sul corrispettivo più vicino nel nuovo sito. Evitate di rimandare a una pagina di categoria se esiste una pagina di prodotto o servizio specifica.
4. Gli URL privi di equivalente dovrebbero restituire lo stato 410 Gone, anziché un 301 verso una pagina non correlata. Il codice 410 comunica chiaramente ai motori che il contenuto è stato rimosso; un 301 forzato invia un segnale fuorviante.
5. Rilasciate i reindirizzamenti contestualmente al nuovo sito, mai a posteriori.
6. Monitorate Google Search Console per 4–6 settimane successive, controllando gli errori di scansione e la copertura dell'indice.

Il punto 4 può sembrare controintuitivo: è molto meglio informare un motore di ricerca che una pagina non esiste più piuttosto che inviarlo su un contenuto irrilevante.

Lo slash finale negli URL

/pagina e /pagina/ sono tecnicamente due URL distinti. Scegliete una convenzione chiara, reindirizzate l'altra verso di essa e assicuratevi che tutti i link interni utilizzino la forma canonica prescelta.

L'impatto principale non è il contenuto duplicato — a cui sopperisce il canonical — bensì un redirect aggiuntivo a ogni navigazione interna, causato da link interni che puntano alla variante non canonica.

Reindirizzamento versus Canonical

Utilizzate un reindirizzamento quando una pagina è stata definitivamente spostata e gli utenti devono raggiungere la nuova posizione.

Utilizzate un tag canonical quando entrambi gli URL devono rimanere raggiungibili ma solo uno deve essere indicizzato (es. un prodotto accessibile da due categorie diverse, una versione stampabile, URL con parametri di tracciamento).

Reindirizzare quando servirebbe il canonical rompe la navigazione; usare il canonical quando servirebbe un redirect lascia pagine duplicate accessibili e disorienta i motori di ricerca.

Dove configurare i reindirizzamenti

A livello di server web — file .htaccess su Apache e LiteSpeed, blocco server su Nginx. È l'opzione più veloce, perché interviene prima dell'avvio dell'applicazione.

A livello applicativo — tramite router del framework o plugin CMS. Più lento perché richiede l'avvio del backend, ma più pratico per regole dipendenti dal database.

Mai lato client. Reindirizzare con JavaScript o meta-refresh è lento, interpretato male dai motori di ricerca e inaffidabile per il passaggio dei segnali SEO.

Checklist riassuntiva

• Gli spostamenti definitivi utilizzano il codice 301, non 302
• Nessuna catena di redirect supera il singolo passaggio
• L'header HSTS è attivo affinché gli utenti abituali evitino il redirect HTTP
• Ogni vecchio URL con visite o backlink punta al suo corrispettivo specifico
• Le pagine eliminate senza equivalente restituiscono 410, non un redirect alla home
• Tutti i link interni puntano direttamente all'URL finale
• I singoli URL strategici sono stati collaudati puntualmente