Une page qui répond 200, s’affiche correctement dans un navigateur, et pourtant Google la classe « indexée sans contenu ». Le paradoxe agace, à juste titre. On vérifie l’URL, on la recolle dans la barre, tout est là. Sauf que Googlebot, lui, n’a peut-être jamais vu ce que vous voyez. Ce statut de la Search Console traîne depuis des mois dans les rapports d’indexation, et il est presque toujours mal interprété. On l’accuse de venir du JavaScript, alors que le coupable se cache ailleurs, du côté du serveur ou du CDN.
ce que le statut « page indexée sans contenu » raconte vraiment
Le message est plus subtil qu’il n’y paraît. Google a bien trouvé l’URL, il l’a même ajoutée à son index, mais le contenu qu’il a récupéré était vide. Pas de texte, pas de balises utiles, rien à se mettre sous la dent.
Voilà pourquoi la page apparaît dans les résultats tout en affichant un contenu famélique, souvent réduit à un titre ou à un extrait incohérent. Pour comprendre la mécanique complète du crawl, un site spécialisé comme creaweb3000.com détaille les rouages du rendu côté Google.
Le réflexe commun consiste à pointer du doigt le rendu JavaScript. C’est confortable, mais souvent faux. Selon John Mueller de Google, cette erreur indique presque toujours un blocage de Googlebot par le serveur ou le CDN, pas un souci de rendu côté client.
Autrement dit, l’agent de Google s’est fait refuser l’entrée avant même d’avoir eu l’occasion d’exécuter le moindre script. Le robot repart les mains vides, et la Search Console enregistre ce vide comme un contenu absent.
pourquoi le serveur ferme la porte sans le dire
Un blocage ne ressemble pas toujours à une réponse d’erreur bien nette. Les pare-feux applicatifs, les règles anti-bot des CDN et certaines configurations de sécurité renvoient des réponses ambiguës, parfois un code de succès avec une coquille vide, parfois une page de vérification. Googlebot reçoit quelque chose, mais pas votre contenu. La réponse HTTP dit « tout va bien » alors que le corps de la page ne contient rien d’exploitable.
Les causes reviennent souvent, et elles se ressemblent :
- Une règle WAF qui classe Googlebot parmi les robots suspects, à cause d’une plage d’IP mal configurée ou d’un test de navigateur trop strict.
- Le CDN sert une version en cache corrompue ou une page d’attente, sans jamais rafraîchir l’originale.
- Un test anti-DDoS déclenché sur les requêtes sans cookies ni en-têtes de navigateur classiques.
- Une protection par mot de passe ou un mode « maintenance » resté actif sur un sous-domaine.
- Une redirection interne mal fichue qui aboutit sur un gabarit vide plutôt que sur la page demandée.
Dans tous ces cas, le navigateur humain passe sans encombre parce qu’il envoie des en-têtes, des cookies et exécute le défi JavaScript du CDN. Googlebot, plus austère, se fait jeter à la porte. La différence de traitement entre un visiteur et le robot explique à elle seule une bonne partie des faux mystères.
ne pas confondre avec « explorée, actuellement non indexée »
Les deux statuts vivent dans le même rapport, et on les mélange allègrement. « Explorée, actuellement non indexée » signifie que Google a vu la page, l’a lue, a compris son contenu, puis a décidé de ne pas l’indexer. C’est un choix éditorial de l’algorithme, lié à la qualité, à la duplication ou au manque d’intérêt perçu. Rien à voir avec un problème d’accès.
« Indexée sans contenu », en revanche, veut dire que Google a indexé l’URL mais n’a rien trouvé à afficher. L’indexation a eu lieu sur la foi d’une coquille vide. La distinction change tout le diagnostic. Dans le premier cas, on travaille le contenu et la valeur de la page. Dans le second, on enquête sur l’infrastructure, les logs serveur et les règles du CDN. Confondre les deux fait perdre des semaines à réécrire des textes qui n’ont jamais été lus.
Un troisième statut traîne parfois dans le même coin, celui des pages bloquées par le fichier robots.txt ou par une balise noindex. Là encore, ce sont des refus explicites d’indexation, pas des échecs de récupération. Le rapport de couverture de la Search Console les range dans des catégories distinctes, et il faut les lire séparément pour ne pas s’égarer. Sur ce point, voir aussi notre article sur premiere page google.
ce que les vidéos non indexées nous apprennent à côté
La Search Console possède un rapport dédié à l’indexation des vidéos, et il révèle le même genre de confusion à une autre échelle. Il présente le nombre de pages indexées contenant une vidéo indexée, et le nombre de pages indexées contenant une vidéo non indexée, avec le motif d’échec associé. Un motif revient souvent, du type « la vidéo n’est pas sur une page de lecture, la vidéo est un contenu complémentaire de la page ».
Sur le forum WebRankInfo, un utilisateur nommé espagne signale le 10 février 2025 que 28 vidéos ne sont pas indexées, avec précisément ce motif. Le cas illustre bien la logique de Google : chaque type de ressource a son propre motif d’échec, sa propre catégorie. Une vidéo non indexée ne dit rien de l’indexation de la page qui la porte. Même chose pour une page sans contenu : le statut décrit un incident précis, pas une maladie générale du site.
Cette segmentation a une conséquence pratique énorme. Quand on cherche pourquoi une page ne remonte pas, on ouvre le bon rapport. Le rapport de couverture des pages pour un problème de contenu vide, le rapport vidéo pour une vidéo absente des résultats enrichis. Mélanger les deux revient à consulter la mauvaise ordonnance. Franchement, la moitié des diagnostics ratés vient de là.
Et si vous vous demandez comment bloquer volontairement l’indexation d’une page, c’est encore une autre histoire. La balise noindex ou une règle robots.txt font le travail proprement, mais elles produisent un statut de refus, pas un statut de contenu vide. Savoir ce qu’on veut obtenir évite de bricoler au hasard et de s’étonner du résultat.
les vérifications qui règlent le problème
Le point de départ reste l’outil d’inspection d’URL de la Search Console. On y demande une exploration en direct, et on regarde la réponse HTTP, le contenu récupéré, les éventuels blocages signalés. Si le corps de la réponse est vide alors que la page s’affiche chez vous, le problème est côté serveur, sans ambiguïté. Un test avec l’agent utilisateur de Googlebot depuis la ligne de commande confirme souvent la chose en quelques secondes.
Côté hébergeur et CDN, il faut traquer les règles qui filtrent les robots, les challenges JavaScript imposés à tout le monde et les caches qui servent une version périmée. Une liste d’IP de Google à jour, un cache qui se rafraîchit correctement, et le statut disparaît généralement au passage suivant du robot. Une fois le blocage levé, on relance une inspection pour vérifier que Googlebot récupère enfin le contenu attendu.
Beaucoup d’éditeurs cherchent d’abord la meilleure astuce pour trouver une information, avant de vérifier la plomberie. C’est l’ordre inverse. Aucun moteur ne peut indexer ce qu’il n’a pas pu lire, et le débat sur les outils passe loin derrière la mécanique d’accès elle-même. L’enquête commence toujours par les logs.
une question d’accès avant d’être une question de contenu
Le statut « page indexée sans contenu » ressemble à un aveu de faiblesse éditoriale, alors qu’il pointe d’abord vers une porte fermée. Googlebot n’a pas vu la page, il a vu une coquille. Le corriger demande de regarder les logs, les règles du serveur et la configuration du CDN, pas de réécrire le texte une troisième fois.
La nuance avec « explorée, actuellement non indexée » mérite d’être connue par cœur, parce qu’elle oriente tout le reste du diagnostic. Et vous, la dernière fois qu’une page est restée vide aux yeux de Google, avez-vous pensé à vérifier ce que le serveur racontait vraiment ?