Come reindirizzare un dominio senza perdere path e UTM
Scopri come reindirizzare un dominio preservando path, query string e tracking campagna, evitando loop, problemi SSL e link rotti.
Per reindirizzare un dominio preservando path e query string, il livello di redirect deve inoltrare l'intera URI richiesta, non solo l'hostname. In pratica, una richiesta come:
old-brand.it/pricing?plan=pro&utm_source=email
dovrebbe arrivare a:
new-brand.it/pricing?plan=pro&utm_source=email
Se la configurazione inoltra solo il dominio base, perdi il percorso richiesto dall'utente. Questo rompe link campagna, deep link, pagine docs e spesso anche il valore SEO della migrazione.
Se il cambio fa parte di una migrazione più ampia, parti dalla checklist redirect per migrazioni sito e poi torna su questo dettaglio tecnico.
Cosa significa preservare path e query
Quando qualcuno dice "domain forwarding" o "inoltro dominio", può intendere cose diverse.
Forwarding solo host
Ogni richiesta va alla nuova homepage:
old-brand.it/* -> new-brand.it/
È semplice, ma butta via il contesto.
Forwarding con preservazione del path
Il percorso dopo il dominio resta intatto:
old-brand.it/blog/post-1 -> new-brand.it/blog/post-1
È quello che serve alla maggior parte delle migrazioni sito.
Forwarding con query preservation
Parametri campagna e tracking restano intatti:
old-brand.it/pricing?utm_source=x -> new-brand.it/pricing?utm_source=x
Senza questo, analytics e attribuzione diventano meno affidabili già dal primo giorno.
Se sai che i parametri campagna contano, inseriscili nella specifica redirect invece di lasciarli a una nota QA dell'ultimo minuto.
Perché DNS da solo non basta
È uno dei punti di confusione più comuni.
Record DNS come CNAME o A dicono a internet dove inviare il traffico. Da soli non emettono un redirect HTTP 301 o 302 per il browser.
Se vuoi che utenti e crawler atterrino su una URL diversa, ti serve un layer HTTP che restituisca:
- codice di stato corretto
- destinazione corretta
- eventuale preservazione path
- eventuale gestione query string
Per questo l'inoltro dominio non è solo un'attività DNS. È routing.
Se stai ancora decidendo se il cambio è permanente o temporaneo, leggi redirect 301 vs 302 vs 307 vs 308 prima di pubblicare la regola.
Il pattern più sicuro per una migrazione dominio
Per molte migrazioni, la base migliore è:
- scegli l'hostname canonico finale
- forza HTTPS
- inoltra ogni vecchio path importante al nuovo equivalente
- preserva i parametri query necessari
- mantieni il percorso a un solo hop
Esempio:
http://old-brand.it/docs/api?ref=partner
-> https://new-brand.it/docs/api?ref=partnerÈ molto meglio di:
http://old-brand.it/docs/api
-> https://old-brand.it/docs/api
-> https://www.new-brand.it/docs/api
-> https://new-brand.it/docs/apiQuando preservare il path conta di più
Migrazioni sito
Se cambi dominio o piattaforma, preservare la struttura path mantiene utili backlink e URL indicizzate.
Documentazione e knowledge base
Gli utenti della documentazione raramente partono dalla homepage. Arrivano su una guida specifica. Mandarli tutti su / distrugge l'esperienza.
Campagne paid
Se un utente clicca un annuncio con cinque parametri di tracking e il redirect li elimina, il reporting diventa subito meno affidabile.
Bio social e short link
Molti branded link sono piccole regole di routing. Se il path target sparisce, sparisce anche la chiarezza della strategia link.
Modello wildcard pulito
Il modello mentale più semplice è:
source: old-brand.it/*
destination: new-brand.it/$1Significa:
- prendi tutto ciò che viene dopo lo slash
- inseriscilo nel path di destinazione
- preserva la forma della richiesta
Esempio:
| Richiesta | Destinazione |
|---|---|
/about | /about |
/blog/post-1 | /blog/post-1 |
/pricing/enterprise | /pricing/enterprise |
Se preservi anche le query, allora:
/pricing/enterprise?utm_source=partner
resta:
/pricing/enterprise?utm_source=partner
Se il piano attuale produce due o tre hop prima della pagina finale, correggilo prima del lancio. La guida su catene e loop di redirect mostra cosa cercare.
Quattro controlli che evitano la maggior parte degli errori
1. Conferma prima l'hostname finale
Scegli un solo host:
new-brand.it- oppure
www.new-brand.it
Non deciderlo a metà migrazione. È così che nascono catene http -> https -> www -> final.
2. Decidi il codice di stato
Se il cambio è permanente, usa un codice permanente come 301.
Se è temporaneo, usa un codice temporaneo come 302.
Per un ripasso, vedi redirect 301 vs 302 vs 307 vs 308.
3. Sii esplicito sulle query
Non assumere che ogni provider mantenga le query automaticamente. Testalo.
Usa esempi reali:
curl -I 'https://old-brand.it/pricing?plan=pro&utm_source=email'Poi verifica che l'header Location contenga path e parametri attesi.
4. Testa root e deep URL
Molti redirect funzionano su / e falliscono su pagine profonde:
/docs/api/blog/post-slug/pricing/enterprise/old-category/product-123
HTTPS e SSL fanno parte del redirect
Uno dei peggiori risultati di migrazione è questo:
- il redirect è tecnicamente corretto
- ma il vecchio dominio non termina HTTPS correttamente
- quindi l'utente vede un errore certificato prima del redirect
Il flusso redirect comincia dalla prima richiesta, non dopo che il routing ha già avuto la possibilità perfetta di rispondere.
Se vuoi una gestione già pronta, UrlEdge Free Redirect Service include HTTPS automatico e supporto wildcard forwarding.
Errori comuni
Reindirizzare solo la homepage
È il classico errore "sul dominio funziona". Gli utenti reali non visitano solo /.
Dimenticare www e root domain
Devi pensare a:
old-brand.itwww.old-brand.it- sottodomini, se sono nel perimetro
Perdere parametri campagna
Anche se la SEO sembra a posto, puoi rompere attribuzione e reporting in una notte.
Creare più hop
La preservazione path perde valore se la richiesta rimbalza tra due o tre host intermedi.
Mischiare male HTTP e HTTPS
Se il vecchio host non gestisce HTTPS, gli utenti possono vedere errori sicurezza prima ancora della destinazione.
Setup pratico con UrlEdge
Per una migrazione permanente tipica:
- collega il vecchio dominio
- abilita HTTPS
- crea una regola wildcard
- preserva il path
- preserva i parametri query necessari
- testa le pagine principali con Redirect Checker
È utile quando vuoi una migrazione no-code o low-code senza ricostruire logica di routing in Nginx, Apache o middleware app.
FAQ
Posso reindirizzare un naked domain e mantenere il path?
Sì, se il livello di redirect supporta root domain forwarding e preservazione del path. È un setup molto comune nelle migrazioni.
Devo sempre preservare query string?
Non sempre, ma devi deciderlo. Mantieni tracking, campagne e parametri funzionali importanti. Elimina parametri inutili solo se sei certo che non servano.
Il wildcard forwarding basta per ogni migrazione?
No. Alcune migrazioni richiedono mappature uno-a-uno per path rinominati. Le wildcard sono ottime quando la struttura resta simile.
Posso testarlo prima di cambiare DNS per tutti?
Sì. Testa su staging o host controllati, poi verifica un campione reale di path prima del cutover completo.
Guide correlate UrlEdge
- Free Redirect Service
- Redirect 301 permanenti
- Documentazione DNS
- Checklist redirect per migrazioni sito
Riferimenti autorevoli
Pronto a ottimizzare i tuoi reindirizzamenti?
Usa UrlEdge per gestire redirect, domini e traffico all'Edge da un unico posto.
IniziaArticoli correlati
Visualizza tutto
Alternativa a Firebase Dynamic Links dopo la chiusura
Firebase Dynamic Links è stato dismesso il 25 agosto 2025. Ecco come sostituirlo con smart link brandizzati, app link e fallback controllati.
Redirect 301 vs 302 vs 307 vs 308: quale usare
Usa 301 o 308 per spostamenti permanenti, 302 o 307 per modifiche temporanee. La scelta dipende soprattutto da intento e metodo HTTP.