Le 13 mai 2025, un bug de logging côté Google a commencé à gonfler artificiellement les compteurs d'impressions dans Search Console. Pendant près d'un an, des dizaines de milliers de sites ont vu leurs rapports de performance afficher des chiffres d'impressions supérieurs à la réalité — sans que le trafic réel ne suive. Google a confirmé le problème et annoncé un correctif progressif. Si vous avez fondé des décisions stratégiques sur ces données entre mai 2025 et aujourd'hui, il est temps de revoir vos analyses.
Ce qu'on sait du bug : anatomie d'une erreur de logging
Le bug est documenté dans le Data anomalies in Search Console de Google. Il ne s'agit pas d'un problème d'indexation ou de crawl, mais d'une erreur dans le pipeline de collecte des données de performance — le système qui enregistre quand une URL apparaît dans les résultats de recherche.
Impressions vs. clics : pourquoi seules les impressions sont touchées
Une impression dans Search Console est comptabilisée quand un lien vers votre site est rendu dans les résultats, que l'utilisateur scrolle jusqu'à le voir ou non (pour les résultats web classiques ; les règles diffèrent pour les images ou Discover). Le clic, lui, nécessite une action explicite de l'utilisateur — un événement distinct dans le pipeline de données.
Le bug a affecté le compteur d'impressions parce qu'il se situe en amont dans la chaîne : c'est un log côté serveur Google qui enregistre "cette URL a été incluse dans la SERP pour cette requête". Une duplication dans ce logging — par exemple, un même affichage de SERP loggé deux fois à cause d'un retry ou d'un batch mal dédupliqué — gonfle les impressions sans affecter les clics.
Le résultat observable : une chute artificielle du CTR sur les rapports de performance, puisque le dénominateur (impressions) était surévalué.
Chronologie et scope
- 13 mai 2025 : début de l'anomalie dans les données.
- Mars 2026 : premiers signalements publics de la communauté SEO. Des rapports sur X et des forums spécialisés mentionnent des hausses d'impressions inexpliquées sans corrélation avec le trafic Analytics.
- Avril 2026 : Google confirme le bug et annonce un correctif progressif. Les données historiques seront corrigées rétroactivement dans les semaines suivantes.
Cela représente potentiellement 11 mois de données d'impressions biaisées. Pour tout site qui utilise Search Console comme source de vérité pour le reporting SEO — ce qui est le cas de la majorité — c'est un problème structurel.
Quantifier l'impact : un scénario concret
Prenons un cas réaliste : un site e-commerce de 12 000 pages produits positionné sur des requêtes longue traîne dans le secteur de l'ameublement.
Avant le bug (avril 2025)
| Métrique | Valeur |
|---|---|
| Impressions mensuelles | 2,4 millions |
| Clics mensuels | 96 000 |
| CTR moyen | 4,0% |
| Pages avec impressions > 0 | 8 200 |
Pendant le bug (janvier 2026)
| Métrique | Valeur |
|---|---|
| Impressions mensuelles | 3,1 millions |
| Clics mensuels | 98 000 |
| CTR moyen | 3,16% |
| Pages avec impressions > 0 | 9 400 |
L'équipe SEO observe une hausse de 29% des impressions avec un trafic quasi stable. Deux interprétations possibles à ce moment-là :
- Google affiche plus le site mais les snippets ne convertissent pas → il faut optimiser les titles et meta descriptions.
- Les données sont fausses.
Sans connaissance du bug, la plupart des équipes choisissent l'interprétation 1. Résultat : des semaines de travail sur l'optimisation des snippets pour un problème qui n'existe pas. Pire, certaines équipes revoient leur stratégie de contenu en concluant que de nouvelles pages "gagnent en visibilité" alors qu'il s'agit d'impressions fantômes.
C'est exactement le type de régression silencieuse qui consomme des ressources sans produire de résultat — parce que le problème est dans la mesure, pas dans le site.
Détecter l'anomalie dans vos propres données
La question immédiate : vos données sont-elles affectées, et à quel degré ? Voici comment le vérifier systématiquement.
Extraction via l'API Search Console
L'interface web de Search Console ne permet pas d'exporter facilement des séries temporelles longues avec la granularité nécessaire. Passez par l'API. Voici un script Python qui extrait les impressions et clics quotidiens sur une période donnée et calcule le taux de variation par rapport à une baseline pré-bug :
#!/usr/bin/env python3
"""
Détection d'anomalies d'impressions Search Console.
Compare la période post-bug (2025-05-13 à aujourd'hui)
avec une baseline pré-bug (3 mois avant).
"""
from google.oauth2 import service_account
from googleapiclient.discovery import build
import pandas as pd
from datetime import datetime, timedelta
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'service-account-key.json'
SITE_URL = 'sc-domain:votredomaine.fr' # Propriété de domaine
# Périodes de comparaison
BASELINE_START = '2025-02-13'
BASELINE_END = '2025-05-12'
BUG_START = '2025-05-13'
BUG_END = '2026-03-31'
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE, scopes=SCOPES
)
service = build('searchconsole', 'v1', credentials=credentials)
def fetch_daily_data(start_date: str, end_date: str) -> pd.DataFrame:
"""Récupère impressions et clics quotidiens."""
rows = []
request_body = {
'startDate': start_date,
'endDate': end_date,
'dimensions': ['date'],
'rowLimit': 25000,
'dataState': 'all'
}
response = service.searchanalytics().query(
siteUrl=SITE_URL, body=request_body
).execute()
for row in response.get('rows', []):
rows.append({
'date': row['keys'][0],
'clicks': row['clicks'],
'impressions': row['impressions'],
'ctr': row['ctr'],
'position': row['position']
})
return pd.DataFrame(rows)
baseline_df = fetch_daily_data(BASELINE_START, BASELINE_END)
bug_df = fetch_daily_data(BUG_START, BUG_END)
# Calcul des moyennes quotidiennes
baseline_avg_impressions = baseline_df['impressions'].mean()
baseline_avg_clicks = baseline_df['clicks'].mean()
baseline_avg_ctr = baseline_df['ctr'].mean()
bug_avg_impressions = bug_df['impressions'].mean()
bug_avg_clicks = bug_df['clicks'].mean()
bug_avg_ctr = bug_df['ctr'].mean()
impression_delta = ((bug_avg_impressions - baseline_avg_impressions)
/ baseline_avg_impressions) * 100
click_delta = ((bug_avg_clicks - baseline_avg_clicks)
/ baseline_avg_clicks) * 100
print(f"Baseline impressions/jour : {baseline_avg_impressions:,.0f}")
print(f"Post-bug impressions/jour : {bug_avg_impressions:,.0f}")
print(f"Delta impressions : {impression_delta:+.1f}%")
print(f"")
print(f"Baseline clics/jour : {baseline_avg_clicks:,.0f}")
print(f"Post-bug clics/jour : {bug_avg_clicks:,.0f}")
print(f"Delta clics : {click_delta:+.1f}%")
print(f"")
print(f"Baseline CTR : {baseline_avg_ctr:.2%}")
print(f"Post-bug CTR : {bug_avg_ctr:.2%}")
# Flag si les impressions augmentent significativement
# sans que les clics suivent
if impression_delta > 15 and abs(click_delta) < 5:
print("\n⚠ ANOMALIE DÉTECTÉE : hausse d'impressions "
"sans corrélation clics. Probable impact du bug GSC.")Le signal clé : une hausse significative d'impressions (>15%) avec des clics stables ou en légère progression. Si les deux métriques évoluent dans des proportions similaires, l'augmentation est probablement organique.
Croisement avec les logs serveur
Les données Search Console sont déclaratives (côté Google). Vos logs serveur sont factuels (côté vous). En croisant les deux, vous pouvez confirmer la divergence.
# Extraction du nombre de visites organiques Google par jour
# depuis les access logs Nginx (format combined)
# Filtre sur le referer Google et exclut les bots
awk -F'"' '
/google\.(com|fr|de|co\.uk)/ && !/Googlebot|AdsBot/ {
split($1, a, " ")
split(a[4], d, ":")
gsub(/\[/, "", d[1])
dates[d[1]]++
}
END {
for (date in dates)
print date, dates[date]
}
' /var/log/nginx/access.log.* | sort -k1 > google_organic_visits.tsv
# Comparaison rapide avec les clics GSC exportés
paste google_organic_visits.tsv gsc_clicks_export.tsv | \
awk '{
diff = ($2 - $4) / $4 * 100;
printf "%s\tLogs: %d\tGSC: %d\tDelta: %.1f%%\n", $1, $2, $4, diff
}'Un delta constant entre logs serveur et clics GSC confirme que les clics GSC restent fiables. C'est bien les impressions qui sont le problème.
Cette approche de validation croisée est exactement ce que recommande un monitoring continu : ne jamais se fier à une seule source de données.
Les effets en cascade sur vos workflows SEO
Le problème ne se limite pas à des chiffres faux dans un rapport. Les impressions Search Console alimentent des dizaines de workflows en production.
Priorisation des optimisations on-page
La matrice classique CTR vs. position — où vous identifiez les requêtes à fort potentiel (bonne position, CTR faible) — est directement corrompue. Avec des impressions gonflées, le CTR calculé est mécaniquement plus bas. Des requêtes parfaitement performantes apparaissent comme sous-optimisées.
Si vous avez utilisé cette matrice entre mai 2025 et maintenant pour prioriser des refontes de titles ou de meta descriptions, relancez l'analyse après la correction des données.
Reporting client et KPIs
Pour les agences et les consultants, les impressions sont un KPI de reporting standard. Une hausse de 25% des impressions, même sans clics supplémentaires, peut être présentée comme un signal positif ("la visibilité augmente, les clics suivront"). Ce narratif est faux si les impressions sont gonflées.
Recommandation pragmatique : ajoutez une note dans tous les rapports couvrant la période mai 2025 – correction confirmée, indiquant que les données d'impressions GSC sont suspectes et seront révisées.
Modèles de forecasting
Si votre modèle de prévision de trafic utilise les impressions GSC comme variable d'entrée — ce qui est courant dans les modèles de type clicks = impressions × CTR_modélisé — vos projections pour 2026 sont biaisées. Le modèle a appris un niveau d'impressions artificiellement élevé.
Après la correction, re-entraînez vos modèles sur les données corrigées. En attendant, basez vos forecasts sur les clics uniquement.
Automatiser la détection de ce type d'anomalie
Ce bug illustre un problème plus large : comment détecter une dérive dans des données tierces que vous ne contrôlez pas ?
Monitoring des ratios plutôt que des absolus
Les valeurs absolues d'impressions peuvent varier pour mille raisons légitimes (saisonnalité, nouveau contenu, core update). Ce qui trahit une anomalie de données, c'est la rupture dans les ratios.
Le ratio clics/impressions (CTR) est normalement stable à position constante. Si la position moyenne ne bouge pas, que les clics sont stables, mais que le CTR chute — c'est un signal fort d'anomalie côté impressions.
Voici un check automatisable en TypeScript qui interroge l'API GSC et alerte quand le CTR dévie de plus de 2 écarts-types par rapport à la moyenne glissante :
// ctr-anomaly-detector.ts
// À exécuter en cron quotidien via GitHub Actions ou un scheduler
import { google } from 'googleapis';
interface DailyMetrics {
date: string;
impressions: number;
clicks: number;
ctr: number;
position: number;
}
async function fetchMetrics(
auth: any,
siteUrl: string,
startDate: string,
endDate: string
): Promise<DailyMetrics[]> {
const searchconsole = google.searchconsole({ version: 'v1', auth });
const response = await searchconsole.searchanalytics.query({
siteUrl,
requestBody: {
startDate,
endDate,
dimensions: ['date'],
rowLimit: 25000,
},
});
return (response.data.rows || []).map((row) => ({
date: row.keys![0],
impressions: row.impressions!,
clicks: row.clicks!,
ctr: row.ctr!,
position: row.position!,
}));
}
function detectCtrAnomaly(
metrics: DailyMetrics[],
windowSize: number = 30,
threshold: number = 2.0
): { date: string; ctr: number; expected: number; zScore: number }[] {
const anomalies: {
date: string; ctr: number; expected: number; zScore: number;
}[] = [];
for (let i = windowSize; i < metrics.length; i++) {
const window = metrics.slice(i - windowSize, i);
const mean = window.reduce((s, m) => s + m.ctr, 0) / windowSize;
const stdDev = Math.sqrt(
window.reduce((s, m) => s + Math.pow(m.ctr - mean, 2), 0) / windowSize
);
if (stdDev === 0) continue;
const current = metrics[i];
const zScore = (current.ctr - mean) / stdDev;
// On cherche spécifiquement une chute du CTR (z-score négatif)
// combinée à une position stable
const avgPosition =
window.reduce((s, m) => s + m.position, 0) / windowSize;
const positionDrift = Math.abs(current.position - avgPosition);
if (zScore < -threshold && positionDrift < 1.0) {
anomalies.push({
date: current.date,
ctr: current.ctr,
expected: mean,
zScore,
});
}
}
return anomalies;
}
// Usage
async function main() {
const auth = new google.auth.GoogleAuth({
keyFile: 'service-account-key.json',
scopes: ['https://www.googleapis.com/auth/webmasters.readonly'],
});
const metrics = await fetchMetrics(
await auth.getClient(),
'sc-domain:votredomaine.fr',
'2025-01-01',
'2026-03-31'
);
const anomalies = detectCtrAnomaly(metrics);
if (anomalies.length > 0) {
console.error(`🔴 ${anomalies.length} anomalies CTR détectées :`);
anomalies.forEach((a) => {
console.error(
` ${a.date}: CTR=${(a.ctr * 100).toFixed(2)}% ` +
`(attendu: ${(a.expected * 100).toFixed(2)}%, z=${a.zScore.toFixed(2)})`
);
});
process.exit(1); // Fail pour déclencher une alerte
} else {
console.log('✅ Pas d\'anomalie CTR détectée.');
}
}
main();Ce type de détection aurait signalé le problème dès la troisième semaine de mai 2025 — soit 10 mois avant la confirmation officielle de Google.
Un outil comme Seogard, qui monitore les métriques SEO en continu et détecte les écarts statistiquement significatifs, permet d'automatiser ce type de surveillance sans maintenir des scripts maison. Le principe reste le même : surveiller les ratios, pas les absolus.
Intégration dans un pipeline CI/CD
Pour les équipes qui ont déjà des checks SEO dans leur CI/CD, ajoutez un job scheduled (pas déclenché au deploy, mais en cron) qui exécute ce type de vérification :
# .github/workflows/gsc-anomaly-check.yml
name: GSC Anomaly Detection
on:
schedule:
- cron: '0 8 * * 1' # Tous les lundis à 8h UTC
workflow_dispatch:
jobs:
check-ctr-anomalies:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- name: Run CTR anomaly detection
env:
GOOGLE_SERVICE_ACCOUNT_KEY: ${{ secrets.GSC_SERVICE_ACCOUNT_KEY }}
run: npx tsx scripts/ctr-anomaly-detector.ts
- name: Notify on failure
if: failure()
uses: slackapi/[email protected]
with:
payload: |
{
"text": "⚠️ Anomalie CTR détectée dans Search Console. Vérifiez les données d'impressions."
}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}Ce que ce bug révèle sur la fiabilité des données Google
Search Console n'est pas une source de vérité absolue
Ce n'est pas la première anomalie de données dans Search Console. Google maintient une liste des anomalies connues qui documente des incidents récurrents — certains ayant duré plusieurs mois avant correction.
Les données Search Console sont un échantillon traité de ce que Google observe, pas un reflet exhaustif et exact de la réalité. Les impressions en particulier dépendent de définitions complexes (qu'est-ce qu'une "impression" pour un résultat en position 8 sur mobile ? pour un carrousel d'images ? pour un résultat Discover ?). La documentation officielle Google sur les impressions détaille ces nuances.
La redondance des sources de données n'est pas optionnelle
Si votre stack de reporting SEO repose à 100% sur l'API Search Console, vous avez un single point of failure sur la fiabilité des données. Croisez systématiquement avec :
- Logs serveur : le referer Google dans vos access logs donne le volume réel de visites organiques. Pas les impressions, mais les clics — ce qui permet de valider la cohérence.
- Google Analytics / solution analytics côté client : pour une deuxième mesure du trafic entrant.
- Outils de suivi de position tiers (Semrush, Ahrefs, etc.) : si votre position moyenne GSC reste stable mais que le CTR chute, c'est un signal d'anomalie côté impressions.
Ce principe de triangulation est particulièrement critique quand vous interprétez les effets d'une core update : il faut distinguer une variation réelle de performance d'un artefact de mesure.
L'impact sur les rapports GSC sous-exploités
Le rapport Discover, le rapport Google News, le rapport sur les performances vidéo — ces rapports souvent ignorés de Search Console utilisent le même pipeline de logging. Il est probable que le bug les ait également affectés, même si Google n'a pas explicitement confirmé le scope exact.
Vérifiez vos données Discover avec la même méthodologie : si les impressions Discover ont bondi en mai 2025 sans que vos analytics ne confirment une hausse de trafic Discover, le bug est probablement en cause.
Actions concrètes : que faire maintenant
Court terme (cette semaine)
- Identifiez l'amplitude du problème sur votre site avec le script Python ci-dessus ou via l'export manuel de GSC (Performance → Export → Google Sheets).
- Documentez l'anomalie dans votre outil de reporting. Ajoutez une annotation sur la date du 13 mai 2025 dans Google Analytics et dans tout dashboard qui affiche des données GSC.
- Gelez les décisions basées sur le CTR calculé à partir des données GSC sur la période affectée. Ne lancez pas de chantier d'optimisation de snippets basé sur un CTR artificiellement bas.
Moyen terme (après le correctif Google)
- Re-téléchargez les données corrigées via l'API une fois le rollout du fix confirmé. Comparez avec vos exports pré-correction pour quantifier l'écart exact sur votre site.
- Recalibrez vos modèles de forecasting si vous utilisez les impressions comme variable d'entrée.
- Auditez les décisions prises entre mai 2025 et la correction. Y a-t-il des chantiers lancés sur la base de données fausses ?
Long terme (process)
- Mettez en place un monitoring automatisé des ratios GSC (CTR à position constante, ratio impressions/clics). Le script TypeScript ci-dessus est un point de départ.
- Diversifiez vos sources de données : ne faites jamais reposer un KPI stratégique sur une seule source, surtout une source que vous ne contrôlez pas.
Ce bug est un rappel brutal : les données tierces peuvent mentir silencieusement pendant des mois. Un déploiement un vendredi soir peut casser votre SEO et vous le saurez vite. Un bug de logging côté Google peut biaiser votre stratégie pendant un an — et vous ne le saurez que quand Google décidera de le communiquer.
La seule défense durable, c'est la surveillance continue multi-sources, avec des alertes sur les écarts statistiques — pas sur les valeurs absolues. C'est exactement ce que des outils comme Seogard automatisent : détecter la dérive avant qu'elle ne devienne une erreur stratégique.