Hai spostato la pagina dei servizi e un cliente apre ancora il vecchio indirizzo: senza un reindirizzamento, può trovarsi davanti a un errore 404. In genere un redirect porta la richiesta alla nuova pagina, ma il codice scelto cambia ciò che browser e motori di ricerca possono dedurre.
Un redirect ben scelto porta le persone alla pagina giusta senza creare deviazioni inutili
- Pagina spostata in modo definitivo: in genere si usa un redirect permanente.
- Destinazione provvisoria: il reindirizzamento temporaneo mantiene distinta la scelta dalla migrazione definitiva.
- Moduli e checkout: il codice può influire sul metodo della richiesta e sui dati inviati.
- Controllo finale: verifica la destinazione, l’eventuale catena di passaggi e l’accesso alla pagina.
Il redirect accompagna la richiesta fino a una nuova pagina
Una pagina aziendale cambia indirizzo, ma il vecchio URL resta in brochure, email e preferiti. Il server può rispondere con un codice 3xx e indicare la nuova destinazione nell’intestazione HTTP Location; il browser la richiede e mostra la pagina raggiunta.
Per chi visita il sito, il passaggio spesso avviene senza accorgersene. Per l’azienda, però, la destinazione deve essere coerente: se la vecchia pagina descriveva un servizio di consulenza, mandare chi la apre alla homepage costringe a cercare di nuovo l’informazione e può interrompere il contatto.
Per una pagina spostata scegli il 301, per una pausa il 302
Il punto non è quale codice sembri più moderno, ma quanto durerà il cambio. Per una pagina sostituita in modo stabile, sceglierei un 301; se il trasferimento è provvisorio, per esempio durante un’interruzione programmata di un servizio, userei un 302.
Google Search Central distingue i reindirizzamenti permanenti da quelli temporanei anche come segnali per l’indicizzazione: i primi indicano che la destinazione può diventare la pagina canonica, mentre i secondi non comunicano la stessa scelta. La parola “temporaneo” va quindi presa sul serio: lasciare un 302 in modo indefinito rende meno chiara l’intenzione del sito.
Con richieste POST, 307 e 308 evitano un cambio di metodo
Una pagina informativa si apre con una richiesta GET, ma un modulo invia spesso i dati con POST. Qui una scelta frettolosa può alterare la richiesta successiva: secondo la specifica RFC 9110, con 301 e 302 il client può trasformare un POST in GET; i codici 307 e 308 indicano invece di mantenere il metodo originale.
In pratica, per un reindirizzamento temporaneo che deve conservare POST si considera il 307; per uno permanente con lo stesso requisito si considera il 308. Se sposti una pagina di pagamento o un flusso di invio dati, verifica il comportamento dell’applicazione e del gateway: il browser può seguire il redirect, ma ciò non garantisce che il processo commerciale resti integro.
Una pagina di servizio spostata richiede una destinazione equivalente
Immagina che l’indirizzo /servizi/consulenza-digitale sia stato sostituito da /consulenza-sostenibile. Se il contenuto nuovo copre lo stesso servizio, imposta un redirect permanente diretto tra i due URL e aggiorna anche menu, link interni e materiali scaricabili.
Se invece il servizio è stato ritirato e non esiste un’alternativa davvero vicina, non manderei ogni visita alla homepage: chi arriva da un vecchio preventivo si aspetta una risposta precisa, non una pagina generica. In quel caso una pagina che spiega la chiusura e propone un servizio affine può essere più utile del reindirizzamento automatico.
Un loop o una catena si riconoscono dalla sequenza degli URL
Quando il browser mostra “troppi reindirizzamenti”, la causa spesso sta in regole sovrapposte: ad esempio, il server forza HTTPS mentre un proxy o un plugin interpreta la connessione come HTTP e la forza di nuovo. Per isolare il punto, controlla ogni passaggio e modifica una sola regola alla volta.
| Situazione | Possibile causa o effetto | Cosa fare |
|---|---|---|
| Il browser segnala un loop | Due livelli rimandano l’uno all’altro, per esempio tra HTTP e HTTPS | Controlla le regole di server, proxy/CDN e CMS, poi rimuovi la duplicazione |
| Il vecchio URL passa da due o più indirizzi prima di arrivare | Catena di redirect che aggiunge richieste e rende più difficile la manutenzione | Fai puntare il vecchio indirizzo direttamente alla destinazione finale |
| La pagina si apre, ma mostra un contenuto generico o non pertinente | La destinazione non corrisponde all’intento della pagina rimossa | Scegli una pagina sostitutiva equivalente oppure spiega che il servizio è stato ritirato |
| Il modulo arriva alla pagina, ma non completa l’invio | Il metodo o il corpo della richiesta potrebbero non essere conservati | Verifica il flusso con il codice di redirect appropriato e prova l’invio dall’inizio alla conferma |
Il controllo non finisce quando l’URL finale si carica: prova anche il modulo, il login o il checkout se la pagina li usa. Un redirect funzionante per una visita normale può comunque interrompere una richiesta con dati.
Prima di chiudere la modifica, prova il percorso completo
Per ogni URL spostato, annota la destinazione prevista e prova il vecchio indirizzo in una finestra privata. Controlla che il browser raggiunga la pagina giusta senza giri intermedi e che le funzioni presenti sulla pagina continuino a operare.
La regola pratica è semplice: destinazione stabile, redirect permanente; cambio provvisorio, redirect temporaneo. Quando entrano in gioco moduli o pagamenti, aggiungi una verifica del metodo e dei dati: è il passaggio che distingue un URL corretto da un percorso davvero utilizzabile.