Pourquoi l'API Search Console ne renvoie-t-elle pas les mêmes données que l'interface web ?

L'API et l'interface utilisent-elles vraiment le même backend ?

Oui. John Mueller le confirme sans ambiguïté : l'API Search Console et l'interface web interrogent exactement la même source de données. Aucun traitement différencié, aucune latence spécifique, aucun filtre appliqué côté API.

Cette clarification met fin à une croyance persistante chez certains praticiens : l'idée que l'API fournirait des données « brutes » tandis que l'interface appliquerait des filtres ou des agrégations. C'est faux. Les deux accès pointent vers le même système backend, avec les mêmes règles d'échantillonnage et les mêmes limitations.

D'où viennent les différences de données constatées ?

Le problème surgit presque toujours au niveau de la vérification du domaine. Search Console distingue strictement HTTP et HTTPS, www et non-www — chaque combinaison constitue une propriété distincte.

Imaginons : vous vérifiez votre propriété en HTTP sans www dans l'interface, mais votre script API interroge la version HTTPS avec www. Résultat : zéro donnée retournée par l'API, alors que l'interface affiche des métriques. Ce n'est pas un bug — vous interrogez simplement deux propriétés différentes.

Quelle différence entre propriété de domaine et propriété d'URL ?

Search Console propose deux types de propriétés : propriété de domaine (couvre toutes les variations HTTP/HTTPS, www/non-www, sous-domaines) et propriété d'URL préfixe (une seule version précise). La propriété de domaine nécessite une vérification DNS.

Si vous utilisez une propriété d'URL préfixe, vous devez interroger l'API avec exactement le même préfixe que celui vérifié. Un seul caractère de différence — un slash final, un s manquant — et l'API ne renverra rien. Avec une propriété de domaine, ce problème disparaît, mais la vérification initiale est plus contraignante.

• L'API et l'interface web partagent le même backend — aucune différence technique entre les deux systèmes.
• Les écarts de données proviennent de différences dans la vérification du domaine : HTTP vs HTTPS, www vs non-www.
• Une propriété de domaine agrège toutes les variations ; une propriété d'URL préfixe ne couvre qu'une seule version précise.
• Vérifiez toujours que votre script API interroge exactement la même propriété que celle affichée dans l'interface.
• Un seul caractère de différence dans l'URL peut faire échouer l'appel API sans message d'erreur explicite.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Totalement. Les praticiens qui ont creusé cette question confirment : les écarts API/interface proviennent presque toujours d'une erreur de configuration, pas d'une divergence technique. J'ai moi-même debuggé des dizaines de scripts qui interrogeaient la mauvaise propriété — et dans 100% des cas, corriger l'URL de la propriété résolvait le problème.

Ce qui reste flou, c'est le délai de propagation entre la vérification d'une nouvelle propriété et sa disponibilité via API. Certains praticiens rapportent des latences de plusieurs heures, d'autres aucun délai. Google ne documente pas ce point — [À vérifier] si vous déployez des automatisations critiques.

Quelles nuances faut-il apporter à cette affirmation ?

La déclaration de Mueller est correcte, mais elle passe sous silence les limitations d'échantillonnage. Search Console n'affiche pas toutes vos requêtes — seulement un échantillon représentatif. Cette limitation s'applique aussi bien à l'interface qu'à l'API, mais elle devient plus visible quand on agrège des données via script.

Autre point : les permissions IAM et les quotas d'API peuvent créer des écarts perçus. Si votre compte de service n'a pas les droits appropriés sur la propriété, l'API retournera une erreur 403 — que certains scripts interprètent comme « pas de données ». Ce n'est pas un problème backend, c'est un problème d'authentification.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous observez des données dans l'interface mais zéro résultat via API après avoir vérifié la propriété, deux scénarios possibles : soit vous interrogez une plage de dates antérieure à la vérification de la propriété, soit vous avez atteint les limites d'échantillonnage pour des dimensions très granulaires.

Attention aussi aux propriétés désactivées ou supprimées. L'interface peut conserver des données en cache pendant quelques jours après la suppression d'une propriété, alors que l'API retournera une erreur immédiatement. Ce n'est pas documenté, mais observé empiriquement — [À vérifier] dans vos propres audits.

Que faut-il faire concrètement pour éviter les écarts API/interface ?

D'abord, listez toutes vos propriétés vérifiées dans Search Console. Notez exactement leur préfixe : HTTP ou HTTPS, www ou non-www, slash final ou non. Ensuite, vérifiez que votre script API interroge exactement la même chaîne de caractères.

Si vous utilisez plusieurs variations de domaine (HTTP redirige vers HTTPS, non-www redirige vers www), préférez une propriété de domaine. Elle nécessite une vérification DNS, mais élimine 90% des erreurs de configuration côté API. C'est un investissement initial qui vous évitera des heures de debug.

Quelles erreurs éviter lors de l'interrogation de l'API ?

Ne jamais supposer que l'URL canonique de votre site correspond à la propriété vérifiée dans Search Console. Ce sont deux concepts distincts. Votre site peut canoniser vers HTTPS avec www, mais si vous avez vérifié uniquement HTTP sans www, l'API ne renverra rien.

Autre piège : les permissions de compte de service. Si vous utilisez OAuth pour authentifier vos appels API, assurez-vous que le compte dispose des droits « Propriétaire » ou « Utilisateur avec accès total » sur la propriété. Un accès « Utilisateur avec accès restreint » ne suffit pas pour certains endpoints.

Comment vérifier que mon script interroge la bonne propriété ?

Utilisez l'endpoint searchanalytics.query avec une plage de dates courte (dernières 7 jours) et aucune dimension — juste les totaux. Si cet appel retourne zéro ligne alors que l'interface affiche des données pour la même période, vous interrogez la mauvaise propriété.

Pour diagnostiquer précisément, listez toutes vos propriétés via l'endpoint sites.list. Comparez les URLs retournées avec celles affichées dans l'interface. Elles doivent correspondre caractère pour caractère, slash final inclus. Si une discordance apparaît, c'est là que se cache votre bug.

• Vérifier que l'URL de propriété utilisée dans l'API correspond exactement à celle de l'interface (HTTP/HTTPS, www, slash final)
• Privilégier une propriété de domaine (vérification DNS) pour couvrir toutes les variations d'URL
• Tester l'appel API avec une plage de dates courte et aucune dimension pour isoler les erreurs de configuration
• Utiliser sites.list pour comparer les propriétés disponibles via API avec celles de l'interface
• Vérifier les permissions du compte de service : droits « Propriétaire » ou « Utilisateur avec accès total » requis
• Documenter les quotas d'API (1 200 requêtes/minute) et implémenter un rate limiting dans vos scripts