Checklist SEO per la migrazione di un sito: cosa controllare prima e dopo

Una checklist SEO per la migrazione di un sito ha tre parti: cosa registri prima dello spostamento, cosa verifichi il giorno in cui il nuovo sito va online e cosa continui a sorvegliare nel mese successivo. Le migrazioni che perdono traffico spesso avevano un piano sensato. Lo perdono perché un noindex di staging o un blocco nel robots.txt è sopravvissuto al passaggio e nessuno se n'è accorto per due settimane.

Vale per un cambio di dominio, un cambio di piattaforma, un passaggio da HTTP a HTTPS o un restyling che mantiene gli stessi URL. Le impostazioni che rendevano lo staging invisibile a Google arrivano in produzione, e il sito smette di essere scansionabile pur sembrando perfettamente normale nel browser.

Da una a due settimane prima del lancio: costruire la baseline

Non puoi dimostrare cosa ha cambiato una migrazione senza una registrazione di cosa c'era prima. Falla abbastanza presto da fotografare il sito nel suo stato normale, non uno già congelato per il lancio.

1. Esporta tutti gli URL dalla sitemap attuale e da un crawl completo, e conserva entrambi i file. Le pagine che portano traffico ma non sono in sitemap sono quelle che le mappe dei redirect dimenticano, quindi incrocia i dati con le principali pagine di destinazione in GA4 o nel report Rendimento di Search Console degli ultimi 12 mesi.
2. Registra title, meta description, H1, canonical e hreflang di ogni URL con traffico organico. Va benissimo un export CSV da un crawler.
3. Elenca il setup di tracciamento con gli ID: l'ID di misurazione GA4 (prefisso G-), il container GTM (prefisso GTM-), l'ID del Meta Pixel e la piattaforma di consenso ai cookie.
4. Annota i tempi di risposta abituali, così potrai capire in seguito se il nuovo stack è più lento.
5. Costruisci la mappa dei redirect, una riga per ogni vecchio URL con la sua destinazione specifica. Ogni URL con traffico o backlink ne ha bisogno.

La nostra guida alle best practice per la sitemap XML spiega come dovrebbe essere la nuova sitemap.

In staging: trovare le impostazioni che rompono la produzione

I meccanismi che tengono lo staging fuori da Google sono esattamente quelli da togliere al lancio. Individua dove si trova ciascuno in staging, poi ricontrolla in produzione entro pochi minuti dal passaggio.

• robots.txt con Disallow: /. Ecco come controllare il robots.txt riga per riga.
• Un tag noindex in un template condiviso, oppure un header X-Robots-Tag: noindex impostato a livello di server o CDN
• Su WordPress, "Scoraggia i motori di ricerca dall'effettuare l'indicizzazione di questo sito" in Impostazioni > Lettura
• Canonical che puntano all'hostname di staging o al vecchio dominio
• Annotazioni hreflang che citano i vecchi URL o a cui mancano i link di ritorno richiesti da ogni versione linguistica
• Autenticazione HTTP basic, che blocca Googlebot con la stessa efficacia di qualsiasi regola robots

Il giorno del lancio

Le prime ore servono a confermare che il passaggio ha funzionato, non a ridisegnare i template.

Prova i redirect confrontandoli con la mappa. curl -sIL https://old.example.com/pagina/ stampa ogni salto con il suo status code, così verifichi che ci sia un solo 301 verso la destinazione giusta e non una catena o un 302. Non reindirizzare tutto alla home per fare prima: Google tende a trattare quei redirect come soft 404 e il valore delle vecchie pagine va perso.

Controlla che il certificato SSL sia valido sia per l'hostname www sia per il dominio senza www. Poi naviga i template principali con il report Tempo reale di GA4 aperto e verifica che GA4 e GTM partano con gli stessi ID registrati nella baseline. Il tracciamento si perde facilmente quando si ricostruiscono i template, e nessuno se ne accorge fino al report mensile.

In caso di cambio di dominio, verifica entrambe le proprietà in Search Console e comunica lo spostamento con lo strumento Cambio di indirizzo (Impostazioni > Cambio di indirizzo) nella vecchia proprietà. Invia la nuova sitemap e lascia raggiungibile quella vecchia per un po', così Google riscansiona i vecchi URL e trova i redirect.

I 30 giorni successivi alla migrazione del sito

I problemi che compaiono dopo la prima settimana sono quelli che nessuno sta cercando. Degli URL possono uscire dalla nuova sitemap mentre il CMS si assesta, un template può riscrivere title e meta description di un'intera sezione, un deploy di routine può cambiare i canonical e i tempi di risposta possono salire man mano che torna il traffico. In Search Console, il report Indicizzazione delle pagine della nuova proprietà dovrebbe mostrare le pagine indicizzate in aumento mentre quelle della vecchia calano, via via che i redirect vengono elaborati. Se la nuova proprietà si ferma, guarda prima la tabella "Motivi per cui le pagine non sono indicizzate".

Lasciare la baseline a un sistema di monitoraggio

Se aggiungi il sito del cliente a Deltio una o due settimane prima del lancio, lo stato di partenza viene registrato al posto tuo. Deltio controlla ogni giorno sitemap e pagine e confronta ogni controllo con il precedente, quindi una sezione che sparisce dalla sitemap, una modifica a noindex o robots.txt, un canonical che punta altrove o un title, una meta description o un H1 riscritti fanno partire un alert su Slack e via email per quel sito. Sorveglia anche uptime, SSL e scadenza del dominio, e se GA4, GTM e Meta Pixel sono ancora sulla pagina.

Un ciclo giornaliero non sostituisce i controlli manuali della prima ora dopo il lancio. Copre il mese successivo, quando di solito l'attenzione passa al progetto seguente. La baseline non si può creare a posteriori, quindi aggiungi i siti prima che venga fissata la prossima migrazione; la prova gratuita di 14 giorni copre senza problemi un lancio.