Nous avons perdu 95% de notre trafic Google en une nuit. Bing nous classe toujours dans le top 3.

Entre le 16 et le 17 avril 2026, notre trafic organique Google a chuté d'environ 95% — du jour au lendemain, littéralement. Aucune pénalité, aucun avertissement. Et le plus étrange : Bing continuait de classer exactement les mêmes pages dans son top 3. Voici le post-mortem honnête — ce qui a cassé (c'était notre propre code), comment nous l'avons retracé à l'heure près, et ce qui ne s'est toujours pas rétabli.

Nous développons des modules SEO, performance et sécurité pour PrestaShop — c'est notre métier. Voir un crash de trafic frapper notre propre boutique a été une leçon d'humilité et, finalement, un révélateur. Alors nous le documentons proprement — y compris les parties que nous n'avons pas encore corrigées.

Ce que ce N'ÉTAIT PAS (les fausses pistes que nous avons écartées)

La plupart des conseils sur les « crashs de trafic » vous envoient d'abord vers ces pistes. Nous y sommes allés aussi, et nous les avons écartées :

• Pas une pénalité. Aucune action manuelle dans la Search Console, aucune notification de liens artificiels. L'API URL Inspection montrait nos pages clés toujours « Envoyée et indexée ». C'était une rétrogradation de classement, pas une désindexation.
• Pas (purement) une mise à jour d'algorithme. La core update de mars 2026 s'était bel et bien achevée autour du 8 avril — huit jours avant notre falaise — et nous ne prétendrons pas que ce contexte de retraitement était sans importance. Mais une core update déployée sur plusieurs semaines n'explique pas des impressions quotidiennes qui s'effondrent entre deux jours consécutifs. Quelque chose de chez nous coïncidait à l'heure près.
• Pas principalement du « thin content » — même si le reproche est recevable. S'il y a une chose, c'est que nous avions plus de contenu que notre autorité ne le justifiait : ~150 pages de modules en six langues, plus le blog, la doc, la FAQ. Nous pensons que cette empreinte a rendu la reprise plus difficile, et nous traitons la perception de « contenu produit à l'échelle / de faible valeur » comme une hypothèse vivante et non résolue, pas comme quelque chose à balayer d'un revers de main.
• Pas les évidences techniques. robots.txt était propre, le sitemap répondait, les canonicals et le hreflang (six locales + x-default) étaient corrects.

L'indice qui a tout recadré : Bing classait exactement le même contenu dans son top 3 — avec un profil de domaines référents si mince que notre score « d'autorité » tiers est quasiment nul. Mêmes pages, deux moteurs de recherche, résultats opposés. C'est l'empreinte d'un verdict de confiance/autorité déclenché par un défaut technique — pas un problème isolé de qualité de contenu ou de vitesse.

La cause racine : nous avons livré le bug nous-mêmes (confiance d'environ 80%)

Voici la partie que la plupart des post-mortems d'éditeurs enterreraient. Le déclencheur, c'était notre propre déploiement.

Entre le 13 et le 18 avril, nous modifiions notre module de produits numériques — un nouveau contrôleur de téléchargement, un correctif « duplicate slug on install », un bouton de téléchargement rendu côté serveur. Quelque part dans ce travail, la génération des URL produits s'est mise à lever l'exception Invalid product vars de PrestaShop (dans classes/Link.php). Nos logs d'exceptions montrent la corrélation à l'heure près :

Le timing est brutal. Nous venions tout juste de décoller dans la « lune de miel » d'un site jeune — autour de 4,000–5,400 impressions par jour, à peu près en position 10, début avril. C'est précisément le moment où Google nous évaluait le plus durement. Et dans cette fenêtre, Googlebot tombait sur ~1,000 liens produits internes cassés par jour. Pour un crawler, un graphe de liens internes qui se met soudain à pointer vers des URL produits cassées en pleine phase d'évaluation, c'est un signal fort : « ce site vient de se dégrader ».

Nous parlons de ~80% de confiance plutôt que de certitude, parce que tout cela est tombé dans une fenêtre réellement bruitée — la core update achevée, une spam update, la fin de la lune de miel, et des pannes serveur/BDD récurrentes de notre côté (mi-mars, 14–16 avril, et de nouveau en juin). Chacun de ces facteurs aggrave une atteinte à la confiance. Mais seul le décompte d'erreurs Link.php s'aligne jour pour jour avec la falaise. Le verdict honnête : un déclencheur technique auto-infligé, qui a détoné dans le contexte d'un site jeune, à faible autorité, juste après une core update.

La catégorie qui explique vraiment un −95% : « Explorée, actuellement non indexée »

Si vous ne retenez qu'une leçon de diagnostic de tout ceci, retenez celle-là. Dans le rapport de couverture de l'index de la Search Console, la catégorie qui compte n'est ni « 404 » ni « 5xx ». C'est « Explorée, actuellement non indexée » — environ 22,800 URL.

Une nuance honnête, parce que nous avons vérifié notre propre historique : cette catégorie n'a pas « explosé » la nuit du crash. Nous l'avons vue apparaître dès février 2025, elle a culminé près de 60k, et elle se vide lentement jusqu'à ~22.8k. La falaise nocturne elle-même était une rétrogradation de classement de pages restées indexées — des impressions quotidiennes de ~5,400 en position ~10 tombées à 161 le lendemain, en position 27. La catégorie « explorée, non indexée » n'est pas le mécanisme de la chute nocturne ; c'est là que le verdict de confiance de long terme devient visible. Nous avons vérifié qu'un échantillon de ces 22.8k pages renvoie 200, index,follow, auto-canonique, riche en contenu. Google a exploré des dizaines de milliers de pages techniquement propres et a choisi de ne pas les indexer.

Rétablissement, partie 1 : rendre l'ardoise technique réellement propre

On ne peut pas demander à Google de réévaluer un site qui trébuche encore sur des erreurs. La phase un a donc été une hygiène impitoyable — chaque défaut technique corrigible corrigé et vérifié en production, pas seulement « livré » (la catégorie de confiance de la section suivante est un problème distinct, non technique) :

• Le déclencheur Link.php : corrigé en premier — 0 erreur depuis mai, les produits rendent un HTML 200 complet.
• 404 : vrais 404 et slugs renommés séparés ; les anciens slugs en 301 vers les canoniques actuelles (un seul saut, localisé).
• URL à facettes : combinaisons valides en 200 + noindex,follow, obsolètes en 301 — les humains filtrent, les crawlers ne se noient pas.
• 5xx : un fatal d'autoload inter-langues dû à une différence de casse, corrigé avec un garde-fou.
• Chaînes de redirections : réduites à un seul saut, résolues au moment de l'émission.
• Données structurées : exactement un brand par produit et longueur de description plafonnée (les deux erreurs qui nous coûtaient réellement des résultats enrichis).
• Assets : suppression du cache-busting ?v= par fichier pour laisser fonctionner le combine-minify natif de PrestaShop.
• Hiérarchie des titres : un seul <h1> par page, un H1 → H2 → H3 propre.

Rétablissement, partie 2 : ne pas relancer le crawl sur un chantier — le « freeze gate »

Voici la discipline que la plupart des récits de rétablissement passent sous silence. Avant de resoumettre quoi que ce soit à Google, nous traitons le sitemap et le pipeline d'indexation comme un portail : rien n'est proposé à l'indexation sans être prouvé propre.

• Le sitemap est régénéré et chaque URL vérifiée indépendamment — 200, index,follow, auto-canonique, hreflang correct, schéma valide. Le nôtre s'est stabilisé à 4,952 URL en six langues.
• La file d'indexation ne soumet jamais que des URL qui sont actuellement des canoniques indexables, avec un contrôle par URL au moment de la soumission — pas une lance à incendie aveugle.

L'audit de chaque URL du sitemap à travers ce contrôle a révélé trois bugs qui auraient silencieusement gâché tout le re-crawl : notre registre interne de pages ignorait 918 URL du sitemap — dont l'intégralité du jeu de documentation de 882 URL ; trois pages FAQ étaient marquées noindex à tort à cause d'une ligne d'association boutique manquante ; et des billets de blog étaient aiguillés vers noindex par un classificateur qui reconnaissait des mots-clés de type support avant la route du blog. Nous avons exigé un résultat zéro bloquée — chacune des 4,952 URL passant le contrôle — avant de déclarer le portail fermé.

La leçon : regagner la confiance signifie que la prochaine chose que Google voit doit être immaculée. Un tour de plus de « merci d'indexer nos pages cassées » ne fait que creuser le trou.

Ce sur quoi nous alertons désormais

La panne est restée invisible pendant des jours parce que rien ne hurlait. Ce que nous surveillons maintenant :

• Alerte sur les exceptions de classe critique sur Link.php / slug manqué du dispatcher — tout pic nous prévient immédiatement, au lieu d'une lecture hebdomadaire des logs.
• Tendance des stats de crawl GSC + Bing examinée chaque semaine, côte à côte — la divergence Bing/Google est notre signal de confiance le plus précoce.
• Watchdog de disponibilité sur l'origine — nos pannes ont fait partie de la blessure, la disponibilité est désormais une métrique SEO de premier rang.
• Contrôle de parité sitemap/registre — le garde-fou qui a trouvé les 918 manquantes tourne en continu.

Ce qui, honnêtement, N'EST PAS (encore) rétabli

C'est ici que la plupart des billets « comment je me suis rétabli » deviennent malhonnêtes. Pas nous.

• Les positions et le trafic ne sont pas revenus. L'ardoise technique est propre et vérifiée, mais Google refuse toujours d'indexer l'essentiel de ce qu'il explore, et la position continue de dériver au lieu de rebondir.
• Le off-page est notre vrai plafond. Notre profil de domaines référents est mince — le même contenu que Bing classe dans son top 3, Google n'en veut pas. Un site propre avec une validation externe faible, c'est exactement à quoi ressemble « explorée, non indexée ».
• Nos locales non anglophones sont un poids mort. Elles génèrent des impressions mais presque aucun clic ; seuls l'anglais et le polonais convertissent réellement. Multiplier des pages traduites automatiquement faisait partie de l'empreinte excessive, pas de l'actif.
• La suite ne se joue pas sur le plan technique. C'est une affaire d'autorité et de temps : de vrais signaux d'expérience et d'expertise, des liens gagnés dans l'écosystème PrestaShop, et laisser un site propre faire ses preuves une fois l'indexation rouverte via la file contrôlée.

Nous publions ceci maintenant, en plein rétablissement, précisément parce qu'un post-mortem écrit après une reprise complète est un conte de fées biaisé par les survivants. Voilà à quoi cela ressemble réellement, vu de l'intérieur.

Si cela arrive à votre boutique PrestaShop

• Vérifiez Bing. Si Bing classe votre contenu et pas Google, cessez d'accuser le contenu et la vitesse — c'est la confiance, et le déclencheur est probablement technique.
• Relisez votre journal de déploiement face à votre courbe de trafic. Notre preuve accablante était un décompte d'exceptions aligné au jour près avec la falaise. La vôtre l'est peut-être aussi.
• Lisez les catégories de couverture de l'index, pas seulement la courbe de trafic. « Explorée — non indexée » à grande échelle est un signal de qualité, pas un bug à corriger.
• Corrigez et vérifiez en production — en direct sur l'origine, pas « ça devrait être corrigé ».
• Ne relancez pas le crawl sur un chantier. Prouvez que votre sitemap et votre lot de soumission sont immaculés avant de redemander un regard à Google.
• Ensuite, soyez patient et bâtissez l'autorité. Il n'existe pas de correctif de code pour la confiance.

Si votre boutique présente ce même schéma — propre en surface, ignorée par Google, saine sur Bing — notre PrestaShop SEO Audit cartographie exactement lesquels de ces modes de défaillance vous frappent, on-site comme off-site. C'est le même processus forensique que nous avons appliqué à nous-mêmes, ci-dessus.