Une page qui n’affiche rien dans les résultats Google passe vite pour une page vide. Le raccourci est tentant, surtout quand le contenu arrive par JavaScript et qu’on inspecte le code source à la va-vite. Sauf que Google ne lit pas une page comme un navigateur lancé à la main : il l’explore, l’affiche, puis décide ou non de l’indexer. Trois étapes, trois occasions de perdre le contenu en route. Confondre « invisible dans la recherche » et « absent du HTML » revient à condamner un site sans avoir regardé ce que le robot a réellement vu.

Trois phases, et une seule coupable à la fois

Google traite les applications Web JavaScript en trois temps bien distincts : exploration, affichage, indexation. L’exploration, c’est le robot qui récupère le HTML brut et suit les liens qu’il y trouve. L’affichage vient ensuite, avec une version toujours actualisée de Chromium qui exécute le JavaScript et produit un rendu.

L’indexation arrive en dernier, quand Google choisit de garder la page dans son index. Un contenu peut disparaître à n’importe laquelle de ces étapes. La marche à suivre pour michel-hunault.com n’a rien à voir selon celle qui a lâché.

La méthode qui marche consiste à isoler la phase fautive avant de toucher au code. Si l’exploration est bloquée, inutile de réécrire vos composants React : le problème n’est pas là. Si le rendu ne s’exécute pas, vous pouvez passer des heures sur le sitemap sans effet. Et si tout fonctionne sauf la dernière étape, c’est du côté de la qualité ou de la duplication qu’il faut chercher.

Comment vérifier ce que Google a réellement indexé

La question « comment puis-je vérifier l’indexation d’un site web sur Google ? » revient sans arrêt, et la réponse tient en une commande : site:votredomaine.fr tapée dans la barre de recherche. Elle liste les pages que Google connaît, avec des approximations. Pour un contrôle plus fin, l’outil d’inspection d’URL de la Search Console reste la référence. Il montre le HTML récupéré, le HTML rendu et les éventuelles erreurs, ce que la simple commande ne donne jamais.

Les vérifications utiles avant de conclure

Avant de déclarer une page vide, prenez l’habitude de comparer ce que vous voyez à l’écran avec ce que Google a compris. Le rendu réel de Googlebot est souvent très différent du code source brut, surtout quand le contenu arrive après le chargement initial.

• Lancez l’inspection d’URL et regardez l’onglet « HTML rendu » plutôt que le code source brut, c’est là que se trouve le vrai contenu.
• Est-ce que votre fichier JavaScript apparaît dans la liste des ressources bloquées ?
• Le sitemap déclare la page, mais Google la refuse : vérifiez la balise noindex posée par erreur dans un composant.
• Vous cherchez désespérément la page dans les résultats alors qu’elle existe : c’est souvent une question d’ancienneté ou de maillage interne trop faible.
• Comment voir les pages indexées par Google sans passer par un outil tiers coûteux ? La Search Console suffit, dans le rapport Couverture.

Ce dernier point mérite qu’on s’y arrête, parce que beaucoup de diagnostics s’arrêtent avant. Une page techniquement parfaite mais jamais liée depuis le reste du site restera au fond de la file d’attente pendant des semaines. Googlebot analyse la réponse pour les autres URL dans l’attribut href des liens HTML, puis ajoute ces URL à sa file. Sans lien entrant, pas de découverte.

Le piège du robots.txt et des fichiers JavaScript bloqués

Voilà l’erreur que je croise le plus souvent. Un développeur bloque un dossier /assets/js/ dans le robots.txt pour éviter que Google n’explore des ressources inutiles, persuadé de faire le ménage. Sauf que Googlebot lit le fichier robots.txt et, si une URL y est marquée comme non autorisée, n’envoie pas la requête HTTP pour cette URL et l’ignore complètement. Le script qui construit votre menu, votre grille de produits ou votre pagination ne sera jamais récupéré, donc jamais exécuté. Sur ce point, voir aussi notre article sur fiche avocat invisible.

Google le dit clairement : la recherche n’affiche pas le code JavaScript des fichiers ou pages bloqués. Résultat, le rendu se fait sur un HTML incomplet, la page semble vide, et vous vous arrachez les cheveux sur un framework qui n’y est pour rien. Le diagnostic est d’autant plus trompeur que votre navigateur, lui, charge bien ces fichiers puisqu’il ignore le robots.txt dans ce contexte.

Le réflexe à garder : avant de soupçonner une frame JavaScript ou un routeur défaillant, ouvrez le rapport robots.txt de la Search Console et vérifiez qu’aucune ressource critique n’est bloquée. Un fichier CSS bloqué suffit parfois à casser la mise en page perçue par le robot, et donc à dégrader le rendu. Pour empêcher la découverte de liens sans casser le rendu, Google recommande le mécanisme nofollow plutôt qu’un blocage d’exploration.

Quand la cause se cache ailleurs, sans JavaScript

Une page peut être parfaitement rendue et malgré tout absente des résultats. Les causes classiques reviennent : une balise canonique pointant vers une autre URL, un contenu dupliqué entre versions mobile et desktop, une redirection mal servie, ou un noindex oublié après une mise en production. Tester les résultats enrichis de Google avec l’outil dédié aide aussi : un balisage cassé n’empêche pas toujours l’indexation, mais il attire l’œil sur des incohérences de structure qui trahissent parfois un problème plus profond.

Franchement, la plupart des fausses alertes « page vide » que j’ai vues venaient d’un rendu non exécuté ou d’un blocage d’exploration, rarement d’un vrai défaut d’indexation. Ça dépend quand même beaucoup des sites : une place de marché avec des milliers de fiches produits générées côté client cumulera les trois problèmes à la fois, tandis qu’un blog statique n’aura souvent qu’un souci de maillage. Le diagnostic se fait page par page, pas sur des généralités.

Ce qu’un audit sérieux regarde en premier

Un audit commence par la comparaison entre le HTML brut et le HTML rendu, sur une poignée d’URL représentatives. Si le contenu principal apparaît dans le premier mais pas dans le second, le problème est côté exécution ou blocage. S’il n’apparaît dans aucun des deux, la question se déplace vers la génération côté serveur, et là, c’est un choix d’architecture qu’il faut trancher, pas un bug à corriger.

La Search Console fournit les preuves : liste des ressources bloquées, erreurs d’exploration, statut d’indexation de chaque URL testée. Croisez ces données avec le rendu réel, pas avec vos impressions de développeur devant son navigateur. La nuance compte, parce qu’un site peut très bien fonctionner pour l’utilisateur et rester invisible pour le robot pendant des mois sans que personne ne s’en aperçoive.

La prochaine fois qu’une page semble vide dans les résultats, posez la bonne question : le robot a-t-il pu explorer, afficher et indexer ce contenu ? Trois vérifications, trois réponses possibles, et un diagnostic qui change du tout au tout selon celle qui cloche. Rien ne sert de réécrire un composant si un dossier est bloqué dans le robots.txt depuis un an. Le rendu final, lui, ne ment jamais.