Runbook: Risposta agli Aggiornamenti dell'Algoritmo

Una risposta a un aggiornamento dell’algoritmo è un’indagine su un incidente, non uno sprint di editing. La sua prima regola è semplice: conferma che il calo sia reale e sia tuo prima di reagire. “Reale” significa che il declino persiste in dati completi e comparabili. “Tuo” significa che riflette la visibilità di ricerca del tuo sito piuttosto che una misurazione errata, una domanda ridotta, una disposizione dei risultati modificata o un aggiornamento che non ha colpito le tue pagine.

Checklist: Risposta agli Aggiornamenti dell’Algoritmo. Timebox: 60–90 minuti per il triage il primo giorno; 2–4 ore per la segmentazione durante la prima settimana; una decisione formale agire-o-aspettare dopo sette giorni completi, a meno che un guasto tecnico verificato non richieda una riparazione immediata. Responsabile: il responsabile SEO gestisce l’incidente e il registro delle decisioni; un analista convalida i dati; l’ingegneria gestisce i guasti tecnici; i proprietari dei contenuti approvano le modifiche alle pagine.

Usa questo runbook quando un calo significativo del traffico di ricerca coincide con un aggiornamento dell’algoritmo di Google confermato o sospetto, ovvero una modifica ai sistemi di ranking di Google. È adatto anche quando nessun aggiornamento è stato confermato ma molti URL si muovono insieme e la causa non è chiara.

Perché questa fase, e perché qui

Questa checklist consuma la misurazione di base datata, le annotazioni di rilascio, la mappa di proprietà delle pagine, l’inventario dei template, la classificazione degli intenti, le analisi, i dati di Search Console e le definizioni di conversione stabiliti in precedenza nel processo. Senza questi input, un team può vedere che una linea si è mossa ma non può stabilire cosa è cambiato, dove è cambiato o se è importante per il business.

L’ordine è importante perché i guasti di misurazione e i guasti del sito possono imitare le perdite dovute all’algoritmo. Un cambio di consenso può rimuovere le sessioni di analytics. Un deployment può aggiungere noindex, scegliere la canonical sbagliata o nascondere i link interni. La stagionalità può ridurre le ricerche mentre i posizionamenti rimangono stabili. Diagnostica questi casi prima di attribuire il calo a un sistema esterno.

Eseguire la remediation prima della segmentazione causa un secondo problema: l’attribuzione scompare. Se il team riscrive i titoli, ristruttura i template, rimuove pagine e modifica i link interni nella stessa settimana, qualsiasi successivo recupero o declino ha diverse cause plausibili. La risposta deve quindi passare dalla verifica, all’isolamento del pattern, a una decisione documentata agire-o-aspettare, e solo allora a un intervento controllato.

Input e output

Il registro delle decisioni è il contratto con il passo successivo. “Google ha cambiato qualcosa” non è un risultato consegnabile; un pattern delimitato, una decisione esplicita e l’evidenza che un altro revisore possa ispezionare lo sono.

La checklist

1. Conferma che il calo sia reale e sia tuo

Cosa: verifica la perdita attraverso misurazioni indipendenti prima di assegnare una causa. Perché: reportistica incompleta, guasti di tracciamento, weekend, stagionalità, cicli di notizie e domanda variabile possono creare un falso allarme convincente. Il traffico organico indica visite non pagate dai risultati di ricerca; può calare anche quando i posizionamenti non cambiano. Come: usa giorni completi, confronta periodi equivalenti allineati al giorno della settimana, verifica click e impressioni di Search Console rispetto a sessioni e conversioni di analytics, ispeziona il contesto anno su anno dove esiste stagionalità e annota la data più recente in cui ogni fonte è stata finalizzata. Strumento: dati di performance di ricerca, analytics, report di conversione, log di uptime e calendario dei rilasci. Completato quando: almeno due segnali indipendenti concordano sulla direzione, gli ultimi tre giorni completi rimangono al di sotto della baseline selezionata, la freschezza dei dati è registrata e il report indica se la perdita è di visibilità, domanda, tracciamento, conversione o una combinazione.

2. Escludi le cause che controlli

Cosa: verifica la presenza di guasti al sito, al tracciamento, alla sicurezza e all’indicizzazione. Perché: un difetto verificato merita una riparazione immediata, mentre aspettare la fine dell’aggiornamento prolungherebbe una perdita prevenibile. L’indicizzabilità è la capacità di una pagina di essere inclusa nell’indice di un motore di ricerca. Come: ispeziona gli URL colpiti e non colpiti per stato della risposta, direttive robots, canonical, rendering, link interni, presenza nella sitemap, notifiche di azioni manuali ed eventi di analytics; allinea ogni modifica con il suo orario di rilascio. Strumento: ispezione URL, log del server e di deployment, output del crawler, debugger di analytics, monitor di uptime e registro delle modifiche. Completato quando: ogni potenziale guasto è stato verificato, confutato o assegnato con un responsabile; qualsiasi guasto corrispondente all’insorgenza è etichettato come ripara ora e separato dalle ipotesi sull’algoritmo.

3. Segmenta per directory, template e intento

Cosa: costruisci una matrice di impatto invece di giudicare la media a livello di sito. Perché: un totale ampio può nascondere il pattern reale: le pagine prodotto potrebbero calare mentre le guide crescono, un template potrebbe perdere click da mobile, o le query informative potrebbero muoversi mentre la domanda di marca rimane stabile. L’intento di ricerca è il compito che una persona vuole completare con una query. Come: calcola le variazioni prima-dopo per click, impressioni, posizione, conversioni e URL colpiti; raggruppa prima per directory, poi per template, intento primario, dispositivo, paese, classe di query e ruolo commerciale. Includi gruppi stabili o in crescita come controlli. Usa totali assoluti ponderati oltre alle percentuali, in modo che dieci click persi su un piccolo segmento non superino diecimila click persi su uno grande. Strumento: report di directory, pagina, query, URL-mover e keyword-mover, più un foglio di calcolo o un notebook di analisi. Completato quando: la matrice copre almeno il 95% dei click di ricerca, mostra segmenti colpiti e di controllo, registra i gruppi a basso volume come inconclusivi e nomina il pattern ripetibile più ristretto supportato dai dati.

4. Ispeziona i vincitori e i perdenti rappresentativi

Cosa: esamina le pagine e le query che rappresentano al meglio ciascun segmento colpito e di controllo. Perché: gli aggregati localizzano il danno ma non lo spiegano. Una pagina dei risultati del motore di ricerca può sostituire gli elenchi classici con unità di shopping, risultati locali, video o risposte AI; questo cambiamento può ridurre i click senza mostrare un difetto correggibile della pagina. Come: seleziona almeno cinque perdenti ad alto impatto e cinque controlli stabili o in crescita quando il segmento contiene abbastanza URL. Confronta la soddisfazione dell’intento, l’originalità, le prove, la paternità, il carico commerciale, la cronologia degli aggiornamenti, il routing interno, le modifiche allo snippet e i formati dei risultati concorrenti. Registra le osservazioni come ipotesi, non come affermazioni di fattori di ranking. Strumento: revisione dei risultati live, rendering della pagina, record di origine, pagine dei concorrenti, dati di ricerca e inventario dei contenuti. Completato quando: ogni ipotesi cita esempi da perdenti e controlli, le prove contraddittorie sono conservate e nessuna raccomandazione si basa su una sola pagina o una sola query.

5. Congela le modifiche dettate dal panico durante la prima settimana

Cosa: proibisci modifiche ampie e speculative mentre continui la diagnosi. Perché: riscritture di massa dei titoli, modifiche alle date di pubblicazione, cancellazione di pagine, obiettivi di conteggio parole a livello di sito, riprogettazioni di template e variazioni di link alterano più variabili contemporaneamente. Possono danneggiare pagine che non erano state colpite e rendere impossibile attribuire qualsiasi movimento successivo. Come: crea una finestra di modifica di sette giorni completi dall’inizio osservato. Consenti solo riparazioni verificate, correzioni legali o fattuali, lavoro di sicurezza e lanci già approvati il cui rinvio comporti un rischio maggiore; annota ogni eccezione. Conserva copie delle pagine correnti e delle esportazioni. Strumento: calendario dei rilasci, permessi CMS, registro incidenti e sistema di annotazione. Completato quando: l’ambito del congelamento, l’inizio, la fine, l’approvatore e le eccezioni sono visibili a publisher e ingegneri; nessun esperimento SEO non registrato viene lanciato all’interno della finestra.

6. Scegli agire, attendere o riparare ora

Cosa: prendi una decisione in un checkpoint nominato. Perché: un’osservazione infinita lascia i difetti reali non trattati, mentre un’azione riflessiva converte l’incertezza in cambiamenti incontrollati. Come: scegli ripara ora per un guasto tecnico o di misurazione riprodotto; scegli agisci quando una perdita materiale persiste, si concentra in un segmento coerente e una debolezza della pagina o del sistema spiega sia i perdenti che i controlli; scegli attendere quando rollout, ritardo dei dati, stagionalità, basso volume o segmenti contraddittori impediscono una causa difendibile. Registra le alternative rifiutate e le evidenze che cambierebbero la decisione. Strumento: report incidente, matrice di impatto, revisione rappresentativa, valutazione del rischio commerciale e approvatore. Completato quando: il registro ha una decisione, un livello di confidenza, un responsabile, una data di revisione, collegamenti alle evidenze e un innesco per la sua riapertura.

7. Esegui un intervento controllato

Cosa: traduci una decisione agisci in una riparazione o esperimento delimitato. Perché: un’ipotesi e un insieme di modifiche coerenti preservano la possibilità di imparare; modifiche simultanee a livello di sito non lo fanno. Come: definisci la coorte colpita, il gruppo di confronto non modificato quando praticabile, la debolezza precisa, il miglioramento previsto per il lettore, la metrica attesa, la finestra di osservazione, la soglia di accettazione e la via di rollback. Per le pagine degradate, usa la checklist per l’aggiornamento dei contenuti invece di modificare le date o espandere il testo alla cieca. Strumento: brief d’azione, inventario pagine, CMS, record QA, responsabile del rilascio e annotazioni. Completato quando: ogni URL modificato corrisponde al pattern diagnosticato, l’intervento ha superato il QA, i controlli rimangono invariati o le deviazioni sono registrate e l’annotazione di rilascio dichiara cosa dovrebbe muoversi e entro quando.

8. Misura, documenta e chiudi o itera

Cosa: valuta l’intervento separatamente dalla narrativa dell’aggiornamento. Perché: il recupero dopo un rilascio è associazione, non prova che il rilascio lo abbia causato; l’aggiornamento potrebbe essere ancora in fase di rollout, i concorrenti potrebbero cambiare e la domanda potrebbe tornare. Come: confronta la finestra post dichiarata con la baseline congelata, mantieni la stessa segmentazione, ispeziona controlli e conversioni e registra i fattori confondenti. Classifica il risultato come positivo, neutro, negativo o inconclusivo. Strumento: risultati delle annotazioni, report di movimento, analytics, report di conversione e registro incidenti. Completato quando: i risultati effettivi rispetto a quelli attesi sono allegati, la confidenza e i limiti sono dichiarati, il responsabile seleziona chiudi, estendi osservazione, reverti o esegui una nuova ipotesi delimitata, e la prossima data di revisione è impostata.

Strumenti in AmICited

AmICited rende la diagnosi riproducibile preservando periodi, segmenti e interventi. Non prova cosa premia un algoritmo; usa i report per individuare pattern e testare decisioni.

1. Apri Organic Rank con il Report Posizionamento Organico per confrontare domanda, posizione media e click attraverso i canali di ricerca collegati. Usalo per decidere se l’incidente è ampio o specifico di un canale.
2. Apri URL Position Movers con URL Position Movers per identificare le pagine che creano la perdita, confrontare i periodi e suddividere il movimento per dispositivo e sezione.
3. Apri Keyword Position Movers con Keyword Position Movers per separare i cambiamenti di posizionamento delle query dalla domanda persa e trovare pattern a livello di intento.
4. Apri Directory di Ricerca Google con Directory di Ricerca Google per passare dall’intero sito alle directory in cui click o impressioni sono cambiati.
5. Usa Pagine di Ricerca Google con Pagine di Ricerca Google e Query di Ricerca Google con Query di Ricerca Google per convalidare URL rappresentativi e le ricerche esatte che servivano.
6. Apri Risultati delle Annotazioni con Risultati delle Annotazioni per registrare l’intervento, l’aspettativa, il checkpoint e il risultato. Considera un risultato valutato come evidenza di associazione, non prova di causalità.

Regole decisionali

Queste sono impostazioni predefinite per il controllo degli incidenti, non affermazioni su come Google valuta le pagine. Il loro scopo è prevenire sia la reazione eccessiva al rumore che l’inazione durante un fallimento materiale. Sostituiscile solo con una soglia documentata basata sulla volatilità consolidata del sito e sul rischio commerciale.

Le percentuali da sole sono insufficienti. Un calo del 50% da due click a uno non è operativamente equivalente a un calo del 15% che coinvolge migliaia di visite. Mantieni sempre il volume assoluto, l’esposizione di conversione e la confidenza insieme alla variazione relativa.

Risultato consegnabile: il pacchetto dell’incidente di aggiornamento algoritmo

Consegna una cartella datata o un registro incidenti, non una slide che dice “impatto core update”. Contiene:

1. Un report incidente di una pagina con innesco, gravità, aggiornamento sospetto, freschezza dei dati, esposizione commerciale, responsabile e decisione corrente.
2. Esportazioni congelate o collegamenti ai report per i periodi di baseline e incidente, inclusi filtri e fuso orario.
3. Una matrice di impatto per directory, template, intento, dispositivo, paese, pagina e query, con coorti colpite e di controllo.
4. Un registro di esclusione delle cause che copre misurazione, domanda, rilasci, crawling, indicizzazione, rendering, sicurezza e modifiche alla disposizione dei risultati.
5. Revisioni rappresentative di perdenti e controlli, con evidenze a supporto e contraddittorie per ogni ipotesi.
6. La decisione agisci/attendere/ripara, le alternative rifiutate, l’approvatore, la prossima data di revisione e le evidenze che riaprirebbero l’incidente.
7. Per un intervento, la coorte URL esatta, le specifiche di modifica, il record QA, la via di rollback, l’annotazione di rilascio, il checkpoint e il risultato finale.

Usa una tabella leggibile a macchina per la matrice di impatto e un riepilogo leggibile dall’umano per la decisione. Il pacchetto è completo quando un altro analista può riprodurre il pattern colpito senza chiedere quali filtri sono stati usati, e un publisher può vedere esattamente cosa è approvato senza interpretare un grafico.

Cosa va storto

L’aggiornamento diventa la spiegazione per tutto

Un annuncio e un calo di traffico si verificano vicini nel tempo, quindi il team smette di testare alternative. La soluzione è mantenere un registro di esclusione e richiedere corroborazione. La tempistica stabilisce un’ipotesi, non la proprietà della perdita.

Le medie del sito nascondono movimenti opposti

Le guide guadagnano mentre le pagine categoria perdono, ma un totale piatto fa sembrare l’evento innocuo. Oppure una grande directory cade e fa apparire debole ogni template. Segmenta gli stessi dati per directory, template, intento, dispositivo e paese, e mantieni i gruppi stabili come controlli.

Le modifiche della prima settimana distruggono l’attribuzione

I team riscrivono le pagine perché agire sembra più sicuro che aspettare. Un recupero successivo non può più essere separato dal completamento del rollout, dalla domanda, dai cambiamenti dei concorrenti o dalle modifiche stesse. Congela il lavoro speculativo per sette giorni completi e annota ogni eccezione.

Le variazioni percentuali esagerano i campioni piccoli

Un gruppo a basso volume passa da quattro click a due e diventa il “perdente” principale al 50%. Abbina sempre la variazione relativa a click assoluti, impressioni, numero di URL colpiti e valore commerciale. Segna i segmenti sottili come indicativi.

I controlli vengono scelti dopo il risultato

Se le pagine stabili vengono selezionate solo dopo aver visto quali sono rimaste stabili, il confronto favorisce la spiegazione preferita. Dichiara la logica di controllo prima dell’intervento: stesso template ma intento diverso, stesso intento ma template diverso, o paese/dispositivo non colpito all’interno della stessa coorte.

Diverse correzioni vengono rilasciate in un unico pacchetto

Titoli, corpo testo, navigazione, schema e template cambiano insieme. Anche un risultato positivo insegna poco. Suddividi le cause in interventi separati quando operativamente possibile; quando non possono essere separati, registra il pacchetto e abbassa la confidenza di attribuzione.

Il recupero viene riportato come prova

La metrica migliora dopo un rilascio, quindi l’azione viene dichiarata causale. Riporta la sequenza accuratamente: la modifica è stata seguita da un recupero, i controlli si sono comportati in un modo dichiarato e i fattori confondenti noti rimangono. Questo linguaggio è più utile di una certezza che le evidenze non possono supportare.

Fase successiva

Un guasto tecnico verificato passa immediatamente al responsabile dell’ingegneria, con la coorte colpita e la condizione di rilancio del test allegate. Un problema di qualità delle pagine diagnosticato entra nel flusso di lavoro di aggiornamento dei contenuti. Un incidente inconclusivo torna in osservazione con una data di revisione nominata, invece di finire in un backlog indefinito.

La fase continua di aggiornamento e iterazione continui necessita di quattro elementi da questo runbook: la coorte colpita, l’ipotesi accettata o rifiutata, il registro delle azioni e annotazioni e la prossima data di misurazione. Utilizza questi output per dare priorità al lavoro senza trattare ogni fluttuazione di posizionamento come un degrado.

FAQ

Il responsabile dell’incidente dovrebbe pubblicare le risposte alle FAQ del frontmatter nel componente FAQ della pagina e mantenerle allineate con le regole decisionali sopra riportate. Il principio guida rimane lo stesso in ogni risposta: verifica, segmenta, decidi, modifica un sistema delimitato e misura.

Rispondi con evidenze, non con urgenza

Apri il report Organic Rank , congela le date di confronto e crea il primo report incidente prima di modificare una pagina. La risposta più rapida utile è una decisione che il team possa successivamente spiegare.