Checklist SEO per la migrazione del sito

Una migrazione del sito è un cambiamento controllato alla piattaforma, al dominio, al protocollo, all’architettura dell’informazione, alla struttura degli URL o al sistema di rendering di un sito. È completa solo quando utenti, crawler e analytics possono raggiungere il contenuto desiderato attraverso rotte stabili e il team può dimostrare che la visibilità di valore è sopravvissuta.

Checklist: SEO per la migrazione del sito. Timebox: inizia 6–12 settimane prima del lancio per un sito medio; riserva gli ultimi 5 giorni lavorativi per un blocco delle modifiche, il giorno del lancio per la validazione con personale dedicato e almeno 4 settimane per il monitoraggio attivo. Responsabile: un lead di migrazione responsabile dell’intera release, supportato da responsabili nominati per ingegneria, SEO, analytics, contenuti e infrastruttura.

Perché questa checklist esiste e perché viene eseguita qui

Questo livello di controllo delle release nel Processo SEO consuma le evidenze di crawl e indicizzazione dall’Audit tecnico di base , le decisioni di mantenere/unire/rimuovere dall’Inventario e audit dei contenuti e la gerarchia di destinazione dalla Mappa tematica e architettura dell’informazione . Questi output devono esistere prima che si possano valutare i redirect o lo staging.

Eseguila dopo che la struttura di destinazione è approvata ma prima che le route di produzione siano congelate. Se viene eseguita prima, il team mappa i redirect verso destinazioni che potrebbero ancora cambiare. Se viene eseguita dopo, routing, template, analytics o comunicazioni di lancio potrebbero già essere troppo costosi da correggere in sicurezza.

La mappa dei redirect è l’artefatto a più alto rischio perché collega le vecchie route a quelle nuove. Ogni vecchio URL di valore dovrebbe andare uno-a-uno alla destinazione più vicina che preserva il suo scopo. Non usare mai la homepage come recupero generico: frustra i visitatori e nasconde le destinazioni mancanti.

Input e output

Gli output sono il contratto con le operazioni di lancio. Un foglio di calcolo senza responsabili, evidenze o condizioni di accettazione non è un passaggio di consegne.

La checklist

Ogni elemento specifica cosa, perché, come, strumento e una condizione osservabile di completamento. Sostituisci una soglia solo con una regola più restrittiva o una basata su evidenze documentate.

Fase 1: inventario pre-migrazione

1. Crea l’inventario URL unione. Cosa: combina ogni vecchio URL scopribile da crawl, XML sitemap, analytics, Search Console, esportazioni backlink, record CMS, campagne a pagamento e log server. Perché: nessuna singola fonte contiene ogni URL di valore o richiesto; una pagina assente dalla navigazione può comunque avere link, traffico o importanza contrattuale. Come: normalizza protocollo, host, maiuscole/minuscole, slash finale, parametri e caratteri codificati, mantenendo il valore sorgente originale. Deduplica solo dopo aver registrato dove è stato trovato ogni URL. Strumento: crawler, esportazione CMS, analytics, Search Console, dati backlink e log. Fatto quando: ogni fonte è datata, ogni riga ha un URL normalizzato e una fonte di scoperta, i duplicati sono risolti e i totali per fonte corrispondono all’inventario finale.

2. Classifica la disposizione di ogni URL. Cosa: etichetta ogni URL come mantenere, spostare, unire, rimuovere o investigare. Perché: i redirect non possono essere mappati correttamente finché la decisione sul contenuto non è esplicita. Come: combina traffico, conversioni, backlink, stato dell’indice, qualità dei contenuti, esigenza aziendale e intento; registra l’evidenza e il responsabile dell’approvazione. Strumento: workbook inventario e audit contenuti. Fatto quando: il 100% degli URL in scope ha una disposizione, un responsabile, una destinazione o una motivazione di rimozione e nessuna riga “investiga” irrisolta rimane al momento del congelamento.

3. Acquisisci la baseline firmata. Cosa: preserva le sessioni organiche pre-lancio, clic, impressioni, conversioni, revenue, URL indicizzati, errori di crawl, codici di risposta, uptime e performance per template e directory prioritari. Perché: senza un punto di confronto datato, la variazione normale e il danno da migrazione appaiono uguali. Come: esporta almeno 28 giorni comparabili, annota campagne e stagionalità e identifica gli URL prioritari che richiedono revisione giornaliera. Strumento: analytics, Search Console, crawler, dati di ranking e monitoraggio. Fatto quando: la baseline è in sola lettura, riproducibile, segmentata, timestampata e approvata dai responsabili SEO e analytics.

Fase 2: mappatura dei redirect

4. Mappa le sorgenti uno-a-uno dove possibile. Cosa: assegna ogni vecchio URL spostato o unito al nuovo URL più vicino con lo stesso intento primario. Perché: una destinazione precisa preserva la continuità per il visitatore e fornisce ai crawler un segnale di sostituzione coerente. Come: confronta argomento, prodotto, geografia, lingua e attività; mappa le unioni alla pagina sopravvissuta e documenta le rimozioni deliberate. Non mappare mai URL senza corrispondenza alla homepage. Strumento: workbook mappa redirect, inventario e crawl della destinazione. Fatto quando: ogni sorgente modificata ha esattamente un esito approvato, ogni destinazione è pertinente e in scope e le mappature generiche alla homepage sono pari a zero.

5. Valida la meccanica dei redirect prima del lancio. Cosa: testa codici di stato, destinazioni, comportamento dei parametri, varianti di maiuscole/minuscole, protocollo, sottodomini, slash finali, file e URL di campagne. Perché: un foglio di calcolo apparentemente corretto può comunque produrre loop, catene, wildcard che ingoiano pagine valide o destinazioni che restituiscono errori. Come: genera le regole di staging o proxy, richiedi ogni sorgente, segui i salti e confronta l’URL finale con la mappa approvata. Strumento: test HTTP automatizzato, crawler e revisione della configurazione del server. Fatto quando: il 100% delle sorgenti mappate raggiunge la destinazione 200 approvata in un unico salto di redirect permanente; loop, catene, redirect temporanei e destinazioni con errore sono pari a zero.

6. Reconcilia canonical, link e sitemap con i redirect. Cosa: fai sì che l’URL canonico , i link interni, i riferimenti hreflang, i dati strutturati, i feed e le XML sitemap puntino direttamente agli URL finali. Perché: reindirizzare vecchi URL continuando a pubblicarli crea segnali di migrazione contrastanti e spreca richieste dei crawler. Come: scansiona ogni fonte di riferimento e confronta i target normalizzati con la mappa dei redirect. Strumento: crawler, HTML renderizzato, parser sitemap e diff di configurazione. Fatto quando: le pagine finali si auto-canonicalizzano a meno che un’eccezione approvata non dica diversamente, i riferimenti interni a URL reindirizzati sono zero e le nuove sitemap contengono solo URL canonical 200.

Fase 3: validazione staging

7. Testa lo staging senza renderlo indicizzabile pubblicamente. Cosa: esegui il crawl della release di staging completa impedendo ai motori di ricerca di indicizzare l’ambiente. Perché: il team ha bisogno di evidenze a livello di crawler senza permettere la comparsa di un sito duplicato nei risultati di ricerca. Come: utilizza il controllo accessi per i crawler esterni, poi esegui un crawl interno autenticato con rendering JavaScript dove il sito di produzione dipende da esso. Tratta un blocco di staging come configurazione temporanea di release, non come qualcosa da copiare ciecamente in produzione. Strumento: crawler autenticato, browser e ispezione delle intestazioni di risposta. Fatto quando: l’inventario di staging atteso è scansionabile dal team di test, l’indicizzazione pubblica non autorizzata è bloccata e la checklist di lancio in produzione rimuove esplicitamente i controlli specifici dello staging.

8. Verifica template e percorsi prioritari. Cosa: testa pagine rappresentative di ogni template più navigazione, ricerca, moduli, registrazione, checkout, localizzazione, paginazione, filtri e pagine di errore. Perché: un test riuscito della homepage non può rivelare un bug canonical sulle pagine prodotto o uno stato di consenso interrotto che sopprime gli analytics. Come: crea una matrice dispositivo-template, testa sessioni pulite e di ritorno e registra screenshot o evidenze di risposta per ogni risultato. Strumento: browser, strumento di accessibilità, validatore di dati strutturati, debugger analytics e test di transazione. Fatto quando: ogni template in scope e percorso primario supera il test sui browser e dispositivi concordati, con zero difetti critici aperti.

9. Confronta lo staging con i contratti approvati. Cosa: confronta titoli, descrizioni, intestazioni, canonical, direttive robots, dati strutturati, link interni, codici di risposta, contenuti e tag analytics rispetto al vecchio sito e alle specifiche di destinazione. Perché: le migrazioni di piattaforma spesso perdono metadati o modificano il rendering anche quando la copia visibile appare intatta. Come: esegui il crawl della vecchia produzione e dello staging con impostazioni corrispondenti, segmenta le differenze per template e approva solo le modifiche intenzionali. Strumento: report di diff crawl e ispezione del sorgente. Fatto quando: ogni differenza significativa è corretta o elencata come modifica approvata con responsabile e motivazione; le modifiche accidentali a noindex, canonical, contenuti e tracciamento sono pari a zero.

10. Congela il candidato alla release. Cosa: congela l’inventario URL, la mappa dei redirect, le definizioni delle route, le regole canonical e robots, la generazione delle sitemap, la configurazione di analytics e consenso, il piano DNS/CDN e i deployment di produzione non correlati. Perché: un risultato del test si applica solo alla versione testata. Come: tagga gli artefatti di release, limita le modifiche al percorso incidente e richiedi il ritest di tutto ciò che è stato modificato da una modifica di emergenza. Strumento: sistema di deployment, registro modifiche e registro approvazioni. Fatto quando: un candidato immutabile è nominato, l’accesso è limitato, tutte le eccezioni hanno un responsabile e ogni modifica post-congelamento è accompagnata da un risultato del test.

Fase 4: giorno del lancio

11. Esegui un runbook con un unico responsabile. Cosa: distribuisci routing, applicazione, DNS/CDN, analytics, sitemap e monitor nell’ordine approvato. Perché: modifiche parallele non sequenziate rendono i guasti difficili da isolare e il rollback pericoloso. Come: un lead di migrazione chiama ogni passo, l’operatore assegnato registra il completamento e i validatori testano l’evidenza prima del passo successivo dipendente. Strumento: runbook, log di deployment, controlli DNS e canale incidente condiviso. Fatto quando: ogni riga ha un orario effettivo, operatore, risultato e link all’evidenza, e nessuna dipendenza è segnata come completata basandosi solo su assicurazioni verbali.

12. Esegui lo smoke test di lancio. Cosa: testa la homepage, il file robots, le sitemap, almeno un URL per template, ogni percorso primario, la ricezione analytics e un campione stratificato di sorgenti di redirect. Perché: la risposta sicura più rapida arriva dal rilevare un guasto esteso prima che cache e crawler lo diffondano. Come: testa dall’esterno della rete di produzione, usa desktop e mobile, verifica sia l’HTML servito dal server che l’output renderizzato e confronta con le aspettative congelate. Strumento: crawler, browser, client HTTP, vista real-time analytics e monitor di transazione. Fatto quando: le pagine critiche restituiscono lo stato e il contenuto previsti, i redirect prioritari raggiungono le loro destinazioni esatte, gli eventi analytics arrivano con URL corretti e tutti i controlli bloccanti per il lancio sono superati.

13. Invia e verifica i segnali di scoperta. Cosa: pubblica le sitemap finali, conferma il comportamento di robots e canonical e richiedi l’ispezione per un piccolo insieme di URL prioritari. Perché: segnali di scoperta puliti aiutano i crawler a incontrare l’insieme delle destinazioni senza trattare l’invio come una garanzia di indicizzazione. Come: invia ogni sitemap di produzione una volta, ispeziona URL rappresentativi nuovi e registra lo stato canonico e dell’indice riportato da Google. Strumento: Sitemap e indicizzazione e Ispezione URL . Fatto quando: le sitemap sono raggiungibili e contengono l’inventario canonico congelato, le ispezioni rappresentative non mostrano blocchi di produzione o canonical errati e ogni avviso ha un responsabile.

Fase 5: monitoraggio post-lancio

14. Monitora le prime 72 ore come finestra incidente. Cosa: monitora uptime, 5xx, 4xx, errori di redirect, latenza, volume di crawl, ricezione analytics, conversioni, elaborazione sitemap e percorsi prioritari in modo continuo o all’intervallo più breve possibile. Perché: i difetti di infrastruttura e routing emergono rapidamente, mentre le performance di ricerca richiedono più tempo e non dovrebbero essere usate come unico allarme di lancio. Come: confronta con la baseline firmata, segmenta per template e directory e instrada gli avvisi a un responsabile di turno. Strumento: log, analytics, crawler, Monitor di uptime e dashboard incidenti. Fatto quando: la dashboard non ha alcun allarme critico per il lancio non spiegato, ogni incidente ha un responsabile e un timestamp, e le revisioni a 24, 48 e 72 ore sono firmate.

15. Continua il monitoraggio di ricerca e indice dopo la stabilità. Cosa: monitora clic a livello di pagina, impressioni, stato dell’indice, canonical selezionati, errori di crawl, performance delle directory e risultati di conversione per almeno quattro settimane. Perché: il crawling, la selezione canonical e la sostituzione dell’indice sono in ritardo rispetto alla validazione dell’infrastruttura. Come: confronta finestre omogenee, separa gli URL spostati dai controlli invariati e investiga i cluster invece di reagire al totale di un singolo giorno. Strumento: Pagine di Google Search , Vista directory , Ispezione URL, analytics e log. Fatto quando: le destinazioni prioritarie sono scopribili e indicizzabili, i vecchi URL risolvono in modo coerente verso le destinazioni approvate, le perdite non spiegate hanno ticket aperti e la responsabilità passa nel normale ritmo di reporting.

Strumenti in AmICited

AmICited fornisce evidenze di lancio e superfici di monitoraggio; la mappa dei redirect approvata e i log di deployment rimangono la fonte di verità operativa.

Regole decisionali

Queste sono barriere di protezione della release, non soglie universali dei motori di ricerca. Concordale prima del lancio e stringile dove il rischio lo richiede.

Il rollback ripristina uno stato di servizio noto e funzionante; non inverte le normali fluttuazioni di ricerca. L’autorità di lancio applica le regole concordate e registra le evidenze.

Deliverable

Consegna un pacchetto di controllo migrazione versionato accessibile a ingegneria e SEO. Usa un workbook o database per i record a livello di riga, un runbook per le azioni di lancio e una dashboard per le misure in tempo reale.

Deve contenere: l’inventario congelato e la riconciliazione delle fonti; la mappa dei redirect approvata con responsabili e test; i crawl vecchio, staging e nuovo confrontati; i diff di metadati, canonical, robots, sitemap, hreflang, dati strutturati, link e analytics; la baseline firmata e le coorti prioritarie; il runbook di lancio e la procedura di recupero; le regole numeriche di rollback e il decisore; e le evidenze a 24, 48 e 72 ore con la responsabilità di monitoraggio per quattro settimane.

Il lead di migrazione deve essere in grado di identificare la release esatta, dimostrare ogni test critico, ricostruire ogni decisione di routing e assegnare ogni eccezione. Altrimenti il pacchetto è incompleto.

Cosa va storto

La mappa dei redirect usa solo la sitemap corrente. Gli orfani, gli URL di campagne, i backlink e le route precedentemente indicizzate scompaiono, quindi ogni riga del foglio di calcolo passa mentre le richieste reali falliscono.

La homepage diventa la destinazione predefinita. Gli utenti arrivano da qualche parte di irrilevante, i segnali dei crawler diventano ambigui e i contenuti mancanti vengono mascherati come progresso dell’implementazione.

I redirect funzionano, ma i riferimenti rimangono vecchi. Navigazione, hreflang, canonical, dati strutturati e sitemap continuano a inviare i crawler attraverso salti inutili e destinazioni contrastanti.

La protezione dello staging arriva in produzione. Un noindex copiato, una regola di autenticazione, un blocco robots o una policy CDN distruggono l’indicizzabilità . Richiedi un passo esplicito di rimozione e un test esterno.

Il team valida solo la homepage. Un template condiviso può configurare male migliaia di pagine mentre la homepage passa. Campiona ogni template e scansiona le regole su larga scala.

Release non correlate vengono distribuite insieme. Quando piattaforma, analytics, consenso, navigazione, checkout e modifiche CDN condividono una finestra, i guasti diventano difficili da isolare o invertire.

La ricerca viene giudicata troppo presto o in modo troppo generale. I totali del sito nascondono directory danneggiate e un singolo giorno volatile provoca correzioni non necessarie. Confronta coorti spostate, controlli invariati, directory e finestre corrispondenti.

Il rollback viene dibattuto durante l’interruzione. Un buon piano nomina soglie, decisore, tempo di recupero, comandi, conseguenze sui dati e sequenza di validazione prima del lancio.

Fase successiva

Una volta che le prime 72 ore sono stabili, il passo successivo è Aggiornamento continuo e iterazione . Necessita della baseline firmata, della mappatura URL finale, delle annotazioni di lancio, delle coorti di directory, delle eccezioni note, della cronologia incidenti e dei responsabili nominati da questa checklist. Senza questi input, una successiva perdita di traffico non può essere separata in modo affidabile tra danno da migrazione, cambiamento normale della domanda, decadimento dei contenuti o errore di misurazione.

Mantieni la mappa dei redirect e l’annotazione di migrazione permanentemente. Sposta i risultati non critici nel normale ritmo di reporting con una severità, un’ipotesi, un responsabile, una data di scadenza e un metodo di verifica.

Domande frequenti

Quando dovrebbe partecipare il team SEO a una migrazione del sito?

Prima che route, template e vincoli di piattaforma siano fissati. La SEO ha bisogno di tempo sufficiente per inventariare gli URL correnti, preservare le destinazioni di valore, influenzare la nuova architettura dell’informazione, definire il comportamento dei redirect e concordare regole misurabili di lancio e rollback.

I vecchi URL dovrebbero reindirizzare alla homepage quando non esiste un sostituto diretto?

No. Reindirizza un vecchio URL alla pagina più vicina che soddisfa lo stesso intento dell’utente. Se non esiste una destinazione pertinente e il contenuto non deve essere preservato, restituisci un onesto 404 o 410 invece di inviare utenti e crawler a una homepage non correlata.

Per quanto tempo devono rimanere attivi i redirect di migrazione?

Mantieni i redirect permanenti finché i vecchi URL potrebbero ancora ricevere visite, link, segnalibri o richieste dai crawler. Trattali come infrastruttura di routing durevole, non come impalcatura di lancio da rimuovere dopo poche settimane.

Cosa dovrebbe essere congelato prima del lancio della migrazione?

Congela l’inventario URL approvato, la mappa dei redirect, le regole canonical e robots, la generazione delle sitemap, la configurazione di analytics e consenso, le modifiche DNS e CDN e le release di produzione non correlate. Le correzioni di emergenza seguono il percorso di change control nominato.

Quando dovrebbe essere eseguito il rollback di una migrazione?

Usa criteri concordati prima del lancio. Esegui il rollback per guasti come indisponibilità prolungata, risposte 5xx diffuse, percorsi primari interrotti, analytics mancanti o difetti di routing che riguardano una quota significativa di URL prioritari e non possono essere corretti in sicurezza entro la finestra di recupero concordata.