— Confrontato con la documentazione di Google Search Console, testato su lanci reali di siti, con dati di migrazione dal nostro passaggio .io → .com a gennaio 2026.
TL;DR: Hai lanciato il sito. Complimenti. Adesso inizia il lavoro vero. I primi 30 giorni dopo il lancio determinano se salirai nell’indice di Google o se sparirai nell’indice. Questa checklist SEO dopo il lancio copre i passaggi esatti — ora per ora, settimana per settimana — che uso per ogni lancio e migrazione. Se salti le prime 24 ore, rischi di passare mesi a recuperare quello che avresti potuto proteggere in un pomeriggio.
Lanciare un sito dà una bella sensazione. Per circa cinque minuti. Poi arriva l’ansia — le pagine si stanno indicizzando? I redirect funzionano? Qualcuno ci sta davvero trovando?
L’ho visto decine di volte. I team passano mesi su design, contenuti, sviluppo. Si fissano su font e colori dei pulsanti. Poi cliccano “pubblica” e se ne vanno.
Ed è lì che le cose si rompono.
Solo il 10% delle migrazioni di siti migliora davvero le performance SEO. L’altro 90% resta piatto o perde traffico — a volte in modo catastrofico. Il tempo medio di recupero dopo una migrazione gestita male? 523 giorni. Quasi un anno e mezzo a guardare il grafico del traffico andare nella direzione sbagliata.
La differenza tra il 10% che migliora e il 90% che no? Una checklist. Letteralmente. I team che seguono un processo post-lancio strutturato recuperano in settimane. Quelli che improvvisano passano trimestri a spiegare ai capi perché il traffico è crollato.
"Internal linking is one of the biggest things that you can do on a website to kind of guide Google and guide visitors to the pages that you think are important."
Il punto di Mueller è particolarmente rilevante dopo il lancio. La nuova architettura del sito deve dire subito a Google cosa conta davvero. Se hai lanciato con link interni rotti, pagine orfane o una sitemap mancante, Google non sa da dove iniziare — e non lo capirà da solo.
Questi controlli sono imprescindibili. Falli prima di annunciare il lancio sui social. Prima di scrivere alla tua mailing list. Prima di qualsiasi altra cosa. Nella nostra migrazione, le prime 24 ore sono state un caos di finestre del terminale e tab di Search Console. Non era affascinante. Ma ogni voce qui sotto esiste perché o abbiamo intercettato un problema in tempo, oppure abbiamo visto qualcun altro non farlo.
| Priorità | Controllo | Perché conta | Come verificare |
|---|---|---|---|
| P0 | Rimuovi i tag noindex | I siti di sviluppo bloccano i motori di ricerca — se ti dimentichi di rimuoverli, l’intero sito diventa invisibile | Visualizza il sorgente → cerca noindex. Controlla robots.txt per Disallow: / |
| P0 | Invia la XML sitemap a GSC | Segnala a Google tutte le pagine del nuovo sito. Senza, l’indicizzazione richiede settimane invece di giorni | Google Search Console → Sitemap → Invia URL |
| P0 | Verifica tutti i redirect 301 | I vecchi URL hanno ancora backlink e segnalibri. Redirect rotti = autorità persa | Esegui la scansione della lista dei vecchi URL e verifica che ognuno restituisca un 301 verso il nuovo URL corretto |
| P0 | Controlla che robots.txt sia accessibile | Se robots.txt è bloccato, Google non può eseguire la scansione del sito | Visita yourdomain.com/robots.txt — deve restituire 200 |
| P1 | Verifica HTTPS su tutte le pagine | Gli avvisi di contenuti misti danneggiano fiducia e ranking | Esegui la scansione del sito — segnala tutte le pagine che caricano risorse via HTTP |
| P1 | Controlla i tag canonical | Canonical errati dicono a Google di ignorare le nuove pagine | Controllo a campione su 10 pagine — il canonical deve puntare all’URL attuale, non al vecchio dominio |
| P1 | Testa il rendering su mobile | Google usa il mobile-first indexing — i siti pensati solo per desktop vengono penalizzati | Strumento Mobile-Friendly Test di Google |
| P1 | Monitora i codici di risposta del server | Errori 500 durante il lancio = pagine che escono dall’indice | Controlla i log del server per risposte 5xx nelle prime 24h |
| P2 | Verifica Google Analytics / Tag Manager | Nessun tracciamento = nessun dato. Ti serve una base di riferimento dal giorno uno | Report in tempo reale in GA — conferma che le pageview stiano arrivando |
| P2 | Richiedi l’indicizzazione delle pagine chiave | Accelera la scoperta dei contenuti più importanti | GSC → Controllo URL → Richiedi indicizzazione (homepage, 10 pagine principali) |
Punto chiave
L’errore di lancio più comune che vedo? Lasciare noindex in produzione. Sembra troppo stupido per essere vero — eppure ho visto progetti di redesign da sei cifre andare online con la casella “Scoraggia i motori di ricerca” ancora attiva in WordPress. Controllalo per primo. Controllalo due volte. Poi fai controllare anche a qualcun altro. Noi stavamo quasi per portarci dietro lo stesso problema nel passaggio a .com — l’abbiamo evitato solo perché il nostro script di deploy ha un controllo automatico sul noindex della homepage. Aggiungine uno anche al tuo.
Ecco un robots.txt pulito per un sito appena lanciato. Adatta l’URL della sitemap e gli eventuali percorsi admin in base al tuo CMS.
User-agent: *
Allow: /
# Block admin and staging paths
Disallow: /wp-admin/
Disallow: /staging/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
# Allow CSS and JS for rendering
Allow: /wp-includes/*.js
Allow: /wp-includes/*.css
Allow: /wp-content/themes/*.js
Allow: /wp-content/themes/*.css
# Sitemap location
Sitemap: https://yourdomain.com/sitemap.xml
# AI crawler directives (new for 2026)
User-agent: GPTBot
Allow: /blog/
Allow: /resources/
User-agent: ClaudeBot
Allow: /blog/
Allow: /resources/
User-agent: PerplexityBot
Allow: /blog/
Allow: /resources/Nota le direttive per i crawler AI in fondo. Nel 2026 non è più una cosa facoltativa. Se vuoi che i tuoi contenuti vengano citati nelle risposte di ChatGPT, Perplexity o Claude, devi consentire esplicitamente l’accesso ai loro crawler. Se li blocchi, sparisci completamente dalla ricerca AI — e si tratta di un canale sempre più importante.
Le prime 24 ore servono a gestire le emergenze. La settimana 1 serve a capire se le fondamenta sono solide. Nella nostra migrazione, il giorno 3 è stato quello in cui è arrivato il vero panico — non per una crisi, ma perché era passato abbastanza tempo da iniziare a vedere i dati in Search Console e capire davvero cosa stesse succedendo. Il vuoto tra “abbiamo lanciato” e “abbiamo dati” mette sempre un po’ i nervi a pezzi.
| Giorno | Controllo | Azione richiesta | Strumento |
|---|---|---|---|
| Giorno 2 | Monitora gli errori 404 | Rivedi il report Copertura di GSC per nuovi errori di crawl. Imposta un monitoraggio dei link rotti. | Google Search Console, SEOJuice Broken Link Checker |
| Giorno 2 | Controlla la velocità di caricamento | Esegui un audit Core Web Vitals. LCP sotto 2.5s, INP sotto 200ms, CLS sotto 0.1. | PageSpeed Insights, Chrome DevTools |
| Giorno 3 | Valida i dati strutturati | Testa lo schema markup sui principali tipi di pagina (homepage, prodotto, articolo, FAQ). | Google Rich Results Test |
| Giorno 3 | Controlla la struttura dei link interni | Esegui la scansione del sito per identificare pagine orfane. Ogni pagina importante deve avere almeno 3 link interni. | Screaming Frog, SEOJuice Internal Linking |
| Giorno 4 | Verifica hreflang (se multilingua) | Conferma che tutte le versioni linguistiche puntino correttamente l’una all’altra. Hreflang mancante = contenuto duplicato. | Hreflang Tag Checker |
| Giorno 5 | Audit di meta title e description | Controlla duplicati, tag mancanti o tag che fanno ancora riferimento al vecchio sito/brand. | SEOJuice Site Audit |
| Giorno 5 | Imposta la base di riferimento del rank tracking | Traccia le tue 50 keyword principali. Ti serve una base di riferimento per misurare l’impatto post-lancio. | GSC, SEOJuice keyword tracker |
| Giorno 6-7 | Rivedi i file di log del server | Controlla i pattern di crawl di Googlebot. Sta trovando le pagine importanti? Quanto velocemente? | Log di accesso del server, Screaming Frog Log Analyzer |
Non riesco davvero a sottolineare abbastanza il pezzo dei link interni. Dopo aver lanciato seojuice.com, la prima cosa che ho fatto è stata eseguire il nostro stesso strumento di internal linking su ogni articolo del blog. Abbiamo trovato 34 pagine orfane il primo giorno. Trentaquattro pagine che Google non aveva modo di raggiungere. Quelle pagine ricevevano traffico sul vecchio dominio — e sul nuovo sarebbero semplicemente sparite in silenzio. Il giorno 3 ho iniziato a vedere le prime pagine orfane comparire in Search Console come “Rilevata — attualmente non indicizzata”. È il modo educato di Google per dire: “So che questa pagina esiste, ma non ho nessun motivo per considerarla importante”. I link interni danno a Google un motivo per interessarsene.
A questo punto il tuo sito dovrebbe già essere in indicizzazione. La fase di emergenza è finita. Il mese 1 serve ad accelerare quello che funziona e correggere quello che non funziona.
| Settimana | Controllo | Metrica di successo | Se fallisce |
|---|---|---|---|
| Settimana 2 | La copertura dell’indice cresce | GSC mostra un aumento quotidiano delle pagine indicizzate | Controlla problemi di crawl budget, pagine orfane o risorse bloccate |
| Settimana 2 | Nessun calo di ranking sulle keyword chiave | Le 20 keyword principali restano entro 5 posizioni rispetto al pre-lancio | Verifica i redirect 301, controlla i tag canonical, fai audit del contenuto on-page |
| Settimana 3 | Il traffico organico si stabilizza | Traffico entro l’80% dei livelli pre-lancio | Controlla pagine noindexed, redirect rotti o contenuti mancanti |
| Settimana 3 | Il profilo backlink è intatto | Il numero di domini referenti corrisponde al pre-lancio | Trova i backlink rotti e imposta i redirect |
| Settimana 4 | Nessun content decay attivato | Nessuna pagina mostra un calo di traffico >20% | Fai audit degli URL modificati, aggiorna i link interni, controlla la parità dei contenuti |
| Settimana 4 | La visibilità AI è mantenuta | Il brand continua ad apparire in ChatGPT/Perplexity per le query chiave | Verifica l’accesso dei crawler AI, controlla le direttive in robots.txt, aggiorna llms.txt |
La metrica della stabilizzazione del traffico è quella che manda più persone nel panico. Ecco la verità: quasi ogni migrazione di sito comporta un calo temporaneo del traffico. È normale. Google deve eseguire di nuovo la scansione, reindicizzare e rivalutare i contenuti nella nuova struttura URL. Un calo del 10-20% nelle settimane 1-2 che recupera entro la settimana 3-4 è da manuale. Un crollo del 50% che non recupera entro la settimana 4 significa che qualcosa è rotto in modo strutturale.
Per la nostra migrazione, il calo è stato del 15%. Lo sapevo in anticipo e comunque ho controllato il grafico del traffico ogni ora per tutta la prima settimana. Sapere che una cosa è normale non la fa sembrare normale quando stai guardando i tuoi numeri.
La checklist non finisce a 30 giorni. Queste sono le cose che dovresti monitorare in modo permanente dopo qualsiasi lancio.
Ogni settimana: controlla GSC per nuovi errori di crawl. Monitora i Core Web Vitals. Rivedi eventuali nuove pagine 404. Richiede 15 minuti. Mettilo in calendario. Io lo faccio ogni lunedì mattina prima di qualsiasi altra cosa.
Ogni mese: scansione completa del sito per intercettare nuove pagine orfane. Audit dei link rotti. Controllo del content decay sulle tue 50 pagine principali. Revisione della visibilità AI per le query principali.
Ogni trimestre: audit tecnico completo. Validazione dello schema markup. Pulizia delle catene di redirect (le catene si allungano nel tempo man mano che aggiungi redirect — noi avevamo catene di 4 hop già al mese 2 perché qualcuno ha aggiunto un redirect verso una pagina che era già reindirizzata). Analisi dei link interni per mantenere l’architettura del sito pulita e compatta.
A volte le cose si rompono nonostante la checklist. Ecco l’ordine di priorità nel triage quando ti trovi davanti a un precipizio nel traffico.
| Sintomo | Causa probabile | Correzione | Tempo di recupero |
|---|---|---|---|
| Intero sito deindicizzato | tag noindex o robots.txt che blocca tutti i crawler | Rimuovi il blocco, invia la sitemap, richiedi l’indicizzazione della homepage | 3-7 giorni |
| Calo di traffico del 50%+ da un giorno all’altro | Redirect 301 rotti dal vecchio dominio | Fai audit di ogni redirect, correggi quelli rotti, invia la sitemap aggiornata | 2-4 settimane |
| Pagine specifiche che non rankano | Canonical che punta all’URL sbagliato | Correggi i tag canonical, richiedi la reindicizzazione delle pagine coinvolte | 1-2 settimane |
| Le soft 404 si moltiplicano | Pagine template che restituiscono 200 senza contenuto | Restituisci un vero 404/410 per le pagine morte, oppure aggiungi contenuto reale | 1-3 settimane |
| I ranking calano ma le pagine sono indicizzate | Problema di parità dei contenuti — le nuove pagine hanno meno contenuto | Ripristina il contenuto mancante, aggiungi link interni, controlla i tag H1 | 2-6 settimane |
| I ranking mobile crollano | Il nuovo design non è responsive | Correggi il layout responsive, testa con Google Mobile-Friendly Tool | 1-2 settimane |
Le prime due righe coprono circa l’80% delle chiamate d’emergenza che ho ricevuto dopo un lancio. Quasi sempre è un tag noindex o redirect rotti. Non una misteriosa penalizzazione algoritmica. Non una cospirazione di Google. Solo checkbox dimenticate.
Dovrei mettere in pratica quello che predico, quindi ecco cosa è successo quando abbiamo spostato SEOJuice dal dominio .io al .com a gennaio 2026.
Eravamo su seojuice.io da oltre un anno. Traffico decente, buon profilo backlink, ranking sulle keyword target. Ma volevo il .com. Non per motivi SEO — l’estensione .io va benissimo per la ricerca — ma per fiducia. Quando vendi ad agenzie ed enterprise, avere il .com conta più di quanto dovrebbe.
Ecco cosa abbiamo fatto:
Prima dello switch: esportato ogni URL dal sito .io. Creato una mappa completa dei redirect. Testato ogni redirect in staging. Aggiornato tutti i link interni per puntare agli URL .com. Avvisato Google tramite lo strumento Change of Address in Search Console.
Il giorno dello switch: deploy dei redirect. Invio della nuova sitemap. Verifica in GSC che la proprietà .com stesse ricevendo dati. Monitoraggio dei log del server per l’attività di crawl. Sono rimasto sveglio fino a mezzanotte a guardare il crawl rate di Googlebot salire poco alla volta.
Cosa è successo: abbiamo visto un calo di traffico del 15% nella settimana 1. Alla settimana 3 eravamo tornati ai livelli pre-migrazione. Alla settimana 6 il traffico superava il pre-migrazione del 12% — in parte perché il dominio .com sembrava ottenere un CTR migliore dalle SERP (le persone si fidano del .com, anche se in modo inconscio).
Cosa stava quasi andando storto: avevamo un gruppo di vecchi articoli del blog con URL .io hardcoded nel contenuto. I redirect gestivano bene il traffico esterno, ma i link interni stavano creando catene di redirect (pagina A linka a un URL .io, che fa 301 verso un URL .com). Ce ne siamo accorti il giorno 3 durante la revisione dei log del server — esattamente il motivo per cui quel controllo è nella tabella della settimana 1 qui sopra. Se avessi saltato la revisione dei log, quelle catene si sarebbero accumulate in silenzio, ognuna aggiungendo latenza e diluendo la link equity.
"Sites with strong content quality, topical authority, and clean technical SEO usually stabilize quickly after a migration. The ones that don't recover are the ones that had hidden problems before they moved."
È esattamente quello che abbiamo vissuto. La migrazione non ha creato problemi — li ha messi in luce. Le pagine orfane che abbiamo trovato erano orfane già prima del trasferimento. Gli URL hardcoded erano debito tecnico, non un problema di migrazione. La checklist ci ha semplicemente costretti a guardare davvero.
Ogni voce di questa checklist esiste perché qualcuno, da qualche parte, non l’ha controllata e ha perso traffico. Non sto esagerando. Il controllo dei redirect è lì perché un sito ecommerce da $2M ha perso il 44% del traffico organico dopo una migrazione in cui qualcuno si era dimenticato di mappare 3,000 URL prodotto. Il controllo del noindex è lì perché una SaaS è andata online con “Scoraggia i motori di ricerca” attivo e nessuno se n’è accorto per tre settimane.
La SEO dopo il lancio non è glamour. È una checklist. È spuntare caselle. È guardare i log del server alle 23:00 il giorno del lancio perché qualcosa non ti torna. Nel nostro giorno di lancio, stavo passando da un terminale che faceva tail degli access log a un bambino di due anni che urlava e si rifiutava di andare a dormire. Entrambe le situazioni richiedevano la stessa cosa: pazienza, approccio sistematico e accettare che le successive 48 ore sarebbero state semplicemente così.
Ma è la differenza tra un lancio che si trasforma in crescita composta e un lancio da cui impieghi un anno e mezzo a riprenderti.
Fai la checklist.
Per un dominio completamente nuovo, aspettati 1-2 settimane per l’indicizzazione iniziale dopo aver inviato la sitemap a Google Search Console. Per una migrazione di dominio (stesso contenuto, nuovo URL), Google in genere reindicizza la maggior parte delle pagine entro 1-4 settimane. Richiedere l’indicizzazione della homepage e delle pagine principali tramite lo strumento Controllo URL accelera il processo. I siti con un profilo backlink forte e contenuti aggiornati regolarmente vengono sottoposti a crawl più velocemente.
Sì. Un calo del 10-20% nelle prime 1-2 settimane è del tutto normale, anche nei lanci eseguiti bene. Google deve eseguire di nuovo la scansione e rivalutare i contenuti. La metrica chiave è il recupero: dovresti tornare ai livelli pre-lancio entro 3-4 settimane. Se dopo 4 settimane il traffico è ancora sotto del 30%+, c’è qualcosa che non va — inizia dalla tabella delle correzioni d’emergenza qui sopra.
No. I vecchi backlink trasferiscono autorità attraverso i redirect 301. Fare disavow significherebbe buttare via link equity che hai già guadagnato. Fai disavow solo dei link che erano davvero spammy già prima della migrazione. Al resto pensa il redirect.
Se ne hai uno, sì. Aggiornalo con la nuova struttura URL e le pagine di contenuto principali. Anche se llms.txt non è ancora diventato uno standard ufficiale, Claude e Perplexity lo consultano. È un’attività da cinque minuti che aiuta i motori di ricerca AI ad avere una mappa chiara dei tuoi contenuti. Pensalo come una sitemap per l’AI — poco sforzo, potenziale ritorno elevato.
Se controlli ancora il vecchio dominio, imposta subito i redirect. Se hai perso accesso al vecchio dominio, concentrati sulla costruzione di nuovi backlink verso le pagine principali e invia una sitemap completa. Il recupero senza redirect richiede molto più tempo — aspettati 3-6 mesi invece di 3-6 settimane.
Puoi fare tutto in questa checklist manualmente con Google Search Console e un foglio di calcolo. Ma se preferisci automatizzare il monitoraggio, ecco cosa ti consiglierei:
SEOJuice Site Audit — Esegui un audit completo subito dopo il lancio. Intercetta automaticamente tag noindex, link rotti, schema mancante e oltre 200 altri problemi.
Broken Link Checker — Fondamentale per intercettare gli errori nei redirect. Eseguilo il giorno 1 e di nuovo il giorno 7.
SEO Hygiene Checklist — La nostra guida completa alla manutenzione SEO continua. Si abbina bene a questa checklist SEO dopo il lancio per la fase di “monitoraggio continuo”.
La fase post-lancio è quella in cui si vince o si perde la maggior parte del valore SEO. I team che la trattano come un processo strutturato — non come una celebrazione — sono quelli che alla fine ottengono i risultati migliori.
no credit card required