Migrazione SEO dell’hosting del sito

TL;DR — Una migrazione di hosting sposta l’infrastruttura del sito mentre i visitatori continuano a usare gli stessi URL. Costruisci e testa prima il nuovo host, abbassa il time to live (TTL) DNS prima del lancio, mantieni attivo il vecchio host durante il passaggio e confronta ciò che restituiscono entrambi i sistemi. Controlla DNS, certificati, codici di stato, contenuti, velocità e accesso dei crawler. Spegni il vecchio host solo quando i suoi log mostrano che il traffico è arrivato a zero.

Che cos’è una migrazione di hosting?

Una migrazione di hosting cambia dove o come viene servito un sito senza modificare gli URL visibili alle persone. Spostarsi verso un’altra azienda di hosting è un esempio. Aggiungere o sostituire una content delivery network (CDN), cambiare il server di origine o passare a un altro provider DNS può rientrare nello stesso progetto.

Il fatto che l’URL resti uguale è la condizione distintiva. https://example.com/page/ deve restare https://example.com/page/ prima e dopo lo spostamento.

Google tratta questo caso come un trasferimento del sito senza modifiche agli URL. Se cambiano dominio, protocollo, hostname o percorso, usa invece il processo completo delle migrazioni di sito. Potresti effettuare due migrazioni contemporaneamente.

Perché uno spostamento con lo stesso URL può influire sulla SEO?

Una migrazione di hosting può cambiare tutto ciò che sta dietro a un indirizzo stabile. I motori di ricerca possono incontrare un codice di risposta diverso, un server più lento, un certificato scaduto, una challenge del firewall, una pagina obsoleta nella cache, un’immagine non funzionante, un header mancante o una pagina renderizzata diversa.

Lo spostamento più sicuro conserva la risposta osservabile sostituendo l’infrastruttura. Utenti e crawler dovrebbero ricevere dal nuovo sistema la stessa pagina funzionante che ricevevano da quello precedente.

Quali sono i passaggi fondamentali?

1. Copia o collega il sito alla nuova infrastruttura.
2. Testa il nuovo origin e la nuova CDN senza modificare il DNS pubblico.
3. Abbassa in anticipo il TTL DNS, così il cambio successivo si propaga più velocemente.
4. Conferma certificati, caching, regole di sicurezza e accesso dei crawler.
5. Modifica il DNS per inviare il traffico alla nuova infrastruttura.
6. Mantieni online entrambi gli ambienti mentre le cache DNS scadono.
7. Monitora log, errori, velocità, crawling e rendimento nella ricerca.
8. Spegni il vecchio host solo quando i suoi log mostrano che non resta traffico.

Google raccomanda questa stessa sequenza di preparazione, passaggio, monitoraggio e spegnimento nella sua documentazione sul cambio di hosting.

Che cosa fa il DNS TTL?

Il DNS TTL controlla per quanto tempo un resolver può mettere in cache una risposta DNS. Un TTL più basso prima dello spostamento fa scadere prima dai cache i record modificati. Non fa passare ogni resolver all’istante, e abbassarlo al momento del lancio è troppo tardi per i cache che conservano ancora il vecchio valore.

Google suggerisce di abbassare il TTL a un valore basso e prudente, per esempio poche ore, almeno una settimana prima dello spostamento. Consideralo un esempio, non un numero universale: il tuo provider DNS e i requisiti operativi determinano il valore esatto.

Servono redirect?

Una vera migrazione di hosting non richiede redirect SEO perché gli URL pubblici non cambiano. Aggiungere redirect generalizzati durante uno spostamento limitato all’host crea nuovi possibili guasti senza risolvere il problema infrastrutturale.

I redirect esistenti devono comunque comportarsi esattamente come prima. Testali sul nuovo stack, comprese le vecchie regole legacy che possono trovarsi nel web server attuale, nel CMS, nel load balancer o nella CDN.

Quando lo spostamento è completato?

Lo spostamento dell’hosting è completato quando la nuova infrastruttura serve in modo coerente le risposte previste e la vecchia infrastruttura non riceve più traffico reale da utenti o crawler. Google raccomanda esplicitamente di controllare i log del vecchio provider e spegnerlo solo quando il traffico arriva a zero.

TL;DR — Tratta una migrazione di hosting, CDN o DNS con lo stesso URL come un progetto di parità delle risposte e instradamento del traffico. Censisci ogni hostname e dipendenza, abbassa il TTL DNS prima del lancio, configura il nuovo origin e il nuovo edge, valida certificati e controlli di sicurezza, esegui load test con una domanda realistica di utenti e crawler e confronta le risposte grezze e renderizzate. Fai funzionare in parallelo la vecchia e la nuova infrastruttura durante la propagazione DNS. Monitora entrambi i flussi di log, le risposte DNS, gli errori, la latenza, il comportamento della cache, l’attività di crawling e Search Console. Esegui il rollback ripristinando l’instradamento precedente solo quando si verifica un guasto infrastrutturale concordato in anticipo.

Decidi se si tratta davvero di una migrazione con lo stesso URL

Una migrazione di hosting con lo stesso URL cambia l’infrastruttura senza modificare l’identica stringa dell’URL pubblico. Schema, hostname, porta, percorso, gestione delle query e comportamento dello slash finale restano stabili.

Classifica il progetto prima di pianificarlo:

Non lasciare che un project manager definisca una modifica dell’URL come “solo hosting”. Il piano di deployment deve includere ogni tipo di migrazione che viene effettivamente rilasciato.

Costruisci l’inventario dell’infrastruttura

L’inventario dell’infrastruttura impedisce che le dipendenze silenziose diventino sorprese il giorno del lancio. Registra:

• tutti gli hostname pubblici, inclusi asset, immagini, API, host internazionali e alias legacy;
• record A, AAAA, CNAME, NS, SOA, CAA, MX, TXT e SRV pertinenti;
• autorità di certificazione, metodi di validazione, Subject Alternative Names e scadenze;
• indirizzi dell’origin, porte, health check, load balancer e comportamento di failover;
• chiavi della cache CDN, regole della cache, redirect, trasformazioni, worker e metodi di purge;
• regole WAF, bot, rate limit, geografiche, di autenticazione e di allow/deny IP;
• header di risposta, compressione, comportamento dei cookie e header di sicurezza;
• destinazioni dei log, conservazione, campionamento, campi e fusi orari;
• metodi di verifica di Search Console e analytics;
• callback di terze parti, webhook, flussi di pagamento, feed e IP in allowlist.

La revisione DNS deve includere i record non web. La rottura di record MX, SPF, DKIM, DMARC o di servizio potrebbe non cambiare direttamente il ranking, ma può interrompere l’attività che stavi cercando di proteggere.

Stabilisci una baseline di parità delle risposte

La parità delle risposte significa confrontare i sistemi vecchio e nuovo per lo stesso URL richiesto, non limitarsi a verificare che entrambi restituiscano 200.

Cattura un insieme rappresentativo tra template e comportamenti:

• stato e catena di redirect;
• URL finale e negoziazione del protocollo;
• title, canonical, direttive robots, hreflang e dati strutturati;
• HTML grezzo e contenuto principale renderizzato dal browser;
• Content-Type, Cache-Control, Vary, compressione e header di sicurezza;
• immagini, font, JavaScript, CSS, PDF e asset multimediali;
• cookie e varianti con accesso o personalizzate;
• comportamento su mobile e desktop;
• latenza, time to first byte e tasso di errore.

Usa Staging vs. Production SEO Diff per controlli affiancati delle pagine. Un crawler completo e una suite di richieste con script dovrebbero coprire l’inventario più ampio.

Prepara il nuovo origin

La preparazione dell’origin inizia dalla parità di contenuti e configurazione. Copia contenuti attuali, template, media, regole robots, redirect, gestione degli errori e file di verifica. Blocca o sincronizza le scritture, così il nuovo database non parte con dati obsoleti.

Testa direttamente l’origin attraverso un hostname controllato, un override del file hosts locale o un meccanismo di anteprima specifico del provider. Il test deve mantenere l’header Host di produzione, perché virtual host, routing dell’applicazione, certificati, canonical e link assoluti dipendono spesso da esso.

Il nuovo origin deve gestire anche il carico dopo il cutover. Riscalda applicazione e database, conferma connection pool e autoscaling ed esegui load test su richieste non in cache. I cache miss della CDN possono concentrare immediatamente il traffico sull’origin dopo il lancio.

Configura la CDN come sistema separato

Una migrazione CDN cambia più della geografia. Confronta esplicitamente il comportamento edge vecchio e nuovo:

• composizione della chiave di cache, incluse stringhe di query, cookie, header e varianti per dispositivo;
• codici di stato e tipi di file memorizzabili in cache;
• TTL del browser, TTL edge, servizio di contenuti obsoleti, revalidazione e origin shielding;
• redirect, rewrite, trasformazioni degli header e funzioni edge;
• regole di bypass della cache per account, carrelli, ricerca e pagine personalizzate;
• compressione e ottimizzazione delle immagini;
• ambito e propagazione del purge;
• WAF, gestione dei bot, rate limiting e protezione dell’origin.

La documentazione attuale di Cloudflare, per esempio, nota che il caching predefinito può rispettare gli header Cache-Control dell’origin, ma può essere sovrascritto dalle regole edge. Fornisce anche purge mirati o completi per forzare nuovi fetch dall’origin. Il comportamento esatto dipende dal vendor, quindi esporta e confronta la configurazione invece di presumere che etichette equivalenti producano risultati equivalenti. Vedi la documentazione della cache di Cloudflare.

Tratta la parità della cache come parità dei contenuti

La configurazione della cache può servire la pagina sbagliata in modo corretto e veloce. Testa varianti anonime, autenticate, localizzate, mobile e con stringhe di query. Una chiave di cache che omette un cookie o un header significativo può esporre contenuti personalizzati. Una chiave di cache che include ogni parametro di tracking può frammentare la cache e sovraccaricare l’origin.

Esegui il purge o il pre-warming di asset e pagine critici secondo il piano di lancio. Non eseguire alla cieca il purge di tutto durante il picco del traffico, a meno che l’origin non sia stato testato per il conseguente miss storm.

Valida TLS dall’utente all’edge e dall’edge all’origin

La validazione TLS ha due percorsi quando una CDN termina HTTPS: dal browser alla CDN e dalla CDN all’origin. Conferma copertura degli hostname, catene complete dei certificati, supporto dei protocolli moderni, rinnovo e validazione rigorosa dell’origin.

I certificati riservati all’origin potrebbero non essere considerati attendibili pubblicamente. Cloudflare avverte che i certificati Origin CA possono produrre errori di attendibilità del browser se il proxy è disabilitato o in pausa. Questo è importante durante un rollback: un fallback DNS-only verso un origin che usa un modello di attendibilità solo edge può fallire per gli utenti. Vedi le indicazioni di Cloudflare su Origin CA.

Testa ogni hostname pubblico, comprese le ipotesi sui wildcard e gli hostname per asset o regioni usati raramente. Un certificato apex valido non dimostra che ogni sottodominio sia coperto.

Abbassa il TTL DNS prima dello spostamento

La pianificazione del TTL inizia prima del cutover. Google raccomanda di abbassare il TTL pertinente a un valore basso e prudente, per esempio poche ore, almeno una settimana prima dello spostamento. Un provider DNS può imporre minimi diversi; i record proxied possono avere anche valori fissi.

La documentazione TTL di Cloudflare spiega il compromesso di base: valori più lunghi aumentano il riutilizzo della cache, mentre valori più brevi permettono ai cambiamenti dei record di avere effetto prima. Registra il TTL originale e pianifica di ripristinarlo solo dopo che la nuova infrastruttura è stabile.

I cambiamenti DNS possono non essere atomici nei sistemi distribuiti. Cambia il meno possibile durante il cutover, verifica le risposte da diversi resolver pubblici e mantieni disponibile la vecchia destinazione finché le risposte in cache restano valide.

Verifica l’accesso dei crawler e i controlli di sicurezza

La parità di sicurezza non equivale alla parità del numero di regole. Un WAF copiato da un altro provider può sottoporre i crawler a challenge o bloccarli, rimuovere parametri di query, riscrivere le risposte o applicare un rate limit al crawling ad alto volume in modo diverso.

La guida di hosting di Google dice di assicurarsi che firewall e protezione denial-of-service non blocchino Googlebot quando raggiunge i server DNS o di hosting. Verifica Googlebot usando i metodi di verifica documentati da Google, non una semplice stringa user-agent.

Testa sia il comportamento ordinario dei crawler sia i picchi legittimi. Evita allowlist ampie che disabilitano la protezione per user agent falsificati. Conserva i log di sicurezza, così le richieste bloccate possono essere distinte dai guasti dell’origin.

Pianifica il funzionamento in parallelo

Il funzionamento in parallelo significa che la vecchia e la nuova infrastruttura possono servire risposte di produzione corrette durante la propagazione. Il vecchio ambiente deve continuare a ricevere contenuti o modifiche ai dati che influenzano il sito. Altrimenti gli utenti instradati da risposte DNS in cache potrebbero vedere inventari obsoleti, sessioni non funzionanti o pagine datate.

Scegli una strategia di sincronizzazione:

• un database di lettura/scrittura condiviso da entrambi gli stack;
• dati replicati con un ritardo noto e una policy di conflitto definita;
• un blocco controllato dei contenuti durante il cutover;
• una replica unidirezionale degli eventi per ordini, moduli o scritture degli utenti.

Stato delle sessioni, upload, invalidazioni della cache e job in background richiedono la stessa decisione. “Entrambi i server sono online” non è un piano di funzionamento in parallelo se il loro stato diverge.

Esegui il cutover

Il cutover dell’hosting dovrebbe essere deliberatamente noioso:

1. Ferma i deployment non correlati e conferma la finestra di modifica.
2. Esegui i controlli finali di parità, certificati, capacità e backup.
3. Rimuovi i blocchi temporanei di crawling o accesso dal nuovo percorso di produzione.
4. Modifica solo i record DNS o di instradamento CDN previsti.
5. Conferma le risposte attese da più resolver.
6. Richiedi le pagine protette attraverso il percorso pubblico come utente e crawler.
7. Conferma che arrivino i log dell’edge, del nuovo origin e del vecchio origin.
8. Osserva errori, latenza, cache miss, carico dell’origin e conversioni.

Non usare lo strumento Cambio di indirizzo di Google per uno spostamento limitato all’host. Nessun URL pubblico è cambiato, quindi non c’è alcun cambio di indirizzo da segnalare.

Monitora le prove che dimostrano il completamento dello spostamento

Il monitoraggio dell’infrastruttura deve separare il traffico vecchio da quello nuovo. Usa un marker di deployment e confronta la stessa baseline del giorno e dell’ora quando la stagionalità è rilevante.

Controlla:

• risposte DNS e propagazione dei resolver;
• richieste al vecchio e al nuovo host da utenti e crawler verificati;
• distribuzione dei codici di stato sull’edge e sull’origin;
• errori TLS, di connessione, timeout e applicativi;
• percentili di latenza e tempo di risposta dell’origin non in cache;
• rapporto di cache hit e volume di richieste all’origin;
• richieste di Googlebot, Crawl Stats, Page Indexing e URL Inspection rappresentativi;
• controlli sintetici tra regioni e reti;
• analytics, conversioni e transazioni aziendali critiche.

Google afferma che una diminuzione temporanea del tasso di crawling di Googlebot subito dopo un cambio di hosting può essere normale, seguita da un aumento nei giorni successivi. Basa ogni decisione sulle prove di accessibilità ed errore, non soltanto su quel comportamento previsto.

Definisci il rollback prima del lancio

Il rollback riporta l’instradamento a uno stato infrastrutturale noto e funzionante. Non è una promessa vaga di “riportare indietro il DNS”. Documenta:

• i record, le route e le configurazioni esatte da ripristinare;
• chi può autorizzare ed eseguire l’inversione;
• come riconciliare contenuti modificati, sessioni, moduli, ordini e upload;
• se i vecchi certificati e le dipendenze restano validi;
• i passaggi di purge della cache su entrambi i percorsi;
• le soglie di errore che attivano il rollback;
• il tempo decisionale massimo sicuro.

I trigger di rollback devono essere osservabili: problemi di disponibilità persistenti, interruzioni rilevanti delle conversioni, contenuti errati diffusi, guasti dei certificati, blocchi dei crawler o collasso della capacità che non può essere corretto durante la finestra. Una variazione temporanea del tasso di crawling, da sola, non è un trigger di rollback.

Ritira la vecchia infrastruttura dai log, non dal calendario

Il ritiro del vecchio host avviene dopo che i log mostrano che utenti e crawler non lo raggiungono più e tutti i servizi dipendenti sono stati spostati. Google raccomanda di spegnere il vecchio host dopo che il suo traffico arriva a zero.

Conserva esportazioni di configurazione, log e artefatti di rollback secondo i requisiti aziendali. Ripristina il TTL DNS al valore previsto a regime dopo aver dimostrato la stabilità. Rimuovi le eccezioni temporanee del firewall e i job pianificati duplicati, così la migrazione non lascia un problema permanente di manutenzione.

Riepilogo AI

• Una migrazione di hosting cambia server, CDN, origin o DNS mentre gli URL pubblici restano identici.
• I cambiamenti degli URL richiedono il processo più ampio di trasferimento del sito. Un vero spostamento limitato all’host non richiede una nuova mappa di redirect né l’invio di un Cambio di indirizzo.
• Fai l’inventario di DNS, TLS, origin, CDN, WAF, cache, log, verifiche, asset e dipendenze aziendali prima del lancio.
• Abbassa il TTL DNS prima del cutover, conserva il vecchio valore e ripristinalo dopo che il nuovo percorso è stabile.
• Confronta risposte grezze e renderizzate, pagine, header, asset, redirect, codici di stato, latenza e comportamento aziendale vecchi e nuovi.
• Valida TLS dal browser all’edge e dall’edge all’origin, oltre ai certificati presenti in ogni percorso di rollback.
• Fai funzionare in parallelo gli ambienti e sincronizza le scritture finché le risposte DNS in cache non inviano più traffico al vecchio stack.
• Monitora entrambi i flussi di log, le risposte DNS, gli errori, il carico dell’origin, il comportamento della cache, l’accesso dei crawler verificati, Search Console e le conversioni.
• Ritira il vecchio host solo quando i suoi log mostrano che il traffico è arrivato a zero.

Documentazione ufficiale

Google

• Cambiare hosting e SEO spiega il processo con lo stesso URL: preparazione, cambio DNS, monitoraggio e spegnimento.
• Spostamenti del sito con modifiche agli URL si applica quando cambiano schema, hostname o percorso.
• Verifica Googlebot documenta la verifica DNS inversa/diretta e degli IP pubblicati.
• Il report Crawl Stats aiuta a monitorare le richieste di Googlebot e la disponibilità dell’host.

Riferimenti sull’infrastruttura

• TTL DNS di Cloudflare spiega il compromesso tra TTL e propagazione.
• La cache di Cloudflare documenta caching edge, regole della cache e purge.
• Cloudflare Origin CA documenta i certificati edge-to-origin e il limite relativo all’attendibilità del browser.

Citazioni dalla fonte

• “This guide is only for migrations that don’t affect the user-visible URL.” Google Search Central. Vai alla guida sull’hosting Parafrasi in italiano: Google raccomanda di ridurre il TTL DNS prima dello spostamento, assicurarsi che i firewall continuino ad ammettere il traffico verificato di Googlebot, aspettarsi un calo temporaneo del tasso di crawling e mantenere disponibile il vecchio host finché il suo traffico non è terminato. Indicazioni sul TTL, indicazioni sul firewall, indicazioni sul tasso di crawling e indicazioni sullo spegnimento.

Checklist della migrazione di hosting

Ambito e baseline

• Confermato che nessun URL pubblico cambierà.
• Inventariato ogni hostname web, per asset, API e regionale.
• Esportate le configurazioni DNS, CDN, WAF, cache, redirect, TLS e origin.
• Salvate baseline rappresentative delle risposte grezze e renderizzate.
• Registrate baseline di traffico, errori, latenza, crawling, indicizzazione e conversioni.

Nuova infrastruttura

• Sincronizzati contenuti attuali, media, redirect, regole robots e file di verifica.
• Testato il routing dell’header Host e ogni hostname pubblico.
• Validati i certificati browser-to-edge ed edge-to-origin.
• Allineati chiavi della cache, bypass, TTL, cookie, trasformazioni e comportamento del purge.
• Allineati comportamento di WAF, bot, rate limit e accesso all’origin.
• Eseguiti load test su cache miss, dipendenze dell’applicazione e capacità del database.
• Confermato che i log edge, origin, applicativi e di sicurezza siano conservati e ricercabili.

DNS e lancio

• Abbassati i TTL pertinenti prima dello spostamento e registrati i valori originali.
• Conservati record non web, DNSSEC, verifiche e dipendenze di servizio.
• Documentati il cambio di instradamento esatto e i comandi di rollback.
• Mantenute attive la vecchia e la nuova infrastruttura con un piano di sincronizzazione dei dati.
• Rimosso ogni blocco temporaneo di crawling o accesso dal percorso di produzione.
• Verificate le risposte DNS attraverso più resolver indipendenti.

Dopo il lancio

• Confrontati in produzione stato, contenuti, header, rendering, asset e redirect.
• Confermato che utenti e crawler verificati non siano sottoposti a challenge o bloccati.
• Monitorati log vecchi/nuovi, errori, latenza, cache miss, carico dell’origin e conversioni.
• Controllati Crawl Stats, Page Indexing e risultati rappresentativi di URL Inspection.
• Ripristinato il TTL a regime solo dopo aver dimostrato la stabilità.
• Ritirato il vecchio host solo dopo che il suo traffico è arrivato a zero.

Il framework della parità a cinque livelli

Il modello degli stati della migrazione

Preparata significa che il nuovo stack supera i test di parità e di carico. In commutazione significa che risposte DNS e richieste sono divise. In stabilizzazione significa che il nuovo stack serve quasi tutto il traffico mentre il vecchio resta disponibile. Completata significa che il traffico verso il vecchio host arriva a zero e tutte le dipendenze sono ritirate o trasferite.

Non definire il progetto completato quando è cambiato il DNS. Quello è l’inizio della commutazione, non la fine della migrazione.

Quale piano di migrazione si applica?

Guasti comuni nelle migrazioni di hosting

Alcune regioni raggiungono ancora il vecchio host

Causa probabile: risposte DNS in cache, comportamento dei resolver o record non modificati in modo coerente. Correzione: confronta le risposte autorevoli con diversi resolver pubblici, mantieni il vecchio host con contenuti aggiornati e controlla i TTL invece di forzare cambiamenti ripetuti.

Le richieste di Googlebot diminuiscono dopo il lancio

Causa probabile: un normale aggiustamento a breve termine del tasso di crawling, una challenge del firewall, un guasto DNS, latenza o errori del server. Correzione: controlla Crawl Stats e i log di accesso del bot verificato. Il calo a breve termine documentato da Google non è un motivo per ignorare veri problemi di accesso.

Le pagine sono veloci ma mostrano contenuti obsoleti

Causa probabile: un TTL edge, una chiave di cache, un purge non riuscito o una fonte dati divergente. Correzione: controlla gli header Age, Cache-Control, Vary e quelli di stato della cache del provider; testa le varianti significative; esegui un purge mirato; poi verifica separatamente origin ed edge.

Il sito funziona attraverso la CDN ma fallisce quando viene bypassata

Causa probabile: attendibilità del certificato dell’origin, routing dell’header Host, allowlist del firewall o dipendenza diretta dall’origin mancante. Correzione: valida il percorso edge-to-origin previsto e il percorso di rollback documentato. Non esporre un origin privato solo per far passare un test di bypass non pianificato.

Gli asset falliscono mentre l’HTML funziona

Causa probabile: hostname degli asset omessi, CORS, certificati, URL assoluti, regole della cache, protezione hotlink o permessi dell’origin. Correzione: esegui crawling e test nel browser sull’inventario degli asset, inclusi font, immagini, CSS, JavaScript, PDF e media.

Il carico dell’origin aumenta bruscamente

Causa probabile: cache fredde, una chiave di cache cambiata, cache bypassata, shielding mancante o traffico dei bot che raggiunge direttamente l’origin. Correzione: ripristina le regole della cache previste, riscalda con attenzione gli oggetti di maggior valore e aggiungi capacità. Esegui il rollback se i guasti persistenti superano la soglia concordata.

Strumenti per uno spostamento dell’infrastruttura con lo stesso URL

• DNS Checker confronta i tipi di record comuni attraverso diversi resolver pubblici. Usalo durante la propagazione, ma confronta il risultato anche con la zona autorevole.
• HTTP Header Checker mostra gli header attraverso i redirect, comprese impronte CDN, compressione, sicurezza e controlli della cache.
• Staging vs. Production SEO Diff confronta URL affiancati per stato, canonical, direttive, header selezionati, schema e contenuti.
• Bulk HTTP Status Code Checker controlla stato, redirect, destinazione e latenza su un insieme rappresentativo di URL.
• Google Index Checker controlla i blocchi osservabili di crawling e indicizzazione, poi indirizza a Search Console per la visualizzazione di Google.
• Log del server e dell’edge dimostrano dove è andato il traffico, quale risposta ha ricevuto e quando la vecchia infrastruttura non è più realmente utilizzata.
• Monitoraggio sintetico testa disponibilità pubblica e transazioni critiche da più reti e regioni.

Dimostra che la migrazione di hosting ha funzionato

Test di propagazione DNS e svuotamento del vecchio host

• Test da eseguire: interroga il DNS autorevole e diversi resolver pubblici, poi traccia il volume delle richieste sulla vecchia e sulla nuova infrastruttura.
• Risultato atteso: le risposte pubbliche convergono sul percorso previsto mentre il traffico verso il vecchio host diminuisce fino a zero.
• Interpretazione del fallimento: record incoerenti, risposte in cache o hostname non tracciati stanno ancora instradando il traffico altrove.
• Finestra di monitoraggio: dal cutover almeno fino al TTL precedente rilevante più lungo e finché i log del vecchio host restano a zero.
• Trigger di rollback: regioni rilevanti non riescono a risolvere o raggiungere il nuovo servizio e il problema non può essere corretto durante la finestra di ripristino.

Test di parità delle risposte

• Test da eseguire: confronta la baseline con la produzione usando Staging vs. Production SEO Diff, un crawler e test di rendering nel browser.
• Risultato atteso: stato, canonical, regole robots, contenuti, dati strutturati, link interni, asset e header previsti sono preservati.
• Interpretazione del fallimento: la configurazione del nuovo origin, dell’edge o dell’applicazione ha cambiato una risposta visibile alla ricerca nonostante gli URL stabili.
• Finestra di monitoraggio: subito prima e dopo il cutover, poi dopo ogni correzione al lancio.
• Trigger di rollback: un guasto di indicizzabilità, canonical, contenuto o asset a livello di sito colpisce template protetti e non può essere corretto in sicurezza al volo.

Test di accesso dei crawler e capacità

• Test da eseguire: ispeziona i log dei crawler verificati, Crawl Stats di Search Console, latenza dell’origin, tassi di errore e risultati dei load test senza cache.
• Risultato atteso: i crawler verificati ricevono risposte riuscite senza challenge mentre l’origin resta entro il proprio intervallo di capacità stabilito.
• Interpretazione del fallimento: WAF, DNS, TLS, rate limiting o capacità dell’origin impediscono un crawling affidabile.
• Finestra di monitoraggio: in modo continuo durante il lancio e nei primi giorni di stabilizzazione del tasso di crawling.
• Trigger di rollback: i guasti persistenti di crawler e utenti superano la soglia approvata di errore o disponibilità.

Test di sicurezza della cache

• Test da eseguire: richiedi varianti anonime, autenticate, localizzate, mobile e con query, ispezionando chiavi della cache e header di risposta.
• Risultato atteso: i contenuti pubblici vengono messi in cache come previsto; le risposte private o personalizzate non vengono condivise; le varianti significative restano distinte.
• Interpretazione del fallimento: le regole di chiave o bypass della cache possono servire contenuti errati o sovraccaricare l’origin.
• Finestra di monitoraggio: prima del lancio, subito dopo il cutover e dopo ogni modifica alle regole della cache o al purge.
• Trigger di rollback: dati personalizzati vengono esposti, vengono serviti contenuti obsoleti su larga scala o l’origin non può sostenere il tasso di miss.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Una migrazione di sito richiede più di una checklist per avere successo copre il processo di migrazione più ampio, baseline, staging e monitoraggio.
• Redirect per la SEO spiega il comportamento dei redirect legacy che deve sopravvivere a uno spostamento dell’infrastruttura.

Guide correlate su questo sito

• Migrazioni di sito tratta la classificazione delle migrazioni e il processo universale.
• La Checklist della migrazione di sito fornisce la checklist del progetto organizzata per fasi.
• I codici di stato HTTP spiegano il livello delle risposte che devi preservare e monitorare.

Dal settore

• Google: cambiare hosting
• Google: verificare Googlebot
• Cloudflare: TTL DNS
• Cloudflare: gestire i record DNS
• Cloudflare: documentazione della cache
• Cloudflare: Origin CA
• Bing: IndexNow

Mettiti alla prova: SEO della migrazione di hosting

Cinque domande per classificare, lanciare e validare uno spostamento dell’infrastruttura con lo stesso URL. Scegli una risposta per ciascuna domanda, poi controlla.

Cronologia modifiche