Abbiamo perso il 95% del traffico Google in una notte. Bing ci tiene ancora in top 3.

Tra il 16 e il 17 aprile 2026 il nostro traffico organico da Google è crollato di circa il 95% — di fatto da un giorno all'altro. Nessuna penalizzazione, nessun avviso. E la cosa più strana: Bing continuava a posizionare esattamente le stesse pagine nella sua top 3. Questo è il post-mortem onesto — cosa si è rotto (era il nostro stesso codice), come lo abbiamo ricostruito all'ora esatta e cosa non si è ancora ripreso.

Costruiamo moduli SEO, performance e sicurezza per PrestaShop di mestiere. Che un crollo di traffico colpisse proprio il nostro negozio è stato umiliante e, alla fine, illuminante. Per questo lo mettiamo per iscritto come si deve — comprese le parti che non abbiamo ancora sistemato.

Cosa NON è stato (le piste sbagliate che abbiamo escluso)

La maggior parte dei consigli sui “crolli di traffico” ti manda prima da queste parti. Ci siamo passati anche noi, e le abbiamo escluse:

• Non una penalizzazione. Nessuna azione manuale in Search Console, nessuna notifica di link innaturali. L'API URL Inspection mostrava le nostre pagine chiave ancora “Inviata e indicizzata”. È stata una retrocessione di ranking, non una deindicizzazione.
• Non (solo) un aggiornamento dell'algoritmo. Il core update di marzo 2026 si era effettivamente concluso attorno all'8 aprile — otto giorni prima del nostro precipizio — e non fingeremo che quel contesto di rielaborazione fosse irrilevante. Ma un core update distribuito su settimane non spiega impressioni giornaliere che collassano tra due giorni adiacenti. Qualcosa di nostro combaciava all'ora esatta.
• Non principalmente “thin content” — anche se l'accusa è legittima. Semmai avevamo più contenuti di quanti la nostra autorevolezza giustificasse: ~150 pagine di moduli in sei lingue, più blog, documentazione, FAQ. Pensiamo che quell'impronta abbia reso la ripresa più difficile, e trattiamo la percezione di “contenuti prodotti in scala e di scarso valore” come un'ipotesi viva e irrisolta, non come qualcosa da liquidare.
• Non le solite ovvietà tecniche. robots.txt era pulito, la sitemap rispondeva, canonical e hreflang (sei lingue + x-default) erano corretti.

L'indizio che ha ribaltato tutto: Bing posizionava esattamente lo stesso contenuto nella sua top 3 — con un profilo di domini referenti così esile che il nostro punteggio di “authority” di terze parti è di fatto zero. Stesse pagine, due motori di ricerca, esiti opposti. È l'impronta digitale di un verdetto di fiducia e autorevolezza innescato da un guasto tecnico — non di un problema isolato di qualità dei contenuti o di velocità.

La causa radice: il bug lo abbiamo rilasciato noi (confidenza attorno all'80%)

Ecco la parte che la maggior parte dei post-mortem aziendali seppellirebbe. L'innesco è stato un nostro deploy.

Tra il 13 e il 18 aprile stavamo modificando il nostro modulo per prodotti digitali — un nuovo controller di download, un fix per il “duplicate slug on install”, un pulsante di download renderizzato lato server. Da qualche parte in quel lavoro, la generazione degli URL prodotto ha iniziato a lanciare l'eccezione Invalid product vars di PrestaShop (in classes/Link.php). I nostri log delle eccezioni mostrano la correlazione all'ora esatta:

Il tempismo è brutale. Eravamo appena schizzati nella “luna di miele” da sito giovane — circa 4,000–5,400 impressioni al giorno, attorno alla posizione 10, a inizio aprile. Esattamente il momento in cui Google ci stava valutando con più severità. E in quella finestra Googlebot incontrava ~1,000 link prodotto interni rotti al giorno. Per un crawler, un grafo di link interni che di colpo punta a URL prodotto rotti durante il picco di valutazione è un segnale forte: “questo sito si è appena degradato”.

Parliamo di ~80% di confidenza e non di certezza perché tutto è caduto in una finestra davvero rumorosa — il core update concluso, uno spam update, la fine della luna di miele e ricorrenti disservizi server/DB nostri (metà marzo, 14–16 aprile e di nuovo a giugno). Ognuno di questi aggrava un colpo alla fiducia. Ma solo il conteggio degli errori Link.php combacia giorno per giorno con il precipizio. Il verdetto onesto: un innesco tecnico autoinflitto, esploso nel contesto di un sito giovane, a bassa autorevolezza, subito dopo un core update.

La categoria che spiega davvero un −95%: “Scansionata, ma attualmente non indicizzata”

Se da tutto questo devi portare a casa una sola lezione diagnostica, è questa. Nel rapporto di copertura dell'indice di Search Console, la categoria che conta non è “404” né “5xx”. È “Scansionata, ma attualmente non indicizzata” — circa 22,800 URL.

Una sfumatura onesta, perché abbiamo controllato la nostra stessa storia: questa categoria non è “esplosa” la notte del crollo. L'abbiamo vista comparire già a febbraio 2025, ha toccato il picco vicino a 60k e da allora si sta lentamente svuotando fino a ~22.8k. Il precipizio notturno in sé è stato una retrocessione di ranking di pagine rimaste indicizzate — impressioni giornaliere di ~5,400 in posizione ~10 crollate a 161 il giorno dopo, in posizione 27. La categoria “scansionata, non indicizzata” non è il meccanismo del crollo notturno; è il punto in cui il verdetto di fiducia di lungo periodo diventa visibile. Abbiamo verificato che un campione di quelle 22.8k pagine risponde 200, index,follow, self-canonical, ricco di contenuti. Google ha scansionato decine di migliaia di pagine tecnicamente pulite e ha scelto di non indicizzarle.

Ripresa, parte 1: rendere la base tecnica davvero pulita

Non puoi chiedere a Google di rivalutare un sito che inciampa ancora negli errori. La fase uno è stata quindi igiene spietata — ogni difetto tecnico correggibile corretto e verificato in produzione, non solo “rilasciato” (la categoria di fiducia della sezione successiva è un problema separato, non tecnico):

• L'innesco Link.php: corretto per primo — 0 errori da maggio, i prodotti renderizzano HTML 200 completo.
• 404: separati i 404 genuini dagli slug rinominati; i vecchi slug in 301 verso i canonical attuali (un solo salto, localizzato).
• URL a faccette: combinazioni valide in 200 + noindex,follow, quelle obsolete in 301 — gli umani filtrano, i crawler non annegano.
• 5xx: un fatal di autoload tra lingue dovuto a una differenza di maiuscole e minuscole, corretto con un fail-safe.
• Catene di redirect: compresse a un solo salto, risolte al momento dell'emissione.
• Dati strutturati: esattamente un brand per prodotto e lunghezza della descrizione limitata (i due errori che ci costavano davvero i risultati avanzati).
• Asset: rimosso il cache-busting ?v= per singolo file, così il combine-minify nativo di PrestaShop funziona.
• Gerarchia dei titoli: un solo <h1> per pagina, H1 → H2 → H3 puliti.

Ripresa, parte 2: non far ri-scansionare un cantiere — il “freeze gate”

Ecco la disciplina che la maggior parte delle storie di ripresa salta. Prima di reinviare qualsiasi cosa a Google, trattiamo la sitemap e la pipeline di indicizzazione come un cancello: nulla viene proposto per l'indicizzazione se non è dimostrabilmente pulito.

• La sitemap viene rigenerata e ogni URL verificato in modo indipendente — 200, index,follow, self-canonical, hreflang corretto, schema valido. La nostra si è assestata su 4,952 URL in sei lingue.
• La coda di indicizzazione invia solo URL che sono canonical indicizzabili in questo momento, con un controllo per singolo URL al momento dell'invio — non un idrante aperto alla cieca.

Il controllo di ogni URL della sitemap attraverso quel filtro ha trovato tre bug che avrebbero silenziosamente sprecato l'intera ri-scansione: al nostro registro interno delle pagine mancavano 918 URL della sitemap — incluso l'intero set di documentazione da 882 URL; tre pagine FAQ erano marcate noindex per errore a causa di una riga di associazione negozio mancante; e i post del blog venivano instradati verso noindex da un classificatore che intercettava parole chiave da supporto prima della rotta del blog. Abbiamo preteso un risultato zero bloccati — ciascuno dei 4,952 URL deve superare il controllo — prima di dichiarare chiuso il cancello.

La lezione: riguadagnare fiducia significa che la prossima cosa che Google vede deve essere immacolata. Un altro giro di “per favore indicizzate le nostre pagine rotte” scava la buca ancora più a fondo.

Su cosa scattano ora i nostri allarmi

Il guasto è rimasto invisibile per giorni perché nulla urlava. Cosa monitoriamo adesso:

• Alert sulle eccezioni di classe critica su Link.php / slug mancato del dispatcher — ogni picco ci avvisa subito, invece di una lettura settimanale dei log.
• Trend delle statistiche di scansione GSC + Bing osservato ogni settimana, fianco a fianco — la divergenza Bing/Google è il nostro segnale di fiducia più precoce.
• Watchdog di disponibilità sull'origine — i nostri disservizi sono stati parte della ferita, quindi l'uptime ora è una metrica SEO di prima classe.
• Controllo di parità sitemap/registro — il filtro che ha trovato i 918 mancanti gira in continuo.

Cosa, onestamente, NON si è (ancora) ripreso

È qui che la maggior parte dei post “come mi sono ripreso” diventa disonesta. Noi no.

• Ranking e traffico non sono tornati. La base tecnica è pulita e verificata, ma Google continua a rifiutarsi di indicizzare gran parte di ciò che scansiona, e la posizione continua a scivolare invece di rimbalzare.
• L'off-page è il nostro vero tetto. Il nostro profilo di domini referenti è esile — lo stesso contenuto che Bing posiziona in top 3, Google lo rifiuta. Un sito pulito con una debole validazione esterna è esattamente l'aspetto di “scansionata, non indicizzata”.
• Le nostre lingue non inglesi sono zavorra. Raccolgono impressioni ma quasi nessun clic; solo inglese e polacco convertono davvero. Scalare pagine tradotte automaticamente è stato parte dell'impronta sovradimensionata, non un asset.
• Da qui in poi la soluzione non è tecnica. È autorevolezza e tempo: segnali reali di esperienza e competenza, link guadagnati nell'ecosistema PrestaShop, e lasciare che un sito pulito si dimostri tale quando riapriremo l'indicizzazione attraverso la coda controllata.

Pubblichiamo tutto questo adesso, a metà della ripresa, proprio perché un post-mortem scritto dopo una ripresa completa è una favola distorta dal bias dei sopravvissuti. Ecco come appare davvero, visto da dentro.

Se sta succedendo al tuo negozio PrestaShop

• Controlla Bing. Se Bing posiziona i tuoi contenuti e Google no, smetti di incolpare contenuti e velocità — è una questione di fiducia, e a innescarla è stato probabilmente qualcosa di tecnico.
• Rileggi il tuo log dei deploy accanto al grafico del traffico. La nostra pistola fumante è stata un conteggio di eccezioni allineato al giorno con il precipizio. Potrebbe esserlo anche la tua.
• Leggi le categorie di copertura dell'indice, non solo la linea del traffico. “Scansionata — non indicizzata” su larga scala è un segnale di qualità, non un bug da correggere.
• Correggi e verifica in produzione — direttamente sull'origine, non “dovrebbe essere a posto”.
• Non far ri-scansionare un cantiere. Dimostra che la tua sitemap e il tuo set di invio sono immacolati prima di chiedere a Google di guardare di nuovo.
• Poi porta pazienza e costruisci autorevolezza. Non esiste un fix di codice per la fiducia.

Se il tuo negozio mostra lo stesso schema — pulito in superficie, ignorato da Google, in salute su Bing — il nostro PrestaShop SEO Audit mappa esattamente quali di queste modalità di guasto ti stanno colpendo, on-site e off-site. È lo stesso processo forense che abbiamo applicato a noi stessi qui sopra.