Mardi matin, 9h12. Un message Slack d’un client : « Mon trafic a plongé, j’ai rien changé. » On ouvre la Search Console. La courbe ressemble à une falaise, 34 % de clics perdus en 72 heures. Première intuition du client : « J’ai dû me faire pénaliser à cause de contenu dupliqué. » On a répondu : « Oublie le contenu, on va lire les logs. »
On te dira que diagnostiquer une baisse de trafic commence par auditer les contenus. C’est l’inverse. Un drop brutal est un signal que la tuyauterie technique a lâché. Le crawl, le rendu, l’indexation, la performance perçue par Googlebot : c’est là que se cachent 8 effondrements sur 10. Le reste, c’est du bruit.
Le mythe du contenu dupliqué et autres fausses pistes
Quand un site perd soudainement du trafic, le réflexe est de suspecter une pénalité de duplicate content ou une mise à jour d’algorithme type Helpful Content. En réalité, les drops brutaux sont presque toujours d’origine technique. Un contenu « pauvre » ne fait pas disparaître 50 % de vos pages indexées en une nuit, un fichier robots.txt mal configuré, si.
💡 Conseil : Si la chute est supérieure à 20 % et date d’un jour précis, cherchez l’événement déclencheur dans le changelog technique plutôt que dans le wording des articles.
La confusion vient de l’époque où les SEO expliquaient chaque oscillation par un coup de pénalité. Aujourd’hui, on a les logs, le test d’URL en temps réel, les rapports Core Web Vitals. Le diagnostic a changé d’étage.
Auditer le crawl : robots.txt, sitemap et codes HTTP 200… ou pas
Premier levier à vérifier : ce que Googlebot a le droit de crawler et ce qu’il reçoit vraiment. Ouvrez le fichier robots.txt du site. Une simple ligne Disallow: / ajoutée par un plugin SEO un vendredi soir suffit à bloquer l’intégralité du crawl. On l’a vu sur un Shopify : le trafic a mis 48 heures pour s’effondrer, le temps que Google recycle ses URL connues.
Vérifiez le sitemap.xml. Ici, piège classique : le fichier renvoie un code 302 au lieu de 200, souvent à cause d’une règle de redirection trop large sur le CDN. Googlebot ignore les sitemaps qui répondent autre chose que 200 ou 301. Un curl -I https://example.com/sitemap.xml révèle la supercherie en une seconde.
Ensuite, attaquez les pages stratégiques. Un rapport « Couverture » dans la Search Console montre les URLs en erreur 5xx, 4xx ou redirigées. Mais ce que la Search Console ne dit pas, c’est si le serveur renvoie un 200 avec un contenu vide. Seul le curl couplé à l’inspection de la réponse HTML vous l’apprendra. Une migration de serveur mal calée peut servir un body quasi vide sans changer le statut, et Google nettoie ces pages en quelques jours.
Quand Googlebot ne voit pas ce que ton navigateur affiche : le rendu JS en cause
On arrive au nœud du problème pour les sites JavaScript lourds. Ouvrez votre page produit dans Chrome, vous voyez le prix, la description, les avis. Googlebot, lui, reçoit un squelette vide parce que le contenu dépend de l’exécution de trois bundles de 400 ko qui mettent 6 secondes à se résoudre côté client. Il ne verra rien et désindexera.
Le test de l’outil d’inspection d’URL dans la Search Console montre la version rendue. On y découvre fréquemment un écran blanc ou un message d’erreur JS. Pendant ce temps, le navigateur affiche tout : le code s’exécute bien, mais trop lentement pour Googlebot, qui n’attend pas. Résultat, des centaines de fiches passent en « Détectée, actuellement non indexée ».
Un bundle monstrueux ne vient pas de nulle part. Dans des applis React, une gestion d’état mal anticipée provoque des cascades de rendus qui retardent le LCP et l’interactivité. On a réduit le TTI de 2,3 secondes sur une SPA en migrant de Redux vers Zustand, un gestionnaire d’état léger qui évite les re-rendus inutiles. Moins de calcul, un rendu plus proche du HTML statique que Googlebot peut digérer. Seul bémol : le lazy-loading des composants doit être testé avec l’inspecteur d’URL, car Googlebot n’active pas tous les événements utilisateur.
⚠️ Attention : Un rendu côté serveur (SSR) ne protège pas automatiquement. Si votre cache CDN sert la version déshydratée à Googlebot à cause d’un User-Agent non reconnu, le contenu disparaît. Testez avec l’outil en spécifiant Googlebot Mobile.
Les Core Web Vitals qui s’effondrent : un tueur silencieux de classement
Contrairement au blocage de crawl, une dégradation des Core Web Vitals ne fait pas chuter le trafic du jour au lendemain. Elle rogne les positions par petits paquets, semaine après semaine. Un LCP qui passe de 2,8 secondes à 5,2 secondes sur mobile peut coûter 6 à 10 places sur des requêtes concurrentielles, sans que rien ne clignote dans la Search Console.
On a documenté ce phénomène sur une landing page B2B dont l’INP a grimpé à 480 ms après l’ajout d’un chat en overlay. Le taux de clics a baissé de 12 % en trois semaines, alors que le contenu n’avait pas bougé. Le diagnostic a été confirmé en croisant les données CrUX avec la courbe de position moyenne. Les signaux de classement documentés intègrent les Core Web Vitals, et leur poids est suffisant pour faire la différence entre la troisième et la huitième place.
Pour mesurer, ne vous fiez pas uniquement au rapport Core Web Vitals de la Search Console, trop agrégé. Utilisez les données de champ via l’API CrUX ou un outil de monitoring synthétique qui simule un Moto G4 sur réseau 4G lent. Reproduisez la même condition que pour le test mobile de Google.
Si vous détectez une dérive, ciblez la ressource responsable : un fichier de police non compressé, un carrousel qui force un layout shift au chargement, un script tiers qui bloque le thread principal. Les corrections sont souvent frugales. Un simple fetchpriority="high" sur l’image LCP ou le retrait d’un gestionnaire onéreux peuvent faire repasser la métrique en dessous du seuil.
Les pièges du noindex et des balises canoniques mal configurées
Parfois, le drame tient en une ligne. Un <meta name="robots" content="noindex"> oublié en staging et poussé en production peut anéantir l’indexation de tout un répertoire. On a perdu un samedi complet à débugger un site Next.js dont le middleware injectait par erreur X-Robots-Tag: noindex sur toutes les pages après une mise à jour de configuration.
L’autre piège, c’est la balise canonique. Une canonical pointant sur une URL en 404 parce que la page cible a été supprimée, et Google cesse d’indexer la source. Vérifiez les chaînes de canonicalisation avec un outil de crawl comme Screaming Frog. Si l’entête HTTP Link contient aussi une canonical, la double indication peut créer des conflits si elle n’est pas cohérente avec la balise HTML.
Dans le cas d’une migration, surveillez les balises hreflang qui pointent toujours sur l’ancien domaine. Google interprète une incohérence comme une erreur de configuration et peut désindexer les versions localisées. On ne le répétera jamais assez : les signaux techniques s’ajoutent, et une erreur simple peut en masquer une autre.
Analyser les logs serveur : la preuve ultime que Google t’ignore
Les rapports Search Console montrent ce que Google a indexé ou tenté de crawler, mais ils ne disent pas combien de requêtes Googlebot échouent silencieusement. Seules les logs brutes vous donnent le volume de hits, les statuts exacts, le temps de réponse et les URL les plus crawlées par rapport à celles qui ne le sont plus.
Après la migration d’un site vers une architecture headless, on a extrait les logs Apache. En filtrant sur l’user-agent Googlebot, on a constaté que 40 % des requêtes aboutissaient à une redirection 302 vers une page d’authentification. Résultat : Google a abandonné ces URLs en quinze jours. La Search Console n’a jamais signalé d’erreur explicite, seulement une baisse des pages indexées.
Pour analyser vite, un simple grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn donne la distribution des codes de statut. On peut aussi compter les hits par jour pour détecter une chute soudaine du crawl budget. Si le nombre de requêtes Googlebot est divisé par trois du jour au lendemain, le problème n’est pas dans le contenu, mais dans la capacité du moteur à accéder au site.
Pour accélérer le dépouillement, on a testé d’ingérer les logs dans Claude Code. L’outil repère les patterns d’URL ignorées et les anomalies de fréquence en quelques minutes, là où un debug manuel prendrait l’après-midi. Ce n’est pas magique, mais le gain de temps est net quand on traite un fichier de plusieurs gigaoctets.
📌 À retenir : Comparez toujours le nombre d’URLs connues dans la Search Console avec le nombre de URLs crawlées dans les logs. Si l’écart explose, le crawl budget est en jeu.
Questions fréquentes
Comment distinguer une pénalité manuelle d’un problème technique ?
Rendez-vous dans le rapport « Actions manuelles » de la Search Console. S’il est vide, il n’y a pas de pénalité manuelle. Les actions algorithmiques sur la qualité ne provoquent pas une chute verticale en 24 heures, contrairement à un blocage de crawl. Si la chute est soudaine et massive, cherchez d’abord la panne technique.
Le duplicate content peut-il vraiment causer une baisse aussi brutale ?
Non. Google peut choisir d’ignorer des pages avec un contenu très similaire, mais cela n’entraîne pas un effondrement instantané de tout le trafic. L’indexation conditionnelle liée au duplicate ronge lentement, et ne touche qu’une partie des pages. Un drop vertical est quasiment toujours un signal serveur ou un noindex étendu.
Les fluctuations saisonnières peuvent-elles expliquer une baisse sans problème technique ?
Elles expliquent des baisses progressives inscrites dans un cycle annuel, pas un décrochage brutal. Si votre courbe plonge subitement hors saison, ne vous abritez pas derrière la saisonnalité avant d’avoir éliminé les hypothèses de crawl, de rendu ou d’erreur serveur.
