Voir son site comme Googlebot : comment voir ce que Google voit

Un propriétaire d’entreprise refait la page d’accueil de son site, et elle a fière allure dans tous les navigateurs qu’il essaie.

Quelques semaines plus tard, elle disparaît discrètement des résultats de Google.

Il l’ouvre dans l’outil d’inspection d’URL de Search Console et obtient une capture d’écran avec des espaces vides à la place du texte et des photos.

Rien ne cloche sur la page dans un navigateur. Quelque chose ne va pas dans ce que Google a vu lorsqu’il a tenté de la lire.

Cet écart entre ce que vous voyez et ce qu’un moteur de recherche voit est fréquent, et il passe généralement inaperçu tant qu’on ne le cherche pas. Voici comment voir votre site comme Googlebot, avec des outils qui ne demandent aucune connaissance en programmation, et ce qu’il faut repérer une fois que vous y êtes.

Pourquoi Googlebot ne voit pas votre site comme vous le voyez

Votre navigateur et Googlebot partent tous deux de la même URL, mais ils n’aboutissent pas toujours à la même page.

Deux étapes distinctes : l’exploration et le rendu Googlebot

La documentation de Google sur JavaScript et le référencement décrit cela en deux étapes distinctes. D’abord, Googlebot explore une page, c’est-à-dire qu’il demande l’URL et télécharge le code HTML brut renvoyé. Ensuite, si la page en a besoin, Google en effectue le rendu dans une étape séparée, en exécutant le JavaScript comme le ferait un navigateur pour afficher le contenu final.

Ces deux étapes ne se déroulent pas toujours ensemble. Le rendu peut intervenir plus tard et utilise des ressources distinctes, si bien qu’une page très dépendante de JavaScript peut attendre dans une file avant que Google n’en voie l’état final.

Pourquoi une même page peut sembler différente pour chacun

Un navigateur exécute le JavaScript immédiatement, à chaque fois, pour chaque visiteur. Google ne traite pas toutes les pages de la même façon. Si une page construit son contenu principal avec JavaScript, il est tout à fait possible que le code HTML brut récupéré en premier par Googlebot paraisse presque vide, le texte et les images réels n’apparaissant qu’une fois le rendu terminé.

La plupart du temps, ce n’est pas une catastrophe. De nombreux sites utilisent JavaScript sans aucun problème. Mais cela signifie qu’une page qui semble complète dans votre navigateur ne vous dit rien sur la question de savoir si la récupération de Googlebot, ou même sa version rendue, ressemble à cela.

Comment voir son site comme Googlebot avec l’outil d’inspection d’URL

L’outil d’inspection d’URL de Google Search Console est le moyen le plus direct de le vérifier par vous-même, et il est gratuit une fois que vous avez validé votre site.

Lancer un test en direct ou consulter la version indexée

Ouvrez Search Console, collez l’URL complète de la page dans la barre d’inspection en haut, puis appuyez sur Entrée. Vous verrez d’abord l’enregistrement de Google indiquant la dernière exploration de cette page, s’il en existe un.

Cet enregistrement peut être ancien. Pour voir ce que Google trouverait maintenant, lancez un test en direct google search console en cliquant sur Tester l’URL en direct. D’après la documentation d’aide de Search Console de Google, cela lance une vérification récente de la page en ligne, distincte de la dernière version indexée.

Le test en direct prend un peu de temps. Une fois terminé, cliquez sur Afficher la page testée pour voir le résultat.

Ouvrir la capture d’écran du rendu

Dans la vue de la page testée, vous trouverez un onglet présentant une capture d’écran de la façon dont Google a rendu la page, ainsi que le code HTML récupéré et le code HTML après rendu. Cette capture est ce qui se rapproche le plus de la vue qu’a Googlebot de votre page.

Comparez-la avec la même page ouverte dans votre propre navigateur. Si du texte, des images ou des sections entières manquent dans la version de Google alors qu’ils figurent dans la vôtre, c’est cet écart qu’il faut examiner.

Lire le rapport d’inspection d’URL champ par champ

Le rapport comporte plusieurs sections, et les intitulés ne sont pas toujours évidents si vous ne l’avez jamais utilisé.

Un rapport sans erreur sur tous les champs ne garantit pas qu’une page sera bien classée. Il permet en revanche d’écarter la raison la plus élémentaire pour laquelle une page pourrait être absente des résultats de recherche : Google n’a tout simplement pas pu la récupérer ni la lire correctement.

Comparer la vue de Googlebot à ce qu’affiche un navigateur

L’outil d’inspection d’URL est la vérification la plus fiable, mais quelques techniques plus simples dans votre propre navigateur peuvent vous donner une première impression rapide, sans quitter la page que vous consultez.

Consulter le code source pour voir le HTML brut

La plupart des navigateurs permettent d’afficher le code HTML d’origine d’une page, avant toute exécution de JavaScript, en tapant view-source: devant l’URL de la page. C’est à peu près à quoi ressemble la première récupération de Googlebot, avant tout rendu.

Si les mots que vous lisez sur la page, votre titre, vos paragraphes principaux, votre offre clé, ne figurent nulle part dans ce code HTML brut, il y a de fortes chances qu’ils soient ajoutés par JavaScript après le chargement initial.

Désactiver JavaScript pour obtenir une approximation

Les outils de développement des navigateurs proposent généralement une option pour désactiver JavaScript et recharger la page. Avec JavaScript désactivé, vous observez une version qui se rapproche du pire scénario de ce qu’un robot d’exploration pourrait voir si le rendu n’avait pas eu lieu ou avait échoué.

Ce n’est pas une correspondance exacte avec ce que fait Googlebot, puisque Google effectue bien le rendu du JavaScript dans de nombreux cas. C’est une vérification approximative utile, mais elle ne remplace pas le test réel dans Search Console.

Problèmes de contenu que Googlebot détecte et que vous ne voyez pas

Certains problèmes n’apparaissent que lorsque l’on compare ce que voit votre navigateur avec ce que voit Googlebot, car une visite normale ne les révèle jamais.

Du texte qui dépend de JavaScript pour s’afficher

Une description de produit, un tableau de tarifs, voire une section entière de la page d’accueil peut être conçu pour n’apparaître qu’une fois un script exécuté. Votre navigateur exécute ce script instantanément, vous ne remarquez donc jamais de délai.

Si l’étape de rendu de Google est retardée, ignorée ou rencontre une erreur, ce même texte peut manquer dans ce qui est indexé. La capture d’écran du rendu dans l’outil d’inspection d’URL permet de le voir : un vide à l’endroit où devrait se trouver un paragraphe ou un prix.

Du contenu caché derrière un clic ou un onglet

Les accordéons, les onglets et les sections « Lire la suite » sont courants sur les pages de services et les FAQ. Un visiteur clique pour les déplier sans y penser.

Google peut parfois lire un contenu masqué de cette façon, mais cela dépend de la construction de la page. Si le contenu n’est chargé dans la page qu’après un clic, au lieu d’être présent dans le HTML et simplement masqué visuellement, il y a un risque réel qu’il ne soit jamais lu. Un rapide contrôle du HTML rendu dans la Search Console indiquera si ce texte masqué est bien présent.

Images et défilement infini qui se chargent tardivement

Une page qui ne charge les images qu’au fil du défilement, ou qui ajoute automatiquement de nouvelles lignes de contenu en arrivant en bas, fonctionne très bien pour un visiteur humain patient. Googlebot ne fait pas défiler la page et n’attend pas comme une personne le ferait.

Un contenu qui n’apparaît qu’après plusieurs défilements peut devenir pratiquement invisible pour un crawl, alors que chaque visiteur qui descend dans la page le voit clairement.

Problèmes de blocage qui empêchent complètement Googlebot d’accéder au site

Un contenu qui ne s’affiche pas correctement est un premier type de problème. Une page que Googlebot ne peut même pas atteindre en est un autre, bien plus grave.

Règles robots.txt qui bloquent une page

La documentation de Google sur robots.txt explique qu’une règle Disallow indique à un robot d’exploration de ne pas demander un chemin donné. Si une page, ou un dossier entier dans lequel elle se trouve, est interdite, Googlebot ne la récupère pas, et son contenu n’a aucune importance si elle n’est jamais lue.

Ce fichier se trouve à la racine d’un site, par exemple example.com/robots.txt, et il vaut la peine de le vérifier directement, car une règle ajoutée lors d’une refonte ou d’une migration de site peut bloquer plus que prévu. Le Robots.txt Checker gratuit de RepGet indique un verdict pour une URL précise selon vos règles actuelles, et notre guide sur le générateur robots.txt explique comment créer un fichier qui ne bloque pas plus que ce que vous voulez.

Balises noindex et en-têtes

Une page peut être entièrement accessible tout en étant signalée comme ne devant pas apparaître dans les résultats de recherche, via une balise meta noindex dans le HTML de la page ou un en-tête HTTP équivalent. Cela est souvent ajouté volontairement sur un site de préproduction ou une page de remerciement, puis oublié après la mise en ligne.

Le champ Couverture de l’outil d’inspection d’URL indiquera clairement si c’est la raison pour laquelle une page n’est pas indexée, c’est donc l’un des premiers points à vérifier lorsqu’une page a disparu.

Fichiers CSS ou JavaScript bloqués

Le HTML d’une page peut être correct alors que les fichiers dont elle dépend pour s’afficher et fonctionner correctement sont bloqués. Si une règle robots.txt interdit par erreur un dossier de feuilles de style ou de scripts, Google peut récupérer la page mais ne pas la rendre comme le fait le navigateur d’un visiteur.

La section Ressources du rapport de l’outil d’inspection d’URL liste précisément les fichiers chargés et ceux qui ne l’ont pas été, ce qui rend ce type de problème facile à repérer une fois qu’on sait où regarder.

Un exemple concret : pourquoi une page d’accueil refondue a disparu

Imaginez un magasin de meubles qui relance la page d’accueil de son site avec un nouveau design construit en grande partie autour d’animations JavaScript. Cet exemple est illustratif.

Tout semble correct dans chaque navigateur testé par le propriétaire. Quelques semaines plus tard, le trafic de recherche vers la page d’accueil chute fortement, et une recherche du nom de l’entreprise ne fait plus apparaître la page d’accueil du tout.

Rien dans le design lui-même n’était cassé. Une seule règle oubliée dans robots.txt avait discrètement coupé les fichiers dont la page avait besoin pour s’afficher, et aucune vérification du site dans un navigateur n’aurait jamais pu le montrer.

Indexation mobile-first : vérifier la version qui compte le plus

La plupart des points abordés jusqu’ici valent aussi bien pour la version desktop que pour la version mobile d’une page. Pour Google en particulier, l’une de ces versions compte davantage que l’autre.

Ce que signifie concrètement l’indexation mobile-first

La documentation de Google sur l’indexation mobile-first explique que Google utilise principalement la version mobile du contenu d’une page pour l’indexation et le classement. Cela ne veut pas dire que la version desktop est totalement ignorée, mais la version mobile est celle qui compte le plus lorsque Google détermine ce que contient une page.

Cela a son importance, car une page peut s’afficher parfaitement sur desktop tout en ayant du contenu manquant sur mobile, si un modèle mobile masque une section, la charge différemment ou la supprime pour gagner de la place. Une capture d’écran desktop propre dans l’outil d’inspection d’URL vous en apprend moins qu’on ne le croit si le rendu mobile est différent.

Vérifier le rendu mobile

Par défaut, le test en direct de l’outil d’inspection d’URL affiche la page telle que la verrait Googlebot Smartphone, puisque c’est la version que Google indexe pour la plupart des sites. La capture d’écran et le HTML obtenus après un test en direct reflètent déjà ce rendu.

Si votre site propose une mise en page réellement différente aux visiteurs mobiles, comme un menu de navigation qui se replie, une colonne latérale qui disparaît ou un bloc de texte masqué derrière un bouton d’affichage, vérifiez que tout ce qui compte sur la page est toujours présent dans ce rendu mobile. Un contrôle uniquement sur desktop peut passer à côté d’un problème propre au mobile.

D’autres moyens gratuits de voir ce que perçoivent les robots

L’outil d’inspection d’URL de Search Console est l’option la plus complète, mais ce n’est pas la seule façon de se faire une idée de ce que rencontre un robot.

Changer l’user agent de votre navigateur

La plupart des outils de développement des navigateurs permettent de modifier l’user agent envoyé par votre navigateur, c’est-à-dire la courte chaîne de texte qui identifie ce qui fait la requête. En le remplaçant par celui de Googlebot, puis en rechargeant la page, vous pouvez repérer des différences dans le contenu servi, si votre site traite différemment les user agents.

Ce contrôle est plus restreint que l’outil d’inspection d’URL, puisqu’il ne fait que modifier la façon dont votre navigateur s’identifie. Il exécute le JavaScript comme le ferait habituellement votre navigateur, donc il ne détectera pas forcément un délai de rendu comme le fera l’étape de rendu réelle de Google. C’est utile comme vérification rapide, mais cela ne remplace pas l’outil officiel.

Des outils gratuits pour une vérification rapide

Quelques outils gratuits répondent à des questions plus ciblées sans nécessiter de propriété Search Console vérifiée. Le AI Crawler Checker de RepGet teste si des robots spécifiques, y compris des robots d’IA comme GPTBot, peuvent accéder à une page donnée. C’est une question proche mais distincte de celle de savoir comment Googlebot rend précisément le contenu d’une page. Notre guide sur le crawler web IA explique comment ces robots demandent et lisent généralement une page.

Le Meta Tag Checker de RepGet analyse les balises présentes dans le HTML d’une page, y compris une directive noindex si elle existe. C’est pratique pour une vérification rapide, avant même d’ouvrir Search Console.

Une checklist de 20 minutes pour vérifier vos pages clés

Il n’est pas nécessaire de auditer tout le site pour que cela soit utile. Vérifier quelques pages importantes en une seule séance permet de repérer l’essentiel.

Refaire cette vérification une fois par mois, ou juste après une refonte, permet de détecter une page bloquée ou un écart de rendu bien avant qu’il n’affecte discrètement ses performances dans les résultats de recherche.

Erreurs courantes lors de la vérification de la vue de Googlebot

Quelques habitudes rendent ce type de contrôle moins utile qu'il ne devrait l'être, même quand on suit les bonnes étapes.

Tester uniquement la version ordinateur, ou se contenter de jeter un œil à l'apparence d'une page dans un navigateur classique, passe à côté de l'écart au cœur de tout cet article. Le but de l'exercice est de voir la version avec laquelle Google travaille réellement, et non celle qui est la plus facile à regarder.

Penser que le test en direct de l'outil d'inspection d'URL et la version indexée sont une seule et même chose est une autre erreur fréquente. La version indexée reflète ce que Google a exploré en dernier, ce qui peut remonter à plusieurs semaines ou plusieurs mois. Seul un test en direct permet de voir la page telle qu'elle est aujourd'hui.

Vérifier une page une seule fois après sa mise en ligne, puis ne plus jamais le faire, laisse les nouveaux problèmes s'accumuler discrètement. Une règle robots.txt peut être ajoutée lors d'une mise à jour ultérieure, un script peut se mettre à échouer après un changement d'hébergement, et rien de tout cela n'apparaît si le contrôle n'est pas refait.

Considérer une capture d'écran vierge comme la preuve d'une catastrophe, sans vérifier quel champ l'explique réellement, fait perdre du temps à chercher la mauvaise solution. Une ressource bloquée, une balise noindex et une véritable défaillance de rendu se ressemblent à première vue, mais demandent des corrections totalement différentes.

La place de RepGet

RepGet ne remplace pas l'outil d'inspection d'URL, et il n'effectue pas de test de rendu en direct avec Googlebot comme le fait Search Console. Ce contrôle précis, qui consiste à comparer une capture du rendu avec votre propre navigateur, reste une tâche manuelle à réaliser directement dans Search Console.

Ce que fait le audit de site web gratuit de RepGet, c'est explorer votre site et lui attribuer un score SEO de 0 à 100, en signalant les problèmes techniques et de contenu à examiner, y compris certaines bases qui mènent à une capture Googlebot vierge, comme un contenu pauvre ou des problèmes de structure. Aucun compte ni carte bancaire requis.

Ses outils gratuits couvrent des vérifications connexes et plus ciblées : le Robots.txt Checker indique si une URL précise est bloquée, le Meta Tag Checker montre si une balise noindex est présente, et le AI Crawler Checker teste l'accès pour d'autres robots d'exploration que Googlebot. Aucun de ces outils ne remplace un véritable examen du rendu de Googlebot, mais ils permettent de vérifier rapidement quelques points avant d'ouvrir Search Console.

En résumé

Une page peut sembler terminée dans tous les navigateurs que vous essayez et pourtant être absente de ce que Google indexe réellement. Le seul moyen d'en avoir la certitude est de regarder la page comme le fait Googlebot, et non comme vous la voyez.

L'outil d'inspection d'URL de Google Search Console rend cette comparaison possible sans aucune connaissance en programmation : une récupération en direct, une capture du rendu, et un relevé clair indiquant si quelque chose a été bloqué en cours de route. La plupart de ce qu'il révèle se ramène à une courte liste de causes : du JavaScript qui n'a pas fini de s'afficher, une règle robots.txt allant plus loin que prévu, ou une balise noindex oubliée après des tests.

Contrôler quelques pages clés de cette façon, régulièrement, permet de repérer ces problèmes alors qu'ils sont encore faciles à corriger, plutôt que des semaines plus tard, quand le seul signe est une baisse silencieuse du trafic.

Découvrez d'abord ce dont votre site a besoin

Avant de tester chaque page une à une dans Search Console, voyez ce dont l'ensemble de votre site a besoin en une seule passe. Lancez un audit de site web gratuit avec RepGet pour vérifier la configuration technique de votre site en même temps que son contenu. Aucun compte ni carte bancaire requis.