Checklist redirect per migrazione sito: 15 controlli prima del DNS

Una migrazione sito riesce o fallisce sulla disciplina dei redirect più spesso che su design, codice o messaggio di lancio. Prima di cambiare DNS, la domanda critica è semplice: ogni vecchia URL importante arriva alla nuova destinazione corretta in un solo hop?

Questa checklist è pensata per team che stanno spostando:

• un sito su un nuovo dominio
• da un CMS a un altro
• da monolite a headless
• da sottodominio a dominio principale
• da vecchie strutture docs o blog a URL più pulite

Se ti serve un esempio specifico Shopify, leggi la guida su migrare URL Shopify a uno storefront headless. Questo articolo è la checklist generale che puoi applicare a quasi ogni stack.

Se la migrazione include anche un cambio dominio con wildcard forwarding, tieni vicino come reindirizzare un dominio senza perdere path e UTM.

L'obiettivo non negoziabile

Prima del lancio, vuoi che queste cinque cose siano vere:

1. le vecchie URL ad alto valore puntano alle nuove URL corrette
2. gli spostamenti permanenti usano intento permanente
3. i redirect risolvono in un solo hop quando possibile
4. i link interni puntano già alle nuove URL canoniche
5. il monitoraggio post-lancio è pronto prima dello spostamento del traffico

Se manca uno di questi punti, il rischio di migrazione sale rapidamente.

Checklist redirect

1. Fai l'inventario delle URL attuali

Non pianificare i redirect a memoria.

Raccogli URL da:

• sitemap XML
• landing page analytics
• pagine principali in Search Console
• URL campagne paid
• template email
• backlink e documenti partner
• vecchi archivi blog e docs

Se una URL porta traffico organico, traffico conversione o richieste supporto, deve entrare nell'inventario.

2. Scegli presto l'hostname canonico finale

Decidi lo standard finale prima di scrivere regole:

• https://new-brand.it
• oppure https://www.new-brand.it

Non lasciare vaga la decisione sull'host. È così che compaiono catene http -> https -> www -> final.

3. Mantieni una mappa redirect in CSV o foglio

Al minimo traccia:

old_url,new_url,status,priority,owner,notes
https://old-brand.it/prezzi,https://new-brand.it/pricing,301,high,marketing,landing principale
https://old-brand.it/docs/api,https://new-brand.it/docs/api,301,high,engineering,migrazione docs

SEO, marketing, engineering e supporto hanno bisogno di una fonte di verità condivisa.

4. Proteggi prima le URL ad alto valore

Dai priorità a:

• homepage
• pricing
• docs
• landing organiche principali
• pagine campagna
• URL supporto linkate da email

Non trattare un archivio a basso traffico come una pagina che genera demo, vendite o ticket.

5. Abbina ogni vecchia URL alla migliore nuova destinazione

L'obiettivo non è sempre preservare il path uno-a-uno. L'obiettivo è la destinazione migliore.

Esempi buoni:

• vecchia pagina prodotto -> nuova pagina prodotto
• vecchia guida docs -> guida equivalente
• campagna rimossa -> offerta o pagina corrente più vicina

Esempi deboli:

• tutto -> homepage
• vecchie docs -> homepage
• deep link rotti -> categoria generica senza contesto

6. Usa redirect permanenti per spostamenti permanenti

Se la vecchia URL non tornerà, usa una policy permanente.

Se non sai quale codice scegliere, vedi redirect 301 vs 302 vs 307 vs 308.

Il punto è non lasciare una migrazione definitiva su un codice temporaneo per mesi.

7. Preserva la struttura path dove ha senso

Se il nuovo sito mantiene una struttura simile, le regole path-preserving riducono lavoro manuale.

Esempi:

• /docs/* -> /docs/*
• /blog/* -> /blog/*
• /features/* -> /features/*

Quando la struttura cambia molto, usa mappature esplicite uno-a-uno per i path ad alto valore invece di wildcard cieche.

Per il pattern tecnico, leggi come reindirizzare un dominio senza perdere path e UTM.

8. Preserva le query importanti

Conta per:

• attribuzione campagna
• parametri affiliati
• tracking lifecycle
• parametri funzionali usati da app o pagina

Non ogni query deve sopravvivere per sempre, ma quelle importanti vanno gestite deliberatamente.

9. Elimina catene prima del lancio

Non aspettare PageSpeed o gli utenti per scoprire che il percorso è disordinato.

Comprimi le catene ora:

old-url -> old-intermediate -> final-url

dovrebbe diventare:

old-url -> final-url

Per debug più profondo, leggi catene e loop di redirect.

10. Testa su staging o host controllati

Prima del cutover pubblico, testa:

• homepage
• landing principali
• path docs
• articoli blog
• URL con parametri
• path mobile-targeted se esistono

Esegui controlli browser e command line:

curl -IL https://old-brand.it/docs/api

11. Aggiorna i link interni prima o subito dopo il lancio

I redirect sono una rete di sicurezza. I link interni dovrebbero puntare direttamente alle nuove URL canoniche.

Questo include:

• nav
• footer
• link nel contenuto
• CTA prodotto
• sidebar docs
• template email se cambiano URL pubbliche

12. Aggiorna sitemap, canonical e navigazione

La mappa redirect è solo una parte della migrazione. Aggiorna anche:

• sitemap XML
• canonical tag
• hreflang, se rilevante
• navigazione principale
• URL nei dati strutturati

Se redirect e canonical dicono cose diverse, stai creando lavoro di pulizia.

13. Prepara il monitoraggio post-lancio

Pianifica i primi 7-14 giorni:

• controlla 404
• ispeziona le URL redirectate principali
• monitora traffico sulle pagine ad alto valore
• verifica link campagna
• conferma che docs e supporto arrivino alla pagina giusta

Qui analytics, redirect checking e broken-link monitoring diventano strumenti operativi, non solo feature interessanti.

14. Mantieni stabile la vecchia infrastruttura di redirect

Un errore comune è pensare ai redirect come attività da una settimana. In realtà vecchi link possono portare traffico per mesi o anni.

Succede soprattutto con:

• backlink
• preferiti
• PDF
• documenti partner
• vecchi post social

Pianifica durabilità, non solo sopravvivenza della settimana di lancio.

15. Documenta eccezioni ed edge case

Non ogni URL merita un redirect. Alcune devono tornare 404 o 410. Alcune pagine legali o supporto possono richiedere trattamento speciale. Alcune route app possono richiedere logica per dispositivo invece di un redirect semplice.

Documenta questi casi perché non diventino comportamento misterioso.

Ordine operativo pratico

La sequenza più breve che funziona:

1. esporta URL
2. scegli host canonico
3. crea la mappa redirect
4. testa le URL principali
5. elimina catene
6. aggiorna link interni e sitemap
7. lancia
8. monitora 404 e traffico redirectato

Questo ordine mantiene il lavoro comprensibile per engineering, marketing e SEO.

Dove aiuta UrlEdge

UrlEdge è adatto quando la migrazione richiede:

• import bulk di redirect
• wildcard path forwarding
• propagazione globale rapida
• strumenti QA per redirect
• visibilità sul traffico post-lancio

È utile soprattutto quando non vuoi spargere logica redirect tra codice app, reverse proxy, plugin CMS e feature del provider DNS.

FAQ

Ogni vecchia URL deve reindirizzare da qualche parte?

No. Alcune URL obsolete devono restituire un vero stato errore. Ma le pagine con valore business o aspettative utente devono puntare a una destinazione rilevante.

Reindirizzare tutto alla homepage è accettabile?

Di solito no. È una delle strategie più deboli: butta via l'intento del path e frustra utenti e crawler.

Quanto devo mantenere i redirect di migrazione?

Più a lungo di quanto molti team immaginino. I redirect importanti spesso devono restare ben oltre il mese di lancio.

Cosa testo prima se ho poco tempo?

Homepage, pricing, docs, landing principali, link campagna e URL con il traffico storico più forte.

Guide correlate UrlEdge

• Bulk URL management
• Redirect 301 permanenti
• Catene e loop di redirect
• Migrazione Shopify headless

Riferimenti autorevoli

• Google Search Central: site move with URL changes
• MDN: Redirections in HTTP