Inspection d’URL : voir votre page telle que Google la lit

Ce que l’inspection d’URL montre vraiment

L’inspection d’URL compare deux choses : la version de votre page stockée dans l’index Google, et la page telle qu’elle existe aujourd’hui sur votre serveur. La première vue, affichée par défaut, décrit l’état indexé. Elle indique si l’URL figure sur Google, la date et l’heure de la dernière exploration, le robot utilisé (Googlebot smartphone dans la grande majorité des cas), si l’exploration et l’indexation étaient autorisées, et quelle URL Google a retenue comme canonique.

Le point le plus mal compris concerne les deux canoniques. La « canonique déclarée par l’utilisateur » est celle que votre balise link rel=canonical annonce. La « canonique sélectionnée par Google » est celle que le moteur a effectivement choisie, et les deux peuvent différer. La documentation Google sur la consolidation des URL en double rappelle que la balise est un signal fort, pas une consigne obligatoire. Quand Google préfère une autre URL, votre page ne se positionne pas : c’est la version choisie qui apparaît.

Troisième information fournie par l’inspection d’URL : les améliorations détectées. Si la page porte des données structurées, un fil d’Ariane ou une FAQ, la section liste les éléments valides et les erreurs. Pour un article qui vise une citation par les IA, c’est le moyen de vérifier que le JSON-LD a bien été lu dans la version indexée, et pas seulement qu’il existe dans le code source.

Les verdicts de l’inspection d’URL et leur signification

Chaque inspection d’URL renvoie un verdict principal, puis un motif détaillé. Le verdict seul ne suffit pas : « L’URL n’est pas sur Google » couvre des situations très différentes, de la simple page jamais découverte à l’exclusion volontaire par noindex. Le tableau ci-dessous reprend les cas les plus fréquents en PME et l’action à mener pour chacun.

Le motif « Explorée, actuellement non indexée » mérite une attention particulière dans l’inspection d’URL. Il signale que le frein n’est pas technique : la page a été lue et comprise, mais Google a jugé qu’elle n’apportait pas assez pour entrer dans l’index. Demander à nouveau l’indexation ne change rien dans ce cas. La réponse se trouve dans le contenu lui-même et dans la confiance accordée au domaine.

Test en direct : le HTML rendu par Googlebot

Dans l’inspection d’URL, le bouton « Tester l’URL en ligne » demande à Googlebot d’explorer la page immédiatement et affiche le résultat en une à deux minutes. Trois onglets donnent le détail : le HTML rendu après exécution du JavaScript, une capture d’écran de la page telle que le robot l’a affichée, et un onglet « Plus d’infos » avec la réponse HTTP, les ressources de la page et les messages de la console JavaScript. C’est l’équivalent d’un œil posé par-dessus l’épaule de Googlebot.

Google rend les pages avec une version récente de Chromium, dite « evergreen », d’après sa documentation sur les bases du SEO JavaScript. Le rendu peut toutefois être différé : l’exploration a lieu d’abord, l’exécution du JavaScript plus tard, dans une file d’attente. Un contenu injecté par script peut donc arriver dans l’index avec retard, ou ne jamais y arriver si une ressource indispensable est bloquée. La rubrique « Ressources de la page » liste précisément les fichiers que le robot n’a pas pu charger.

La capture d’écran ne doit pas être prise au pied de la lettre. Elle ne montre que la partie visible au chargement, sans défilement, et Google affiche de longue date qu’il ignore les ressources bloquées par robots.txt. Un bandeau de consentement qui recouvre toute la page sur la capture ne signifie pas que le contenu est absent : le HTML rendu fait foi. Lead4you compare systématiquement les deux onglets de l’inspection d’URL plutôt que de conclure sur l’image seule.

Enfin, le test en direct de l’inspection d’URL n’est pas une demande d’indexation. Il vérifie que la page est explorable et indexable à l’instant T, mais n’assure ni son entrée dans l’index ni son positionnement. Le bouton « Demander une indexation » existe à part, avec un quota journalier limité par propriété. L’API URL Inspection, utile pour inspecter des lots de pages, plafonne de son côté à 2 000 requêtes par jour et par propriété selon les limites publiées par Google.

Les écarts fréquents entre votre page et la version lue par Google

Le premier écart observé concerne le code HTML lui-même. Un cache serveur, un CDN ou une extension d’optimisation peut servir à Googlebot une version différente de celle qu’un visiteur connecté reçoit : titre d’une ancienne version, CSS manquant, bloc de contenu replié par défaut. Comparer l’onglet HTML de l’inspection d’URL avec le code source vu dans votre navigateur en navigation privée révèle ces différences en quelques secondes.

Deuxième écart révélé par l’inspection d’URL : la canonique. Sur un site WordPress multilingue, il arrive que la version française d’une page déclare une canonique vers la version anglaise, ou l’inverse, à la suite d’un réglage d’extension. Google suit alors la déclaration et ne positionne qu’une des deux pages. Le même phénomène se produit avec les paramètres d’URL de suivi et les variantes avec ou sans barre oblique finale.

Troisième écart : les directives contradictoires. Une page peut être autorisée par robots.txt mais porter un noindex hérité d’un gabarit, ou l’inverse. La documentation Google sur le blocage de l’indexation précise un piège : si le robots.txt interdit l’exploration d’une page, Googlebot ne voit jamais sa balise noindex, et l’URL peut rester indexée avec un extrait vide. L’inspection d’URL affiche les deux lignes « Exploration autorisée » et « Indexation autorisée » côte à côte, ce qui rend la contradiction immédiatement lisible.

Quatrième écart, plus discret : la taille. La documentation Googlebot indique que le robot n’explore que les 15 premiers Mo d’un fichier HTML. Une page qui embarque un script ou des données inline très volumineux en tête de document peut voir sa fin tronquée. Le cas reste rare sur un site vitrine, mais il se rencontre sur des pages catalogue générées automatiquement.

Méthode de diagnostic en 6 étapes

Cette méthode d’inspection d’URL tient en trente minutes pour une dizaine de pages et distingue les trois familles de causes : exploration, rendu, décision d’indexation. Elle s’applique à une page service comme à un article de blog.

1. Choisir les pages qui comptent. Page d’accueil, pages services, cinq à dix contenus censés générer des leads. Inutile d’inspecter tout le site au départ.
2. Lire le verdict indexé de chaque page dans l’inspection d’URL. Noter le verdict, la date de dernière exploration et la canonique choisie par Google. Une date ancienne de plusieurs mois sur une page modifiée récemment est déjà une information.
3. Lancer le test en direct. Comparer le HTML rendu avec le code source vu en navigation privée. Vérifier le titre, la balise meta description, la canonique et la présence du contenu principal dans le HTML rendu.
4. Ouvrir « Plus d’infos ». Relever le code de réponse HTTP, les ressources non chargées et les erreurs JavaScript. Une feuille de style ou un script bloqué par robots.txt se corrige en une ligne.
5. Croiser avec le rapport « Indexation des pages ». Si le même motif revient sur des dizaines d’URL, le problème est structurel : gabarit, extension, réglage de canonique. S’il touche une page isolée, c’est son contenu ou son maillage.
6. Décider avant de demander l’indexation. Demander une indexation n’a de sens qu’après correction d’un vrai frein. Sur un motif « Explorée, actuellement non indexée », travailler le contenu et les liens entrants vers la page passe avant toute nouvelle demande.

Pour aller au-delà de l’inspection d’URL page par page, le rapport d’indexation et l’analyse des logs serveur complètent l’outil. Notre offre SEO et GEO intègre cette lecture technique dans un audit plus large : couverture sémantique, maillage, citabilité par les moteurs IA.

Bing et moteurs IA : lire la page avec leurs yeux

Google n’est plus le seul lecteur de votre page. Bing Webmaster Tools propose sa propre inspection d’URL, avec un verdict d’indexation, les erreurs SEO détectées et le balisage lu. Un site indexé par Bing mais ignoré par Google, ou l’inverse, apprend quelque chose sur la nature du frein : technique si les deux échouent, lié à la confiance si un seul des deux indexe.

Les robots des moteurs IA fonctionnent autrement. GPTBot et OAI-SearchBot chez OpenAI, PerplexityBot chez Perplexity et ClaudeBot chez Anthropic sont documentés par leurs éditeurs, avec les chaînes d’identification et les règles robots.txt qu’ils respectent. En revanche, aucune de ces documentations n’indique qu’ils exécutent le JavaScript comme Googlebot le fait. La prudence impose donc une règle simple : le contenu que vous voulez voir cité, en particulier le bloc de réponse directe et la FAQ, doit figurer dans le HTML initial, sans dépendre d’un script. L’onglet HTML de l’inspection d’URL, lu avant rendu via le code source brut, sert ici de référence : si le texte n’y est pas, un robot IA ne le verra probablement pas.

Cette lecture à trois lecteurs, Google, Bing et robots IA, résume l’approche GEO de Lead4you : une page extractible pour tous, sans version spécifique par moteur. Le dynamic rendering, que Google présente aujourd’hui comme une solution de contournement et non comme une recommandation durable, n’a pas sa place dans cette approche.

Checklist rapide

• L’inspection d’URL de vos dix pages clés a été lue : verdict connu et daté.
• La canonique choisie par Google correspond à la canonique déclarée sur chaque page stratégique.
• Le HTML rendu contient le titre, la meta description et le contenu principal attendus.
• Aucune ressource CSS ou JavaScript indispensable n’est bloquée par robots.txt.
• Les lignes « Exploration autorisée » et « Indexation autorisée » sont toutes deux positives sur les pages à indexer.
• Les données structurées apparaissent dans les améliorations détectées sans erreur.
• Le bloc de réponse directe et la FAQ sont présents dans le code source brut, sans JavaScript.
• Le même contrôle a été fait dans Bing Webmaster Tools.