Un redirect è una risposta HTTP: uno stato 301 o 302 con un header Location che dice al browser dove andare invece. Questo è tutto ciò che è sulla rete, il che significa che la domanda non è davvero come reindirizzare un URL, ma quale livello davanti al tuo sito debba essere quello a rispondere.
Sei livelli possono fare il lavoro, e non sono intercambiabili. Differiscono per chi serve la risposta, se il percorso e la query string sopravvivono al viaggio, quanto in fretta puoi cambiare idea, e quanto della configurazione possiedi tu stesso. Questa guida percorre tutti e sei, la tabella che sceglie tra loro, e i due controlli che separano un redirect che funziona da uno che silenziosamente divora i parametri della tua campagna. Per i codici di stato in sé, i tipi di redirect URL è il riferimento sottostante a questo.
Dove vive davvero un redirect
Comincia dal mito, perché spreca più pomeriggi di qualsiasi altro: il DNS non può reindirizzare un URL. Un record DNS mappa un hostname su un indirizzo. Non vede mai il percorso, non vede mai la query string, e non ha alcun meccanismo per dire "vai da qualche altra parte invece". Un record A o CNAME punta; non inoltra.
Quindi quando il tuo registrar offre l'"URL forwarding", quello che fa realmente è puntare l'hostname verso un piccolo web server che gestisce lui, il quale restituisce il redirect HTTP per tuo conto. Utile, e del tutto legittimo, ma è un web server a fare il lavoro, non il DNS. Una volta che lo vedi in questo modo, i sei metodi qui sotto smettono di sembrare alternative e iniziano a sembrare un'unica domanda: quale macchina nel percorso della richiesta vuoi che risponda?
Sei posti dove puoi mettere un redirect
Ciascuno di questi finisce con la stessa risposta sulla rete. Ciò che cambia è il costo di configurazione, chi lo controlla, e cosa succede a tutto ciò che viene dopo il nome di dominio.
domain forwarding presso il registrar
L'opzione più veloce, e la più brutale. Nel pannello di controllo del tuo registrar punti il dominio verso una destinazione e scegli permanente o temporaneo. Va bene per un dominio comprato a scopo difensivo, un rebrand in cui il vecchio nome deve semplicemente passare il testimone, o un dominio di campagna di breve durata.
Il problema è cosa fa al resto dell'URL: la maggior parte dei forwarding dei registrar appiattisce ogni richiesta sull'unica destinazione configurata, quindi un link profondo arriva sulla homepage. Alcuni offrono una modalità che preserva il percorso; verifica prima di fare affidamento su di essa.
una regola nel tuo web server
Se usi nginx o Apache, il redirect appartiene qui, perché ottieni un controllo esatto su corrispondenza e preservazione. La documentazione di Apache sulla rimappatura degli URL con le regole di rewrite copre gli schemi, e il riferimento del modulo rewrite di nginx copre return 301 e rewrite ... permanent, che è la via rapida per uno spostamento semplice.
Le regole del server sono lo strumento giusto per l'imposizione dell'host canonico e di HTTPS, i rewrite dei percorsi dopo una ristrutturazione, e qualsiasi cosa condizionale. Sono anche il posto dove le regole di redirect si accumulano silenziosamente nel corso degli anni, quindi tratta il file come qualcosa da potare piuttosto che solo da ampliare.
una regola nella tua piattaforma di hosting
La maggior parte degli host moderni si posiziona davanti all'origine e offre un proprio livello di redirect: un file _redirects, un blocco di configurazione, un'interfaccia per le regole nella dashboard. Queste vengono valutate prima che la tua applicazione venga eseguita, il che le rende veloci e sicure, e sono di solito il posto migliore per i redirect in massa dopo una migrazione del sito perché vivono nel version control insieme al resto del progetto.
un plugin o un'impostazione nel tuo CMS
Ogni CMS serio ha un gestore di redirect, e per un team di contenuti è la risposta giusta: nessun deploy, nessun accesso al server, una traccia di audit, e una persona che capisce il contenuto a prendere la decisione sulla mappatura. Il compromesso è che la richiesta deve raggiungere l'applicazione prima che il redirect venga emesso, quindi è più lento dei livelli sopra e smette di funzionare se l'applicazione è offline.
meta refresh o JavaScript sulla pagina
Un'ultima risorsa per quando non puoi toccare nulla lato server. La pagina si carica, poi manda avanti il visitatore con un tag <meta http-equiv="refresh"> o uno script. Funziona, ma costa il caricamento completo di una pagina, dipende dal client che lo esegue, e i motori di ricerca lo trattano come un segnale più debole rispetto a una risposta del server. Usalo quando l'alternativa è il nulla.
uno short link gestito
Quando la cosa reindirizzata è un link che hai pubblicato piuttosto che una pagina che possiedi, il redirect appartiene a un gestore di link. La destinazione è un valore memorizzato che puoi cambiare senza toccare DNS, server, o una pipeline di deploy, ogni salto viene registrato, e il link continua a funzionare dopo essere stato stampato o condiviso. Questa è l'intera meccanica dietro cos'è uno url shortener, ed è il motivo per cui un link di campagna stampato non dovrebbe mai puntare direttamente a una landing page.
Scegliere in trenta secondi
La maggior parte della decisione si riduce a due colonne: chi ha accesso, e cosa deve sopravvivere.
| Metodo | Chi lo serve | Percorso e query preservati | Ideale per |
|---|---|---|---|
| Domain forwarding del registrar | Server del registrar | Spesso no, verifica prima | Passaggio dell'intero dominio |
| Regola del web server | La tua origine | Sì, se scritta in quel modo | Host canonico, ristrutturazione |
| Regola della piattaforma | Host davanti | Sì | Redirect di migrazione in massa |
| Plugin CMS | La tua applicazione | Sì | Team di contenuti, senza deploy |
| Meta refresh o JS | Il browser | Sì, ma lentamente | Nessun accesso al server |
| Short link gestito | Il servizio di link | Sì, dall'URL memorizzato | Link pubblicati e stampati |
Preservare il percorso e la query string
Questo è il guasto che sopravvive ai test, perché tutti testano la radice del dominio e la radice funziona sempre.
Punta oldsite.com su newsite.com con un semplice domain forwarding e poi segui un vero link in ingresso, oldsite.com/pricing?utm_source=newsletter. Con un redirect che appiattisce, quel visitatore atterra sulla nuova homepage, il percorso è scomparso, e i parametri di campagna sono scomparsi con esso. Niente va in errore. Le tue analytics mostrano semplicemente traffico diretto alla homepage, e la newsletter sembra non aver fatto nulla.
Due abitudini lo impediscono. Testa con un URL profondo che porta una query string, mai con il dominio nudo. E quando i due siti hanno strutture diverse, mappa esplicitamente i percorsi importanti invece di mandare tutto alla radice, il che è anche ciò che mantiene il valore SEO dei vecchi URL attaccato alla nuova pagina più simile. La stessa disciplina si applica quando erediti i link di qualcun altro, ed è per questo che migrare gli short link senza romperli è un esercizio di mappatura prima ancora che uno tecnico.
Se i link in questione sono quelli che hai pubblicato tu, mantenere la destinazione modificabile vale più di tutto questo: metti i tuoi link sul tuo dominio e la mappatura diventa un campo che modifichi invece di un file di configurazione che rilasci con un deploy.
Verificalo prima di annunciarlo
Un solo comando risolve la questione:
curl -sIL "https://oldsite.com/pricing?utm_source=newsletter" | grep -E '^HTTP|^[Ll]ocation'
Leggi tre cose nell'output. Il codice di stato dovrebbe essere quello che intendevi, 301 per permanente e 302 mentre le cose sono ancora in movimento, e 301 vs 302 spiega perché questa scelta conta più di quanto sembri. L'header Location dovrebbe portare il percorso completo e la query string, non un dominio nudo. E dovrebbe esserci esattamente un redirect: una catena di tre o quattro salti si risolve comunque, ma ogni salto è latenza e un'altra occasione per perdere i parametri, e un hostname ripetuto significa che hai costruito un loop di redirect invece di un redirect.
Se preferisci non aprire un terminale, il nostro link checker traccia la catena e mostra lo stato a ogni salto.
Cosa fanno i motori di ricerca con questo
Un redirect fatto correttamente non è un rischio SEO, e le linee guida sono insolitamente chiare su questo. La documentazione di Google sui redirect e la ricerca tratta un redirect permanente lato server come il segnale più forte per consolidare un URL sul suo sostituto, colloca i redirect lato client sotto di esso, e chiede di mantenere le catene brevi.
I due errori che effettivamente ti costano sono far confluire molti vecchi URL sulla homepage, il che butta via la rilevanza specifica che ciascuno di essi aveva, e lasciare in piedi una catena di salti storici dopo diverse migrazioni. Nessuno dei due è un motivo per evitare i redirect; entrambi sono motivi per verificarli. Quel controllo è la stessa abitudine settimanale della prevenzione del link rot, e se il redirect è su un dominio breve personalizzato, i domini personalizzati per gli short link copre la metà della configurazione relativa a DNS e certificati.
Scegli il livello che corrisponde a chi possiede la modifica, preserva il percorso, limitati a un solo salto, e un redirect smette di essere qualcosa di cui preoccuparti.
Leggi la serie cornerstone
Questo articolo si inserisce nel cluster tutorials. Per i codici di stato e la loro semantica, i tipi di redirect URL è la mappa, e come funzionano gli short link copre cosa succede quando il redirect è un link piuttosto che una pagina.
Articoli correlati sul blog
- Tipi di redirect URL: 301, 302, 307, 308 e altro
- 301 vs 302 redirect: quale dovrebbero usare gli short link
- Loop di redirect: come trovare e risolvere ERR_TOO_MANY_REDIRECTS
- Short link con dominio personalizzato: DNS, TLS e l'edge
- Migra da Bitly senza rompere i tuoi link
- Gli short link danneggiano la SEO? I meccanismi che contano
Domande frequenti
Come reindirizzo un URL verso un altro URL?
Fai in modo che chi risponde alla richiesta restituisca un 301 o un 302 con un header Location che punta al nuovo indirizzo. In pratica significa scegliere un livello: il domain forwarding presso il tuo registrar, una regola nel tuo web server o nella piattaforma di hosting, un plugin nel tuo CMS, oppure uno short link gestito. Il metodo cambia chi serve la risposta e se il percorso e la query string sopravvivono, non ciò che riceve il browser.
Posso reindirizzare un URL con il DNS?
No, ed è il malinteso più comune di tutto l'argomento. Il DNS risolve un hostname in un indirizzo; non ha idea di quale percorso sia stato richiesto e non può restituire un redirect. Quando un registrar offre l'URL forwarding, in realtà punta l'hostname verso un suo piccolo web server che emette il redirect HTTP al posto tuo.
Un redirect mantiene il percorso e la query string?
Dipende interamente dal metodo scelto. Il domain forwarding del registrar spesso appiattisce tutto su un'unica destinazione, quindi /pricing?utm_source=email atterra sulla homepage con i parametri scomparsi. Una regola sul server o sulla piattaforma può preservare entrambi se scritta in quel modo, e uno short link gestito inoltra la destinazione memorizzata includendo la sua query string. Testa con un URL profondo, non solo con la radice del dominio.
Dovrei usare un redirect 301 o 302?
Usa un 301 quando lo spostamento è permanente e vuoi che i motori di ricerca consolidino i segnali sul nuovo URL, e un 302 finché qualcosa è ancora in fase di assestamento. La trappola pratica è che i browser mettono in cache un 301 in modo aggressivo, quindi un redirect permanente di cui poi ti penti continua a scattare per i visitatori di ritorno molto tempo dopo che hai cambiato il server. Testa con un 302, promuovilo a 301 una volta che la destinazione si è stabilizzata.
Come verifico che il mio redirect funzioni?
Esegui curl -sIL sull'URL e leggi le righe di stato e gli header Location. Vuoi un solo redirect, il codice di stato giusto, e la destinazione che ti aspettavi, con il percorso e la query intatti. Una catena di più salti funziona comunque ma spreca latenza, e un hostname ripetuto significa che hai costruito un loop invece di un redirect.
I redirect danneggiano la SEO?
Un redirect implementato correttamente no. Google tratta un 301 come un segnale forte per consolidare il ranking sulla destinazione, e sono le catene lunghe, non i redirect in sé, a causare problemi. Limitati a un solo salto, punta i vecchi URL alla nuova pagina più simile invece di scaricare tutto sulla homepage, ed evita i redirect lato client quando è possibile farne uno lato server.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno