Michele Eccher
In questa guida
Che cosa cambia e chi può intervenire?
Annota il dominio attuale e quello previsto dopo il lancio, anche se coincidono. Elenca le lingue coinvolte, gli indirizzi che cambiano e i modelli di pagina da modificare, per esempio schede prodotto, categorie e articoli: questi modelli sono spesso chiamati template. Se il progetto è ancora da definire, la guida su restyling o rifacimento del sito aiuta a scegliere l’intervento. Mantieni testi, URL e collegamenti già efficaci quando il cambio di piattaforma non richiede di modificarli.
Quando i vincoli lo consentono, separa i cambi principali: per esempio, sposta il dominio prima di rifare CMS e design. È anche la raccomandazione di Google e permette di risalire più facilmente alla modifica che ha causato un problema.
Dominio o sottodominio diverso
Chi gestisce l’hosting deve poter configurare entrambi i siti, i DNS che indirizzano le richieste ai server e i certificati TLS necessari per HTTPS. Verifica anche gli accessi alle due proprietà Search Console. Il vecchio sito deve restare raggiungibile per reindirizzare chi visita gli indirizzi precedenti.
CMS, design o struttura diversa
Apri una pagina per ciascun template e confrontala con la versione attuale: può conservare l’indirizzo ma perdere testo, navigazione o funzionalità . Se cambiano gli URL, prepara una tabella che associ ogni vecchio indirizzo alla destinazione prevista sul nuovo sito. Questa tabella è il mapping.
Nomina una persona che decide il lancio e il ripristino. Il referente SEO approva il mapping e verifica le pagine; lo sviluppatore implementa e corregge; chi gestisce hosting e DNS controlla accesso e infrastruttura; chi gestisce analytics verifica che contatti e acquisti siano registrati; il referente commerciale prova che le richieste arrivino e gli ordini possano essere completati. Una persona può coprire più ruoli, ma ogni attività deve avere un nome e un sostituto reperibile.
Prima di fissare la data, verifica gli accessi a repository o CMS, hosting/CDN, DNS, log, ambiente di prova, Search Console e analytics. Chiedi permessi personali adeguati al ruolo. Annota dove sono backup e configurazione dei redirect, chi li ripristina e come salvare gli ordini o i contatti ricevuti dopo il lancio senza perderli se si torna alla versione precedente.
Prima: quali dati salvare e quali URL censire?
Unisci gli URL della scansione del sito con sitemap, esportazioni di Search Console e analytics, log disponibili e destinazioni di campagne o backlink. Elimina i duplicati identici. Mantieni invece distinti HTTP e HTTPS, domini o sottodomini e parametri se mostrano pagine o risposte diverse. Includi immagini e PDF che ricevono visite o link: anche questi possono cambiare indirizzo.
Per ogni URL conserva il codice di risposta HTTP, il titolo, il template e la destinazione prevista. Registra anche il canonical, cioè l’indirizzo indicato come versione principale della pagina, e le direttive robots che regolano scansione e indicizzazione. Segna come prioritari gli URL che portano contatti o vendite, clic organici o link esterni utili. Un inventario ottenuto solo dalla navigazione può lasciare fuori vecchie pagine ancora richieste.
| Responsabile | Dato da salvare | Controllo successivo |
|---|---|---|
| SEO | Clic, impressioni, query e pagine, con date, Paese e dispositivo | Confrontare i periodi sullo stesso gruppo di URL, contando ogni indirizzo una sola volta per periodo, anche se più pagine confluiscono nella stessa destinazione |
| Analytics e commerciale | Contatti o acquisti e definizione degli eventi; prova di un percorso funzionante | Distinguere un calo delle richieste da un evento che non viene più registrato |
| Sviluppo e SEO | Scansione finale, HTML, screenshot e dati strutturati dei template prioritari | Trovare contenuti, link o direttive cambiati senza approvazione |
| Hosting | Errori HTTP e richieste nei log, con intervallo e host osservati | Individuare vecchi URL privi di redirect e verificare se il server rifiuta o non riesce a gestire le richieste |
Salva un periodo recente completo e confrontabile per giorni della settimana; per esempio, 28 giorni aiutano a includere quattro cicli settimanali. Conserva anche lo storico utile a leggere stagionalità e campagne. Se durante il confronto cambiano campagne o domanda stagionale, annotalo: anche queste variazioni possono spiegare una differenza di traffico. Per i controlli di scansione e rendering usa l’audit SEO tecnico per approfondire i test tecnici necessari.
Come compilare il mapping vecchio URL → nuovo URL?
Per ogni indirizzo decidi uno stato finale: invariato, spostato, accorpato o rimosso. Usa URL completi di protocollo e dominio nel file operativo. Per le pagine spostate o accorpate indica una sola destinazione finale per riga; per quelle rimosse senza sostituto, annota la rimozione. Motiva gli accorpamenti: la nuova pagina deve soddisfare il bisogno della precedente. Una scheda prodotto eliminata senza sostituto pertinente può restituire 404 o 410; mandarla alla home page può generare una soft 404.
| Vecchio percorso | Nuovo percorso / stato | Verifica attesa |
|---|---|---|
/servizi/seo.html | /servizi/seo/ | Il vecchio URL reindirizza con 301 o 308 alla pagina del servizio SEO, che risponde 200 e indica se stessa nel canonical |
/blog/redirect-301/ | /guide/redirect/ | La vecchia pagina confluisce nella nuova guida, che deve mantenere le istruzioni sui redirect 301 |
/offerta-estate-2024/ | Rimossa, senza equivalente | Il vecchio URL risponde 404 o 410; vengono rimossi i link interni e la voce nella sitemap |
/contatti/ | Invariato | La pagina risponde 200, mantiene i contenuti e il modulo funziona; non occorre aggiungere redirect |
Aggiungi al mapping responsabile, stato osservato, URL finale osservato, prova e data della verifica. Nell’esempio, se /servizi/seo.html passa prima da /seo/ e poi dalla nuova pagina, correggi la regola iniziale affinché raggiunga direttamente /servizi/seo/. Ripeti il test anche sui vecchi redirect già presenti.
Per uno spostamento definitivo, Google raccomanda i redirect permanenti lato server, come 301 o 308. Prova le varianti realmente usate: HTTP/HTTPS, www/non-www, slash finale, maiuscole, caratteri codificati e parametri. Un filtro prodotto utile non deve finire sulla categoria generica solo perché una regola ignora la query string.
https://example.com/servizi/seo.htmlhttps://example.com/servizi/seo/200 · contenuto equivalente · canonical proprioQuali test completare prima di autorizzare il lancio?
Proteggi l’ambiente di prova con autenticazione o accesso limitato. Se usi noindex o regole robots temporanee, registra dove sono e chi le rimuove dalla produzione. Robots.txt non è una protezione per dati riservati. Chiedi allo sviluppatore un modo per provare i redirect con host e configurazione equivalenti alla produzione, senza spostare il traffico pubblico.
Verifica l’intera mappa
Fai richiedere al crawler o allo script tutti i vecchi URL censiti e confronta stato e destinazione con quelli attesi. Esporta catene, cicli, 404 imprevisti e 5xx. Un campione manuale aiuta a controllare la pertinenza, ma non sostituisce il test completo delle regole.
Confronta i template e le pagine prioritarie
Apri almeno un esempio per ogni template, lingua e regola di redirect differente; aggiungi tutte le pagine prioritarie e le eccezioni note. Includi prodotti, categorie, paginazione e filtri se presenti. Confronta HTML e pagina renderizzata su desktop e mobile: testo, titoli, link, immagini, PDF e dati strutturati. Controlla caricamento e navigazione anche con consenso negato o richieste API fallite. Se un template fallisce, estendi la verifica agli URL che lo usano.
Verifica che Google possa accedere alle nuove pagine
Le pagine da indicizzare devono rispondere 200, consentire la scansione e non avere noindex in HTML o X-Robots-Tag. Canonical, link interni, hreflang e sitemap devono usare gli URL finali previsti. Cerca riferimenti al dominio di staging e link che passano ancora dai redirect.
Prova conversioni e ripristino
Invia una richiesta dal modulo di contatto o completa un acquisto nell’ambiente di pagamento di prova. Controlla che la richiesta o l’ordine arrivino e che analytics li registri, con il consenso appropriato. Concorda come riconoscere e rimuovere i dati di test. Prova anche il ripristino di codice e configurazione, con chi gestisce i dati, senza sovrascrivere nuove transazioni.
Per verificare un singolo redirect con una richiesta GET, sostituisci l’URL dimostrativo nei comandi. curl.exe è la forma per Windows; su macOS e Linux puoi usare curl.
curl.exe -sS -D - -o NUL "https://example.com/servizi/seo.html"
curl.exe -sS -L -D - -o NUL "https://example.com/servizi/seo.html"Il primo comando mostra la risposta iniziale e l’intestazione Location; il secondo mostra la catena completa. Su macOS/Linux sostituisci anche NUL con /dev/null. Il risultato previsto nell’esempio è 301 o 308, poi 200 sull’URL mappato. Il comando non verifica testo, canonical o indicizzazione: apri la destinazione e controlla HTML e intestazioni. In Chrome, F12 → Network → Preserve log consente di conservare le richieste mentre navighi dal vecchio URL.
Durante: in quale ordine pubblicare e verificare?
Scegli una finestra con sviluppatore, referente SEO e responsabile della decisione disponibili, preferibilmente in un periodo di minore traffico. Registra ora, versione e configurazione pubblicata. Per un cambio DNS, controlla sia il vecchio sia il nuovo server durante la propagazione: utenti diversi possono raggiungere infrastrutture diverse.
Rendi disponibile la destinazione
Il tecnico verifica host, DNS e TLS e rimuove le protezioni temporanee dalla sola produzione. Il referente SEO controlla da una connessione esterna pagine prioritarie, robots.txt e risposte HTTP.
Attiva i redirect e ripeti i test
Lo sviluppatore attiva la mappa approvata. Controlla subito le pagine prioritarie e le diverse regole, poi riesegui la verifica dell’intero inventario. Confronta l’esportazione con quella pre-lancio.
Verifica il sito e i percorsi commerciali
SEO e sviluppo controllano contenuti, direttive e collegamenti delle destinazioni. Il referente commerciale e analytics provano form o acquisti, consenso e registrazione degli eventi su desktop e mobile.
Invia la sitemap e decidi se confermare il lancio
Pubblica una sitemap con i nuovi URL canonici indicizzabili che rispondono 200, aggiorna il riferimento in robots.txt e inviala nella proprietà Search Console corretta. Applica i criteri di lancio o stop concordati e annota esiti, eccezioni, responsabile e prossimo controllo.
Aggiorna anche destinazioni di annunci, profili e messaggi automatici. Per i link esterni che portano visite importanti, chiedi l’aggiornamento all’URL finale; conserva comunque i redirect per chi usa vecchi documenti e segnalibri.
Quando usare il Cambio di indirizzo in Search Console?
Usalo per il trasferimento fra domini o sottodomini, dopo che sito e redirect funzionano. Devi essere proprietario della vecchia e della nuova proprietà con lo stesso account Google; verifica le varianti coinvolte e tratta separatamente i sottodomini da spostare. Lo strumento non serve per HTTP → HTTPS, www → non-www, cambio dei soli percorsi o hosting con URL invariati. Segui i requisiti del Cambio di indirizzo e conserva l’accesso alle vecchie proprietà .
Per controllare una destinazione, incolla il nuovo URL nel Controllo URL e distingui i dati indicizzati dal test live. Il test live aiuta a verificare l’accesso attuale; lo stato nell’indice e la canonical scelta da Google riguardano l’ultima elaborazione disponibile. Un esito live positivo non garantisce che la nuova pagina sia già indicizzata.
Secondo le indicazioni di Google sugli spostamenti dei siti, conserva i redirect in genere per almeno un anno. Per un cambio di dominio, mantieni registrazione, certificati e infrastruttura del vecchio host; oltre l’anno valuta le richieste ancora presenti prima di rimuovere le regole. I redirect possono restare utili agli utenti anche quando la transizione nella ricerca è terminata.
Quando confermare il lancio, fermarlo o recuperare?
Concorda i criteri prima del rilascio, indicando pagine e percorsi che devono funzionare. Non usare una percentuale universale di calo del traffico: valuta quali attività il difetto impedisce e quante pagine sono effettivamente coinvolte.
Procedere
Puoi confermare il lancio quando i test della mappa riescono, le pagine prioritarie sono accessibili e indicizzabili e contatti o acquisti funzionano. Deve essere possibile ripristinare la versione precedente. Per gli errori ancora aperti, chi autorizza il lancio deve conoscere le conseguenze e approvare un responsabile e una data di correzione.
Fermare il lancio
Un template prioritario eredita noindex, i redirect vanno a pagine sbagliate, il server risponde 5xx o un percorso di acquisto non funziona. Sospendi il rilascio o la sua estensione e verifica gli URL coinvolti.
Correggere in produzione
Puoi intervenire sul sito già online quando l’errore riguarda un gruppo identificato di URL, sai come correggerlo e puoi verificare il risultato. Chi decide il rilascio deve valutare che questa soluzione comporti meno rischi del ritorno alla versione precedente. Per esempio, una regola punta a un percorso inesistente: correggila e riprova tutte le righe che la usano.
Ripristinare
Un blocco esteso non è correggibile nella finestra concordata e la versione precedente è funzionante e recuperabile. Chi decide il rilascio autorizza il ripristino dopo aver verificato ordini, contatti e dipendenze create dopo il passaggio.
Se la nuova versione mantiene gli URL, il tecnico può ripristinare codice e configurazione collaudati. Se cambia il dominio o la struttura, prima disegna i percorsi di ritorno: non lasciare attivi redirect vecchio → nuovo e nuovo → vecchio che creano un ciclo. Per annullare anche il Cambio di indirizzo, segui la procedura specifica di Search Console; non è sufficiente cambiare il DNS.
Ad esempio, immaginiamo un sito con 120 URL mappati, di cui 12 pagine di servizio costruite con lo stesso template. Il referente SEO apre due di queste pagine e trova noindex, la direttiva che chiede ai motori di ricerca di escluderle dall’indice. La scansione conferma il difetto su tutte e 12. Il responsabile ferma il lancio perché queste pagine devono generare contatti. Lo sviluppatore rimuove la direttiva dal template; il referente SEO ripete i test sulle 12 destinazioni e conferma la correzione prima che il responsabile autorizzi il lancio.
Dopo: che cosa controllare e come registrare i problemi?
Come piano iniziale, verifica accesso, redirect e conversioni subito dopo il rilascio e prima che il team termini la finestra di assistenza. Ripeti ogni giorno nella prima settimana i controlli sugli URL prioritari e le regole corrette; poi verifica ogni settimana gli errori ancora aperti e il passaggio dai vecchi ai nuovi URL nei report di ricerca. Aumenta la frequenza se pubblichi altre modifiche o compaiono anomalie; in presenza di un nuovo errore, ripeti subito il test che permette di individuarne la causa.
| Segnale | Come leggerlo | Azione |
|---|---|---|
| 404 imprevisti, cicli o 5xx | Confronta log e crawl con lo stato deciso nel mapping; un 404 pianificato non è un errore di migrazione | Assegna URL e regola al tecnico e riprova dopo la correzione |
| Nuove pagine escluse dall’indice | Leggi motivo, data e canonical scelta nel Controllo URL; verifica anche la versione live | Rimuovi eventuali blocchi alla scansione o all’indicizzazione e correggi canonical o link sbagliati; controlla poi quando Google aggiorna i dati |
| Calo di clic o impressioni | Definisci il gruppo di vecchi e nuovi indirizzi da seguire. In ciascun periodo conta ogni URL distinto una sola volta e confronta i totali con gli stessi filtri per query, Paese e dispositivo | Se il calo riguarda un template, controlla contenuti, redirect e link di quel gruppo; valuta anche domanda e stagionalità |
| Visite presenti, contatti assenti | Confronta ricezione reale, eventi analytics e comportamento del form o checkout | Ripeti il percorso con consenso appropriato; verifica se la richiesta o l’ordine non arrivano oppure se funziona tutto ma analytics non registra l’evento |
Per confrontare i risultati, prepara un elenco senza duplicati degli indirizzi del gruppo: includi i vecchi URL ancora presenti nei report e le destinazioni previste nella mappa. Se più pagine confluiscono in una sola, conta quella destinazione una volta; anche un URL rimasto invariato compare una sola volta. Mantieni lo stesso elenco e gli stessi filtri nei due periodi e calcola un totale per ciascuno, senza sommare il prima al dopo.
Ad esempio, immaginiamo che due pagine, /a e /b, confluiscano in /c. Se nello stesso periodo i report mostrano 10 clic per /a, 20 per /b e 50 per /c, il totale del gruppo è 80 clic. Sommando separatamente le coppie /a con /c e /b con /c otterresti 130 clic, perché conteresti due volte la destinazione condivisa.
Nel registro annota data e ora, vecchio e nuovo URL, template, esito atteso, risultato osservato e prova salvata. Indica su quali URL hai confermato il problema, chi deve correggerlo, entro quando e quale test ripetere. Segna il problema come corretto solo quando quel test riesce dopo la pubblicazione della modifica. Controlla separatamente in Search Console se Google ha indicizzato la pagina: i report di ricerca non si aggiornano in tempo reale.
Prima di ridurre i controlli, verifica che le pagine prioritarie funzionino e che ogni vecchio URL abbia l’esito previsto nella mappa. Se un gruppo importante perde clic o contatti, completa la diagnosi indicata nella tabella e registra ciò che hai verificato e le eventuali azioni ancora da eseguire. Conserva l’elenco degli errori aperti con responsabili e scadenze. Assegna anche il rinnovo del vecchio dominio e dei certificati e il controllo dei redirect dopo gli aggiornamenti del CMS: se questi interventi vengono dimenticati, i vecchi link possono smettere di funzionare.
Checklist e registro da usare con il team
Il PDF contiene quattro pagine A4: preparazione e accessi, scheda di mapping, controlli di lancio con decisione e registro di problemi e monitoraggio. Stampalo o annotalo con un lettore PDF; duplica le schede per gli URL e i problemi da seguire. I campi sono spazi di scrittura, non moduli interattivi.
Scarica il PDF per la migrazione SEO. Compila la prima pagina prima del collaudo, la mappa durante i test e la decisione al lancio. Usa l’ultima pagina per registrare ciascun problema e il risultato del nuovo controllo. Per un progetto che richiede mapping, test e assistenza al rilascio, consulta il servizio di consulenza per la migrazione SEO.
Altri dubbi sulla migrazione SEO
Quanto tempo serve per una migrazione SEO?
Per stimare il lavoro, conta le pagine di cui devi decidere la destinazione, i template da verificare e le integrazioni da trasferire. Chiedi poi a chi se ne occupa quanto tempo richiedono mappatura, sviluppo, test e correzioni. Dopo il lancio, Google elabora gli URL singolarmente: indica alcune settimane o più per molti siti piccoli o medi e più tempo per quelli grandi. Il collaudo serve a verificare che il sito funzioni e sia accessibile ai motori di ricerca; non può fissare una data di recupero dei posizionamenti.
Un redirect 301 fa perdere PageRank?
Google afferma che i redirect permanenti, come 301 e 308, non causano una perdita di PageRank. Questo non garantisce posizionamenti invariati: una destinazione meno pertinente, contenuti rimossi o problemi di accesso possono cambiare il risultato nella ricerca.
Conviene lasciare online la vecchia sitemap?
Dopo avere inviato la nuova sitemap, Google indica che puoi rimuovere quella precedente. Conservane una copia per confrontare i vecchi indirizzi con la mappa e con i report della migrazione. Nella sitemap del nuovo sito inserisci le pagine finali che vuoi far indicizzare, usando i rispettivi URL canonici. Escludi gli indirizzi che ora reindirizzano.
Serve una mappa dei redirect se gli URL rimangono uguali?
Registra gli URL come invariati e controlla che restituiscano ancora le pagine previste. Non aggiungere redirect per il solo cambio di CMS o hosting. La verifica riguarda contenuti, direttive, canonical, link, risorse e percorsi di conversione prodotti dal nuovo sistema.
