Cambiare l’indirizzo di una pagina può sembrare una modifica piccola: si aggiorna il collegamento e si continua a lavorare. Ma il vecchio URL può essere ancora presente nei risultati di ricerca, nei preferiti, in una newsletter o su un sito esterno. Senza un percorso corretto, chi lo apre rischia di trovare un errore o una destinazione che non risponde alla sua richiesta.
I redirect 301 e 302 permettono di accompagnare il visitatore verso un altro indirizzo, comunicando però intenzioni diverse. Il 301 indica uno spostamento permanente; il 302 uno temporaneo. Scegliere il codice giusto è importante, ma non basta: bisogna stabilire una destinazione pertinente, verificare le regole e aggiornare i collegamenti del sito. Questa guida spiega come affrontare il cambiamento con un metodo comprensibile anche a chi coordina il progetto senza configurare personalmente il server.
Che cos’è un redirect
Un redirect è una risposta che invita il client, per esempio il browser, a richiedere una risorsa a un altro indirizzo. Nei reindirizzamenti HTTP il server restituisce un codice di stato e normalmente indica la destinazione nell’intestazione Location. Il visitatore può quindi arrivare alla nuova pagina senza dover cercare manualmente il contenuto.
Per esempio, il percorso /vecchio-servizio può condurre a /nuovo-servizio. L’esempio descrive solo una relazione tra indirizzi: non è una regola pronta da copiare. La documentazione MDN sul 301 illustra risposta e destinazione. Per chi gestisce il sito, il punto operativo è sapere quale richiesta attiva il passaggio e dove termina realmente la navigazione.
Quando usare il 301
Il codice 301 comunica che la risorsa ha un nuovo indirizzo permanente. È adatto quando una pagina viene trasferita stabilmente e il vecchio URL deve continuare ad accompagnare chi arriva da collegamenti precedenti. Un cambio definitivo dello slug o una riorganizzazione consolidata dei contenuti sono situazioni da valutare in questo senso.
La decisione deve riflettere il progetto reale. Prima di impostarlo, chiedersi se la nuova destinazione rappresenterà quel contenuto anche in futuro e se il vecchio indirizzo dovrà tornare operativo. Non scegliere un 301 soltanto perché viene spesso associato alla SEO: se il trasferimento è provvisorio, si comunicherebbe un’intenzione diversa da quella prevista. Documentare il motivo della modifica aiuta chi farà manutenzione successivamente.
Quando usare il 302
Il codice 302 indica che la risorsa si trova temporaneamente a un altro indirizzo. Può essere appropriato quando il vecchio URL resta il riferimento da mantenere e il passaggio verso una destinazione alternativa è previsto per un periodo limitato. Non basta che una modifica sia recente: serve una ragione concreta per considerarla reversibile.
Un caso documentato è un esperimento che invia alcuni visitatori a una variante della pagina. Nelle indicazioni sui test dei siti, Google suggerisce un 302 per questo tipo di reindirizzamento temporaneo. Anche in un test vanno definiti responsabile, conclusione prevista e comportamento finale: una regola dimenticata può rimanere attiva molto oltre l’esperimento.
La domanda da fare prima di scegliere
La domanda principale è: il contenuto ha cambiato casa oppure sta usando una destinazione provvisoria? Nel primo caso si valuta un redirect permanente; nel secondo uno temporaneo. Il calendario da solo non risolve il dubbio: una modifica pensata per durare può essere permanente dal primo giorno, mentre una deviazione lunga può avere comunque una motivazione temporanea.
Scrivere in una riga perché il vecchio indirizzo cambia, quale pagina lo sostituisce e chi decide il termine dell’eventuale deviazione. Se queste informazioni non sono chiare, è meglio definire il progetto prima di aggiungere regole. Il codice HTTP deve esprimere una decisione sui contenuti e sul percorso degli utenti, non sostituirla.
Che cosa comunica ai motori di ricerca
Google distingue i reindirizzamenti permanenti da quelli temporanei anche nella scelta dell’URL rappresentativo del contenuto. La guida ufficiale sui redirect descrive il permanente come un segnale a favore della destinazione quale URL canonico; un temporaneo comunica un’intenzione differente. Ciò non equivale a una promessa di posizione o di traffico.
Per questo non è corretto presentare un 302 come una penalizzazione automatica, né un 301 come garanzia di conservare ogni risultato precedente. La risposta deve essere coerente con lo spostamento. Quando si valuta l’effetto, considerare anche qualità e corrispondenza della nuova pagina, collegamenti, disponibilità del sito e segnali che potrebbero indicare destinazioni contrastanti.
Preparare una mappa tra vecchi e nuovi indirizzi
Prima di intervenire, costruire una lista delle pagine coinvolte. Per ogni vecchio URL indicare la destinazione prevista, il tipo di spostamento, la motivazione e la persona che deve approvarlo. Nei progetti piccoli può bastare un foglio condiviso; l’importante è che la relazione sia verificabile e non dipenda dalla memoria di chi esegue il lavoro.
Raccogliere gli indirizzi dal sito, dalle pagine più utilizzate e dai materiali pubblicati dall’azienda. Includere, se rilevanti, documenti scaricabili e collegamenti usati nelle campagne. Segnare i casi incerti invece di assegnare una destinazione generica. Questa mappa diventa sia la base dell’implementazione sia il riferimento per il collaudo, evitando decisioni improvvisate al momento del rilascio.
Scegliere una destinazione davvero pertinente
Chi apre un vecchio collegamento si aspetta una risposta precisa. Se cercava la scheda di un servizio, arrivare alla pagina iniziale del sito può costringerlo a ricominciare la ricerca. La destinazione dovrebbe quindi conservare, quando possibile, il significato della pagina precedente e permettere al visitatore di continuare il proprio percorso.
Prima di approvare l’abbinamento, confrontare contenuti, obiettivo e azione richiesta. Una pagina aggiornata sullo stesso servizio può essere una buona sostituzione; una sezione solo vagamente collegata potrebbe non esserlo. Non usare il redirect per nascondere una struttura poco chiara. Se più contenuti sono stati accorpati, verificare che la pagina risultante risponda realmente alle esigenze principali di quelli rimossi.
Quando è corretto lasciare un errore 404 o 410
Non ogni pagina eliminata richiede un redirect. Se il contenuto non esiste più e non ha una sostituzione pertinente, una risposta 404 o 410 può descrivere correttamente la situazione. La documentazione Google sugli errori di scansione distingue proprio il contenuto spostato da quello rimosso senza un equivalente.
La pagina di errore può comunque aiutare il visitatore con navigazione e indicazioni utili, mantenendo lo stato HTTP appropriato. Reindirizzare tutto verso una pagina generica soltanto per non vedere errori nel rapporto non risolve necessariamente l’esperienza. La scelta dipende dall’esistenza di una sostituzione reale, non dal desiderio di azzerare qualsiasi URL non disponibile.
Considerare parametri e varianti dell’URL
Un indirizzo può presentarsi con parametri, maiuscole, percorsi diversi o una barra finale. Prima di applicare una regola ampia, capire quali varianti sono valide e quali informazioni devono essere conservate. Un parametro può servire al tracciamento, ma può anche determinare il contenuto o una funzione: rimuoverlo senza verifica può alterare il risultato.
Preparare esempi rappresentativi e provarli uno per uno. Documentare se la destinazione deve mantenere o eliminare i parametri, senza presumere che il sistema scelto faccia automaticamente ciò che si desidera. Per cataloghi, filtri e pagine generate da applicazioni, coinvolgere chi conosce il funzionamento del sito. Un’apparente pulizia degli indirizzi non deve rendere irraggiungibili informazioni o operazioni necessarie.
Evitare catene di reindirizzamenti
Una catena si verifica quando il vecchio indirizzo porta a una pagina che reindirizza ancora, prima di raggiungere quella finale. Può nascere da modifiche successive: prima cambia il percorso, poi il dominio, poi la versione preferita dell’indirizzo. Ogni regola può sembrare corretta da sola, mentre il percorso complessivo diventa difficile da seguire.
Quando si aggiorna una mappa, valutare se il vecchio URL può puntare direttamente alla destinazione attuale. Controllare i passaggi effettivi, non soltanto la pagina che alla fine si apre. Mantenere un percorso semplice aiuta a verificare il comportamento e a individuare problemi. Non è necessario aspettare che una catena produca un errore evidente per rivedere regole diventate inutilmente complicate.
Riconoscere ed eliminare i loop
Un loop compare quando le regole riportano il visitatore a un indirizzo già attraversato, senza raggiungere una destinazione stabile. Per esempio, una regola può imporre la barra finale e un’altra rimuoverla. Lo stesso tipo di conflitto può nascere quando livelli diversi gestiscono dominio, protocollo o percorsi con impostazioni incompatibili.
Prima di aggiungere una nuova regola, controllare quelle presenti nel CMS, nel server e negli eventuali servizi intermedi. Se il browser segnala troppi reindirizzamenti, ricostruire l’intera sequenza e individuare il punto in cui si torna indietro. Correggere il conflitto alla fonte è più affidabile che aggiungere altre eccezioni senza capire quale componente stia producendo ciascuna risposta.
Aggiornare anche i collegamenti interni
Un redirect mantiene un percorso per chi usa vecchi riferimenti, ma i link gestiti dall’azienda dovrebbero essere aggiornati quando il trasferimento è definitivo. Menu, pulsanti, articoli correlati e collegamenti nel testo possono continuare a inviare verso l’indirizzo precedente se ci si limita a configurare la regola.
Usare la mappa per rivedere i contenuti interessati e controllare i modelli che generano automaticamente i collegamenti. Verificare anche firme email, pagine di campagne e materiali che possono essere modificati. In questo modo il redirect rimane una continuità per i riferimenti esterni o storici, mentre la navigazione ordinaria utilizza il percorso attuale e risulta più semplice da mantenere.
Coordinare sitemap e indicazioni canoniche
La sitemap e le indicazioni canoniche devono essere considerate insieme alla nuova struttura. La guida Google sulla canonicalizzazione illustra diversi segnali per indicare l’URL preferito. Una annotazione canonical non sposta il visitatore come fa un redirect: riguarda una preferenza comunicata ai motori di ricerca.
Quando una pagina viene trasferita definitivamente, controllare che la destinazione non continui a indicare come preferito un indirizzo precedente o estraneo al progetto. Verificare anche ciò che il CMS genera automaticamente. Segnali incoerenti rendono più difficile capire l’intenzione del sito. Per chi coordina i lavori, chiedere un controllo congiunto è più utile che considerare separatamente tre caselle da spuntare.
Preferire una risposta server quando è disponibile
Un reindirizzamento può essere realizzato a livelli diversi. Una risposta HTTP permette di comunicare il trasferimento prima di caricare una pagina che esegue altro codice. Le soluzioni basate su script o aggiornamenti della pagina richiedono valutazioni differenti e non vanno considerate identiche solo perché il browser arriva alla stessa destinazione.
Prima di scegliere, chiarire quali strumenti offre l’hosting e quali vincoli impone l’applicazione. Il responsabile tecnico deve verificare che il codice di stato sia quello voluto, non soltanto che l’indirizzo nella barra cambi. Se si usa una soluzione alternativa per una limitazione concreta, documentarla e prevedere un controllo del comportamento con browser e strumenti di analisi.
Configurare la regola nel livello giusto
Un pannello del CMS, il server web o un servizio intermedio possono gestire il redirect. Il livello va scelto conoscendo la configurazione esistente e chi la mantiene. Duplicare la stessa responsabilità in più strumenti rende più difficile capire quale impostazione abbia effetto e dove correggere un problema.
Su Apache, per esempio, la documentazione distingue direttive di reindirizzamento permanente e regole con codice di risposta esplicito. Non esiste però una riga universale da incollare in ogni sito: percorsi, regole precedenti e contesto contano. Prima di modificare la produzione, conservare la configurazione e provare il comportamento in un ambiente adeguato.
Tenere conto della cache
Un browser o un intermediario può conservare risposte secondo le regole di caching applicabili. Il 301 è definito come memorizzabile euristicamente dalla specifica HTTP. Questo rende importante evitare di usarlo come esperimento senza aver deciso la destinazione: correggere il server non significa necessariamente che ogni client dimentichi subito una risposta precedente.
Durante i test, confrontare le richieste di rete con ciò che mostra una sessione già utilizzata. Verificare eventuali cache del sito o del servizio intermedio e seguire la procedura di aggiornamento prevista. Non dedurre, al contrario, che un 302 non possa mai essere conservato: il comportamento va valutato insieme alle intestazioni e alle impostazioni effettive.
Fare attenzione a moduli, POST e API
Per una normale visita a una pagina si usa comunemente una richiesta GET, ma un sito contiene anche invii di moduli e operazioni applicative. In questi flussi non basta distinguere permanente e temporaneo: occorre sapere se il metodo e i dati della richiesta devono essere preservati e dove possono essere inviati.
La RFC 9110 consente per ragioni storiche il passaggio da POST a GET con 301 e 302. I codici 307 e 308 servono a esprimere reindirizzamenti che preservano il metodo, rispettivamente temporanei e permanenti. Per moduli, pagamenti e API, far valutare al tecnico anche sicurezza e comportamento dell’applicazione prima di riutilizzare una regola pensata per pagine informative.
Gestire cambi di dominio e passaggi a HTTPS
Un trasferimento di dominio richiede di considerare sia il vecchio sia il nuovo ambiente. I visitatori possono continuare ad aprire indirizzi storici: il vecchio dominio deve poter ricevere la richiesta e rispondere nel modo previsto. Anche nomi alternativi e versioni del protocollo vanno inclusi nelle prove, secondo ciò che era realmente disponibile.
Per richieste HTTPS verificare certificati e connessione prima del redirect: un errore in quella fase può impedire di arrivare alla nuova pagina. Non limitarsi a provare il nuovo dominio. Preparare un elenco di indirizzi rappresentativi e chiarire chi mantiene DNS, hosting e certificati durante la transizione. Il trasferimento dei contenuti e la continuità dei vecchi riferimenti devono essere pianificati insieme.
Conservare il contesto delle lingue
In un sito multilingua, una pagina italiana dovrebbe condurre a una destinazione coerente con la lingua e il contenuto attesi, quando disponibile. Reindirizzare tutte le versioni verso una sola pagina può far perdere il contesto a chi arriva da un collegamento specifico. La mappa deve quindi includere le varianti linguistiche effettivamente esistenti.
Coinvolgere chi cura i contenuti per stabilire le corrispondenze. Non assumere che percorsi apparentemente simili siano traduzioni equivalenti o che basti cambiare una parte dell’URL. Provare anche il selettore di lingua e i collegamenti tra versioni dopo lo spostamento. L’obiettivo è preservare un percorso comprensibile per il lettore, non soltanto ottenere una risposta tecnicamente valida.
Collaudare vecchio indirizzo e destinazione
Il test deve partire dall’URL che l’utente potrebbe aprire, non soltanto dalla pagina nuova. Controllare il codice restituito, la destinazione indicata e gli eventuali passaggi intermedi. Alla fine verificare che la pagina attesa sia disponibile, contenga il contenuto giusto e permetta di completare l’azione prevista.
Provare collegamenti con e senza parametri rilevanti e controllare da un contesto non dipendente da una sessione amministrativa. Per flussi più complessi, ripetere le operazioni reali con dati di test. Annotare esito, data e anomalie nella mappa. Un semplice “si apre” è un controllo troppo limitato quando può nascondere un codice diverso da quello voluto o una destinazione sbagliata.
Monitorare dopo la pubblicazione
Il rilascio non conclude il lavoro. Controllare errori, percorsi più visitati e richieste che arrivano ancora agli indirizzi precedenti aiuta a individuare abbinamenti mancanti. Confrontare il comportamento del sito con la mappa approvata e raccogliere eventuali segnalazioni di utenti o reparti che usano collegamenti storici.
Search Console può contribuire al controllo della scansione e della pagina scelta da Google come canonica. La guida alla risoluzione dei problemi di canonicalizzazione descrive l’uso del controllo URL. Queste informazioni vanno lette insieme alle prove dirette del sito. Un cambiamento nei rapporti richiede interpretazione: non va attribuito automaticamente al solo codice 301 o 302.
Decidere quanto mantenere i reindirizzamenti
Un vecchio collegamento può continuare a essere usato molto dopo un trasferimento. Nelle indicazioni sulle migrazioni, Google raccomanda di mantenere i redirect il più a lungo possibile, generalmente almeno un anno. Il riferimento non è una scadenza dopo la quale ogni collegamento storico smette di avere valore.
Valutare richieste ricevute, collegamenti esterni noti e necessità dell’azienda prima di eliminare regole permanenti. Per quelle temporanee, fissare invece una revisione collegata al motivo della deviazione. In entrambi i casi conservare un proprietario della decisione: regole senza spiegazione diventano difficili da rimuovere e possono sopravvivere a più rifacimenti del sito senza che nessuno sappia perché esistano.
Una lista di controllo prima di confermare
Prima di considerare conclusa la modifica, verificare che:
- Ogni vecchio URL abbia una decisione e una destinazione pertinente, se prevista.
- Il codice esprima correttamente un trasferimento permanente o temporaneo.
- Non ci siano loop o passaggi intermedi evitabili.
- Collegamenti interni, sitemap e indicazioni canoniche siano coerenti.
- Moduli, parametri, lingue e versioni HTTPS siano stati provati dove rilevanti.
- Esistano un responsabile e una data per il controllo successivo.
La lista non sostituisce la conoscenza del sito, ma rende il confronto tra chi gestisce contenuti e chi configura il sistema più concreto. Per i casi esclusi dal trasferimento, documentare anche la scelta di rimuovere una pagina senza sostituirla.
Domande frequenti
Se cambio soltanto il nome finale della pagina serve un redirect?
Se il vecchio indirizzo deve continuare a portare al contenuto, va previsto un percorso verso quello nuovo. Prima di farlo, verificare che il CMS non abbia già creato una regola automatica. Il test deve partire dal vecchio URL e controllare risposta e destinazione effettive.
Un 302 danneggia automaticamente la SEO?
No. È un codice adatto a comunicare uno spostamento temporaneo. Il problema nasce quando il comportamento non corrisponde all’intenzione del progetto o gli altri segnali sono incoerenti. La scelta deve seguire il trasferimento reale, senza promesse automatiche sui risultati di ricerca.
Posso mandare tutte le pagine eliminate alla home?
Non è una buona soluzione generale. Chi apre una pagina specifica potrebbe non trovare ciò che cercava. Individuare una sostituzione pertinente; se non esiste, valutare una corretta risposta di risorsa non disponibile con indicazioni utili per proseguire la navigazione.
Posso passare da 302 a 301 quando lo spostamento diventa definitivo?
Sì, dopo aver confermato la decisione. Aggiornare la regola, controllare le cache pertinenti e ripetere le prove sui vecchi indirizzi. Verificare anche collegamenti e indicazioni del sito, così il cambiamento non rimane limitato al codice restituito dal server.
Conclusione: comunicare il cambiamento in modo coerente
Il 301 è adatto a un trasferimento permanente, il 302 a una deviazione temporanea. La qualità del lavoro dipende però anche da destinazioni pertinenti, regole comprensibili e controlli completi. Un redirect corretto accompagna chi arriva da un vecchio collegamento verso il contenuto che si aspetta.
Preparare una mappa, coinvolgere chi cura contenuti e infrastruttura, verificare il percorso reale e mantenerlo nel tempo aiuta a evitare errori inutili. Il risultato da cercare è una transizione chiara per utenti e sistemi, con decisioni documentate e verificabili anche quando il sito cambierà di nuovo.
Vuoi approfondire questo tema per la tua attività? Azienda Digitale può aiutarti a valutare le soluzioni più adatte e a metterle in pratica. Azienda Digitale