Tout spécialiste du SEO connaît l'interface de la Search Console : on tape une URL dans la barre d'inspection, ou on exporte un rapport de performances, une propriété à la fois. L'API Search Console promet de lever ce plafond : les mêmes données officielles, pour des milliers d'URLs, sur tous les sites qu'on gère, au rythme qu'on choisit.
La difficulté n'est pas d'obtenir les données. C'est ce que Google en accorde par jour, et la façon dont cette limite se comporte dès qu'on dépasse une seule propriété. Combien d'URLs peut-on réellement inspecter avant que Google ne freine ? Le quota se compte-t-il par compte ou par site ? Et pourquoi un script qui tourne bien pour une propriété s'effondre-t-il sur vingt ? C'est là que l'API cesse d'être un simple tuyau pour devenir un problème d'ingénierie.
Ce que l'API Search Console vous donne vraiment
L'API Search Console est la porte programmatique vers les mêmes données officielles que l'interface de la Google Search Console affiche : vos performances de recherche et les verdicts d'indexation de Google, renvoyés sous forme de données structurées plutôt qu'à l'écran. Elle permet de récupérer ces données en volume, sur chacune de vos propriétés vérifiées, selon un calendrier que vous maîtrisez, sans jamais scraper une page de résultats. Son usage est gratuit, plafonné par un quota et non facturé.
C'est ce dernier point qui fait toute sa valeur pour le travail SEO. L'interface répond à une question à la fois : une URL dans la barre d'inspection, un rapport ouvert pour une propriété. L'API répond aux mêmes questions pour une liste, un site entier, ou un portefeuille de clients. Tout ce qui suit porte sur ce qu'on peut lui demander, ce que cela coûte en quota, et le moment où gérer ce quota soi-même devient le vrai travail.
Les deux API que les SEO utilisent vraiment : Search Analytics et URL Inspection
Ce qu'on appelle « l'API Search Console » est en réalité une famille de méthodes, et deux d'entre elles concentrent presque toute la valeur au quotidien. Les confondre, ou n'en couvrir qu'une seule, est la lacune la plus fréquente des guides positionnés sur le sujet.
L'API Search Analytics renvoie vos données de performance : clics, impressions, taux de clics et position moyenne, ventilés par requête, page, pays, appareil et date. Elle va bien au-delà des limites d'export de l'interface, ce qui en fait la colonne vertébrale de la plupart des chaînes de reporting et d'analyse SEO. Elle répond aux questions sur la façon dont vous vous positionnez déjà.
L'API URL Inspection répond à une tout autre question : comment Google indexe une URL donnée, maintenant. Pour n'importe quelle URL d'une propriété que vous possédez, elle renvoie le verdict (« URL is on Google » ou non), le statut de couverture dans les termes mêmes de Google (« Explorée, actuellement non indexée », « Détectée, actuellement non indexée », « Exclue par la balise noindex », et les autres), la canonique que vous déclarez à côté de celle que Google a retenue, la date et le user agent du dernier crawl, les statuts robots.txt et de récupération, la présence d'un noindex en balise meta ou en en-tête HTTP, ainsi que les sitemaps et les pages référentes que Google associe à l'URL. C'est la version exploitable par une machine de l'outil d'inspection, que nous décodons champ par champ dans notre guide complet de l'outil d'inspection d'URL.
Deux autres méthodes complètent la famille : l'API Sitemaps (soumettre, supprimer et lire le statut de vos sitemaps) et l'API Sites (ajouter, retirer et lister vos propriétés). Utiles pour l'automatisation, mais c'est avec les deux précédentes que se prennent les décisions SEO. Le moyen le plus simple de ne pas les confondre : Search Analytics parle de performance, URL Inspection parle d'indexation, et seule la seconde porte les statuts de couverture de notre répertoire complet des statuts d'indexation de la Search Console.
La mécanique des quotas que personne n'explique
C'est ici que les guides se taisent. Google documente le chiffre d'affiche, 2 000 inspections d'URL par jour et par propriété, et 600 par minute, puis s'arrête là. Le chiffre est facile à trouver ; la façon dont il se comporte ne l'est pas, et mal le comprendre, c'est gaspiller une journée de quota. Quatre propriétés de ce quota, vérifiées par nos propres tests, décident de ce qu'on peut réellement faire.
D'abord, le quota journalier est une fenêtre glissante de 24 heures, pas une remise à zéro à minuit. La capacité ne réapparaît pas d'un coup au changement de date ; elle se libère progressivement, à mesure que chaque requête franchit la barre des 24 heures. Une analyse bloquée à la limite à 15 heures n'attend pas minuit pour reprendre : elle repart peu à peu, quand les requêtes du matin expirent.
Ensuite, le quota est attaché à la propriété et partagé par tous les comptes qui l'inspectent. Ce n'est pas une allocation par utilisateur. Deux personnes, ou deux outils, qui inspectent la même propriété puisent dans les mêmes 2 000, et connecter davantage de comptes Google à cette propriété ne multiplie rien. Deux analyses lancées en parallèle sur le même site se privent l'une l'autre, en silence.
Par ailleurs, une propriété de domaine et les propriétés à préfixe d'URL du même site disposent de quotas indépendants. Une propriété à préfixe vérifiée obtient ses propres 2 000 inspections quotidiennes : découper un gros site entre une propriété de domaine et N propriétés à préfixe porte le plafond à environ (N+1) × 2 000 par jour. Ce levier est connu des utilisateurs avancés, mais rarement posé comme un calcul, et il a son propre coût de gestion, sur lequel les sections suivantes reviennent.
Enfin, l'API Search Analytics fonctionne sur un quota distinct de celui d'URL Inspection. Récupérer des données de performance n'entame pas votre budget d'inspection, et l'inverse est vrai aussi. Ce sont deux robinets sur deux compteurs.
Une réserve honnête traverse tout cela : rien de tout ceci ne fait disparaître le plafond. On peut dépenser le quota plus intelligemment, le répartir entre propriétés, éviter de le gâcher sur des pages déjà confirmées, mais les gains sont proportionnels à la part de la liste déjà réglée. Il n'y a ni illimité, ni instantané.
💡 Sur un seul site de quelques milliers d'URLs, le quota journalier étale déjà une inspection complète sur plusieurs jours. Sur un portefeuille de sites clients, il devient un problème d'ordonnancement. Voyez comment notre vérificateur d'indexation Google en masse s'en charge →
Ce qu'on peut en construire (sans écrire de scraper)
Dès qu'on sait lire les données d'indexation par programme, une série de tâches devient possible, que l'interface ne sait tout simplement pas faire à l'échelle, et dont aucune ne consiste à scraper Google.
On peut mener un audit d'indexation en masse : passer toute sa liste d'URLs par la méthode d'inspection et lire la distribution des statuts de couverture, au lieu de vérifier les pages une à une. On peut suivre la fraîcheur du crawl en surveillant la date du dernier passage de Googlebot sur l'ensemble du site, ce qui révèle où le crawl a vieilli et pourquoi un correctif peut rester invisible. On peut faire de la détection de régression : réinspecter la même liste à intervalle régulier et repérer les pages sorties de l'index entre deux passages, souvent le premier signal qu'une chose a cassé. Et on peut réconcilier performance et indexation, en croisant les données Search Analytics avec les résultats d'inspection pour distinguer « ne se positionne pas » de « n'est pas indexée », la distinction au cœur de notre guide sur les raisons pour lesquelles un site n'apparaît pas sur Google.
Pour un petit site inspecté une fois, un court script fait tout cela. L'ennui, c'est que l'indexation n'est pas une question qu'on pose une seule fois, et que peu de sites sont petits.
Quand le faire à la main cesse de tenir
Un script local qui inspecte 2 000 URLs d'une propriété, une fois, est un problème résolu, et les tutoriels développeur positionnés sur le sujet le résolvent bien. Les ennuis commencent dès que le travail ressemble à du vrai travail SEO.
Sur un gros site de plusieurs dizaines de milliers d'URLs, 2 000 inspections par jour signifient qu'une seule passe complète prend des jours. Le script doit alors conserver son état entre deux exécutions, reprendre à l'intérieur de la fenêtre glissante à mesure que la capacité se libère plutôt que de tirer à l'aveugle et de brûler du quota en rejets, et, pour valoir la peine d'être lancé, sauter les URLs déjà confirmées indexées afin que le budget aille aux pages qui vous apprennent encore quelque chose. Cette seule étape de filtrage suppose de garder une trace de ce que chaque URL a renvoyé la fois précédente.
C'est encore plus dur en agence. Gérer plusieurs sites clients, volumineux ou non, c'est autant de propriétés, chacune avec son quota, sa propre autorisation OAuth, son propre calendrier. Tirer davantage de capacité d'un gros client en le découpant en propriétés à préfixe, comme la section sur les quotas l'a montré, multiplie le quota et le nombre de budgets distincts qu'il faut désormais orchestrer. Garder un historique par client pour montrer ce qui a changé d'un mois à l'autre suppose une base de données, pas un tableur. Ce qui commençait en cinquante lignes de script est devenu une petite infrastructure : un ordonnanceur qui respecte une fenêtre glissante, un stock de résultats passés, une règle de déduplication, et un modèle multi-propriétés, multi-clients par-dessus.
C'est tout le propos de l'article, et c'est là qu'un outil trouve sa place. IndexProbe, c'est cette orchestration construite une fois pour toutes, sur l'API officielle : vous apportez votre liste d'URLs, il lance les inspections au rythme du quota le long de la fenêtre glissante, reprend les pages déjà prouvées indexées au lieu de les réinspecter, et conserve chaque résultat pour que vous puissiez filtrer, segmenter, comparer les analyses et exporter, sur plusieurs propriétés et plusieurs clients au même endroit. Il ne lève pas le plafond de Google, rien ne le peut, mais il dépense le budget de 2 000 par jour seulement là où il apporte une information nouvelle, et il absorbe l'ordonnancement, la déduplication et la comptabilité multi-propriétés qu'un script maison laisse sur votre bureau.
Essayez IndexProbe en accès anticipé pour transformer l'API Search Console en audit d'indexation sur toutes vos URLs, et tous vos sites, d'un coup.
Questions fréquentes
Combien d'URLs puis-je inspecter par jour avec l'API ?
L'API URL Inspection est documentée à 2 000 requêtes par jour et par propriété, et 600 par minute. En pratique, l'allocation quotidienne se comporte comme une fenêtre glissante de 24 heures plutôt que comme une remise à zéro à minuit : la capacité se libère progressivement, pas d'un seul coup.
Le quota est-il par compte Google ou par site ?
Par propriété, et partagé par tous les comptes qui l'inspectent. Connecter davantage de comptes Google à la même propriété n'ajoute pas de quota. Ce qui en ajoute, c'est de vérifier des propriétés à préfixe d'URL du même site, puisque chaque propriété vérifiée porte ses propres 2 000 par jour, indépendants.
Search Analytics et URL Inspection, est-ce la même API ?
Ce sont deux méthodes de la même API Search Console, avec des quotas distincts et des rôles opposés. Search Analytics renvoie vos données de performance (clics, impressions, position) ; URL Inspection renvoie le verdict d'indexation et le statut de couverture de Google pour une URL donnée. La plupart des chantiers SEO utilisent les deux, pour des questions différentes.
Faut-il savoir coder pour l'utiliser ?
Pour appeler l'API directement, oui : c'est une interface pour développeurs, qu'on interroge avec un langage comme Python ou Node et un compte Google autorisé. Si vous voulez les mêmes données officielles sans écrire ni maintenir de script, un outil bâti sur l'API vous en donne les résultats, l'historique et la gestion multi-propriétés sans le code.
Pourquoi ne pas simplement lancer un script local ?
Pour une propriété inspectée une fois, un script suffit. Il cesse de tenir quand une passe complète prend des jours (conserver l'état, reprendre dans la fenêtre glissante, sauter les URLs déjà indexées) ou quand vous gérez plusieurs propriétés ou clients à la fois, chacun avec son quota et son historique. À ce stade, vous maintenez une infrastructure, plus un script.
L'API permet-elle de vérifier des sites que je ne possède pas ?
Non. Comme l'interface, chaque méthode exige une propriété vérifiée. L'API industrialise le travail sur les sites que vous contrôlez ; elle n'ouvre pas l'accès aux données Search Console de quelqu'un d'autre.