Bug Search Console : impressions gonflées depuis mai 2025

Vos impressions Search Console ont bondi de 20 à 40 % à partir de mi-mai 2025, sans déploiement, sans nouveau contenu, sans core update. Vous n'avez pas rêvé : Google a confirmé un bug de logging qui sur-comptait les impressions dans le rapport Performance depuis le 13 mai 2025. La correction est en cours de déploiement, et les données historiques vont être rétroactivement ajustées.

Ce qui semble anodin — un simple bug de comptage — a des conséquences techniques profondes sur la fiabilité de toute chaîne d'analyse SEO qui s'appuie sur l'API Search Console. Décortiquons le problème, mesurons l'impact réel, et construisons les outils pour ne plus jamais piloter à l'aveugle.

Ce que Google a cassé : anatomie d'un bug de logging

Le 13 mai 2025, un changement dans le pipeline de logging côté Google a introduit un double-comptage (voire un triple-comptage dans certains cas) des impressions pour les résultats de recherche standards. Le bug ne concernait ni les clics, ni la position moyenne, ni les données Discover ou Google News — uniquement le champ impressions du rapport Performance pour la recherche web classique.

Pourquoi un bug de logging est si insidieux

Contrairement à un bug d'affichage dans l'interface GSC, un bug de logging corrompt les données à la source. Toute requête à l'API Search Console, tout export CSV, tout dashboard Looker Studio, tout script d'extraction automatisé a ingéré des données fausses pendant des mois. Les systèmes en aval — alertes de baisse/hausse, rapports clients, modèles de prédiction — sont tous contaminés.

Le problème est aggravé par le fait que Google n'a communiqué officiellement qu'après que la communauté SEO ait identifié l'anomalie par recoupement. Entre le 13 mai et la confirmation publique, les équipes SEO ont perdu du temps à chercher des explications rationnelles à des hausses d'impressions inexplicables : impact d'un core update ? Changement d'indexation ? Nouveau format SERP ?

Ce qui n'est PAS touché

Point crucial pour éviter la panique : les métriques suivantes ne sont pas affectées selon la communication de Google :

Clics : le comptage des clics reste fiable sur toute la période.
Position moyenne : non impactée par le bug de logging.
CTR : mécaniquement impacté (car CTR = clics / impressions), mais par dérivation, pas par un bug propre.
Données Discover et Google News : pipelines de logging séparés.

La conséquence directe : votre CTR a artificiellement chuté sur la période concernée. Si vous avez déclenché des alertes sur des baisses de CTR depuis mai 2025, c'est probablement un artefact du bug, pas un signal de dégradation réelle de vos snippets.

Quantifier l'impact : scénario concret sur un e-commerce

Prenons un cas réaliste : un e-commerce de meubles avec 12 000 pages produits, 800 pages catégories et 200 pages de contenu éditorial. Avant le bug, le site enregistrait environ 2,4 millions d'impressions par semaine dans GSC.

Avant / après le 13 mai 2025

Métrique	Avant (semaine du 5 mai)	Pendant le bug (semaine du 19 mai)	Écart
Impressions	2 400 000	3 360 000	+40 %
Clics	72 000	73 500	+2 % (variation naturelle)
CTR moyen	3,0 %	2,19 %	-27 %
Position moyenne	18,4	18,2	Stable

Le Lead SEO voit une hausse massive d'impressions et une chute de CTR. Sans contexte sur le bug, deux interprétations plausibles mais fausses émergent :

"Google nous positionne sur de nouvelles requêtes à fort volume mais faible intent" — le réflexe serait d'auditer les nouvelles requêtes apparues, ce qui est une perte de temps.
"Nos snippets se sont dégradés" — le réflexe serait de retravailler les meta descriptions, voire de lancer des tests A/B de titles inutiles.

Dans les deux cas, l'équipe optimise un fantôme.

L'impact sur les rapports clients

Si vous êtes en agence et que vous avez envoyé des rapports mensuels entre juin et décembre 2025 montrant +30 % d'impressions, vous avez un problème de crédibilité rétroactif. Quand les données corrigées atterriront dans GSC, la courbe va brutalement redescendre. Préparez la communication client maintenant, pas quand ils verront le creux dans leur dashboard.

Détecter l'anomalie dans vos données : scripts d'audit

Ne comptez pas uniquement sur Google pour corriger rétroactivement. Vous devez être capable d'identifier quelles requêtes et quelles pages ont été le plus touchées pour recalibrer vos analyses.

Extraction des données via l'API Search Console

Voici un script Python qui extrait les impressions jour par jour et identifie les ruptures statistiques autour du 13 mai 2025 :

import datetime
from googleapiclient.discovery import build
from google.oauth2 import service_account
import pandas as pd
import numpy as np

SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'service-account-key.json'
SITE_URL = 'sc-domain:votresite.fr'

credentials = service_account.Credentials.from_service_account_file(
    SERVICE_ACCOUNT_FILE, scopes=SCOPES
)
service = build('searchconsole', 'v1', credentials=credentials)

def fetch_daily_impressions(start_date: str, end_date: str) -> pd.DataFrame:
    """Récupère les impressions quotidiennes agrégées."""
    request = {
        'startDate': start_date,
        'endDate': end_date,
        'dimensions': ['date'],
        'rowLimit': 25000,
        'type': 'web'
    }
    response = service.searchanalytics().query(
        siteUrl=SITE_URL, body=request
    ).execute()

    rows = response.get('rows', [])
    data = [{
        'date': row['keys'][0],
        'clicks': row['clicks'],
        'impressions': row['impressions'],
        'ctr': row['ctr'],
        'position': row['position']
    } for row in rows]

    return pd.DataFrame(data)

# Période d'analyse : 2 mois avant + 2 mois après le bug
df = fetch_daily_impressions('2025-03-13', '2025-07-13')
df['date'] = pd.to_datetime(df['date'])

# Calcul de la moyenne mobile 7 jours
df['impressions_ma7'] = df['impressions'].rolling(window=7).mean()

# Détection du saut : ratio avant/après le 13 mai
before = df[df['date'] < '2025-05-13']['impressions'].mean()
after = df[(df['date'] >= '2025-05-13') & (df['date'] < '2025-06-13')]['impressions'].mean()
inflation_ratio = (after - before) / before * 100

print(f"Impressions moyennes avant le 13 mai : {before:,.0f}")
print(f"Impressions moyennes après le 13 mai : {after:,.0f}")
print(f"Inflation estimée : {inflation_ratio:.1f}%")

# Export pour analyse dans Looker Studio ou Sheets
df.to_csv('gsc_impressions_audit.csv', index=False)

Ce script vous donne un inflation_ratio qui quantifie l'ampleur du bug sur votre site spécifique. Si vous obtenez +25 à +45 %, vous êtes dans la fourchette typiquement rapportée. En dessous de +10 %, votre site a probablement été moins touché (certains segments de requêtes semblent plus affectés que d'autres).

Identifier les requêtes les plus impactées

Le bug n'a pas gonflé toutes les requêtes de manière uniforme. Les requêtes à fort volume d'impressions et faible CTR semblent avoir été davantage touchées. Pour isoler les requêtes suspectes :

def fetch_query_comparison(period_before: tuple, period_after: tuple) -> pd.DataFrame:
    """Compare les impressions par requête entre deux périodes."""
    def get_queries(start, end):
        request = {
            'startDate': start,
            'endDate': end,
            'dimensions': ['query'],
            'rowLimit': 5000,
            'type': 'web'
        }
        response = service.searchanalytics().query(
            siteUrl=SITE_URL, body=request
        ).execute()
        return pd.DataFrame([{
            'query': r['keys'][0],
            'impressions': r['impressions'],
            'clicks': r['clicks']
        } for r in response.get('rows', [])])

    df_before = get_queries(*period_before)
    df_after = get_queries(*period_after)

    merged = df_before.merge(
        df_after, on='query', suffixes=('_before', '_after')
    )
    merged['impression_delta_pct'] = (
        (merged['impressions_after'] - merged['impressions_before'])
        / merged['impressions_before'] * 100
    )
    # Filtre : requêtes avec au moins 100 impressions avant
    # et une hausse > 30% sans hausse proportionnelle de clics
    merged['click_delta_pct'] = (
        (merged['clicks_after'] - merged['clicks_before'])
        / merged['clicks_before'].replace(0, 1) * 100
    )
    suspicious = merged[
        (merged['impressions_before'] >= 100) &
        (merged['impression_delta_pct'] > 30) &
        (merged['click_delta_pct'] < 10)
    ].sort_values('impression_delta_pct', ascending=False)

    return suspicious

suspects = fetch_query_comparison(
    ('2025-04-13', '2025-05-12'),
    ('2025-05-13', '2025-06-12')
)
print(f"{len(suspects)} requêtes suspectes identifiées")
suspects.head(20).to_csv('suspicious_queries.csv', index=False)

Le critère clé : une hausse d'impressions > 30 % sans hausse de clics proportionnelle. Ces requêtes sont quasi certainement victimes du bug de logging, pas d'un gain de visibilité réel.

Corriger vos dashboards et rapports historiques

La correction rétroactive de Google va modifier les données historiques. Vos exports CSV réalisés pendant la période bugguée ne seront pas mis à jour automatiquement. Si vous avez archivé des données, vous devez les ré-extraire après le déploiement complet du fix.

Annotations dans Looker Studio

Ajoutez immédiatement une annotation dans vos dashboards pour signaler la période de données non fiables. Looker Studio ne propose pas d'annotations natives comme Google Analytics, mais vous pouvez contourner avec une source de données d'annotations :

-- Table BigQuery ou Google Sheets servant de source d'annotations
-- À joindre à vos données GSC dans Looker Studio via un blend

SELECT '2025-05-13' AS annotation_date,
       'Début bug GSC impressions (logging error)' AS label,
       'warning' AS severity
UNION ALL
SELECT '2026-03-28' AS annotation_date,  -- date approximative du fix
       'Correction bug GSC impressions déployée' AS label,
       'info' AS severity

Intégrez cette table comme source secondaire dans votre rapport Looker Studio. Utilisez un graphique en barres ou une ligne de référence pour matérialiser visuellement la zone contaminée. Vos clients ou votre direction comprendront instantanément pourquoi la courbe plonge quand le fix sera en place.

Recalculer le CTR réel

Puisque les clics sont fiables, vous pouvez estimer le CTR corrigé en appliquant le ratio d'inflation calculé précédemment :

# Si votre inflation_ratio est de 38%, le facteur de correction est :
correction_factor = 1 / (1 + 38 / 100)  # ≈ 0.7246

# Application sur les données de la période bugguée
df_buggy = df[df['date'] >= '2025-05-13'].copy()
df_buggy['impressions_corrected'] = (
    df_buggy['impressions'] * correction_factor
).astype(int)
df_buggy['ctr_corrected'] = df_buggy['clicks'] / df_buggy['impressions_corrected']

print(df_buggy[['date', 'impressions', 'impressions_corrected',
                  'ctr', 'ctr_corrected']].head(10))

C'est une approximation — le facteur de correction varie par requête et par jour. Mais c'est suffisant pour ne pas prendre de décisions stratégiques basées sur un CTR fantôme.

Les leçons structurelles : pourquoi ne jamais dépendre d'une seule source de données

Ce bug met en lumière un problème de fond que les équipes SEO matures connaissent mais que beaucoup sous-estiment : Google Search Console est une source de données déclarative, échantillonnée et opaque. Ce n'est pas la première fois que les données GSC sont erronées, et ce ne sera pas la dernière.

Les précédents

Mars 2019 : bug de sous-comptage des impressions pendant plusieurs jours, confirmé par John Mueller.
Décembre 2020 : anomalies sur les données Discover avec des pics artificiels.
Août 2022 : problème de latence sur les données de performance, avec des retards de 5 à 7 jours au lieu des 2-3 habituels.

Le pattern est toujours le même : Google détecte (ou la communauté remonte), Google confirme, Google corrige, les données historiques sont ajustées. Pendant la fenêtre d'incertitude, vous pilotez à l'aveugle.

La stratégie de triangulation

Les équipes SEO résilientes croisent systématiquement au moins trois sources de données :

Google Search Console (impressions, clics, position) — la vision de Google sur votre visibilité organique.
Analytics server-side (Google Analytics 4, Matomo, ou logs serveur bruts) — la vérité terrain du trafic réel.
Outils de suivi de positions tiers (SEMrush, Ahrefs, Sistrix) — une mesure indépendante de votre visibilité SERP.

Quand GSC montre +40 % d'impressions mais que GA4 montre un trafic organique stable et que vos positions Sistrix n'ont pas bougé, le diagnostic est clair : c'est GSC qui ment, pas la réalité qui a changé.

C'est exactement le type de divergence qu'un système de monitoring automatisé détecte. Un outil comme Seogard, qui surveille en continu les métriques techniques et les compare à des baselines, aurait levé une alerte sur l'incohérence entre stabilité du crawl/indexation et explosion des impressions déclarées.

Monitoring des logs comme source de vérité

Pour les sites à fort volume, les logs serveur restent la source de données la plus fiable car vous les contrôlez de bout en bout. Voici une commande rapide pour compter les visites Googlebot réelles et les comparer aux impressions GSC :

# Comptage des hits Googlebot uniques par jour sur les 30 derniers jours
# Adaptez le chemin et le format de log à votre configuration

zcat /var/log/nginx/access.log.*.gz | \
  grep -i "googlebot" | \
  awk '{print $4}' | \
  cut -d: -f1 | \
  tr -d '[' | \
  sort | uniq -c | sort -rn | head -30

# Pour un comptage plus fin par URL crawlée :
zcat /var/log/nginx/access.log.*.gz | \
  grep -i "googlebot" | \
  grep "GET" | \
  awk '{print $4, $7}' | \
  cut -d: -f1 | \
  tr -d '[' | \
  sort | uniq -c | sort -rn > googlebot_crawl_daily.txt

Si Googlebot crawle le même volume de pages avant et après le 13 mai 2025, et que vos positions sont stables, la hausse d'impressions GSC est confirmée comme artefact. Ce recoupement prend 5 minutes et vous épargne des semaines de fausse analyse.

Impact sur vos workflows d'alerte et d'automatisation

Le bug a une implication directe sur tout workflow automatisé qui consomme l'API GSC. Si vous avez des alertes Slack/email qui se déclenchent sur des seuils d'impressions, elles ont probablement été silencieuses (pas d'alerte de baisse) ou ont généré de fausses alertes positives.

Repenser les seuils d'alerte

Les alertes basées sur des valeurs absolues d'impressions sont fragiles face à ce type de bug. Une approche plus robuste consiste à alerter sur le ratio clics/impressions combiné à la position :

# Pseudo-code d'alerte robuste
# Au lieu de : "alerte si impressions chutent de > 20%"
# Préférer : "alerte si clics chutent de > 15% ET position stable"

def should_alert(current: dict, baseline: dict) -> bool:
    """
    Alerte uniquement quand les clics (fiables) baissent
    significativement sans changement de position.
    Les impressions sont exclues comme signal primaire.
    """
    click_delta = (current['clicks'] - baseline['clicks']) / baseline['clicks']
    position_delta = abs(current['position'] - baseline['position'])

    # Baisse de clics significative avec position stable
    if click_delta < -0.15 and position_delta < 2.0:
        return True

    # Dégradation de position significative
    if current['position'] - baseline['position'] > 3.0:
        return True

    return False

Cette approche est résiliente aux bugs de comptage d'impressions parce qu'elle s'appuie sur les clics (non affectés par le bug de mai 2025) et sur la position (calculée indépendamment). Les impressions restent utiles en tant que signal complémentaire, mais elles ne doivent jamais être le déclencheur unique d'une alerte.

Versionner vos extractions de données

Si vous n'archivez pas déjà vos extractions GSC dans un data warehouse (BigQuery, Snowflake, PostgreSQL), ce bug est un argument définitif pour commencer. Quand Google corrigera les données historiques, vous perdrez la trace du "avant correction" si vous n'avez que l'interface GSC ou l'API live. Archiver les données brutes vous permet de :

Comparer les données pré-correction et post-correction pour quantifier l'impact exact.
Recalculer vos KPIs historiques avec les données corrigées.
Démontrer à un client que la baisse apparente est un artefact, pas une régression réelle.

La question du crawl budget et de l'indexation

Un point rarement évoqué dans les analyses de ce bug : les impressions GSC ne sont pas un proxy fiable pour le crawl budget ou l'état d'indexation. Le bug le prouve une fois de plus.

Si vous utilisiez les impressions comme indicateur indirect d'indexation ("cette page a des impressions, donc elle est indexée et servie"), le signal était déjà approximatif — et il était en plus faussé depuis mai 2025.

Pour monitorer l'indexation réelle de vos pages, les sources fiables restent :

Le rapport Indexation des pages de GSC (non affecté par ce bug).
L'API d'inspection d'URL pour vérifier le statut page par page.
Le monitoring de vos URLs critiques via des requêtes site: automatisées (avec les limites de précision connues de cet opérateur).

Sur le sujet de l'indexation et des problèmes de rendering côté Google, les sites en SPA ou avec un SSR mal configuré sont particulièrement vulnérables. Un hydration mismatch peut faire que Google indexe une version différente de celle que vous voyez dans votre navigateur — et les impressions GSC ne vous diront rien sur ce type de problème. De même, si vous hésitez entre SSR et CSR pour votre architecture, gardez en tête que la fiabilité des données GSC n'est pas un facteur dans ce choix : les deux architectures sont également exposées aux bugs de logging côté Google.

Que faire maintenant : checklist actionable

Cette semaine :

Exécutez le script d'audit pour quantifier votre inflation_ratio spécifique.
Ajoutez une annotation dans tous vos dashboards signalant la période du 13 mai 2025 au déploiement du fix.
Communiquez proactivement à vos clients/direction : "les données d'impressions GSC sont erronées depuis mai 2025, Google corrige, nos clics et positions réels n'ont pas été affectés."

Dans les deux prochaines semaines :

Re-extrayez vos données historiques via l'API après confirmation du déploiement complet du fix.
Comparez avec vos archives pré-correction pour valider la cohérence.
Recalculez vos KPIs CTR et vos benchmarks internes.

En continu :

Basculez vos alertes automatisées sur des signaux multi-sources (clics + position) plutôt que sur les impressions seules.
Archivez systématiquement vos extractions GSC dans un data warehouse.
Croisez toujours GSC avec au moins une source indépendante avant de prendre une décision d'optimisation.

Ce type de bug est un rappel brutal : les données Google ne sont pas des données terrain. Elles sont le reflet de ce que Google choisit de vous montrer, filtré par des pipelines de logging qui peuvent — et qui vont — casser. Un monitoring continu multi-sources, comme celui que propose Seogard pour les métriques techniques, reste le seul moyen de distinguer un signal réel d'un artefact de mesure.