Google n'explorait que 8 % de notre site (et le coupable était un réglage qu'on n'avait jamais activé)

Une page classée première disparaît du jour au lendemain. En regardant de plus près, onze autres expressions du même groupe se sont éteintes exactement au même moment. Aucune pénalité, aucune erreur technique, aucune mise à jour de l'algorithme, et tous les outils d'audit continuent d'afficher cent pour cent de santé.

Ils avaient raison. Le problème ne venait pas de nos pages, il venait de ce que Google avait le temps de lire. Il nous a fallu une journée pour comprendre, et ce qu'on a trouvé concerne probablement votre site aussi.

On raconte l'enquête complète ci-dessous, avec les chiffres réels, et la méthode pour vérifier le vôtre en dix minutes.

Le symptôme, des pages qui s'éteignent sans prévenir

Ce qu'on a observé

Une de nos pages tenait la première place sur une expression précise depuis plusieurs semaines. Un matin, elle n'apparaissait plus nulle part. En creusant, on s'est aperçu que onze expressions du même groupe avaient disparu ensemble, au même moment, alors qu'elles occupaient des positions très différentes la veille.

Une disparition simultanée sur un groupe entier, ce n'est jamais du hasard. C'est un signal, et il fallait comprendre lequel.

Les vérifications qui n'ont rien donné

Le premier réflexe consiste à chercher la faute dans la page elle-même, alors on l'a passée au crible.

Elle répondait normalement, en moins d'une seconde. Elle autorisait explicitement l'indexation, sa balise canonique pointait sur elle-même et était correctement formée. Elle contenait 2 873 mots de contenu original, structurés en sections. Google Search Console affichait sans la moindre ambiguïté que cette URL était sur Google et que la page était indexée.

Tout était juste, et pourtant elle n'apparaissait plus dans les résultats.

L'erreur de raisonnement à ne pas commettre

À ce stade, la tentation est grande de modifier la page : réécrire le titre, ajouter du contenu, changer la structure interne, refaire le maillage. C'est l'erreur classique, celle qui coûte le plus cher sur la durée. On répare quelque chose qui n'était pas cassé, on perd au passage ce qui fonctionnait, et le vrai problème reste entier pendant qu'on s'agite.

Avant de toucher à quoi que ce soit, il faut savoir ce qu'on cherche.

Éliminer l'extérieur avant d'accuser son propre site

Est-ce que Google a bougé ?

Une chute de positions coïncide souvent avec une secousse chez Google, et il existe des indicateurs publics de volatilité des résultats de recherche, mis à jour quotidiennement pays par pays. C'est la première chose à consulter, avant même de regarder son propre site.

Le jour de notre chute, la France affichait 0,5 sur 10. Le seul pic des trente jours précédents remontait à deux semaines plus tôt, à 3,1, un niveau que l'outil lui-même qualifie de normal.

Ce que cela permet d'éliminer

Un calme plat pendant une chute concentrée sur un seul groupe de pages ferme la piste algorithmique. Si Google avait modifié quelque chose dans son classement, l'effet aurait été plus large et se serait vu ailleurs sur le site, pas sur onze expressions liées entre elles.

Le problème venait donc de chez nous. Restait à savoir où, et c'est là que l'enquête a vraiment commencé.

La réponse était dans un rapport que personne n'ouvre

Où le trouver

Search Console contient un rapport rangé dans les paramètres, à l'écart des tableaux de bord qu'on consulte habituellement, qui s'appelle « statistiques sur l'exploration ». Il ne dit pas ce que Google indexe, ni comment vos pages se positionnent. Il dit ce que le robot de Google télécharge réellement sur votre site, fichier par fichier, jour après jour.

La distinction paraît anodine et c'est pourtant elle qui a tout éclairé.

Ce qu'il affichait

Huit pour cent.

Sur 14 500 requêtes en trois mois, Google ne consacrait que huit pour cent de son travail à lire des pages. Tout le reste partait dans les fichiers techniques qui font tourner le site, ceux que personne ne lit jamais et qui n'apportent aucun contenu à indexer.

La confirmation par un second angle

Le même rapport propose une répartition par type de robot, et elle raconte exactement la même histoire sous une autre forme. Cinquante-deux pour cent des visites relevaient du simple chargement de ressources, contre trente-huit pour cent de lecture de pages proprement dite.

Deux mesures indépendantes qui pointent vers la même conclusion, c'est ce qui a transformé une intuition en diagnostic.

Ce que cela donne en jours

L'arithmétique est simple et elle fait mal.

Quatorze mille cinq cents requêtes sur quatre-vingt-dix jours, cela représente environ cent soixante et une requêtes par jour. Huit pour cent de ce total en pages, cela fait treize pages lues quotidiennement, pour un site qui en compte cent quatre.

Il fallait donc à Google huit jours au minimum pour faire le tour complet du site. En pratique bien davantage, puisqu'un moteur repasse beaucoup plus souvent sur une page d'accueil que sur une page profonde, ce qui déséquilibre encore la répartition.

Vérification faite sur la page disparue, sa dernière exploration remontait à dix-huit jours. Google avait tout simplement cessé de suivre ce qui se passait dessus.

La cause, trente caractères ajoutés automatiquement

Ce qu'on a trouvé dans le code

Chaque page de notre site charge vingt-huit fichiers techniques. On les a listés un par un, en regardant les adresses complètes plutôt que les noms de fichiers.

/_next/static/media/NeueMontreal_Bold.woff2?dpl=dpl_DgApsTYk8KqUwTBCUvUk1EovJQGY
/_next/static/chunks/1mfby909i8658.css?dpl=dpl_DgApsTYk8KqUwTBCUvUk1EovJQGY

Ce ?dpl= à la fin de chaque adresse est un identifiant de déploiement, et il change à chaque mise en ligne du site. Sur les vingt-huit fichiers, les vingt-huit le portaient, polices de caractères comprises, alors que celles-ci n'avaient pas bougé depuis des mois.

C'est un mécanisme qu'on retrouve sur la plupart des plateformes modernes, y compris sur les sites générés automatiquement par les outils d'intelligence artificielle, qui reposent sur les mêmes socles techniques.

Pourquoi c'est un problème

Une adresse qui change, pour Google, est une adresse nouvelle. Le fait que le fichier soit rigoureusement identique au précédent ne change strictement rien à l'affaire, puisque le moteur raisonne sur l'adresse et pas sur le contenu.

À chaque mise en production, il découvrait donc vingt-huit adresses inédites par page. Il les téléchargeait, les traitait, les mémorisait, puis recommençait exactement pareil à la mise en ligne suivante. Sur un site déployé plusieurs fois par jour, l'effet cumulé devient considérable en quelques semaines.

La preuve

Elle était sous nos yeux depuis des mois, dans le rapport d'indexation. Cent quatre-vingt-dix-sept adresses classées « explorée, actuellement non indexée », un chiffre en augmentation continue depuis le mois de novembre précédent.

On a ouvert la liste, et les dix premières adresses portaient dix identifiants de déploiement différents. Google gardait en mémoire les fichiers de dix versions successives du site et continuait de tous les visiter, semaine après semaine.

Pourquoi ce réglage existe et pourquoi il reste invisible

Le problème qu'il résout est réel

Ce paramètre vient d'une fonction appelée protection contre le décalage de version, et elle répond à un besoin légitime. Quand vous mettez le site à jour pendant qu'un visiteur a une page ouverte depuis un moment, ce visiteur peut se retrouver avec une version hybride, moitié ancienne moitié nouvelle, et tomber sur une erreur au moment où il clique. L'identifiant garantit que chacun reste sur une version cohérente jusqu'à ce qu'il recharge.

Ce n'est donc pas une mauvaise fonctionnalité. C'est une fonctionnalité utile dont personne n'a mesuré l'effet secondaire côté référencement.

Trois raisons pour lesquelles on ne la voit jamais

Premièrement, elle est activée par défaut sur tous les projets créés depuis fin 2024. Aucune décision n'a été prise, aucune case n'a été cochée, elle est simplement là.

Deuxièmement, elle reste totalement invisible pour un visiteur. Le site fonctionne parfaitement, les performances sont excellentes, et aucun symptôme perceptible ne permet de la soupçonner.

Troisièmement, et c'est le plus gênant, son effet sur le référencement n'est documenté nulle part. Ni dans la documentation de la plateforme, ni dans les guides de bonnes pratiques qui circulent dans le métier. Le seul endroit où le mécanisme est décrit, c'est la documentation de Google, mais elle traite du principe général sans jamais nommer les outils qui le déclenchent.

Ce qu'en dit Google, précisément

La phrase qui décrit exactement notre cas

La documentation Search Central traite ce scénario mot pour mot, dans un article publié en décembre 2024 sur le fonctionnement de l'exploration :

« Utilisez les paramètres de cache busting avec précaution : si les URL des ressources changent, Google peut être amené à les explorer à nouveau, même si leur contenu n'a pas changé. Cela va bien sûr consommer du budget d'exploration. »

Pourquoi les réglages de cache classiques ne servent à rien ici

Le même document précise autre chose, qui explique pourquoi le problème échappe même à des équipes techniques compétentes. Le service de rendu de Google conserve les ressources en cache pendant trente jours au maximum, indépendamment des instructions de mise en cache envoyées par le serveur.

Nos fichiers étaient pourtant configurés de façon exemplaire, avec une durée de conservation d'un an et la mention immutable, celle qui indique au navigateur que le fichier ne changera jamais. Sans le moindre effet. Google applique ses propres règles, et une adresse qui change reste une adresse neuve à ses yeux, quelles que soient les instructions qu'on lui envoie par ailleurs.

C'est contre-intuitif, et c'est précisément ce qui rend ce problème si difficile à repérer.

Le piège dans lequel il ne faut surtout pas tomber

La fausse bonne idée

Une fois le diagnostic posé, la réaction instinctive consiste à interdire aux robots l'accès à ces fichiers techniques, via le fichier robots.txt. Le raisonnement semble imparable : moins de fichiers explorés, donc plus de budget disponible pour les pages qui comptent vraiment.

C'est une très mauvaise idée, et Google le dit sans détour dans la même documentation :

« Interdire l'exploration des ressources entraîne généralement des problèmes. Si le service de rendu ne peut pas récupérer une ressource essentielle à l'affichage, la recherche Google peut avoir du mal à extraire le contenu de la page et à permettre à celle-ci d'être classée dans les résultats. »

Ce qui se passe réellement

En bloquant ces fichiers, vous économisez effectivement du budget d'exploration, et vous perdez vos pages dans la foulée. Google ne peut plus reconstituer ce que le visiteur voit à l'écran, donc il ne peut plus juger de la pertinence du contenu, donc il cesse de classer la page.

Le remède tue le patient. On a failli le faire, et c'est en relisant la documentation qu'on s'est arrêtés à temps.

La correction et ce qu'elle a changé

Ce qu'on a fait

La solution ne consistait pas à bloquer quoi que ce soit, mais à cesser de créer des adresses neuves à chaque déploiement. On a désactivé la protection contre le décalage de version dans les paramètres du projet, puis remis le site en ligne.

Une seule case, un seul déploiement, moins de deux minutes de manipulation.

La vérification immédiate

Sur les vingt-huit fichiers techniques d'une page, plus aucun ne portait le paramètre. Aucune chaîne de requête nulle part, les adresses étaient redevenues propres.

Les noms de fichiers restent identifiés par leur contenu, ce qui signifie qu'un fichier inchangé conserve exactement la même adresse d'une mise en ligne à l'autre. Google n'a donc plus rien de neuf à découvrir tant que le fichier lui-même ne bouge pas.

Le signal qui ressemble à un problème et n'en est pas

Quatre jours plus tard, le nombre d'adresses en erreur 404 a augmenté dans Search Console. Un chiffre qui grimpe dans un rapport d'erreurs, en général, ce n'est pas bon signe, et on est allés voir ce qui se passait.

La liste ne contenait que d'anciens fichiers techniques portant le fameux paramètre, ceux des versions précédentes du site, qui n'existent effectivement plus depuis longtemps.

C'est le nettoyage qui commence. Ces adresses quittent le statut « explorée mais non indexée », dans lequel Google revient indéfiniment sans jamais rien en faire, pour le statut « introuvable », dans lequel il finit par les abandonner définitivement. Et comme le paramètre n'est plus ajouté aux nouveaux fichiers, le stock ne se reconstitue pas.

Combien de temps avant de voir l'effet

Autant être honnête sur les délais, parce que c'est là que beaucoup se découragent. Les statistiques d'exploration sont une moyenne glissante sur quatre-vingt-dix jours, elles bougent donc lentement par construction, et un correctif récent s'y trouve mécaniquement dilué dans les données des trois mois précédents.

Les signaux rapides se trouvent ailleurs. La date de dernière exploration de vos pages importantes réagit en quelques jours, tout comme la courbe du nombre d'adresses classées « explorée, actuellement non indexée ». Ce sont ces deux indicateurs qu'il faut surveiller pendant les deux premières semaines, pas la moyenne globale.

Vérifier votre site en dix minutes

Cette enquête se reproduit sur n'importe quel site, sans compétence technique particulière. Cinq étapes, dans cet ordre. Google publie par ailleurs un guide complet sur la gestion du budget d'exploration, utile si vous voulez aller plus loin.

Étape 1, la répartition de l'exploration

Ouvrez Search Console, allez dans le menu Paramètres, puis dans Statistiques sur l'exploration, et regardez le tableau intitulé « par type de fichier ».

Si la part des pages HTML descend sous les vingt pour cent, votre budget part ailleurs. En dessous de dix pour cent, le problème est sérieux et mérite qu'on s'y arrête tout de suite.

Étape 2, la confirmation par le type de robot

Restez dans le même rapport et descendez jusqu'à la section « par type de Googlebot ». Si la ligne « chargement des ressources de la page » dépasse la moitié du total, ce que vous avez vu à l'étape précédente est confirmé par une seconde mesure.

Étape 3, la liste des adresses fantômes

Passez dans le menu Indexation, puis Pages, et ouvrez le motif « explorée, actuellement non indexée » pour afficher la liste des adresses concernées.

Si vous y trouvez des chemins techniques, des noms de fichiers, des dossiers aux noms illisibles, plutôt que de vraies pages de votre site, vous tenez le coupable.

Étape 4, le paramètre dans le code

Ouvrez n'importe quelle page de votre site, affichez le code source, et regardez les fichiers qu'elle appelle. Vérifiez si leur nom est suivi d'un point d'interrogation puis d'une suite de lettres et de chiffres.

Si c'est le cas, remettez le site en ligne et regardez à nouveau. Si cette suite a changé alors que le fichier lui-même n'a pas bougé, vous avez exactement le même problème que nous.

Étape 5, la fraîcheur de vos pages

Prenez une page qui compte pour votre activité, collez son adresse dans l'outil d'inspection d'URL de Search Console, ouvrez le détail de l'indexation et lisez la date de dernière exploration.

Si elle remonte à plus de deux semaines, Google ne suit plus ce que vous publiez sur cette page, et tout ce que vous y modifiez met un temps considérable à être pris en compte.

Ce que cette histoire dit vraiment

Un site sans défaut peut se saborder tout seul

Notre site affichait cent pour cent de santé sur tous les outils d'audit, zéro erreur et zéro avertissement. Ces outils n'avaient pas tort, d'ailleurs : au sens où ils l'entendent, il n'y avait effectivement aucun défaut à signaler.

Le problème n'était pas un défaut. C'était un réglage parfaitement légitime, appliqué par défaut par une plateforme sérieuse, dont l'effet secondaire n'apparaît sur aucune grille de contrôle existante. Aucun outil ne le cherche parce qu'aucun outil ne sait qu'il faut le chercher.

La différence entre un site qui marche et un site qui est suivi

Un site livré, même impeccablement construit, dérive avec le temps. Les plateformes modifient leurs réglages par défaut sans prévenir, les outils changent de comportement au fil des versions, les moteurs ajustent leurs priorités. Ce qui était juste il y a six mois ne l'est plus nécessairement aujourd'hui, et rien ne vous en informe. C'est vrai du budget d'exploration comme du référencement à l'ère des réponses générées, où les règles ont changé sans que personne ne soit prévenu.

Aucune alerte ne se déclenche, aucun voyant ne passe au rouge. Il faut aller regarder soi-même, régulièrement, dans des rapports qu'on n'ouvre jamais spontanément parce qu'ils ne servent à rien tant que tout va bien.

Ce qu'on en retire

Cette panne ne nous a rien coûté d'autre que du temps, parce qu'on est allés voir. Un site sans personne pour ouvrir ces rapports aurait pu perdre sa visibilité pendant des mois sans jamais comprendre pourquoi, en réécrivant consciencieusement des pages qui n'avaient absolument aucun problème.

C'est la partie du métier qui ne se voit pas, celle qu'on ne facture jamais explicitement, et c'est pourtant celle qui fait la différence sur la durée.