Checklist SEO post-lancio: un sistema di triage, non un semplice elenco di attività

TL;DR: La checklist SEO post-lancio più efficace è più corta di quanto pensi. Un lancio raramente fallisce perché manca una meta description; fallisce quando Google non riesce a eseguire la scansione, il rendering, a fidarsi o a collegare i nuovi URL ai vecchi segnali di autorevolezza. Controlla prima accesso, rendering, redirect, canonical, analytics e sitemap. Se questi passano, il sito probabilmente non sta bruciando. Poi puoi pensare alle rifiniture.

Ho pubblicato siti di clienti con mindnow, ricostruito vadimkravcenko.com e ora sto creando seojuice.io con pagine pubbliche static-first e sezioni di app che non devono posizionarsi. Il panico dopo il lancio quasi mai nasce da “ci siamo dimenticati un attributo alt”. Nasce da “la nuova route React restituisce un guscio vuoto”, “la mappa degli URL ha buchi” o “Search Console indica discovered but not indexed e nessuno vuole ammettere che le pagine sono deboli”.

È questo lo schema mentale da rompere. Una checklist SEO post-lancio deve funzionare come un triage, non come un foglio Excel dove ogni riga ha lo stesso peso morale. Prima si ferma l’emorragia, poi si lucida.

La checklist SEO post-lancio è un triage, non un elenco di compiti

Le checklist di lancio standard appiattiscono il rischio. Una meta description mancante e un robots.txt che blocca tutto non appartengono allo stesso livello, così come un hero image lento e una mappa di redirect 301 rotta.

La prima ora serve per le prove (è la parte che la maggior parte dei team salta). I crawler riescono a raggiungere le pagine? Google vede l’URL previsto, il canonical, il contenuto e lo status? Gli URL vecchi, i link interni, l’analytics e le citazioni sono sopravvissuti? Solo dopo ci si può spostare sul lavoro di miglioramento.

Ecco perché un buon audit SEO tecnico dopo il lancio parte dai possibili fallimenti, non dagli abbellimenti. I lanci sono politici: senza ordine, ogni riunione diventa teatro.

Cosa verificare nei primi 60 minuti dopo il lancio

Non dare per scontato che “il sito si carica in Chrome” significhi che Google vede il contenuto. Chrome è il tuo browser. Googlebot è un crawler con fasi di rendering, code di crawl, risorse bloccate e un lavoro diverso.

Parti dal robots.txt di produzione. Conferma che le sezioni da posizionare siano consentite. Controlla poi meta robots, intestazioni x-robots-tag, codici di stato HTTP e tag canonical. Le pagine live devono restituire 200. I redirect permanenti 301. Le pagine rimosse 404 o 410. I canonical devono essere autoreferenziali o consolidati intenzionalmente.

Usa quindi l’Ispezione URL in Google Search Console. Testa un URL per ogni tipo di pagina indicizzabile: homepage, categoria, prodotto, articolo, località, pagina programmatica e qualunque nuovo template. Esegui il fetch, ispeziona l’HTML renderizzato, verifica contenuto principale, link interni, canonical, titolo e dati strutturati.

«Il problema principale con la CSR è che, se qualcosa va storto durante la trasmissione, l’utente potrebbe non vedere alcun contenuto. Questo può avere anche implicazioni SEO.»

Quel monito di Martin Splitt, Developer Advocate di Google, è il problema del giorno di lancio spiegato in parole semplici. Il rendering lato client non è il male — è fragile al lancio perché uno script fallito, un bug di hydration, un problema di route o un asset bloccato possono trasformare una pagina piena di contenuti in un guscio vuoto.

• Scansiona un campione di template, non solo la homepage.
• Testa un URL per ogni tipo di pagina indicizzabile.
• Usa Ispezione URL per fetch e HTML renderizzato.
• Assicurati che nessuna regola noindex di staging sia finita in produzione.
• Verifica che i contenuti chiave compaiano senza interazione obbligatoria.
• Controlla che i link di navigazione siano link HTML crawlable ove possibile.

Se il sito usa molto JavaScript, aggiungi un passaggio di SEO per JavaScript. Il view-source non basta: conta il DOM renderizzato.

Perché i redirect meritano più attenzione di quella che ricevono

Se gli URL sono cambiati, la mappatura dei redirect è obbligatoria: è il ponte tra i segnali guadagnati del sito vecchio e la nuova struttura.

«Se gli URL cambiano e i vecchi non sono mappati correttamente ai nuovi con 301, il sito rischia di perdere un serio potere SEO.»

Glenn Gabe, Founder di G-Squared Interactive, è diretto perché il fallimento è comune. Gli URL vecchi reindirizzano alla homepage, partono 302 invece di 301, le catene di redirect si accumulano tra vecchi percorsi CMS, regole di slash, HTTP→HTTPS e cartelle di locale (di solito perché nessuno possiede la mappa di migrazione). Gli URL con query string vengono abbandonati senza controllare backlink o traffico.

Scansiona la lista di URL vecchi dopo il lancio (il nuovo sito è la metà facile). È lì che si nasconde la perdita di traffico. Non limitarti a scansionare il nuovo sito e dichiarare vittoria.

• Gli URL vecchi devono puntare alla nuova pagina più equivalente.
• I trasferimenti permanenti vanno fatti con 301.
• Accorcia le catene di redirect.
• I link interni devono puntare agli URL finali, non a quelli reindirizzati.
• Le sitemap XML devono escludere URL reindirizzati e non canonical.

Google può seguire i redirect — l’obiettivo non è testare la sua pazienza. Mantieni i percorsi diretti.

Sitemap e Search Console: utili, ma non magiche

Molte checklist mettono “invia la sitemap” in cima come se forzasse l’indicizzazione. Google Search Central dice che l’invio della sitemap è “solo un suggerimento” e non garantisce download, scansione o utilizzo.

Le sitemap restano utili: aiutano la scoperta, mostrano problemi di reportistica e offrono a Search Console una superficie pulita. Contano di più quando il sito è nuovo, ha pochi link esterni, molte pagine o URL difficili da raggiungere tramite link interni.

Una volta ho visto una sitemap piena di URL reindirizzati nascondere il vero problema: le nuove pagine canonical avevano pochi link.

• Invia l’indice sitemap XML corretto in Google Search Console.
• Rimuovi URL di staging, vecchi domini, reindirizzati, bloccati e non canonical.
• Dividi i file prima di 50 MB non compressi o 50 000 URL.
• Fidati di lastmod solo se il CMS lo scrive con precisione.
• Confronta inviati vs indicizzati per tipo di template.

L’invio della sitemap è logistica. L’indicizzazione si merita.

Se non puoi misurare il lancio, non puoi debuggare

Tutti dicono che il tracciamento è a posto. Poi si rompe la thank-you page, il banner di consenso, l’evento di checkout o il referral cross-domain.

Prima di discutere di ranking, dimostra che la misurazione funziona. GA4 deve attivarsi su ogni template pubblico. Search Console deve essere verificata per la proprietà corretta (protocollo, sottodominio e dominio contano). Bing Webmaster Tools entra in checklist se il sito dipende da Bing, Copilot o traffico da search enterprise.

• Esporta il rank tracking prima del lancio.
• Esporta le landing page organiche per URL, template, paese e dispositivo.
• Conferma la disponibilità dei log del server o CDN se il crawling cala.
• Aggiungi un’annotazione di lancio negli strumenti analytics.
• Testa gli eventi di conversione dopo consent mode e regole del tag manager.

Il team deve capire se il traffico è cambiato per ranking, indicizzazione, misurazione, stagionalità o un redirect rotto. Senza baseline, la riunione post-lancio diventa un’ipotesi con grafici.

Core Web Vitals dopo il lancio: misurare subito, non aspettare il CrUX

Il Web Almanac HTTP Archive 2025 mostra perché le performance meritano attenzione al day zero. HTTPS e tag title sono ormai comuni: HTTPS appare su circa il 91,7 % delle pagine desktop e 91,5 % mobile, i title tag sul 98,6 % desktop e 98,5 % mobile. I Core Web Vitals sono più deboli: tasso di passaggio desktop 56 %, mobile 48 %.

Ciò significa che i Core Web Vitals sono uno dei punti più comuni dove i lanci falliscono — lontano da un compito marginale.

INP è diventato un Core Web Vital stabile il 12 marzo 2024, sostituendo FID. Le soglie sono semplici: 200 ms o meno è buono; da oltre 200 ms a 500 ms da migliorare; sopra 500 ms è scarso. Il Web Almanac riporta che il 77 % delle pagine mobile passa INP, contro il 97 % desktop. Solo il 53 % dei top 1 000 siti passa, indice di grandi siti pesanti di JavaScript.

CrUX usa una finestra rolling di 28 giorni, quindi le nuove pagine potrebbero non avere subito dati field. Usa Lighthouse, PageSpeed Insights (lab), WebPageTest, RUM e test a livello di template finché i dati field non maturano.

• Testa prima su mobile.
• Testa il template più lento, non la pagina più bella.
• Controlla LCP su hero image e risposta server.
• Controlla INP su menu, filtri, accordion, search, form e configuratori.
• Controlla CLS dopo font, ads, banner, embed e cookie notice.

Qualità dei contenuti e link interni: perché “Discovered, currently not indexed” non è un problema di pulsante

La gente vede “Discovered, currently not indexed” e ricomincia a inviare URL. Può aiutare Google a ritrovare una pagina, ma non la rende degna di indicizzazione.

«Nella maggior parte dei casi si tratta però di qualità complessiva del sito.»

Questa frase di John Mueller, Search Advocate di Google, è uno schiaffo utile. La maggior parte delle checklist post-lancio tratta l’indicizzazione come un problema di configurazione. Mueller la riposiziona come problema di qualità.

Verifica che le pagine importanti siano linkate da navigazione crawlable, hub, breadcrumb o blocchi di contenuti correlati. Cerca link nel body spariti durante il redesign. Esamina pagine location, categoria, tag o programmatiche sottili che si sono moltiplicate. Assicurati che il contenuto unico non sia sepolto sotto tab, script o hero copy generici.

Qui entra in gioco la strategia di link interni. I link interni non sono solo percorsi di crawl, sono priorità editoriale: se il sito non punta a una pagina, sta dicendo ai motori che non è centrale.

Verificare title, canonical, schema e metadata — ma non idolatrarli

I metadata contano ancora: vanno solo messi nel giusto livello.

Il Web Almanac 2025 ha trovato tag canonical su circa il 68 % delle pagine desktop e 67 % mobile. I title sono quasi universali. HTTPS è comune. Questi sono controlli di base, non il punto dove si nascondono i disastri di lancio più seri.

In un restyling, lo schema di staging con review finte è finito in produzione. Il problema era visibile a chiunque aprisse il sorgente.

• Usa title unici sui template indicizzabili.
• Scrivi meta description per le pagine dove il CTR conta.
• Imposta un solo canonical chiaro per pagina indicizzabile.
• Controlla le anteprime Open Graph delle pagine condivise al lancio.
• Valida dati strutturati per prodotti, articoli, breadcrumb, organizzazioni, attività locali, FAQ e recensioni quando applicabile.
• Testa hreflang se esistono varianti linguistiche o regionali.
• Rimuovi schema copiati da staging, brand vecchi o URL sbagliati.

Fai il lavoro, ma non confondere il completamento dei metadata con la sicurezza del lancio.

Controllo lancio 2026: regole per crawler AI e continuità delle citazioni

La policy sui crawler AI ora è una decisione da day zero (nel 2026 non è più opzionale). Il Web Almanac 2025 ha rilevato regole gptbot nel robots.txt sul 4,5 % delle pagine desktop e 4,2 % mobile, +55 % YOY. Le regole claudebot quasi raddoppiano: 3,6 % desktop e 3,4 % mobile.

Consentire GPTBot non garantisce visibilità nella ricerca AI, ma il robots.txt viene sempre più usato per controllare l’accesso dei crawler AI: il team di lancio deve avere una policy documentata.

1. Decidi se consentire o bloccare i principali crawler AI prima del lancio.
2. Preserva la continuità delle citazioni reindirizzando gli URL vecchi che hanno guadagnato menzioni, link e riferimenti.
3. Mantieni coerenti i segnali di entità: brand, autori, schema organizzazione, pagine about, contact, nomi prodotto e pagine sorgente canonical.

Gli URL rotti possono distruggere le trail di citazioni che i sistemi di risposta usano. Mantieni crawlable le pagine che dimostrano chi sei.

Il loop di monitoraggio dei primi 7 giorni

Giorno 0 è accesso e rendering. Giorno 1 redirect, analytics e report sitemap. Giorni 2-7 rilevamento pattern.

• Rivedi copertura e indicizzazione in Search Console per template.
• Controlla errori server e soft 404.
• Ri-scansiona la lista di URL vecchi per errori di redirect.
• Trova landing page organiche scomparse.
• Controlla query brand e indicizzazione homepage.
• Osserva nuove pagine bloccate in discovered o crawled ma non indicizzate.
• Rivedi spike o drop di crawl nei log.
• Testa di nuovo il tracciamento conversioni.
• Monitora i termini chiave, aspettandoti volatilità iniziale.

La pazienza conta: non ogni calo è un disastro. Ma ogni calo non misurato diventa una discussione politica.

Il check dei 30 giorni: cosa sistemare quando l’incendio è spento

Dopo la prima settimana, smetti di cercare solo errori catastrofici e inizia a migliorare i sistemi deboli.

• Rivedi i dati field dei Core Web Vitals quando disponibili.
• Trova pagine con impression ma CTR basso.
• Aggiungi link interni a nuove pagine strategiche.
• Confronta indicizzazione per tipo di template.
• Pulisci link interni ancora reindirizzati.
• Rivedi contenuti che hanno perso ranking dopo riscritture o fusioni.
• Sistema warning schema e problemi di rich result.
• Conferma la policy crawler AI con legale e brand.
• Rafforza segnali di expertise, contesto autore e contenuti di supporto.

Qui un setup di monitoraggio SEO pagato a dovere inizia a ripagarsi. Non puoi giudicare ogni risultato SEO in 48 ore, ma puoi giudicare se il sistema sta migliorando.

Checklist SEO post-lancio da copiare

Accesso e indicizzabilità

• Il robots.txt di produzione consente le sezioni previste.
• Nessuna direttiva noindex di staging rimasta.
• Le pagine indicizzabili restituiscono 200.
• Le pagine rimosse restituiscono 404 o 410.
• I canonical puntano agli URL previsti.
• L’Ispezione URL conferma fetch e render.

Rendering e template

• Il contenuto principale appare nell’HTML renderizzato.
• I link di navigazione sono crawlable.
• I link importanti non sono nascosti dietro azioni utente obbligatorie.
• Gli errori JavaScript non bloccano il contenuto della pagina.
• Ogni template principale è stato testato su mobile.

Redirect e continuità URL

• Lista URL vecchi scansionata dopo il lancio.
• 301 single-hop presenti per gli URL cambiati.
• I redirect puntano a pagine equivalenti, non alla homepage.
• I link interni puntano agli URL finali.
• La sitemap XML esclude URL reindirizzati.

Search Console e sitemap

• Proprietà corretta verificata.
• Indice sitemap inviato.
• La sitemap contiene solo URL canonical indicizzabili.
• Inviati vs indicizzati monitorati per template.
• Azioni manuali e problemi di sicurezza controllati.

Analytics e tracking

• GA4 si attiva su tutti i template pubblici.
• Landing page organiche registrate.
• Conversioni testate.
• Annotazione di lancio aggiunta.
• Ranking e traffico baseline esportati.

Performance

• LCP controllato sui template chiave.
• INP testato sugli elementi interattivi.
• CLS controllato dopo banner, font ed embed.
• Strumenti lab usati finché i dati CrUX maturano.
• Mobile testato prima del desktop.

Contenuti e link interni

• Pagine prioritarie linkate da hub o navigazione.
• I contenuti vecchi importanti non sono stati eliminati senza sostituzione.
• Revisionate pagine programmatiche sottili.
• Title e heading corrispondono all’intento di ricerca.
• Pagine orfane identificate.

Dati strutturati e metadata

• Title unici sulle pagine indicizzabili.
• Meta description controllate per le pagine chiave.
• Schema breadcrumb validato.
• Schema prodotto, articolo, organizzazione, local o review testati dove rilevante.
• Hreflang testato se applicabile.

Ricerca AI e policy crawler

• Regole crawler AI nel robots.txt documentate.
• URL vecchi citati reindirizzati.
• Dettagli entità brand e autore coerenti.
• Pagine about, contact e source restano crawlable.
• Pagine informative chiave preservate durante la migrazione.

Se hai solo un’ora, controlla accesso crawler, rendering, redirect, canonical, analytics e sitemap. Se questi passano, il lancio probabilmente non è in fiamme. Da lì inizia il vero lavoro SEO.

FAQ

Quanto presto dovrei eseguire una checklist SEO post-lancio?

Esegui i controlli di accesso, rendering, robots, status code, canonical, analytics e redirect nella prima ora. Esegui sitemap, Search Console e crawl degli URL vecchi il primo giorno. Monitora indicizzazione, log, ranking e conversioni per la prima settimana.

Inviare una sitemap basta per indicizzare un sito nuovo?

No. Google dice che l’invio della sitemap è “solo un suggerimento”. Invia la sitemap perché aiuta scoperta e reportistica, soprattutto per siti nuovi o grandi. Non trattarla come un pulsante di indicizzazione.

Qual è l’errore SEO post-lancio più grave?

I fallimenti più costosi sono crawl bloccato, rendering rotto, redirect sbagliati, canonical errati e misurazione mancante. Gli errori di metadata sono più facili da correggere quando il sito è stabile.

Devo controllare gli URL vecchi o solo il sito nuovo?

Entrambi, ma scansiona la lista di URL vecchi dopo il lancio. È lì che emergono equity persa, backlink rotti, mapping errati e redirect alla homepage. Questo è SEO di migrazione.

Quando vanno rivisti i Core Web Vitals dopo il lancio?

Testa subito con strumenti lab e RUM. I dati field CrUX usano una finestra di 28 giorni, quindi le pagine nuove potrebbero avere bisogno di tempo prima di report stabili.

Hai bisogno di aiuto per trovare i problemi di lancio che contano davvero?

SEOJuice è progettato per aiutare i team a individuare il lavoro che cambia i risultati: link interni rotti, priorità deboli delle pagine, contesto mancante e problemi SEO post-lancio che si nascondono sotto la superficie. Se il tuo sito è appena andato online, inizia con i controlli di triage sopra e usa SEOJuice per mantenere il ritmo del cleanup.