Vous collez une adresse dans la barre de recherche en haut de la Google Search Console, vous validez, et quelques secondes plus tard l'outil d'inspection d'URL rend son verdict : « L'URL est sur Google », ou un motif qui explique pourquoi elle n'y est pas. Sous ce verdict s'alignent une douzaine de champs : comment la page a été découverte, quand Googlebot est passé pour la dernière fois, quelle canonique Google a retenue, à quoi ressemble le HTML une fois rendu. C'est le seul endroit où Google vous dit, URL par URL, ce qu'il a réellement fait de votre page. Deux questions se posent alors naturellement. Que signifie chacun de ces champs, et lesquels doivent guider vos décisions ? Et comment faire quand les pages à vérifier se comptent en centaines, puisque l'outil inspecte exactement une URL à la fois ?
À quoi sert l'outil d'inspection d'URL ?
L'outil d'inspection d'URL est une fonction de la Google Search Console qui renvoie les informations d'indexation officielles de Google pour une URL donnée : la page est-elle indexée, pourquoi (ou pourquoi pas), quelle canonique Google a choisie, la date du dernier crawl, et la page telle que Googlebot l'a rendue. Il sert à diagnostiquer, page par page, la façon dont Google voit votre site, et à demander l'indexation d'une URL précise.
On y accède par la barre de recherche présente en haut de tous les écrans de la Search Console, ou en cliquant une URL dans le rapport « Indexation des pages ». Un prérequis conditionne tout le reste : l'URL doit appartenir à la propriété ouverte. Vous inspectez vos propres pages, pas celles d'un concurrent.
Les deux modes : version indexée et test en direct
L'outil répond à deux questions différentes, et les confondre est l'erreur de lecture la plus courante. Par défaut, une inspection décrit l'état de la version indexée : la documentation précise que les résultats proviennent de la dernière version indexée de la page, pas de la version en ligne. Si vous avez corrigé une balise noindex ce matin, la vue par défaut décrit toujours la page telle que Google l'a vue à son dernier passage, donc sans votre correction.
Le test en direct (le bouton « Tester l'URL en ligne ») répond à l'autre question : il récupère la page en temps réel et indique si elle pourrait être indexée telle qu'elle est servie aujourd'hui. Il a ses propres angles morts : il ne vérifie ni la présence de l'URL dans les sitemaps ni les pages référentes, et certains contrôles de la version indexée n'y sont pas exécutés. La règle pratique : la vue par défaut dit ce que Google a fait, le test en direct dit ce qu'il trouverait aujourd'hui. Une correction n'est prouvée que lorsque les deux concordent.
Les deux modes s'enchaînent d'ailleurs en une séquence naturelle après toute correction : déployer, lancer un test en direct pour confirmer que la page est désormais indexable, demander l'indexation (ou attendre le prochain crawl), puis revenir vérifier que la vue par défaut a basculé à son tour. Sauter la première étape revient à demander l'indexation d'une page peut-être encore défaillante ; sauter la dernière revient à se fier à un test en direct positif que l'index n'a pas encore rattrapé.
Les données renvoyées, bloc par bloc
Un résultat d'inspection concentre l'essentiel de sa valeur dans des champs que beaucoup d'utilisateurs ne déroulent jamais. Voici chaque bloc, et ce qu'il faut en faire.
Le verdict : « L'URL est sur Google » (et ce qu'il ne promet pas)
Le verdict de tête indique si l'URL peut apparaître dans les résultats. « L'URL est sur Google » signifie indexée ; cela ne signifie ni visible, ni bien positionnée : une page indexée peut rester au-delà de la cinquième page sur toutes les requêtes. Les verdicts négatifs s'accompagnent toujours d'un motif, et c'est là que le diagnostic commence réellement. Si l'outil indique que l'URL lui est totalement inconnue, vous êtes dans le cas « URL inconnue de Google » : jamais découverte, jamais explorée.
Le statut de couverture : le motif, dans les mots de Google
Sous « Indexation de la page », l'outil nomme l'état exact de l'URL, avec les mêmes libellés que le rapport « Indexation des pages ». Ces états sont le cœur du diagnostic, et chacun des plus fréquents a sa logique et ses correctifs : « Explorée, actuellement non indexée » (lue, puis écartée), « Détectée, actuellement non indexée » (connue, pas encore explorée), « Exclue par la balise noindex », « Bloquée par le fichier robots.txt » et son pendant paradoxal « Indexée malgré le blocage par robots.txt », la famille des doublons (« Page en double sans URL canonique », « Google n'a pas choisi la même URL canonique », « Autre page avec balise canonique correcte »), « Soft 404 » et « Page avec redirection ». D'autres états existent ; ceux-là sont les plus fréquents, et notre répertoire complet des statuts traite chacun en profondeur.
Une grille de lecture utile consiste à se demander vers quelle famille de travail l'état pointe. Certains appellent un travail de configuration : un noindex à lever, une règle robots.txt à retirer, une canonique à corriger. D'autres un travail de contenu : « Explorée, actuellement non indexée » sur une page qui compte, c'est Google qui juge la page, pas vos réglages. D'autres enfin de la patience ou un travail de découverte : « Détectée, actuellement non indexée » sur une page de trois jours est une file d'attente, pas un défaut. Se tromper de famille fait perdre des semaines ; le libellé de l'état est ce qui vous oriente vers la bonne.
Les canoniques : votre déclaration face au choix de Google
Deux champs se répondent : la canonique déclarée par l'utilisateur (ce que votre page revendique) et la canonique sélectionnée par Google (ce qu'il a décidé). Quand elles diffèrent, Google a tranché contre vous, et cette simple comparaison explique la plupart des statuts de doublons. Aucun crawler ne peut fournir le champ de droite : votre code montre la déclaration, seul Google connaît la décision.
Deux réflexes complètent la lecture. Quand Google a choisi une autre canonique, inspectez cette URL dans la foulée : c'est elle qui porte votre contenu dans l'index, et son propre état dit si la consolidation joue en votre faveur. Et une canonique Google absente ou « N/A » signifie le plus souvent que la page n'est pas indexée du tout : il n'y a rien à consolider, et le statut de couverture au-dessus explique pourquoi.
La découverte : sitemaps et page référente
L'outil liste les sitemaps qui déclarent l'URL et une page référente par laquelle Googlebot l'a trouvée. Un bloc découverte vide sur une page importante est un signal d'alerte précoce : si aucun sitemap ni aucun lien connu n'y mène, Google n'a pas de chemin fiable vers la page. C'est aussi ici que l'on vérifie que le sitemap couvre bien les pages qui comptent, un prérequis détaillé dans notre guide pour soumettre son site à Google.
Le crawl : dernière exploration, user-agent, récupération
Dernière exploration date le passage le plus récent de Google : tout ce que montre l'inspection décrit la page à cette date. Exploré avec indique le user-agent venu la lire (mobile ou desktop). Récupération de la page et Exploration autorisée ? disent si le serveur a répondu et si le robots.txt a permis la visite. Une page dont le dernier crawl date de trois mois ne reflétera nulle part la correction de la semaine passée, et une récupération en échec réoriente tout le diagnostic vers le serveur plutôt que vers le contenu.
La page rendue : HTML, capture d'écran, et ce que Google a exécuté
« Afficher la page testée » (ou « Afficher la page explorée ») ouvre la page telle que Googlebot l'a construite : HTML rendu, ressources chargées, messages de la console JavaScript et, en test en direct uniquement, une capture d'écran. C'est la référence pour les sites à fort JavaScript : ce que votre navigateur ou votre crawler affiche est une simulation, cet onglet montre ce que Google lui-même a exécuté, une distinction que notre guide JavaScript et SEO développe. Un contenu absent du HTML rendu est un contenu que Google a indexé sans.
Enrichissements et expérience
Les derniers blocs signalent les données structurées détectées sur la version indexée, ainsi que les signaux HTTPS et d'expérience. Utiles pour déboguer les résultats enrichis ; rarement la raison pour laquelle une page est absente de l'index.
Demander l'indexation : ce que le bouton fait, et ne fait pas
Le bouton « Demander l'indexation » place l'URL dans une file en vue d'un éventuel recrawl. Trois faits de la documentation calibrent ce qu'il faut en attendre. Ce n'est pas immédiat : l'exploration demande environ un jour, parfois plus. Ce n'est pas garanti : demander l'indexation n'assure pas l'apparition dans les résultats. Et c'est rationné : il existe une limite quotidienne de demandes par propriété, sans chiffre officiel ; en pratique, le bouton se verrouille après une douzaine de demandes dans la journée. Au-delà de quelques URLs, le conseil de Google lui-même s'applique : soumettre un sitemap. La méthode complète, et quoi faire quand des pages soumises n'apparaissent toujours pas, sont couvertes dans notre guide de soumission.
Ce que l'outil ne peut pas faire (ses limites structurelles)
Tout ce qui précède décrit un excellent instrument de diagnostic. Ses limites sont tout aussi structurelles, et méritent d'être posées clairement, parce qu'elles définissent le moment où l'outil cesse d'être le bon instrument.
Une URL à la fois. L'entrée est une barre de recherche unique ; il n'existe aucun mode par lot. Vérifier 300 fiches produit, c'est 300 inspections manuelles.
Ni export, ni historique. Un résultat d'inspection ne se télécharge pas, et l'outil ne garde aucune trace des inspections précédentes : le verdict d'hier disparaît dès que vous ré-inspectez. Suivre une correction dans le temps suppose de ré-inspecter à la main et de noter ailleurs.
Le rapport ne se filtre pas sur vos URLs. Le rapport « Indexation des pages » agrège par motif, mais vous ne pouvez pas lui confier votre liste (les pages stratégiques, les URLs d'une migration) et lui demander où en sont celles-là.
Propriétés possédées uniquement. L'URL doit appartenir à une propriété que vous avez validée ; impossible d'inspecter une page d'un site que vous ne contrôlez pas.
Certaines choses ne sont jamais testées. La documentation liste ce que l'outil n'évalue pas : la qualité du contenu, les actions manuelles, les problèmes de sécurité, les retraits légaux et les blocages temporaires relèvent d'autres rapports.
Aucune de ces limites n'est un défaut au regard de l'objectif de l'outil, qui est le contrôle ponctuel d'URLs isolées. Elles deviennent un problème quand la question change : non plus « qu'est-il arrivé à cette page ? », mais « qu'est-il arrivé à toutes mes pages ? ».
💡 Vérifier 300 URLs à la main dans la barre d'inspection occupe une après-midi ; la même liste via l'API officielle tient en une analyse. Découvrir IndexProbe en accès anticipé →
Passer à l'échelle : l'API URL Inspection
Un point dont on parle assez peu, et qu'aucun des guides positionnés sur cette requête ne mentionne : l'outil d'inspection d'URL a une API officielle. L'API URL Inspection renvoie les mêmes blocs de données, sous forme structurée, pour toute URL d'une propriété que vous possédez : le verdict, le statut de couverture (mêmes libellés que l'interface), les canoniques déclarée et sélectionnée, la date et le user-agent du dernier crawl, les états robots.txt et de récupération, les sitemaps et pages référentes connus, plus les détections mobile et résultats enrichis. Autrement dit, tout ce que cet article a décodé jusqu'ici, sous forme de données exploitables plutôt que d'un écran à recopier. Ses limites sont documentées : 2 000 requêtes par jour et par propriété, 600 par minute (« 2000 QPD », « 600 QPM » dans la documentation des limites de Google).
Ce chiffre est le vrai plafond de la donnée d'indexation vérifiée par Google, et trois propriétés de ce quota, que nous avons vérifiées par des tests directs, comptent en pratique. D'abord, le quota se comporte comme une fenêtre glissante de 24 heures, pas comme un compteur remis à zéro à minuit : la capacité se libère progressivement à mesure que les anciennes requêtes sortent de la fenêtre. Ensuite, le quota est attaché à la propriété et partagé entre tous ceux qui l'inspectent : connecter davantage de comptes Google à la même propriété ne multiplie rien. Enfin, une propriété Domaine et des propriétés à préfixe d'URL du même site disposent de quotas indépendants : chaque propriété préfixe validée ajoute 2 000 inspections quotidiennes, une option qui change le calcul pour les grands sites.
Cette API est exactement ce qu'IndexProbe industrialise : vous fournissez votre liste d'URLs, il exécute les inspections officielles au rythme du quota, conserve l'historique, et vous laisse filtrer, segmenter, comparer et exporter : la version en masse de l'outil que cet article décrit. Sur une analyse de plusieurs jours, les pages déjà prouvées indexées (par une impression récente ou une inspection récente concluante) peuvent être reprises au lieu d'être ré-inspectées, ce qui raccourcit les analyses à proportion de la part de la liste déjà prouvée ; une analyse réelle de 3 465 URLs a récemment traité 93 % de sa liste en douze minutes de cette façon. Les limites ne disparaissent pas : le budget de 2 000 inspections quotidiennes est simplement dépensé là où il apporte une information nouvelle.
La boucle complète que cela permet est celle que l'outil manuel ne peut pas offrir : inspecter la liste entière, lire la répartition des statuts, corriger ce qu'ils désignent, puis relancer la même liste et vérifier la bascule. Essayez IndexProbe en accès anticipé pour obtenir les données de l'outil d'inspection d'URL sur toutes vos URLs à la fois.
Questions fréquentes
À quoi sert l'outil d'inspection d'URL ?
Il renvoie les informations d'indexation officielles de Google pour une URL d'une propriété que vous possédez : la page est-elle indexée et pourquoi, quelle canonique Google a retenue, la date du dernier crawl, et la page telle que Googlebot l'a rendue. C'est l'instrument de la Search Console pour diagnostiquer une page précise et en demander l'indexation.
Combien d'URLs peut-on inspecter par jour ?
Dans l'interface de la Search Console, Google applique une limite quotidienne par propriété sans en publier le chiffre. Via l'API officielle URL Inspection, la limite est documentée : 2 000 requêtes par jour et par propriété, 600 par minute. Le bouton « Demander l'indexation » a son propre plafond, bien plus bas.
Quelle différence entre l'inspection par défaut et le test en direct ?
La vue par défaut décrit la dernière version indexée de la page, à la date du dernier crawl ; le test en direct récupère la page en temps réel et dit si elle pourrait être indexée telle quelle. Une correction apparaît immédiatement dans le test en direct, mais seulement après recrawl dans la vue par défaut.
Demander l'indexation garantit-il que la page sera indexée ?
Non. La demande place l'URL dans une file en vue d'un recrawl, qui prend en général un jour environ, et Google précise qu'elle ne garantit pas l'inclusion. Répéter la demande pour la même URL n'accélère rien. Pour de nombreuses URLs, soumettez un sitemap plutôt que de cliquer page par page.
Peut-on inspecter une URL d'un site qu'on ne possède pas ?
Non. L'URL doit appartenir à la propriété ouverte, et les propriétés exigent une validation. Pour évaluer la page d'un tiers, le signal public le plus proche est une recherche site:, approximative et sans motifs.
Existe-t-il un moyen d'utiliser l'outil d'inspection d'URL en masse ?
Pas dans l'interface de la Search Console, qui traite une URL à la fois sans export. La voie officielle est l'API URL Inspection (2 000 requêtes par jour et par propriété), via vos propres scripts ou un outil construit dessus. IndexProbe est cette version en masse : les mêmes verdicts officiels, sur toute votre liste, avec historique et comparaison.