154 29/03/2026 07/04/2026 5 min

Diagnosi probabile

Un calo di traffico dopo un deploy raramente dipende da una sola causa. Le ipotesi più comuni sono: errori tecnici introdotti nel rilascio, tag di tracciamento rotto, blocchi di indexazione, modifiche a URL o redirect, peggioramento delle performance o perdita di contenuti visibili ai motori.

La priorità è distinguere tra un problema reale di acquisizione traffico e un problema di misurazione. Se i dati di analytics scendono ma le impression in Search Console restano stabili, spesso il problema è nel tracking. Se invece calano impression, clic e pagine indicizzate, è più probabile un impatto SEO o tecnico.

In pratica, dopo un deploy conviene verificare in questo ordine: stato del sito, tracciamento, indicizzazione, redirect, canonical, robots, performance e solo alla fine il contenuto editato.

Verifiche immediate

  1. Controlla se il calo è reale o solo di tracciamento: confronta Analytics con Search Console nello stesso intervallo. Se le sessioni scendono ma impression e clic restano simili, il problema è probabilmente nel codice di analytics.
  2. Verifica la homepage e 2-3 URL importanti con risposta HTTP corretta. Un esito atteso è 200 per le pagine valide e 301 per i redirect permanenti voluti.
  3. Apri il codice sorgente e controlla che il tag di monitoraggio sia ancora presente e caricato una sola volta. Se manca o è duplicato, i dati possono essere falsati o incompleti.
  4. Controlla in Search Console se ci sono aumenti di pagine escluse, errori di scansione o problemi di “Pagina con reindirizzamento”, “Bloccata da robots.txt” o “Noindex rilevato”.

Se vuoi una verifica rapida via terminale, puoi usare questi controlli base su un URL sospetto:

curl -I https://www.tuosito.it/pagina-importante

Esito atteso: codice 200 o 301 coerente con la configurazione. Se vedi 404, 500, 403 o catene di redirect anomale, il deploy ha probabilmente introdotto un problema tecnico.

Soluzione consigliata passo-passo

  1. Riparti dal confronto tra prima e dopo il deploy. Segna la data e verifica se il calo coincide con il rilascio. Se il calo è immediato, la causa è quasi sempre collegata a codice, template, redirect o tracking.
  2. Controlla il tracciamento. Su WordPress, CMS o sito custom, verifica che lo snippet analytics sia ancora nel template corretto, che non sia stato rimosso da un plugin di ottimizzazione e che non venga bloccato da policy di consenso o script error.
  3. Verifica robots e meta tag. Controlla che non siano stati introdotti noindex, nofollow, blocchi in robots.txt o canonical errate verso URL non canonici. Una canonical sbagliata può spostare segnali SEO su una pagina diversa.
  4. Analizza i redirect. Dopo un deploy, una mappa redirect incompleta o una catena lunga può far perdere crawl budget e far scendere le performance. Mantieni redirect diretti, preferibilmente a un solo salto.
  5. Controlla i tempi di caricamento e gli errori lato server. Se il sito è più lento o restituisce errori, i crawler possono ridurre la frequenza di scansione e gli utenti abbandonare prima della conversione. Le metriche da osservare sono TTFB, tempo di risposta, CPU, RAM, I/O e cache hit.
  6. Se il deploy ha cambiato contenuti, verifica che titoli, H1, testi e link interni non siano stati rimossi o semplificati troppo. Un tema o un builder che nasconde testo importante può ridurre rilevanza e visibilità organica.
  7. Se il problema è nel codice, esegui un rollback parziale del solo componente sospetto: tema, plugin, template, configurazione cache o regola redirect. È la strada più sicura perché è reversibile e permette di isolare la causa.

Per chi usa cPanel, Plesk o pannelli simili, il controllo pratico è spesso più rapido: apri i log errori del dominio, verifica gli ultimi eventi del deploy e confronta la data del rilascio con l’inizio del calo. Se trovi errori PHP, 403 o redirect infiniti, correggi prima quelli.

Se il sito usa WordPress, controlla anche:

  • plugin di cache e minify che possono rompere lo script di analytics;
  • plugin SEO che possono aver cambiato canonical, noindex o sitemap;
  • tema o child theme che può aver rimosso il tag di tracking;
  • pagina home e template articolo, perché spesso il problema è lì e non su tutto il sito.

Se usi server Linux e hai accesso ai log, questi due controlli sono spesso decisivi:

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/httpd/error_log

Il file esatto dipende dal web server in uso. Cerca errori ripetuti, file mancanti, permessi errati, timeout o eccezioni PHP. Se trovi un errore introdotto in corrispondenza del deploy, hai già la causa da correggere.

Checklist di correzione rapida

  1. Ripristina temporaneamente il componente sospetto e verifica se il traffico si normalizza.
  2. Controlla che analytics, Search Console e sitemap siano ancora integri.
  3. Verifica redirect, canonical, robots e meta noindex.
  4. Misura risposta server e tempi di caricamento.
  5. Ricontrolla impression e clic dopo 24-48 ore.

Controlli finali / rollback

  1. Conferma la stabilità con un test su almeno 3 URL: homepage, una categoria e un articolo o pagina chiave. Esito atteso: nessun errore 4xx/5xx e redirect coerenti.
  2. Verifica in Search Console che non stiano aumentando pagine escluse o errori di scansione. Se gli errori salgono dopo il fix, il problema non è ancora risolto.
  3. Controlla che il tracking registri nuovamente visite e conversioni. Se i dati rimangono fermi ma il sito risponde bene, il rollback deve concentrarsi sul codice analytics o sul consenso cookie.
  4. Se il traffico non recupera e il calo coincide chiaramente con il deploy, fai rollback del componente modificato più recente, non dell’intero sito. Mantieni backup della configurazione precedente per tornare indietro in modo rapido e reversibile.

Assunzione operativa: il calo è avvenuto dopo un rilascio recente e hai accesso almeno a Search Console, analytics e ai log del server o del pannello hosting.