Una migrazione sito web non ha una durata garantita. Quattro mesi non rappresentano una scadenza, un limite o una soglia ufficiale oltre la quale si possa concludere automaticamente che qualcosa non funziona.
Nel caso raccontato da Search Engine Journal, il nuovo dominio avrebbe inizialmente recuperato traffico, mentre in seguito Google avrebbe ricominciato a mostrare il vecchio. Inoltre, oltre 5.000 URL del nuovo dominio risultavano nello stato “Scansionata, ma attualmente non indicizzata”. John Mueller ha indicato che alcune migrazioni possono richiedere molto tempo, senza però formulare una diagnosi definitiva sul caso.
Il punto operativo è quindi distinguere due possibilità: una rielaborazione ancora in corso oppure la presenza di segnali tecnici incoerenti. Si tratta di ipotesi da verificare, non di conclusioni che possono essere ricavate dalla sola durata della migrazione.
Di cosa parlerò in questa pagina
Quattro mesi non sono una scadenza ufficiale
Il caso citato è utile per comprendere la complessità di una migrazione, ma non costituisce un riferimento temporale valido per tutti i siti. Dimensioni, struttura, quantità di risorse storiche e capacità del server possono influire sull’elaborazione.
Anche lo stato “Scansionata, ma attualmente non indicizzata” descrive una condizione, non la sua causa. Da solo non dimostra che esista un problema nei redirect, che Google abbia commesso un errore o che le pagine non saranno indicizzate.
Prima di arrivare a una conclusione bisogna analizzare un campione rappresentativo di URL e verificare l’intero sistema di segnali: risposte HTTP, destinazioni dei redirect, canonical, sitemap, link interni, hreflang e varianti del dominio.
Come Google elabora una migrazione URL per URL
Google gestisce lo spostamento per singola URL. Deve tornare sulle vecchie risorse, leggere le risposte del server, seguire i redirect e raggiungere le nuove destinazioni. Dopo la pubblicazione può quindi aumentare temporaneamente la scansione del sito.
Questo processo può essere più lungo in presenza di:
- siti grandi o con molte URL storiche;
- immagini, PDF e altre risorse trasferite;
- pagine poco collegate o difficili da raggiungere attraverso i link interni;
- server lenti o soggetti a timeout;
- errori 5xx o risposte 429;
- firewall, CDN o sistemi anti-bot che limitano il crawler.
La velocità di elaborazione non dipende quindi soltanto dal momento in cui vengono attivati i redirect. Anche l’accessibilità delle vecchie e delle nuove risorse ha un ruolo nel processo.
Vecchio dominio ancora visibile: attesa o segnali incoerenti?
Se il vecchio dominio continua a comparire nei risultati, la migrazione potrebbe essere ancora in elaborazione. In alternativa, Google potrebbe ricevere segnali contrastanti. Questa distinzione deve essere trattata come un’interpretazione da verificare tecnicamente, non come una diagnosi automatica.
I principali elementi da confrontare sono:
- redirect: ogni vecchia URL dovrebbe portare direttamente alla nuova risorsa equivalente;
- canonical: le nuove pagine devono fornire riferimenti coerenti con la destinazione prevista;
- sitemap XML: deve rappresentare le URL che si desidera far elaborare sul nuovo sito;
- link interni: non dovrebbero continuare a puntare alle vecchie URL;
- hreflang: i riferimenti tra versioni linguistiche o geografiche devono essere aggiornati;
- varianti del dominio: vanno controllati www, non-www ed eventuali sottodomini pertinenti.
La presenza di una variante non gestita può meritare un controllo, ma non bisogna attribuire automaticamente il problema alla configurazione www/non-www. Allo stesso modo, la ricomparsa del vecchio dominio non dimostra da sola l’esistenza di un bug di Google.
Checklist prima della migrazione sito web
Una migrazione dovrebbe essere pianificata come un progetto tecnico, non come il semplice passaggio da un dominio a un altro. Prima del rilascio è utile completare almeno i controlli seguenti.
1. Inventario e mapping delle URL
Preparare un inventario delle URL esistenti e associare ogni risorsa a una destinazione equivalente. Il mapping uno a uno permette di evitare redirect generici e di individuare in anticipo i contenuti privi di una destinazione corretta.
Se un contenuto è stato eliminato e non esiste un equivalente, è preferibile restituire una risposta 404 o 410 reale anziché rinviare indiscriminatamente alla homepage.
2. Redirect permanenti server-side
Configurare redirect permanenti 301 o 308 dal vecchio indirizzo alla nuova destinazione equivalente. Il percorso dovrebbe essere diretto, senza catene o loop.
Il test deve includere pagine, categorie, file e altre risorse importanti, non soltanto la homepage.
3. Aggiornamento dei segnali interni
Aggiornare i riferimenti al nuovo dominio in:
- canonical;
- link interni;
- sitemap XML;
- hreflang;
- dati strutturati;
- feed;
- riferimenti Open Graph.
Redirect e segnali interni devono indicare la stessa destinazione. Se una pagina reindirizza verso il nuovo dominio ma canonical, sitemap o link continuano a indicare il vecchio, il sistema diventa più difficile da interpretare.
4. Controllo delle impostazioni ereditate dallo staging
Prima della pubblicazione bisogna verificare che il sito non conservi direttive noindex o blocchi nel file robots.txt provenienti dall’ambiente di staging.
5. Riduzione delle modifiche simultanee
Quando possibile, è consigliabile cambiare una cosa alla volta. Modificare contemporaneamente dominio, CMS, architettura, contenuti e design rende più difficile interpretare eventuali perdite e isolare la loro origine.
Controlli dopo il rilascio
La pubblicazione non conclude la migrazione. È l’inizio della fase di verifica, durante la quale bisogna osservare come crawler, server e segnali interni stanno gestendo lo spostamento.
Mantenere operativo il vecchio dominio
Il vecchio dominio deve rimanere raggiungibile e disporre di un certificato TLS valido. I redirect vanno conservati per almeno un anno e, quando possibile, più a lungo.
Configurare Search Console
Occorre configurare e controllare le proprietà, le varianti e gli eventuali sottodomini pertinenti. Dove richiesto, vanno inviati il cambio di indirizzo e la nuova sitemap.
L’ispezione dovrebbe riguardare campioni rappresentativi: URL ad alto traffico, pagine profonde, sezioni diverse, risorse trasferite e contenuti che presentano stati di indicizzazione inattesi.
Analizzare log e scansioni tecniche
I log del server e i crawl permettono di cercare:
- errori 5xx e timeout;
- risposte 429;
- richieste dirette a vecchi hostname;
- canonical errati;
- catene o loop di redirect;
- pagine orfane;
- limitazioni causate da hosting, CDN, firewall o sistemi anti-bot.
Questi controlli aiutano a separare una rielaborazione che richiede tempo da un impedimento tecnico concreto.
Confrontare i dati con una baseline
Traffico, impression, clic, ranking e indicizzazione devono essere confrontati con una baseline precedente alla migrazione. Il monitoraggio dovrebbe proseguire per almeno 3–6 mesi e può essere esteso per i siti più grandi.
Il confronto non serve a promettere un recupero entro una data, ma a individuare quali sezioni stanno seguendo l’andamento previsto e quali richiedono un’analisi più approfondita.
Come impostare aspettative realistiche con il cliente
Per agenzie web, digital agency e freelance è importante definire la migrazione come un’attività composta da pianificazione, rilascio e monitoraggio. Il lavoro non si esaurisce con l’attivazione del nuovo dominio.
Nei contratti e nei piani di progetto è opportuno distinguere:
- gli errori tecnici verificabili, come redirect errati o blocchi alla scansione;
- i normali tempi di rielaborazione di Google, che non hanno una durata garantita;
- le attività comprese nel monitoraggio successivo alla pubblicazione;
- le responsabilità relative a hosting, CDN, CMS e configurazioni esterne.
Una checklist accurata riduce i rischi, ma non garantisce il recupero completo di traffico, ranking o indicizzazione entro una data prestabilita.
Serve supporto tecnico per la migrazione?
Posso supportare agenzie, professionisti e team digitali nella preparazione del mapping, nella verifica dei redirect e dei segnali interni, nella configurazione tecnica e nel monitoraggio successivo al rilascio.
Contattami per saperne di più.
AI Modified
Fonti
- Google Says Why Site Migrations Can Exceed 4 Months via @sejournal, @martinibuster (www.searchenginejournal.com)
- Site Moves and Migrations | Google Search Central | Documentation | Google for Developers (developers.google.com)
- Site Moves and Migrations | Google Search Central | Documentation | Google for Developers (developers.google.com)
Domande frequenti sulla migrazione sito web
Non esiste una durata garantita. Quattro mesi non sono una scadenza ufficiale. Google elabora lo spostamento URL per URL e i tempi possono aumentare per siti grandi, risorse storiche, pagine poco collegate o problemi di risposta del server.
La rielaborazione potrebbe essere ancora in corso oppure potrebbero esserci segnali incoerenti tra redirect, canonical, sitemap, link interni, hreflang e varianti del dominio. Sono possibilità da verificare: la presenza del vecchio dominio non identifica automaticamente una causa.
Significa che la URL è stata scansionata ma non risulta attualmente indicizzata. Questo stato descrive una condizione e non permette, da solo, di stabilirne la causa.
La documentazione citata nel dossier indica di mantenerli per almeno un anno e, quando possibile, più a lungo. Anche il vecchio dominio deve restare operativo e avere un certificato TLS valido.
Bisogna verificare tutte le varianti pertinenti, incluse www, non-www ed eventuali sottodomini. Nessuna singola variante deve però essere considerata la causa certa di un problema senza un’analisi tecnica.
Quando possibile, è meglio modificare una cosa alla volta. Accorpare dominio, CMS, architettura, contenuti e design rende più difficile comprendere l’origine di eventuali perdite.
