Monitorare i cambiamenti di codice di un sito: come scoprire il deploy che ha rotto la SEO

Monitorare i cambiamenti di codice di un sito significa sorvegliare l'HTML pubblicato per le modifiche da cui dipendono motori di ricerca e analytics, e ricevere un avviso quando ne compare una. Uno sviluppatore rilascia, nessun ticket parla di SEO, e un title riscritto, un canonical spostato o un tag GA4 sparito restano in produzione finché qualcuno non va a cercarli.

Alle agenzie capita spesso una versione di questa storia. Le posizioni scendono per un mese, qualcuno indaga e la causa è una modifica al template arrivata con un rilascio di routine. Per i loro standard gli sviluppatori non hanno sbagliato niente: la pagina si vede, i test passano, il cliente ha approvato il design. È cambiata la parte del markup che leggono solo i crawler e gli script di tracciamento.

Quali parti del codice monitorare

Gran parte del codice di una pagina può cambiare liberamente senza conseguenze per la SEO. Un piccolo gruppo di elementi no.

Elemento	Come si rompe di solito	Effetto
<meta name="robots"> e X-Robots-Tag	Un'impostazione di staging o una variabile d'ambiente finita in produzione	Pagine rimosse dall'indice
<link rel="canonical">	Il nuovo template lo costruisce dall'URL sbagliato o lo fa puntare a un host di staging	Google indicizza un URL diverso o ignora la pagina
<title> e meta description	Reset del plugin SEO, o un template che sovrascrive i campi delle singole pagine	CTR più basso, a volte minore pertinenza
<h1>	Il restyling trasforma il titolo in un <div> stilizzato, o il logo diventa un secondo H1	Segnale sull'argomento della pagina più debole
Snippet di GA4, GTM e Meta Pixel	Una nuova build toglie il container dal layout	Reportistica e attribuzione delle campagne si fermano
Banner dei cookie	CMP sostituita o rimossa	Tag bloccati, oppure attivi senza consenso

Il robots.txt non sta nell'HTML della pagina, ma cambia con gli stessi rilasci e merita la stessa attenzione. Un Disallow: / rimasto dallo staging fa più danni di tutte le voci della tabella messe insieme.

HTML sorgente e HTML renderizzato

Su un sito renderizzato lato server conta l'HTML che restituisce il server. Sui siti costruiti con React, Vue o framework simili, i tag dell'head possono essere impostati da JavaScript dopo il caricamento, quindi il sorgente grezzo e il DOM renderizzato possono essere diversi. Google esegue il JavaScript, ma un canonical che esiste solo dopo il rendering, o che cambia tra versione sorgente e renderizzata, è una causa frequente di confusione. Quando indaghi su una modifica, confronta view-source: con il pannello Elementi dei DevTools e usa lo strumento Controllo URL di Search Console per vedere l'HTML renderizzato registrato da Google.

Perché i segnali abituali arrivano tardi

Probabilmente il tuo team non riceve le notifiche di rilascio del cliente. Search Console riporta le conseguenze, non le cause: le pagine finiscono sotto "Esclusa in base al tag 'noindex'" nel report Indicizzazione delle pagine solo dopo che Google le ha riscansionate, e il report si aggiorna con un certo ritardo. I rank tracker mostrano il calo quando è già avvenuto. E nessuno apre il sorgente di una pagina che nel browser sembra a posto.

È in quella finestra che i cambiamenti SEO silenziosi fanno i loro danni, e la risposta è un confronto che gira anche quando nessuno si è ricordato di controllare.

Cosa deve segnalare un buon rilevamento delle modifiche al codice

Confronta, invece di verificare solo la presenza. Sapere che un title esiste vale poco; sapere che ieri era "Scarpe da running uomo | Brand" e oggi è "Collezione" è un'informazione su cui puoi agire. Lavora per URL, perché le modifiche ai template di solito colpiscono una sezione, non la homepage. E l'avviso contiene URL, valore precedente, valore nuovo e data, cioè esattamente quello che ti serve da mandare al cliente.

Cosa fare quando arriva l'avviso

Carica la pagina in una finestra privata per escludere la cache. Decidi se la modifica era voluta: un title migliorato dal copywriter non richiede nulla, mentre un canonical che punta a un host di staging va sistemato oggi. Manda al cliente le prove e chiedi cosa è stato rilasciato quel giorno. Se la modifica fa parte di un restyling o di un cambio di piattaforma, smetti di correggere un URL alla volta e segui la checklist SEO per la migrazione.

Cosa confronta Deltio, e cosa no

Deltio legge sitemap e pagine di ogni sito una volta al giorno e confronta il risultato con il controllo precedente. Su ogni pagina guarda noindex, canonical, title, meta description e H1, segnala i valori mancanti, duplicati o fuori misura e ti avvisa quando cambiano. Controlla anche il robots.txt, gli URL aggiunti o rimossi dalla sitemap, GA4, GTM e Meta Pixel, e il banner dei cookie. Gli avvisi arrivano su Slack ed email per singolo sito. Dopo un rilascio di cui sei al corrente puoi lanciare una scansione SEO manuale invece di aspettare il controllo del giorno dopo, e con i piani Professional ed Enterprise puoi esportare i risultati in CSV.

Non fa confronti visivi né screenshot, e non confronta codice arbitrario come script o CSS: si concentra sugli elementi descritti sopra. Inoltre gira una volta al giorno, quindi non sostituisce i test nella pipeline di rilascio. Il lato del tracciamento è approfondito nel monitoraggio dei marketing tag.