URL Inspection API : elle lit, elle n'indexe pas

Tu balances tes URLs dans l'API URL Inspection de Google Search Console, tu attends, et tu es persuadé que Google va toutes les avaler et les indexer d'un coup. Spoiler alert : non. Elle te dit juste ce que Google pense déjà de tes pages. C'est un moniteur, pas un bouton magique « indexe-moi ça ».

Cette API est sortie le 31 janvier 2022. Depuis, elle traîne une réputation qu'elle ne mérite pas, et je vois encore des gens la traiter comme un accélérateur d'indexation. On va remettre les choses à plat, parce que la confusion coûte du temps et du quota pour rien.

Le point qui fâche, autant le poser tout de suite : l'API URL Inspection est en lecture seule. Elle interroge l'état d'indexation connu de Google pour une URL, elle renvoie un rapport, et c'est fini. Elle ne soumet aucune page pour exploration. Google le dit noir sur blanc dans son annonce de lancement.

C'est un peu comme ouvrir le journal des logs d'un serveur de jeu : tu vois qui s'est connecté, quand, et si le serveur a planté. Consulter le log ne fait pas apparaître de nouveaux joueurs. Là c'est pareil. Tu lis un état, tu ne le modifies pas.

Je suis tombé sur un thread Reddit où un mec s'étonnait que ses pages restaient hors index après quelques centaines d'appels à l'API. Normal : il inspectait en boucle, il ne soumettait rien. Il avait juste construit le plus beau tableau de bord de son échec d'indexation. Si l'indexation coince à la base, va plutôt regarder du côté de la crawlabilité et de l'indexation technique, c'est là que ça se joue.

Bon, si elle n'indexe pas, elle sert à quoi ? À monitorer. Et là, elle est plutôt généreuse. L'objet principal, indexStatusResult, te renvoie de quoi diagnostiquer une page sans ouvrir l'interface :

• verdict : PASS, FAIL ou NEUTRAL, le résumé brut de la situation
• coverageState : l'état de couverture en texte, celui que tu lis d'habitude dans l'interface
• robotsTxtState : ALLOWED ou DISALLOWED, pour savoir si ton robots.txt bloque
• indexingState : INDEXING_ALLOWED, ou bloqué par une balise meta ou un en-tête HTTP
• googleCanonical contre userCanonical : la canonique que Google a retenue face à celle que tu as déclarée
• lastCrawlTime, pageFetchState, crawledAs : quand, comment, et sur quel agent Google a crawlé

Ce couple googleCanonical / userCanonical, c'est de l'or pour un audit à l'échelle. Tu détectes en masse les pages où Google a décidé, tout seul, qu'une autre URL était la bonne. Bonne chance pour repérer ça à la main sur dix mille pages.

L'API remonte aussi un richResultsResult (tes données structurées et leurs erreurs) et un ampResult si tu as encore des pages AMP dans la nature. Franchement, la première fois que j'ai lu la doc complète, j'ai mis un moment à réaliser tout ce qu'on pouvait en tirer côté monitoring pur.

Là où beaucoup se plantent : le fameux plafond de 2 000 requêtes par jour. Sauf que ce chiffre n'est pas un mur absolu sur ton compte. C'est 2 000 requêtes par jour et 600 par minute par propriété vérifiée. Au niveau du projet dans la Google Cloud Console, tu montes à 10 millions de requêtes par jour et 15 000 par minute. Autant dire que le vrai goulot, c'est la propriété, pas le projet.

Et comme chaque appel n'inspecte qu'une seule URL (le champ inspectionUrl est au singulier, pas de traitement par lot natif), tu boucles. Une requête, une URL. Pour scanner un gros site, tu enchaînes les appels en respectant les 600 par minute.

Le contournement que tout le monde utilise : découper ton site en plusieurs propriétés Search Console (sous-domaines, sous-dossiers), chacune avec son propre quota de 2 000 par jour. Screaming Frog, qui intègre l'API pour du monitoring de masse, récupère jusqu'à 2 000 URLs par jour et par propriété sur un crawl. Multiplie les propriétés, multiplie le plafond. C'est bête mais ça marche.

Côté auth, rien d'exotique : OAuth avec le scope webmasters ou webmasters.readonly, une propriété vérifiée, et si tu passes par un compte de service, tu l'ajoutes comme utilisateur dans les paramètres de Search Console. Sans ça, l'API te claque la porte au nez. Pour tout ce qui touche au suivi post-crawl, ça se marie bien avec l'analyse des logs serveur et des crawl stats.

Voilà la vraie source du malentendu. Il existe une deuxième API, l'Indexing API, et elle, elle soumet des URLs pour exploration prioritaire. C'est celle que les gens croient utiliser quand ils appellent URL Inspection.

Sauf que l'Indexing API a deux limites qui refroidissent vite. Son quota par défaut est de 200 requêtes de publication par jour et par projet (180 par minute pour getMetadata, 380 par minute toutes méthodes confondues). Et surtout, Google la réserve aux pages qui embarquent du balisage JobPosting ou du BroadcastEvent dans un VideoObject. Une offre d'emploi, un événement en direct. Ton article de blog ou ta fiche produit ? Hors périmètre.

Donc non, tu ne peux pas « forcer » l'indexation de ton site avec l'une ou l'autre. URL Inspection lit, Indexing API soumet mais seulement pour deux types de contenus très précis. Si tu retiens une chose, c'est celle-là. Pour le reste, ton budget de crawl se travaille à l'ancienne, en soignant ton crawl budget.

Petit piège pour finir. Le champ mobileUsabilityResult existe encore dans le schéma de réponse, mais il est marqué comme déprécié. Google a retiré le rapport Mobile Usability, le Mobile-Friendly Test et son API : annoncé en avril 2023, effectif le 4 décembre 2023.

Le champ est donc un zombie. Il apparaît, il ne raconte plus rien d'utile, et tu perds ton temps si tu construis un monitoring dessus. Ignore-le, comme cette notification que tu ne lis jamais.

L'API URL Inspection, c'est un excellent outil de surveillance : suivi d'indexation après publication, détection de pages désindexées, chasse aux erreurs serveur, audit canonique à grande échelle. Un tableau de bord de l'état de santé de ton site vu par Google.

Ce qu'elle n'est pas : un raccourci vers l'index. Personne ne va te faire indexer plus vite en boucant des appels. Le jour où tu intègres ça, tu arrêtes de gaspiller ton quota et tu commences à en tirer quelque chose. Et si tu veux voir à quoi ressemble une vraie galère GSC, va lire le bug Discover de mai 2026, ça relativise.

• Google for Developers : Usage Limits (Search Console API)
• Google Search Central : Welcoming the new URL Inspection API
• Google for Developers : Method index.inspect
• Google for Developers : UrlInspectionResult
• Google for Developers : Indexing API quota & pricing
• Search Engine Land : Google drops Mobile Usability report and tools
• Screaming Frog : How to automate the URL Inspection API