API vs Interface Google Search Console : pourquoi les données ne correspondent pas ?

Vous avez déjà remarqué que les chiffres ne correspondent pas entre l'interface web de la Google Search Console, l'export CSV et les données récupérées via l'API ? Vous n'êtes pas seul. C'est l'une des confusions les plus fréquentes en SEO.

Dans cet article, nous expliquons précisément d'où viennent ces écarts, pourquoi Google les considère comme normaux, et comment obtenir les données les plus complètes possibles.

Tableau récapitulatif : Interface vs Export CSV vs API vs BigQuery

Source : Google Search Central – Deep dive into performance data

Le problème n°1 : les requêtes anonymisées (46% des clics !)

C'est la cause principale des écarts entre l'API et l'interface. Google masque certaines requêtes pour des raisons de confidentialité : celles saisies par un trop petit nombre d'utilisateurs ou contenant des informations personnelles.

Combien de données sont cachées ?

Beaucoup plus qu'on ne le pense. Selon une étude Ahrefs de 2022 portant sur 146 741 sites web et environ 9 milliards de clics :

• 46,08% de tous les clics proviennent de requêtes anonymisées
• La fourchette la plus courante est de 45 à 80% de requêtes cachées selon les sites
• Avant cette étude, Google qualifiait ces requêtes de « très rares ». Après sa publication, Google a modifié sa documentation pour dire « certaines requêtes »

Source : Ahrefs – Almost Half of GSC Clicks Go to Anonymous Queries

L'impact varie selon la taille du site

Une étude de SEOGets sur 9 sites montre des résultats frappants :

Source : SEOGets – What Are Anonymous Queries

Concrètement : si votre site est petit, vous ne voyez peut-être que 20% de vos requêtes réelles. C'est une limitation majeure dont peu de professionnels SEO sont conscients.

Où sont incluses les requêtes anonymisées ?

• Interface web (graphiques du haut) : ✓ incluses dans les totaux, sauf si vous appliquez un filtre de requête
• Interface web (tableau) : ✗ jamais affichées en lignes individuelles
• Export CSV : ✗ exclues (l'export correspond au tableau)
• API : ✗ exclues des résultats retournés
• BigQuery Bulk Export : ✓ incluses avec la valeur NULL dans le champ requête

C'est pourquoi la somme des lignes de l'API sera toujours inférieure aux totaux affichés dans les graphiques de l'interface.

La limite de lignes : 1 000 vs 25 000 vs 50 000

La deuxième cause d'écart majeure est la troncature des données :

• Interface web et export CSV : limités à 1 000 lignes. Si votre site a 5 000 requêtes positionnées, vous n'en voyez que 20%
• API : jusqu'à 25 000 lignes par requête (paramètre rowLimit). Avec pagination (startRow), vous pouvez atteindre 50 000 lignes par jour par propriété et par type de recherche
• BigQuery : aucune limite. Toutes les données sont exportées

Attention : si vous ne spécifiez pas le paramètre rowLimit dans l'API, la valeur par défaut est 1 000 lignes (comme l'interface). Il faut explicitement demander plus.

Pour les gros sites, même la limite de 50 000 lignes de l'API peut être insuffisante. Une étude de Similar.ai a montré que les sites e-commerce avec une architecture profonde peuvent perdre jusqu'à 90% de leurs mots-clés et 66-67% de leurs impressions à cause de cette troncature.

Source : Similar.ai – Closing the Google Search Console Sampling Gap

L'agrégation : byProperty vs byPage

C'est l'une des sources de confusion les plus sous-estimées. Google propose deux modes d'agrégation qui comptent les impressions différemment :

Mode byProperty (par défaut)

Si votre site affiche 3 pages dans les résultats pour une même requête, cela compte comme 1 seule impression pour la propriété. Les clics et la position sont reportés pour l'URL la mieux classée uniquement.

Mode byPage

Chaque URL qui apparaît dans les résultats obtient sa propre impression. Si 3 pages apparaissent pour une requête, cela compte 3 impressions.

Quand le mode bascule

• Interface sans filtre page : mode byProperty (par défaut)
• Interface avec filtre ou dimension page : bascule automatiquement en byPage
• API sans dimension page : byProperty (défaut), modifiable via aggregationType
• API avec dimension page : forcé en byPage, même si vous demandez byProperty

Résultat : les totaux en mode byPage sont presque toujours plus élevés que les totaux en mode byProperty. Si vous comparez des données API (avec dimension page) aux totaux de l'interface (sans filtre page), les chiffres ne correspondront pas.

Source : Google – How Search Console counts impressions, position, and clicks

Les Bloom Filters : pourquoi Google perd des données

En septembre 2023, Gary Illyes (Google Search Relations) a confirmé que Google utilise en interne des Bloom Filters – des structures de données probabilistes – pour basculer rapidement entre les vues par propriété et par page.

Le problème : les Bloom Filters sacrifient un peu de précision pour gagner en vitesse. Cela signifie qu'à chaque basculement de mode d'agrégation, une petite quantité de données peut être perdue. Ce n'est pas un bug, c'est un compromis technique assumé par Google.

Sources : Search Engine Journal – Google's Use of Bloom Filters, Search Engine Roundtable

La fraîcheur des données

Autre source d'écarts possibles : les données ne sont pas disponibles en temps réel.

Si vous comparez les données de l'interface (qui affiche les données fraîches par défaut) avec celles de l'API (qui utilise dataState=final par défaut), les jours récents ne correspondront pas.

Google précise : « Chaque point de donnée fraîche sera remplacé par le point de donnée final après quelques jours. »

Source : Google – Fresher data in Search Performance report

Précision des positions et du CTR

La position : une moyenne pondérée trompeuse

L'API renvoie la position sous forme décimale (ex : 3.7142857), alors que l'interface l'arrondit. Mais le vrai piège est ailleurs :

• La « position moyenne » est une moyenne pondérée par les impressions, pas une moyenne simple. Un mot-clé avec 1 000 impressions en position 2 pèse bien plus qu'un mot-clé avec 5 impressions en position 8
• Seule la position la plus haute de votre site est enregistrée pour chaque requête. Si vos pages apparaissent en positions 2, 5 et 9, seule la position 2 est comptabilisée
• Un mot-clé qui alterne entre position 3 et position 30 (cannibalisation) affichera une moyenne de ~16, masquant complètement le problème

Le CTR : attention à l'agrégation

L'API renvoie le CTR comme un décimal (ex : 0.0423 = 4,23%). L'erreur courante est de moyenner les CTR individuels au lieu de faire le calcul correct :

CTR agrégé = total des clics ÷ total des impressions

Si vous faites la moyenne des CTR ligne par ligne, vous obtiendrez un résultat différent de l'interface, qui utilise la moyenne pondérée.

Source : Search Engine Journal – How Accurate is the Average Position Metric

Ce que l'API offre en plus de l'interface

L'API n'est pas qu'une version programmatique de l'interface. Elle offre des fonctionnalités exclusives :

• Filtres regex (includingRegex, excludingRegex) : impossible dans l'interface
• Données horaires : jusqu'à 10 jours de granularité horaire (l'interface ne montre que 24h)
• Contrôle de l'agrégation : choix explicite entre byProperty et byPage
• 25 000 lignes par requête (vs 1 000 dans l'interface)
• Contrôle de la fraîcheur : choix entre données provisoires (dataState=all) et définitives (dataState=final)
• Types de recherche spécifiques : Discover, Google News, images, vidéos en plus de la recherche web

Source : Google – Search Analytics API query method

Ce que Google dit officiellement

En octobre 2022, Google a publié un article détaillé (Deep dive into performance data) qui clarifie la situation :

Impact pratique : quand ces différences comptent

Pour le reporting client

Si vous présentez les données API à un client qui regarde l'interface, les totaux ne correspondront pas. Soyez transparent : expliquez que l'API ne reflète pas les requêtes anonymisées. Présentez toujours la même source de période en période pour que les comparaisons soient fiables.

Pour la détection de tendances

Les écarts absolus ne sont pas graves si vous utilisez toujours la même méthode de récupération. L'important est de comparer des données obtenues de la même façon. Un outil comme SEO Pilote utilise systématiquement l'API GSC avec les mêmes paramètres, ce qui garantit la cohérence des comparaisons d'un import à l'autre.

Pour l'analyse de mots-clés

Avec l'API, vous récupérez 25× plus de mots-clés que via l'interface (25 000 vs 1 000). Cela fait une différence énorme pour la découverte de mots-clés de longue traîne et la détection de cannibalisation.

Questions fréquentes