Pendant environ 50 semaines, Search Console a enregistré des données de performance incorrectes. Google a corrigé le bug en mai 2026. Mais l'historique reste tel quel — aucune correction rétroactive. Si vous avez pris des décisions stratégiques basées sur ces données entre mi-2025 et début 2026, vous avez potentiellement travaillé sur des hypothèses fausses.
Ce que Google a réellement cassé (et corrigé)
Le problème, documenté par Search Engine Land, concerne le logging des données de performance dans l'API et l'interface Search Console. Le bug affectait la manière dont certaines impressions et certains clics étaient attribués aux pages et aux requêtes. Google n'a pas communiqué de détails techniques précis sur la nature exacte du dysfonctionnement — ce qui est un problème en soi.
Ce qu'on sait :
- Le bug a duré environ 50 semaines, soit quasiment toute l'année calendaire 2025 et le début de 2026.
- Les données futures (post-fix) devraient être fiables.
- Les données historiques ne seront pas corrigées. Elles restent dans votre compte telles quelles, faussées.
- Le bug impactait potentiellement les métriques d'impressions, de clics, de CTR et de position moyenne — les quatre colonnes fondamentales du rapport de performance.
Pourquoi ce n'est pas anodin
Search Console est la seule source de données first-party pour les performances organiques Google. Contrairement à des outils tiers qui estiment le trafic (Semrush, Ahrefs, Sistrix), GSC rapporte les données réelles du moteur. Quand cette source est corrompue, c'est l'ensemble de la chaîne de décision SEO qui est compromise :
- Les rapports de performance envoyés aux clients ou au management contenaient des chiffres erronés.
- Les A/B tests SEO (title tags, meta descriptions) ont potentiellement été évalués sur des données fausses.
- Les décisions de priorisation de contenu basées sur les impressions sans clics (opportunités de CTR) étaient biaisées.
- Les analyses de cannibalisation de mots-clés, qui reposent lourdement sur le rapport de requêtes GSC, étaient potentiellement incorrectes.
Quantifier l'impact : un scénario concret
Prenons un cas réaliste. Un site e-commerce de 12 000 pages produits, générant 800 000 sessions organiques par mois. L'équipe SEO utilise les données GSC pour produire un rapport mensuel de performance et prioriser les optimisations.
Le problème en chiffres
Si le bug a surestimé les impressions de 15 % sur certaines catégories de requêtes (un scénario plausible pour un bug de logging — Google n'ayant pas confirmé l'amplitude exacte), voici ce que ça donne sur un an :
- Impressions réelles mensuelles : 25 millions
- Impressions reportées (avec bug) : 28,75 millions (+15 %)
- CTR calculé par l'équipe : 3,2 % (basé sur les impressions gonflées)
- CTR réel : 3,68 %
L'équipe pensait avoir un problème de CTR sur ses pages catégories et a investi 3 mois à réécrire 200 title tags et meta descriptions. En réalité, le CTR était dans la fourchette normale pour son secteur. Ces 3 mois auraient pu être investis sur l'architecture de liens internes ou la couverture de requêtes long-tail — des chantiers qui attendaient.
Les décisions polluées
L'équipe a aussi identifié une "baisse de positionnement" sur 40 requêtes stratégiques en septembre 2025. Position moyenne passée de 4.2 à 6.8. Une task force a été montée, des contenus ont été réécrits, des backlinks ont été acquis en urgence. Sauf que cette baisse était peut-être un artefact du bug de logging, pas un signal algorithmique réel.
Ce scénario n'est pas hypothétique. C'est exactement le type de cascade de décisions erronées qu'un bug de données provoque dans une équipe SEO structurée.
Comment auditer vos données GSC sur la période impactée
Google ne corrigera pas l'historique. C'est à vous de déterminer dans quelle mesure vos données ont été affectées et quelles décisions doivent être réévaluées.
Croiser GSC avec vos données Analytics
La première étape est de comparer les clics GSC avec les sessions organiques Google dans votre outil analytics (GA4, Matomo, Plausible, etc.). Ces deux métriques ne sont jamais parfaitement alignées — le filtrage de GSC, le sampling de GA4, les bloqueurs de tracking créent toujours un écart. Mais cet écart devrait être relativement stable dans le temps.
Exportez vos données avec l'API GSC et comparez-les mois par mois :
import pandas as pd
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
# Récupération des données GSC via API
def get_gsc_data(service, site_url, start_date, end_date):
request = {
'startDate': start_date,
'endDate': end_date,
'dimensions': ['date'],
'rowLimit': 25000
}
response = service.searchanalytics().query(
siteUrl=site_url, body=request
).execute()
rows = response.get('rows', [])
return pd.DataFrame([{
'date': row['keys'][0],
'clicks': row['clicks'],
'impressions': row['impressions'],
'ctr': row['ctr'],
'position': row['position']
} for row in rows])
# Comparer avec GA4 (export BigQuery ou CSV)
gsc_df = get_gsc_data(service, 'sc-domain:votre-domaine.fr', '2025-05-01', '2026-05-01')
ga4_df = pd.read_csv('ga4_organic_sessions_daily.csv')
merged = gsc_df.merge(ga4_df, on='date', how='inner')
merged['delta_pct'] = ((merged['clicks'] - merged['sessions_organic']) / merged['sessions_organic']) * 100
# Identifier les mois où l'écart dévie de la norme
baseline_delta = merged[merged['date'] < '2025-05-01']['delta_pct'].mean()
merged['anomaly'] = abs(merged['delta_pct'] - baseline_delta) > 10 # seuil de 10 points
print(merged[merged['anomaly']][['date', 'clicks', 'sessions_organic', 'delta_pct']])Si vous observez une divergence croissante entre clics GSC et sessions GA4 à partir de mi-2025, suivie d'une convergence après le fix, vous tenez votre preuve d'impact.
Utiliser les logs serveur comme source de vérité
Les logs serveur ne mentent pas. Chaque requête HTTP est enregistrée, indépendamment de tout JavaScript, cookie ou bug d'API Google. Pour les sites à fort volume, c'est la source de vérité ultime.
Extraire les visites Googlebot et les visites organiques réelles depuis vos access logs :
# Compter les visites organiques réelles (referer Google, user-agent non-bot)
# sur un mois donné
zcat /var/log/nginx/access.log.*.gz | \
grep -i 'referer.*google\.\(com\|fr\|co\)' | \
grep -v -i 'googlebot\|apis-google\|mediapartners' | \
awk '{print $4}' | \
cut -d: -f1 | \
sed 's/\[//' | \
sort | uniq -c | sort -rn | head -30
# Comparer le volume de crawl Googlebot sur la même période
zcat /var/log/nginx/access.log.*.gz | \
grep -i 'googlebot' | \
awk '{print $4}' | \
cut -d: -f1 | \
sed 's/\[//' | \
sort | uniq -c | sort -rn | head -30Si le volume de visites organiques réelles (logs) reste stable alors que GSC montrait des variations importantes, le bug est confirmé pour votre site.
Screaming Frog + exports GSC pour l'audit page par page
Pour les sites avec des milliers de pages, une analyse macro ne suffit pas. Vous devez identifier quelles pages et quelles requêtes ont été les plus affectées.
Exportez l'intégralité de vos données GSC via l'API (pas via l'interface qui limite à 1000 lignes) en segmentant par page et par requête. Importez ces données dans Screaming Frog via le connecteur API custom ou en CSV dans un tableur :
# Export granulaire par page + query pour identifier les anomalies
def get_gsc_pages_queries(service, site_url, start_date, end_date):
all_rows = []
start_row = 0
while True:
request = {
'startDate': start_date,
'endDate': end_date,
'dimensions': ['page', 'query', 'date'],
'rowLimit': 25000,
'startRow': start_row
}
response = service.searchanalytics().query(
siteUrl=site_url, body=request
).execute()
rows = response.get('rows', [])
if not rows:
break
for row in rows:
all_rows.append({
'page': row['keys'][0],
'query': row['keys'][1],
'date': row['keys'][2],
'clicks': row['clicks'],
'impressions': row['impressions'],
'ctr': row['ctr'],
'position': row['position']
})
start_row += 25000
if len(rows) < 25000:
break
return pd.DataFrame(all_rows)
# Identifier les pages dont le CTR a "sauté" après le fix
df = get_gsc_pages_queries(service, 'sc-domain:votre-domaine.fr', '2026-04-01', '2026-05-04')
df_pre = get_gsc_pages_queries(service, 'sc-domain:votre-domaine.fr', '2026-03-01', '2026-03-31')
# Comparer CTR moyen par page avant/après fix
ctr_pre = df_pre.groupby('page')['ctr'].mean().reset_index()
ctr_pre.columns = ['page', 'ctr_pre_fix']
ctr_post = df.groupby('page')['ctr'].mean().reset_index()
ctr_post.columns = ['page', 'ctr_post_fix']
comparison = ctr_pre.merge(ctr_post, on='page')
comparison['ctr_shift'] = comparison['ctr_post_fix'] - comparison['ctr_pre_fix']
comparison = comparison.sort_values('ctr_shift', ascending=False)
# Les pages avec le plus grand shift positif de CTR post-fix
# sont celles dont les impressions étaient les plus gonflées
print(comparison.head(50))Les pages qui montrent une hausse brutale de CTR après le fix (sans changement de title/description/contenu) sont celles dont les impressions étaient artificiellement gonflées par le bug.
Les limites structurelles de Search Console comme source de données
Ce bug met en lumière un problème plus profond : la dépendance quasi totale de l'industrie SEO à un outil gratuit, opaque, dont Google contrôle unilatéralement la qualité des données.
Un historique limité à 16 mois
GSC ne conserve que 16 mois de données. Cela signifie que les données faussées de mi-2025 commenceront à sortir de la fenêtre de rétention d'ici fin 2026. Vous perdrez à la fois la trace du bug et la possibilité de le quantifier rétroactivement.
Si vous n'avez pas encore d'export automatisé de vos données GSC, mettez-le en place maintenant. Des outils comme Search Analytics for Sheets (add-on Google Sheets), des pipelines BigQuery via l'API, ou des solutions de monitoring comme Seogard qui archivent vos données de performance au-delà de la fenêtre GSC sont indispensables pour ce type de situation.
Pas de changelog, pas de SLA
Google ne fournit aucun SLA (Service Level Agreement) sur la qualité des données Search Console. Il n'existe pas de changelog public des bugs de données. La communication sur ce bug est venue de la communauté SEO et de Search Engine Land, pas d'un bulletin officiel Google.
Comparez avec la transparence de la documentation Google sur le rapport de performance : elle explique les métriques, mais ne mentionne nulle part les limitations de fiabilité ou l'existence de bugs historiques.
L'anonymisation croissante
Ce bug s'ajoute à la tendance de fond : Google anonymise de plus en plus de requêtes dans GSC. Sur beaucoup de sites, 30 à 50 % du trafic organique provient de requêtes que GSC ne montre pas. Le rapport de performance n'a jamais été un reflet exact de la réalité — ce bug l'a simplement rendu encore moins fiable.
Comment construire un système de monitoring résilient
La leçon fondamentale n'est pas "Google a un bug". C'est que toute source de données unique est un single point of failure.
Le triangle de vérification
Pour chaque métrique SEO critique, vous devriez avoir au minimum deux sources indépendantes qui se recoupent :
| Métrique | Source primaire | Source de vérification |
|---|---|---|
| Clics organiques | GSC | GA4 / Matomo (sessions organic) |
| Impressions | GSC | Données de positionnement (Semrush/Ahrefs) × volume de recherche |
| Positionnement | GSC | Outil de rank tracking dédié |
| Pages indexées | GSC (rapport de couverture) | site: operator + Screaming Frog crawl |
| Crawl | GSC (rapport d'exploration) | Logs serveur |
Quand les deux sources divergent significativement, c'est un signal d'alerte. Soit votre site a un problème, soit l'une des sources a un bug. Dans les deux cas, vous devez investiguer — et c'est précisément ce type de divergence qu'un outil de monitoring comme Seogard peut détecter automatiquement, en croisant les données de crawl, d'indexation et de performance.
Automatiser la détection d'anomalies
Ne comptez pas sur une vérification manuelle mensuelle. Les anomalies de données doivent déclencher des alertes automatiques. Un script basique de détection d'anomalie sur vos exports GSC quotidiens :
import numpy as np
def detect_anomaly(series, window=28, threshold=2.5):
"""
Détecte les anomalies dans une série temporelle
en utilisant un z-score sur une fenêtre glissante.
threshold=2.5 correspond à environ 1.2% de faux positifs
pour une distribution normale — ajustez selon votre tolérance.
"""
rolling_mean = series.rolling(window=window).mean()
rolling_std = series.rolling(window=window).std()
z_scores = (series - rolling_mean) / rolling_std
return z_scores.abs() > threshold
# Application sur le delta clics GSC vs sessions GA4
merged['is_anomaly'] = detect_anomaly(merged['delta_pct'], window=28, threshold=2.5)
# Alerter si plus de 3 jours consécutifs d'anomalie
consecutive = merged['is_anomaly'].rolling(window=3).sum()
if (consecutive >= 3).any():
# Envoyer une alerte Slack/email
alert_dates = merged[consecutive >= 3]['date'].tolist()
print(f"ALERTE: Anomalie de données détectée sur {alert_dates}")Ce type de détection aurait permis d'identifier le bug GSC en quelques semaines, pas en 50.
Les décisions à réévaluer maintenant
Si vous êtes Lead SEO ou CTO, voici les actions concrètes à mener cette semaine.
1. Identifier les décisions prises entre juin 2025 et avril 2026 basées sur GSC
Passez en revue vos tickets Jira/Linear, vos comptes-rendus de réunion, vos rapports mensuels. Toute décision argumentée par "les données GSC montrent que..." doit être réévaluée.
2. Recalculer vos baselines
Vos baselines de performance (CTR moyen par type de page, impressions par catégorie, position moyenne par cluster de requêtes) sont probablement faussées si elles ont été calculées sur la période du bug. Attendez 4 à 6 semaines de données post-fix pour recalculer des baselines fiables.
3. Auditer les contenus modifiés "en réaction" à des baisses
Si vous avez modifié des pages parce que GSC montrait une baisse de performance, vérifiez via vos logs serveur et GA4 si cette baisse était réelle. Si elle ne l'était pas, le contenu original était peut-être meilleur que la version "optimisée".
4. Communiquer avec vos stakeholders
Si vous avez des rapports mensuels ou trimestriels envoyés à des clients ou au management, préparez une note explicative. Les comparaisons year-over-year pour 2026 vs 2025 seront mécaniquement faussées. Mieux vaut prévenir que devoir expliquer pourquoi "les chiffres n'ont pas de sens" dans 6 mois.
Le précédent et ce qu'il signale
Ce n'est pas la première fois que GSC présente des problèmes de données. En 2019, un bug similaire avait affecté les données de couverture d'index. En 2022, des anomalies de données Discover avaient été signalées. Le pattern est toujours le même : découverte tardive, communication minimale, pas de correction rétroactive.
Ce qui distingue ce bug, c'est sa durée — près d'un an. C'est suffisamment long pour avoir influencé des stratégies SEO annuelles complètes, des budgets, des recrutements, des arbitrages produit.
L'industrie SEO a un problème de dépendance à des données dont elle ne contrôle ni la production, ni la qualité, ni la rétention. Ce bug devrait être un catalyseur pour investir dans des systèmes de monitoring multi-sources qui ne reposent pas sur la fiabilité d'un seul outil. Le fait de s'appuyer excessivement sur un outil unique est un angle mort technique bien documenté — un biais qui affecte même les équipes les plus expérimentées.
Les données post-fix devraient être fiables. Archivez-les dès maintenant, croisez-les avec vos autres sources, et construisez le système de vérification que vous auriez dû avoir depuis un an. La prochaine fois — et il y aura une prochaine fois — vous le saurez en semaines, pas en mois.