Modificato un redirect 301, ma il browser continua ostinatamente a mandare i visitatori al vecchio URL? Un grattacapo familiare per chiunque abbia configurato migrazioni di siti o ristrutturato i link.

Il problema non è né del server né di WordPress. Il browser memorizza in modo permanente un redirect permanente e non interroga più il server; è così che funziona la specifica HTTP. Finché la cache non scade o l'utente non la svuota manualmente, la vecchia regola resta in vigore.

Ecco una strategia chiara: come testare i redirect senza conseguenze, perché il 302 ti salva i nervi durante il debug e cosa fare se la cache è già bloccata per i visitatori reali.

💡 Panoramica rapida:

• Inizia sempre con il 302 (temporaneo), testa e solo dopo passa al 301 (permanente)
• Svuota la cache del browser ogni volta che modifichi le regole di redirect
• Per Chrome: DevTools → Network → Disable cache, oppure scheda Application → Clear site data
• Se un 301 è già in cache presso gli utenti, puoi solo aspettare o cambiare l'URL di destinazione

Come il browser mette in cache un redirect 301

Quando il server risponde con lo stato 301 Moved Permanently, il browser lo interpreta alla lettera: «questo URL si è spostato per sempre». Memorizza la coppia «vecchio URL → nuovo URL» nella propria cache dei redirect, separata dalla cache delle pagine e delle immagini.

La volta successiva che l'utente (o tu, lo sviluppatore) apre lo stesso indirizzo, il browser non invia affatto una richiesta al server. Sostituisce immediatamente l'URL di destinazione salvato dalla cache. Il server non vede alcuna richiesta e tu non vedi il comportamento attuale.

La specifica HTTP non definisce un periodo di conservazione rigido per questa cache. In pratica, Chrome, Firefox e Safari mantengono il 301 in cache finché non viene svuotata esplicitamente. L'header Cache-Control del server può essere ignorato dal browser specificamente per il 301, perché «permanente» significa permanente.

Questo comportamento è una funzionalità, non un bug. Risparmia un round-trip per spostamenti permanenti legittimi (ad esempio, un cambio di dominio). Tuttavia, durante lo sviluppo diventa una trappola.

Perché questo causa problemi durante la configurazione

Immagina uno scenario. Stai impostando un redirect dal vecchio URL /old-page a /new-page. Configuri un 301, lo testi nel browser e funziona. Un'ora dopo ti accorgi di aver fatto un errore: l'URL corretto è /new-page/v2.

Modifichi la regola sul server e premi «aggiorna» nel browser. Atterri su /new-page. Di nuovo. Perché il browser ha già memorizzato la prima coppia e non dà al server la possibilità di mostrare la nuova regola.

Pensi che il redirect non funzioni. In realtà funziona, solo non quello che hai appena configurato.

Su un sito di test, una volta abbiamo passato mezz'ora a modificare le regole di .htaccess prima di capire che il browser stava mostrando la cache. Svuotata la cache, tutto ha funzionato immediatamente come previsto.

La situazione è peggiore con i visitatori. Se hai attivato un 301 errato su un sito in produzione, chiunque lo abbia visitato in quei minuti ha ricevuto la regola sbagliata nella cache del proprio browser. Hai corretto l'errore sul server in 10 minuti, ma i loro browser continueranno a mandarli al vecchio URL per giorni o settimane, finché la cache non viene svuotata.

Nota: non puoi svuotare la cache dei redirect dal lato utente. Nessun trucco lato server può raggiungere il browser di qualcun altro.

La strategia 302 → 301: testare senza conseguenze

Una regola che fa risparmiare ore di debug e protegge da errori su un sito live:

Inizia sempre con un redirect 302 (temporaneo). Passa al 301 solo dopo essere certo che la regola sia corretta.

Il browser non mette in cache il 302 in modo aggressivo; interroga il server a ogni richiesta. Modifica la regola sul server e il browser recepisce immediatamente il nuovo comportamento. Nessuno svuotamento della cache necessario.

Approccio passo passo per qualsiasi modifica di URL:

• Imposta un redirect 302 in .htaccess, nella configurazione di Nginx o tramite un plugin WordPress (ad esempio, Redirection).
• Apri il vecchio URL in modalità incognito o con l'opzione «Disable cache» attiva nei DevTools.
• Conferma di atterrare sulla pagina di destinazione corretta.
• Verifica altri 2-3 URL dello stesso gruppo.
• Solo quando tutto è testato, sostituisci 302 con 301 nelle regole.
• Fai un controllo finale in modalità browser normale.

In pratica, questo approccio richiede esattamente due minuti extra per gruppo di redirect ed elimina completamente il rischio di un «errore in cache» per i visitatori.

Se usi il plugin Redirection per WordPress, questo crea 301 per impostazione predefinita. Passa manualmente a 302 nel menu a tendina quando crei una regola e non dimenticare di tornare a 301 dopo il test.

Come svuotare la cache dei redirect in locale

Quando il browser ha già memorizzato un 301 errato e non riesci a vedere il comportamento attuale, ecco cosa aiuta:

Chrome. Apri DevTools (F12), vai alla scheda Network e seleziona Disable cache. Oppure fai un reset completo: Application → Clear storage → Clear site data. Il metodo più affidabile per un sito specifico è chrome://settings/clearBrowserData → Immagini e file memorizzati nella cache.

Firefox. Strumenti di sviluppo web → Network → Disable Cache. Per una pulizia completa: Cronologia → Cancella cronologia recente → Cache.

Safari. Sviluppo → Disabilita cache (il menu Sviluppo si attiva in Impostazioni → Avanzate).

Modalità incognito è un modo rapido per verificare il comportamento aggiornato senza svuotare la cache principale. Il browser usa una sessione pulita, senza redirect salvati.

Sfumatura importante: chiudere il browser NON svuota la cache dei redirect 301. A differenza dello storage di sessione, la cache dei redirect sopravvive ai riavvii del browser. Solo lo svuotamento esplicito o la modalità incognito funzionano.

Cosa fare se la cache è bloccata per gli utenti

Questo è lo scenario più spiacevole: un 301 errato è stato attivo sul sito in produzione per un certo periodo e una parte del tuo pubblico ora lo porta nella cache del proprio browser. Hai corretto la regola sul server, ma questi utenti continuano ad atterrare nel posto sbagliato.

Ecco cosa puoi fare:

• Cambia l'URL di destinazione con uno nuovo. Se il vecchio location puntava a /page-v1 e ti serve /page-v2, sostituisci semplicemente l'indirizzo nella stessa regola. I browser con il vecchio URL di destinazione in cache continueranno ad andare lì (il problema). Tuttavia, i nuovi visitatori andranno nel posto giusto. Questo non risolve il problema per chi è già «infetto», ma blocca la diffusione.

• Usa un metodo di redirect diverso. Se il 301 è in cache, il browser non interroga il server, ma la logica lato server funziona ancora per i nuovi visitatori. Aggiungi un redirect JavaScript sulla pagina di destinazione come livello aggiuntivo sopra il redirect HTTP per chi atterra ancora sulla vecchia pagina.

• Riconoscilo onestamente: non esiste una cura diretta. Non puoi raggiungere il browser dell'utente. Se la cache è già caricata, l'unico modo per resettarla è che l'utente svuoti la cache o visiti il sito tramite un link in incognito. Fortunatamente, la cache dei redirect non vive per sempre: reinstallazioni del browser, cambi di dispositivo e aggiornamenti del sistema operativo prima o poi la resettano.

Nella nostra esperienza, un 301 errato diventa critico solo in due casi: una migrazione di massa (centinaia di URL) con un errore nelle regole, o un redirect della homepage. In entrambi i casi, il danno da errore in cache supera qualsiasi tempo risparmiato saltando i test.

301, 302, 307, 308: Quando usare cosa

Per evitare confusione, tieni a portata di mano questa tabella rapida dei codici di redirect:

Per un sito WordPress, conoscere la differenza tra 301 e 302 è sufficiente nella stragrande maggioranza dei casi. I codici 307 e 308 sono strumenti di nicchia per situazioni in cui preservare il metodo HTTP è critico (ad esempio, un form deve rimanere una richiesta POST e non trasformarsi in GET durante il redirect).

In breve: il 302 è il tuo strumento di lavoro durante lo sviluppo. Il 301 è il timbro finale «fatto».

Un'altra trappola: WordPress e i plugin di caching

Su WordPress, il problema della cache del 301 si somma al caching del server e dei plugin. Una situazione tipica:

Modifichi un redirect nel plugin Redirection, clicchi «salva» e non funziona. Svuoti la cache del browser e appare ancora la vecchia pagina. Cosa sta succedendo? Un plugin di caching (WP Rocket, LiteSpeed Cache, W3 Total Cache) ha servito una versione cache della pagina; il server non ha mai nemmeno eseguito la regola di redirect.

Passaggi per il debug dei redirect su WordPress:

• Svuota la cache del plugin di caching (ogni plugin ha il suo pulsante «Purge All Cache»).
• Disabilita il caching durante i test (in WP Rocket è la Development Mode).
• Svuota la cache del browser (come descritto sopra).
• Solo dopo testa il redirect.

Su un sito di test, teniamo il plugin di caching disabilitato finché tutti i redirect non sono completamente pronti e lo attiviamo solo dopo il passaggio finale da 302 a 301.

Questo breve video in inglese mostra visivamente la differenza tra 301 e 302 nella pratica e spiega perché la scelta del codice di redirect influisce sulla SEO:

⁉️🤔 Domande frequenti

Perché il browser mette in cache il 301 invece di interrogare il server ogni volta?

La specifica HTTP definisce il 301 come «la risorsa è stata spostata permanentemente». Interrogare il server ogni volta che l'URL viene aperto contraddirebbe il significato di «permanentemente» e creerebbe carico inutile. Mettere in cache il redirect fa risparmiare una richiesta HTTP per visitatore. Su una scala di decine di migliaia di visite, questo accelera notevolmente la navigazione. Il browser mette in cache il fatto del redirect in sé (la coppia «da → a»), non il contenuto della pagina. Questo è un tipo di cache separato chiamato cache dei redirect. Chrome la memorizza nel profilo utente; Firefox la memorizza nel file places.sqlite insieme alla cronologia di navigazione. Ecco perché svuotare la cache di immagini e script non sempre resetta i redirect; serve uno svuotamento completo o la pulizia dei dati del sito.

Si può impedire al browser di mettere in cache il 301 lato server?

Formalmente, no. I browser possono ignorare l'header Cache-Control: no-store per i redirect permanenti. La specifica non richiede ai browser di onorare Cache-Control per 301/308, poiché un redirect permanente implica che la regola non cambierà. Alcune versioni di Chrome e Firefox rispettano Cache-Control per il 301, ma non puoi fare affidamento su questo in produzione; il comportamento non è garantito e varia tra le versioni. L'unico modo affidabile per «annullare» il caching del browser di un 301 è usare inizialmente il 302 durante i test. Se un 301 è già in cache presso l'utente, il server è impotente.

In pratica, in cosa differisce il 302 dal 307?

Entrambi sono redirect temporanei e nessuno dei due viene messo in cache dal browser. La differenza sta nella gestione del metodo HTTP. Con il 302, il browser può trasformare una richiesta POST in GET durante il redirect (è accaduto storicamente e molti browser lo fanno ancora). Con il 307, la conservazione del metodo è garantita: POST resta POST, PUT resta PUT. Per WordPress e praticamente qualsiasi sito, la differenza è trascurabile poiché i redirect coinvolgono quasi sempre richieste GET (apertura di pagine). Il 307 serve solo se form, API o upload di file passano attraverso un URL che stai reindirizzando temporaneamente.

Come posso verificare quale redirect è in cache nel mio browser?

Apri DevTools (F12) → scheda Network e seleziona «Disable cache» (questo è OBBLIGATORIO, altrimenti il browser non farà una richiesta al server e non vedrai la risposta attuale). Poi apri il vecchio URL. Nella colonna Status vedrai il codice di risposta effettivo dal server (301, 302, ecc.) e l'header Location con l'URL di destinazione. Senza «Disable cache», DevTools mostrerà uno stato 200 o (disk cache), il che significa che il browser ha servito dalla cache e il server non è stato interrogato.

Bisogna mantenere un redirect 301 per sempre?

Google raccomanda di mantenere i redirect permanenti per almeno un anno dopo uno spostamento. In pratica, se il vecchio URL non è più promosso, non ha link esterni e non è indicizzato, il redirect può essere rimosso dopo 6-12 mesi. Tuttavia, se altri siti linkavano al vecchio URL o questo è presente negli indici dei motori di ricerca, dovresti mantenere il redirect permanentemente. Rimuovere un 301 con una regola in cache presso gli utenti non risolverà il problema; i loro browser continueranno a usare la coppia in cache finché non svuotano la cache.

Bisogna aver paura dei redirect 301?

No, se segui la regola «prima il 302». Un redirect permanente è uno strumento affidabile per spostare contenuti, cambiare domini e pulire i duplicati. I problemi sorgono solo quando il 301 viene impostato senza test.

Ricorda il punto chiave: il 301 è una promessa al browser che «non cambierò idea». Non fare quella promessa finché non sei certo. Dieci minuti di test di un redirect 302 in incognito ti faranno risparmiare giorni di pulizia degli errori in cache per il tuo pubblico reale.