Una migrazione web viene spesso dichiarata conclusa quando la nuova home page risponde. È un criterio troppo debole per un sito aziendale. Il cambio può comprendere dominio, schema HTTP, percorsi URL, DNS, certificati, API, immagini, moduli, login, pagamenti, callback e posta elettronica. Ogni superficie può continuare a puntare alla versione precedente o rispondere in modo diverso a seconda del resolver, del client e della rete. Il collaudo deve quindi trasformare l’idea generica di “sito online” in una serie di fatti osservabili: quale URL viene richiesto, quale catena di redirect restituisce il server, quale record DNS è pubblicato, quale certificato viene consegnato e quale squadra deve intervenire se il risultato è diverso da quello atteso.
Definire il perimetro prima di toccare la configurazione
Prima di cambiare qualcosa, scrivi che cosa sta cambiando e che cosa deve restare invariato. Un passaggio da example.it a example.eu, per esempio, non è uguale a una semplice sostituzione del server. Potrebbe coinvolgere anche www, api, login, immagini, file scaricabili, portali per clienti, endpoint di pagamento, webhook e indirizzi usati dalle campagne. Google Search Central suggerisce di preparare una mappatura dagli URL attuali ai nuovi e di procedere con una modifica principale alla volta quando è possibile. Per un progetto commerciale aggiungi condizioni verificabili per accesso, ricerca interna, moduli, acquisti, fatture e integrazioni. Senza questo inventario una risposta 200 viene facilmente scambiata per un collaudo completo.
- Domini vecchi, nuovi, www e varianti senza www
- Host per sito, API, login, immagini, file e callback
- Mappatura di URL vecchi verso destinazioni finali
- Record DNS e certificati coinvolti
- Responsabili di sito, DNS, posta e applicazioni
- Finestra di rilascio, criteri di rollback e contatti d’emergenza
Salvare una baseline ripetibile
Una baseline rende possibile il confronto. Prima del rilascio salva A, AAAA, CNAME, NS, MX, TXT e CAA con orario, risposta e TTL. Per gli URL principali conserva stato HTTP, destinazione finale, canonical, regole robots, titolo e sitemap. Per HTTPS annota nome del certificato, SAN, periodo di validità, catena e risultato della connessione. Se il dominio invia posta, conserva SPF, selettori DKIM e DMARC. Non serve registrare ogni pagina del web, ma la selezione deve includere le pagine con più traffico, i link esterni importanti e tutti i percorsi che sostengono un processo di business. Anche una risposta vuota, NXDOMAIN, SERVFAIL o timeout è un dato utile e non va confusa con l’assenza certa del record.
{
"domain": "example.it",
"checked_at": "2026-08-31T09:00:00Z",
"dns": "expected",
"redirects": "pending",
"tls": "verified",
"mail": "unchanged",
"unknowns": ["legacy-api-host"],
"decision": "hold"
}Verificare delega e record DNS
Il controllo DNS ha almeno due livelli. Per prima cosa verifica che la delega restituisca i name server previsti. Poi interroga ogni server autorevole e confronta SOA, NS, A, AAAA, CNAME, MX, TXT e CAA. Un errore frequente è aggiornare un solo server, lasciare la delega sul vecchio servizio oppure copiare la zona senza il record MX o il token usato da un’integrazione. Dopo il controllo autorevole, osserva lo stesso nome da più resolver pubblici. Un resolver può avere in cache un valore precedente; un risultato NXDOMAIN o SERVFAIL, invece, richiede una classificazione propria. TTL e propagazione aiutano a stimare la visibilità, ma non sostituiscono il confronto con la zona autorevole.
Collaudare la catena di redirect su URL reali
La mappatura dovrebbe comprendere pagine ad alto traffico, percorsi con link esterni, login, moduli, download, immagini e URL API. Per ogni voce richiedi l’indirizzo vecchio e salva ogni codice di stato e ogni intestazione Location fino alla destinazione finale. Google raccomanda redirect permanenti lato server, come 301 o 308, e invita a evitare catene inutili. Una catena aumenta latenza e può essere interpretata in modo diverso da client meno completi. Prova HTTP e HTTPS, www e non-www, slash finale, maiuscole quando applicabili, parametri di query e vecchi percorsi usati nelle campagne. Un redirect che porta alla home invece che alla pagina equivalente può confondere gli utenti e indebolire il significato della migrazione.
Dopo i redirect aggiorna canonical, link interni, sitemap, dati strutturati e riferimenti a versioni linguistiche. Le pagine eliminate senza una sostituta coerente dovrebbero restituire 404 o 410, non essere tutte inviate a un’unica pagina generica. Salva l’elenco degli URL falliti con responsabile e prossima azione. Il risultato utile non è solo una percentuale di successi, ma una coda di problemi che il team può ripetere dopo ogni correzione.
Separare TLS, HTTP e applicazione
Il certificato nuovo deve contenere il nome host realmente usato. Controlla validità, SAN, catena e capacità di stabilire una connessione TLS. Poi verifica la risposta HTTP e infine l’autenticazione applicativa. Un 401 o un 403 può essere una protezione voluta, mentre un timeout, un nome non corrispondente o un 5xx richiedono un’indagine diversa. API, applicazioni mobili e callback possono usare host che non compaiono nella navigazione del sito. Per questo il catalogo deve partire dall’uso reale e non soltanto dai menu pubblici. Conservando i risultati per livello è più facile assegnare il problema alla persona giusta senza trasformare ogni anomalia in un generico errore SSL.
La posta merita una verifica separata. Controlla MX, priorità, SPF, selettori DKIM e DMARC, soprattutto se il nuovo dominio viene usato per password dimenticate, fatture o risposte dei clienti. Prova invio, ricezione, inoltro e gestione dei bounce da indirizzi esterni. Non cancellare vecchi TXT finché non hai confermato quali applicazioni li usano. Un sito raggiungibile non dimostra che i messaggi arrivino, così come un DNS aggiornato non dimostra che un’applicazione stia presentando il certificato previsto.
Monitorare il periodo dopo il rilascio
Nel giorno della migrazione osserva traffico vecchio e nuovo, errori 4xx e 5xx, hit sui redirect, risposte DNS, errori TLS e conversioni dei processi importanti. Google ricorda che una variazione temporanea nei risultati di ricerca può essere normale mentre i sistemi rileggono e indicizzano gli URL; questo non rende normali un picco persistente di pagine non trovate o una sitemap non aggiornata. Invia la nuova sitemap, verifica separatamente le proprietà interessate e mantieni i redirect abbastanza a lungo. Aggiorna appena possibile i link interni, i profili pubblici, le campagne e i collegamenti esterni più importanti.
Per ripetere il collaudo su più siti, struttura input e output con lo stesso formato. Ogni riga dovrebbe contenere URL, host, aspettativa, risultato osservato, orario, prova, responsabile e stato. DomScan offre il controllo redirect, il lookup DNS, lo storico DNS, il controllo SSL e il profilo dominio come punti di verifica distinti. Un’integrazione batch deve conservare risultati parziali e stato unknown, insieme ai limiti e alle regole di retry dell’interfaccia usata. L’automazione serve a ridurre omissioni e confronti manuali, non a trasformare una risposta incerta in un esito positivo.
Per rendere il collaudo utile anche a marketing e assistenza, collega ogni URL importante al suo scopo. Una pagina di prodotto può avere un owner diverso da una pagina legale, un feed può essere essenziale per una campagna e un endpoint di autenticazione può non essere visibile a un crawler. Registra il livello di impatto e il comportamento atteso quando un controllo fallisce. Una risposta lenta, un redirect verso un dominio inatteso e un 404 su un contenuto eliminato non richiedono la stessa priorità. Questa classificazione evita che il team insegua dettagli estetici mentre un percorso di pagamento o una callback rimane irraggiungibile.
Esegui una prova in una finestra a basso traffico, ma non confondere il momento tranquillo con una garanzia. Il traffico dei motori, dei partner e delle applicazioni mobili può seguire orari diversi da quelli degli utenti del sito. Dopo il rilascio confronta accessi vecchi e nuovi, errori per percorso, tempi di risposta, richieste ai DNS e richieste di certificato. Se compare un’anomalia, conserva la prima osservazione e il momento in cui il comportamento è tornato normale. La cronologia aiuta a capire se il problema era propagazione, configurazione, cache o una regressione applicativa.
La documentazione di chiusura dovrebbe contenere mappa URL, snapshot DNS, risultati TLS, test posta, stato delle sitemap, problemi rimasti e decisione sul rollback. Indica anche quanto a lungo mantenere redirect e quali vecchi account o record verranno rimossi. Un secondo controllo il giorno seguente e un altro dopo il primo ciclo di traffico forniscono evidenza più solida del controllo immediato. Se il sito ha versioni linguistiche, verifica canonical, alternate e collegamenti per ogni lingua, perché una migrazione può riuscire in italiano e lasciare la versione internazionale con riferimenti obsoleti.
Prima di dichiarare conclusa la migrazione, chiedi una conferma ai proprietari dei percorsi che non sono visibili dal solo browser. Verifica callback di pagamento, webhook, integrazioni con CRM, feed per partner, job programmati e URL usati nelle applicazioni mobili. Per ogni percorso annota una prova di successo e una prova di errore controllato, quando è sicuro eseguirla. Se un vecchio hostname resta necessario per compatibilità, documenta chi lo usa, quale redirect applica e la data della revisione. Questo passaggio riduce il rischio che un URL dimenticato continui a ricevere dati o che venga rimosso senza avvisare un processo essenziale.
Criteri di chiusura e rollback
Chiudi la migrazione soltanto quando la delega DNS e i record chiave corrispondono al piano, gli URL principali arrivano direttamente alla destinazione, TLS e HTTP sono corretti per ogni host critico, posta e API hanno superato i test e gli unknown hanno un responsabile. Se una sola autorità DNS è diversa, un MX importante è scomparso, un certificato non corrisponde o un account di gestione non è accessibile, sospendi il completamento. Il rollback deve includere DNS, redirect, certificati, applicazioni e posta, non soltanto una voce nel pannello. Una baseline e una seconda verifica dopo il rilascio rendono questa decisione documentabile e difendibile.