Le rapport de statistiques d'exploration de Search Console n'affichait aucune donnée pour les 15 et 16 août 2026. Repéré sur X par plusieurs SEO dont Glenn Gabe, relayé par Search Engine Roundtable le 21 août, le trou a été comblé le week-end du 23 août en même temps que le bug des favicons, sans communication de Google. C'était un bug de reporting : Googlebot a continué d'explorer normalement, comme les logs serveur des sites concernés l'ont montré.
- Le rapport concerné est le seul endroit où Google montre son propre comportement de crawl sur un site : requêtes par jour, octets, temps de réponse, codes de réponse, types de fichiers, finalité (découverte ou rafraîchissement), par hôte
- Deux jours manquants ne changent rien au crawl, mais faussent toute moyenne hebdomadaire et déclenchent les alertes automatiques calées sur le jour ; les données ont été restaurées, ce qui n'est pas systématique dans ce type d'incident
- C'est le premier d'une série d'incidents de reporting Google cet été ; la parade est la même à chaque fois : une source indépendante, vos logs
Ce que le rapport mesure, et pourquoi un trou fait plus de dégâts qu'il n'en a l'air
Le rapport se trouve dans Paramètres puis Statistiques sur l'exploration, sur les propriétés de type domaine. Il agrège les requêtes de Googlebot sur 90 jours avec un décalage de deux à trois jours. Trois usages courants dépendent de sa continuité : détecter une chute de crawl après une mise en production, repérer une hausse de codes 5xx ou de temps de réponse, et suivre la part de crawl consacrée à la découverte de nouvelles URL. Sur chacun, deux jours à zéro au milieu d'une fenêtre de sept jours produisent une fausse alerte de chute de 28 %, puis une fausse « reprise » quand les données reviennent.
Le distinguo entre crawl et reporting est celui que Google a fait pour ses bugs d'avril sur les apparences Offres d'emploi (« logging only ») et qu'il a refait implicitement ici en restaurant les données. Le rapport est une vue, pas la source. La source, c'est le journal de votre serveur, où chaque requête de Googlebot est inscrite avec son adresse, son code de réponse et sa taille. Quelques lignes de shell suffisent à recompter les requêtes par jour et à vérifier que les 15 et 16 août ressemblent au 14 et au 17.
Mon avis : ce bug a été corrigé en quarante-huit heures et n'a rien coûté, mais il a rappelé à beaucoup d'équipes qu'elles n'avaient aucune autre source que Google pour mesurer Google. La suite de l'été (favicons et restauration des données, panne de diffusion du 28, GA4 sans données le 1er septembre) a confirmé le besoin.
Ce que ça change pour vous
Si vous suivez le crawl dans Search Console, annotez les deux dates dans vos tableaux de bord et vérifiez que les données restaurées sont cohérentes avec les jours voisins avant de les réutiliser. Si vous n'avez pas accès aux logs, c'est le moment de le demander : c'est la seule assurance contre le prochain trou, et ils servent à bien plus que ça.
- Compare dans tes logs le nombre de requêtes Googlebot des 15 et 16 août aux jours voisins : si c'est stable, tu as ta preuve que seul le rapport a manqué
- Passe tes alertes de crawl sur une fenêtre glissante de sept jours avec exclusion des jours à zéro strict : un zéro exact est un trou de données, pas une chute
- Ajoute au rapport de crawl une colonne « source : logs » dans ton suivi mensuel, ne serait-ce qu'un total quotidien, pour ne plus dépendre d'une seule vue
Sources
- Search Engine Roundtable - Google Search Console Crawl Stats Report Missing Data (21 août 2026)
- Search Engine Roundtable - restauration des données et correction des favicons (23 août 2026)
- Google Search Console Help - Rapport Statistiques sur l'exploration
Source : Seroundtable.com
Cet article a été rédigé avec l’assistance d’un modèle de langage (LLM).
