Il redirect 301 non funziona? 6 cause comuni e relative soluzioni

Hai impostato un reindirizzamento del dominio, hai atteso la propagazione, hai testato il vecchio URL — e non succede nulla. La pagina rimane invariata, restituisce un errore oppure entra in un loop infinito.

I guasti nei redirect sono frustranti e costano più del solo tempo. Ogni redirect rotto significa traffico perso, backlink interrotti e una pessima esperienza per chi clicca un vecchio link. Per le aziende che fanno affidamento sulla ricerca organica, un redirect configurato male può far perdere silenziosamente valore SEO per settimane prima che qualcuno se ne accorga.

La buona notizia: la maggior parte dei guasti nei redirect dipende solo da alcune cause. Questa guida passa in rassegna ognuna di esse, dai problemi DNS agli errori di configurazione del server, con passaggi concreti per diagnosticarle e risolverle.

#1 Il DNS non si è ancora propagato#

Il problema: Hai puntato i record DNS del tuo dominio al servizio di redirect o al nuovo server, ma i visitatori vedono ancora il vecchio sito.

Perché succede: Le modifiche DNS non hanno effetto istantaneamente. Ogni record DNS ha un valore TTL (Time to Live) — in genere da 300 secondi (5 minuti) a 86.400 secondi (24 ore). Finché il vecchio TTL non scade in tutto il mondo, i resolver DNS su Internet continuano a servire il vecchio indirizzo IP.

Come diagnosticare:

• •
  Esegui dig example.com nel terminale e controlla la sezione ANSWER — l'IP è quello vecchio o quello nuovo?
• •
  Usa un verificatore globale della propagazione DNS come whatsmydns.net per vedere lo stato della propagazione nelle diverse regioni
• •
  Controlla il TTL del tuo dominio nelle impostazioni del tuo provider DNS

Come risolvere:

• •
  Riduci il TTL prima della modifica pianificata e attendi che il TTL precedente scada prima. Ridurlo dopo che i resolver hanno memorizzato nella cache il vecchio record non accorcia quella voce della cache esistente.
• •
  Confronta la risposta DNS autorevole con le risposte dei resolver ricorsivi. Il tempo dipende dal TTL precedente e dal provider; attendere un numero fisso di ore non dimostra che i record siano corretti.
• •
  Se la propagazione sembra bloccata, verifica di aver aggiornato i record presso il provider DNS corretto (quello a cui puntano i tuoi nameserver, non necessariamente il registrar del dominio)

#2 Errori di sintassi .htaccess#

Il problema: Hai aggiunto una regola di reindirizzamento al tuo file .htaccess, ma il server restituisce un errore interno 500, ignora completamente la regola oppure la applica in modo errato.

Perché succede: mod_rewrite di Apache è potente ma inflessibile. Un singolo spazio mancante, un flag sbagliato o una regola in conflitto possono compromettere l'intera configurazione. Gli errori comuni includono:

• •
  Mancanza di RewriteEngine On all'inizio del blocco delle regole
• •
  Usando http:// invece di https:// nell'URL di destinazione
• •
  Controlla la sintassi della direttiva che stai usando. In un pattern RewriteRule in un file .htaccess a livello di directory, Apache rimuove la barra iniziale; le regole in altri contesti possono comportarsi in modo diverso.
• •
  Regole in conflitto che si sovrascrivono a vicenda a causa dell'ordine

Come diagnosticare:

• •
  Controlla il registro degli errori del tuo server — Apache registra i numeri di riga esatti per gli errori di sintassi
• •
  Rinomina temporaneamente .htaccess in qualcos'altro — se l'errore scompare, il tuo .htaccess è il colpevole

Come risolvere:

• •
  Inizia con una regola minima e testala prima di aggiungere complessità
• •
  Sintassi corretta per un redirect 301 di base:

apacheRedirect 301 /old-page https://example.com/new-page

• •
  Per i redirect basati su regex con mod_rewrite:

apacheRewriteEngine On
RewriteRule ^old-path/(.*)$ https://example.com/new-path/$1 [R=301,L]

• •
  Se il tuo sito gira su Nginx invece che su Apache, i file .htaccess vengono completamente ignorati — devi aggiungere le regole nella configurazione del server block

#3 Catena o ciclo di redirect#

Il problema: Il redirect inizia ma non raggiunge mai la destinazione — il browser alla fine mostra "troppi redirect" oppure la pagina impiega un'eternità a caricarsi.

Perché succede: Una catena di redirect si verifica quando l'URL A reindirizza a B, B reindirizza a C, e così via. Un ciclo si verifica quando la catena torna a un URL precedente. Entrambi sono comuni durante le migrazioni di siti web, quando i vecchi redirect e i nuovi redirect si sovrappongono senza pulizia.

Come diagnosticare:

• •
  Apri Chrome DevTools → scheda Network → ricarica la pagina — esamina la catena di richieste 3xx
• •
  Se vedi lo stesso URL apparire due volte nella catena, si tratta di un ciclo
• •
  Inserisci l'URL nel nostro test di velocità dei redirect per vedere ogni passaggio, il suo codice di stato e dove termina

Come risolvere:

• •
  Mappa ogni regola di redirect attiva che hai — in .htaccess, nei plugin del CMS, nelle regole edge del CDN e nello strumento di gestione dei redirect
• •
  Rimuovi le regole intermedie che non sono più necessarie. Consolida le catene in un unico redirect diretto (A → D invece di A → B → C → D)
• •
  Se usi WordPress, controlla tutti i plugin attivi — i plugin di caching, SEO e sicurezza possono tutti aggiungere regole di redirect in conflitto

#4 Fantasmi della cache#

Il problema: Hai aggiornato o rimosso un redirect, ma i visitatori vengono ancora reindirizzati alla vecchia destinazione.

Perché succede: I browser, i nodi edge del CDN e le cache a livello di server memorizzano in modo aggressivo i redirect 301. Una volta che un browser vede un 301, può ricordare quel redirect indefinitamente — anche dopo che lo hai modificato. Lo stesso vale per le cache del CDN come Cloudflare, che possono servire risposte di redirect obsolete dai nodi edge.

Come diagnosticare:

• •
  Confronta il risultato di una finestra privata con una sessione normale e con una richiesta da riga di comando. Una differenza suggerisce lo stato del browser o la cache, ma non è di per sé una diagnosi completa.
• •
  Usa curl -I https://example.com/old-page per vedere le effettive intestazioni di risposta del server senza interferenze del browser
• •
  Controlla gli header Cache-Control e Age nella risposta

Come risolvere:

• •
  Cancella le immagini e i file memorizzati nella cache del browser, oppure continua a testare in una finestra privata
• •
  Svuota la cache del tuo CDN per il vecchio URL; la maggior parte dei CDN consente di svuotare un singolo URL
• •
  Per i reindirizzamenti futuri, usa 302 (temporaneo) durante i test, poi passa a 301 (permanente) solo quando sei sicuro che la destinazione sia corretta
• •
  Aggiungi header di cache espliciti: Cache-Control: no-cache, max-age=0 per i reindirizzamenti che prevedi di modificare

#5 Problemi misti HTTP/HTTPS#

Il problema: La destinazione del tuo reindirizzamento usa HTTPS, ma il reindirizzamento invia il traffico alla versione HTTP, o viceversa. I visitatori vedono un avviso del certificato o una pagina non funzionante.

Perché succede: Questo è uno dei casi di errore dei reindirizzamenti più trascurati. Hai configurato un reindirizzamento da http://old-domain.com a http://new-domain.com, ma il nuovo dominio applica HTTPS tramite HSTS. Il browser esegue un reindirizzamento, poi viene immediatamente reindirizzato di nuovo a HTTPS — oppure, peggio, la versione HTTPS del vecchio dominio ha un certificato scaduto o non corrispondente.

Come diagnosticare:

• •
  Controlla sia la versione http:// sia quella https:// del tuo URL di origine
• •
  Cerca avvisi di contenuti misti nella console del browser
• •
  Verifica se HSTS è applicato (controlla l'intestazione di risposta Strict-Transport-Security)

Come risolvere:

• •
  Reindirizza sempre all'URL HTTPS completo: https://new-domain.com/page invece di new-domain.com/page
• •
  Assicurati che ogni dominio nella catena abbia installato un certificato SSL valido
• •
  Se reindirizzi da un vecchio dominio, assicurati che anche il vecchio dominio disponga di copertura SSL, anche se serve solo reindirizzamenti
• •
  Usa ovunque nelle regole di reindirizzamento un unico protocollo canonico (sempre HTTPS)

#6 Tipo di reindirizzamento errato#

Il problema: Il tuo reindirizzamento funziona, ma i motori di ricerca non trasferiscono il valore dei link, oppure i visitatori non possono aggiungere ai segnalibri la destinazione correttamente.

Perché accade: Diversi codici di stato HTTP dicono a browser e motori di ricerca cose diverse sul reindirizzamento:

• •
  301 (Spostato in modo permanente): Trasmette la maggior parte dell’equità dei लिंक. Usalo per spostamenti permanenti come cambi di dominio o ristrutturazioni
• •
  302 (Trovato): Temporaneo. Google di solito mantiene indicizzata la vecchia URL, quindi i segnali di ranking restano lì. Usalo solo per reindirizzamenti temporanei come test A/B o landing page stagionali
• •
  307 (Reindirizzamento temporaneo): Simile al 302 ma preserva il metodo HTTP. Usato per reindirizzamenti API temporanei
• •
  Meta refresh: un reindirizzamento HTML, non HTTP. Google considera un meta refresh istantaneo (0 secondi) come permanente e uno ritardato come temporaneo, ma funziona solo dopo il caricamento della pagina, quindi usa un reindirizzamento lato server quando possibile

Come diagnosticarlo:

• •
  Controlla il codice di stato della risposta usando curl -I https://example.com/old-page
• •
  Cerca l’intestazione Location e il codice di stato 3xx nella prima riga della risposta

Come risolvere:

• •
  Usa 301 o 308 per spostamenti permanenti verso una sostituzione pertinente. Se una pagina viene rimossa senza una sostituzione adeguata, un 404 o 410 può essere appropriato invece di un reindirizzamento non pertinente.
• •
  Usa 302 o 307 solo per reindirizzamenti davvero temporanei (promozioni, pagine di manutenzione, test A/B)
• •
  Evita il meta refresh (<meta http-equiv="refresh">) per gli URL importanti; usa invece un vero HTTP 301
• •
  Scegli lo status in base al fatto che lo spostamento sia permanente o temporaneo, poi verifica il comportamento. Non dare per scontato che ogni risposta temporanea comporti una perdita fissa di valore SEO.

Come prevenire i fallimenti dei reindirizzamenti#

Il ciclo di diagnosi e correzione dei problemi di reindirizzamento richiede tempo. Ecco come evitarne la maggior parte in anticipo:

• •
  Prova con curl prima del lancio: Esegui curl -IL https://source-url.com per verificare l'intera catena di reindirizzamenti prima di annunciare qualsiasi modifica di URL
• •
  Mantieni una mappa dei reindirizzamenti: Documenta ogni regola di reindirizzamento. Quando migri o ristrutturi, aggiorna la mappa. Questo previene catene accidentali e regole orfane
• •
  Usa una piattaforma dedicata alla gestione dei reindirizzamenti: Gestire i reindirizzamenti tramite .htaccess, plugin di WordPress o file di configurazione del server funziona — finché non funziona più. Quando hai dozzine o centinaia di reindirizzamenti, l'approccio manuale genera errori. Una piattaforma dedicata ti offre debug visivo delle catene di reindirizzamento, gestione automatica dell'HTTPS, analisi del traffico di reindirizzamento, importazione ed esportazione in blocco e registri di audit per tenere traccia delle modifiche.
• •
  Imposta TTL bassi prima di apportare modifiche al DNS: Riduci il tuo TTL a 300 secondi almeno 24 ore prima di qualsiasi aggiornamento DNS pianificato
• •
  Testa in un ambiente di staging: Non distribuire mai le modifiche ai reindirizzamenti direttamente in produzione senza testare l'intero percorso
• •
  Mappa ogni vecchio URL alla sua nuova pagina più vicina: inviare tutto alla home page "funziona" tecnicamente, ma i visitatori e i motori di ricerca perdono la pagina che stavano cercando

L'approccio di RedirHub: elimina le congetture#

I problemi di reindirizzamento possono verificarsi con qualsiasi configurazione. Un servizio gestito può ridurre la configurazione del server che devi gestire, ma i record DNS, i prerequisiti dei certificati, le risposte memorizzate nella cache e la disponibilità della destinazione richiedono comunque attenzione.

RedirHub gestisce i reindirizzamenti dalla propria rete edge, separata dal tuo server web. Non ci sono file .htaccess da rompere né server da riavviare quando aggiungi una regola. Gestisci i reindirizzamenti in una dashboard, l'HTTPS viene emesso automaticamente con certificati SSL gratuiti per root e www, e le migrazioni di grandi dimensioni possono essere caricate con un importazione CSV di reindirizzamenti invece di regole scritte a mano.

Ecco come questo si collega alle cause sopra:

• •
  Configurazione DNS: usa i valori richiesti in Connect DNS. I domini root usano i record A e TXT di verifica mostrati; i sottodomini supportati usano CNAME. Le voci DNS memorizzate nella cache esistenti devono comunque scadere.
• •
  Errori .htaccess: non c'è alcuna configurazione del server da modificare. Compili Redirect from, Redirect to e Redirect type, e What happens mostra in anteprima dove finiranno gli URL di esempio prima del salvataggio.
• •
  Catene: ogni reindirizzamento vive in un unico elenco Links, quindi puoi puntare i vecchi URL direttamente alla destinazione finale invece di impilare regole in più punti.
• •
  Cache: le modifiche hanno effetto dal nostro lato non appena le salvi. I browser che hanno già memorizzato nella cache un vecchio 301 possono comunque ricordarlo, quindi testa le modifiche in una finestra privata o con curl.
• •
  HTTPS: i certificati vengono emessi e rinnovati automaticamente sia per root che per www, quindi il vecchio dominio funziona anche su https://.
• •
  Codici di stato: scegli 301, 302, 307 o 308 per ogni redirect e guarda il codice accanto a ogni URL di esempio prima di crearlo.

Se hai un solo sito su un server che controlli, correggere la regola lì è gratuito e rapido. Un servizio di redirect conviene quando gestisci molti domini o una migrazione del sito con migliaia di URL, dove nelle regole mantenute manualmente si insinuano catene e refusi. I piani partono da 49 $/mese (Core) con una prova gratuita di 14 giorni.

Checklist di riferimento rapido#

• •
  Il DNS del vecchio dominio punta al punto in cui è configurato il redirect? (dig o un controllo DNS)
• •
  curl -IL https://old-url mostra un 301 al primo salto e l’URL finale corretto?
• •
  http://, https://, www e non-www reindirizzano tutti?
• •
  C’è un solo salto fino all’URL finale, senza loop?
• •
  Il vecchio dominio ha un certificato valido?
• •
  Hai testato in una finestra privata per escludere un redirect memorizzato nella cache?
• •
  Ogni vecchia pagina va alla corrispondente nuova pagina, non alla home page?

Ancora bloccato? A volte il problema è a livello di infrastruttura: regole CDN in conflitto, riscritture a livello server che prevalgono sulle regole a livello applicativo, o impostazioni DNS a livello di registro. Se hai seguito questa checklist e il reindirizzamento ancora non funziona, uno strumento visivo di diagnostica dei reindirizzamenti può mostrarti esattamente cosa accade a ogni passaggio.