Page indexée sans contenu : dans l'index, et pourtant invisible
Dans le rapport « Indexation des pages » de la Google Search Console, voir une URL passer en « indexée » ressemble à une victoire. « Page indexée sans contenu » range cette victoire au rayon des fausses bonnes nouvelles : la page est bien dans l'index, et elle ne se positionnera sur rien, parce que Google l'a lue vide.
Le statut le dit sans détour : c'est le seul où Google admet ne pas savoir, la page apparaît dans l'index mais son contenu reste illisible « pour une raison que nous ignorons ». Reste alors trois questions qui décident de tout. Pourquoi Google reçoit-il du vide là où un navigateur affiche une page complète ? Pourquoi ajouter du texte ne change-t-il rien quand le problème n'est pas la quantité ? Et comment distinguer ce statut du Soft 404, qui lui ferme la porte avant même l'index ?
Trois questions qui séparent la page réellement vide de celle que Google n'arrive simplement pas à lire.
Que signifie « Page indexée sans contenu » ?
« Page indexée sans contenu » signifie que votre URL figure dans l'index de Google, mais que Googlebot n'a rien pu extraire de son contenu lors de l'exploration. La page existe pour Google, sans matière exploitable derrière. Résultat : elle est indexée, et incapable de se positionner sur la moindre requête.
« Cette page apparaît dans l'index, mais Google ne parvient pas à en lire le contenu pour une raison que nous ignorons. Il est possible que la page ne soit pas accessible à Google ou que son format ne permette pas son indexation. » — Google, rapport « Indexation des pages », catégorie « Autres ».
Ce qui rend ce statut singulier, c'est l'aveu d'ignorance. Google ne pointe pas une cause précise comme il le fait pour un Soft 404 ou un blocage robots.txt. Il constate un écart : l'URL a répondu, elle a été retenue, mais le rendu n'a livré aucun contenu exploitable. La balle revient dans votre camp, sans diagnostic fourni. C'est précisément ce flou qui rend le statut difficile à traiter, et ce qui suit sert à le lever.
Pourquoi c'est une fausse victoire, pas un simple bug d'affichage
Une page « indexée sans contenu » occupe une ligne dans l'index, mais sans aucun signal de pertinence à offrir. Google n'a indexé qu'une coquille. Sans texte exploitable, aucune requête ne peut la déclencher : elle est techniquement présente, et commercialement absente.
Le piège tient au mot « indexée ». Dans le rapport, il rassure, alors qu'ici il ne garantit rien. Une page peut rester des mois dans cet état, comptée parmi vos URLs indexées, sans jamais générer une impression. Vous croyez la zone couverte, et le trafic attendu ne vient pas.
À cela s'ajoute le crawl dépensé pour rien. Googlebot revient régulièrement vérifier une page dont il ne tire toujours rien. Sur une poignée d'URLs, l'effet est négligeable. À l'échelle d'un gabarit entier qui sert systématiquement du vide, c'est du budget d'exploration gaspillé sur des pages mortes, au détriment de celles que vous voulez vraiment voir indexées. Comprendre pourquoi Google reçoit du vide commence par identifier laquelle des quatre causes possibles vous touche.
Les quatre causes : du vide réel au blocage invisible
Quatre familles de causes mènent à ce statut, et elles n'ont presque rien en commun. Trois relèvent d'un problème de lecture, où Google reçoit du vide alors que la page existe. Une seule correspond à une page réellement vide. Identifier la bonne famille conditionne tout le reste : un correctif appliqué à la mauvaise cause ne produit aucun effet.
« Je vois le texte, pas Googlebot » : rendu JS et ressources bloquées
C'est le cas le plus courant côté code. Votre contenu n'existe pas dans le HTML initial : il est injecté par JavaScript après le chargement. Si l'exécution échoue, expire, ou dépend de ressources que Googlebot ne récupère pas, le rendu se fige sur une page vide. Même mécanisme quand vos fichiers CSS et JS sont bloqués par le robots.txt : Google explore le HTML, ne peut pas charger ce qui construit la page, et n'obtient qu'une carcasse. Vous voyez une page complète dans votre navigateur, Googlebot voit le squelette d'avant l'injection.
« Google reçoit du vide » : serveur, CDN ou pare-feu
Ici, le problème n'est pas dans votre code, il est sur le chemin entre Googlebot et votre serveur. Un pare-feu applicatif (WAF), une protection anti-bot ou une règle CDN trop agressive peut servir une réponse vide à Googlebot, tout en livrant la page complète à un visiteur humain. Selon une clarification rapportée de John Mueller début 2026, le rendu JavaScript serait rarement seul en cause dans ce statut : très souvent, c'est le serveur, le CDN ou une couche de filtrage qui retourne du vide à Google. À prendre comme une mise au point utile, pas comme une vérité absolue : les deux familles de causes coexistent, et c'est le diagnostic par symptôme qui tranche. Quand la réponse serveur se dégrade complètement, vous basculez d'ailleurs vers un autre statut, traité dans Erreur serveur (5xx).
La page est réellement vide ou trop fine
Le cas le plus simple, et le seul que « ajouter du contenu » corrige vraiment. La page répond, son HTML est lisible, mais il n'y a presque rien dedans : un gabarit sans corps, une fiche jamais remplie, une catégorie sans produit, un conteneur en attente de données qui ne sont jamais arrivées. Google lit ce qu'il y a, et ce qu'il y a ne suffit pas à constituer un contenu.
Cloaking, volontaire ou accidentel
Le cloaking consiste à servir à Googlebot une version différente de celle vue par l'internaute. Volontaire, c'est une infraction aux règles de Google. Accidentel, c'est beaucoup plus fréquent : une détection du user-agent mal réglée, une redirection conditionnelle, une variante servie selon l'IP ou la géolocalisation qui prive Googlebot du contenu réel. Le résultat est le même, une version vide côté Google.
| Symptôme observé | Cause probable | Quoi vérifier |
|---|---|---|
| Contenu visible dans le navigateur, absent du HTML source | Rendu JS ou ressources bloquées | HTML source vs HTML affiché, robots.txt sur les fichiers CSS/JS |
| Page complète pour vous, vide pour Googlebot | Serveur, CDN ou pare-feu | Réponse servie au user-agent Googlebot, règles WAF et CDN |
| HTML lisible mais quasi rien dedans | Page réellement vide ou trop fine | Présence d'un corps de contenu réel dans le gabarit |
| Version Google différente de la version visiteur | Cloaking, souvent accidentel | Détection user-agent, redirections conditionnelles, règles par IP |
Le faux remède : non, ajouter 600 mots ne corrige rien
Ajouter du contenu ne corrige qu'un seul des quatre cas : celui de la page réellement vide. Dans les trois autres, le problème est la lecture, pas la quantité. Si Google reçoit du vide à cause du rendu ou du serveur, 600 mots de plus restent tout aussi illisibles : vous enrichissez une page que Googlebot ne voit toujours pas.
C'est le réflexe le plus tenace face à ce statut, et le plus contre-productif. Le mot « contenu » dans l'intitulé oriente naturellement vers l'idée d'un déficit de texte. Mais le statut ne dit pas « contenu insuffisant », il dit que Google ne parvient pas à lire le contenu existant. La nuance est décisive. Tant que vous n'avez pas vérifié ce que Googlebot reçoit réellement, ajouter du texte revient à remplir un seau percé.
La bonne démarche inverse l'ordre : d'abord confirmer si Google reçoit ou non du contenu, ensuite seulement décider s'il faut en ajouter. Tout part du diagnostic, jamais de l'enrichissement à l'aveugle.
Mesurer l'ampleur : combien de vos URLs sont concernées
Avant de corriger, sachez combien de pages sont touchées et lesquelles. Le rapport « Indexation des pages » liste bien le statut, mais il ne se filtre pas sur votre propre liste d'URLs stratégiques : impossible d'isoler facilement, parmi vos pages qui comptent, celles servies vides à Google. C'est exactement la lacune que l'inspection en masse comble.
L'inspecteur d'URL de la Search Console donne ce verdict officiel, mais une URL à la fois : ausculter une liste entière à la main est impraticable. IndexProbe reprend la même donnée officielle de Google et l'applique à la liste d'URLs que vous fournissez, ou que vous constituez depuis la GSC, pour isoler en une analyse celles au statut « Page indexée sans contenu ». Vous parlez alors de pages précises, datées du dernier passage de Googlebot, parmi les URLs que vous analysez, sans extrapoler à l'ensemble du site.
💡 Combien de vos pages sont « indexées sans contenu », et lesquelles ? IndexProbe inspecte votre liste d'URLs via l'API de la Search Console et remonte, par page, le verdict d'indexation officiel de Google, daté de son dernier passage. Tester IndexProbe en accès anticipé →
Voir ce que Googlebot reçoit vraiment : l'onglet « HTML affiché »
Pour trancher entre une page vide et une page mal lue, regardez ce que Google a réellement reçu. Dans l'inspection d'URL de la Search Console, ouvrez le résultat de l'indexation, puis « HTML affiché » et la capture d'écran : c'est le rendu obtenu par Googlebot. S'il est vide alors que votre navigateur affiche tout, vous tenez un problème de lecture.
Une précaution capitale : le test en direct (Live Test) ne reproduit pas ce statut. Le test en direct rejoue une exploration à l'instant T, avec un comportement de rendu et des conditions réseau qui peuvent différer de celles du moment où Google a indexé la page vide. Une page peut très bien s'afficher correctement en test en direct et rester « indexée sans contenu » dans l'index.
La donnée qui compte est donc la version indexée, pas le test en direct. Comparez systématiquement le HTML source (ce que le serveur envoie au départ) au HTML affiché (ce qu'obtient Google après rendu). Si le texte apparaît dans le source mais disparaît à l'affichage, suspectez un blocage de ressources. S'il manque dès le source, le rendu JavaScript ou le serveur est en cause. Ce diagnostic décide du correctif à appliquer.
Corriger selon la cause, pas à l'aveugle
Il n'existe pas un correctif unique, mais un correctif par cause, en miroir de la grille de symptômes. Le diagnostic du HTML affiché vous a déjà orienté : appliquez la réparation qui correspond à la famille identifiée, et une seule. Corriger au hasard, c'est risquer d'enrichir une page que Google ne lit pas, ou de réécrire un serveur quand le problème vient du JavaScript.
Si la cause est le rendu JS ou des ressources bloquées, rendez le contenu principal présent dès le HTML initial (rendu côté serveur ou pré-rendu), et débloquez les fichiers CSS et JS nécessaires à l'affichage. Vérifiez d'ailleurs qu'aucune ressource décisive n'est interdite d'exploration : le sujet recoupe directement Bloquée par le fichier robots.txt.
Si la cause est le serveur, le CDN ou le pare-feu, identifiez la règle qui sert du vide à Googlebot et autorisez son user-agent à recevoir la version complète. C'est souvent une protection anti-bot ou une règle WAF trop large.
Si la page est réellement vide ou trop fine, là, et là seulement, produisez un contenu substantiel et unique, ou retirez la page de l'index si elle n'a pas vocation à se positionner.
Si la cause est un cloaking accidentel, supprimez la logique qui sert une version différente selon le user-agent, l'IP ou la géolocalisation, pour que Google reçoive ce que voit l'internaute.
Ne pas confondre avec Soft 404 ni « Indexée malgré le blocage par robots.txt »
Trois statuts proches piègent même les SEO aguerris, parce qu'ils touchent tous à la lecture du contenu. La différence tient à une seule question : la page est-elle dans l'index, et si oui, son contenu a-t-il été lu ? « Page indexée sans contenu » est dans l'index avec un contenu illisible. Un Soft 404 n'y est pas. Une page indexée malgré un blocage robots.txt y est sans avoir été lue.
| Page indexée sans contenu | Soft 404 | Indexée malgré le blocage par robots.txt | |
|---|---|---|---|
| Dans l'index ? | Oui | Non | Oui |
| Contenu lu ? | Non, illisible au rendu | Non, traitée comme introuvable | Non, crawl bloqué |
| Cause | Rendu, serveur, page vide ou cloaking | Page perçue comme inexistante malgré un code 200 | Exploration interdite par le robots.txt |
| Correctif | Rendre le contenu lisible par Googlebot | Renvoyer un vrai contenu ou un 404 franc | Débloquer l'URL dans le robots.txt |
Pour creuser chacun, voyez Soft 404 et Indexée malgré le blocage par robots.txt. Retenez la frontière : ici, Google a retenu la page mais n'a rien pu en lire au rendu, là où le Soft 404 la juge inexistante et où le blocage robots.txt l'indexe sans jamais l'avoir explorée.
Vérifier que la correction a fonctionné
Une correction n'est validée que lorsque Google a re-crawlé la page et changé son verdict. Le statut ne bascule pas à l'instant où vous déployez le correctif : il faut attendre le prochain passage de Googlebot. Le bon indicateur n'est pas votre navigateur, c'est l'évolution du statut entre deux inspections de la même URL.
Suivre cette bascule sur une page se fait à la main dans l'inspecteur d'URL. La suivre sur dix, cent ou mille pages corrigées en même temps demande de comparer deux états dans le temps. C'est le rôle de la vue Comparaison : relancer l'analyse sur la même liste après le correctif, et lire combien d'URLs sont passées de « indexée sans contenu » à l'état pleinement sain, « Envoyée et indexée », page par page et à la date du dernier passage de Googlebot.
💡 Vérifiez que vos corrections passent côté Google. IndexProbe remonte, pour la liste d'URLs que vous fournissez ou constituez depuis la GSC, le verdict d'indexation officiel daté du dernier passage de Googlebot, et la vue Comparaison met deux analyses côte à côte pour suivre la bascule du statut, page par page, sans extrapoler à l'ensemble du site. Tester IndexProbe en accès anticipé →
Questions fréquentes
Que signifie « Page indexée sans contenu » dans la Search Console ?
Ce statut signifie que votre URL est dans l'index de Google, mais que Googlebot n'a pu lire aucun contenu exploitable lors du rendu. La page existe pour Google, sans matière derrière, donc elle ne se positionne sur aucune requête malgré son indexation.
Pourquoi Google ne lit-il pas le contenu d'une page que mon navigateur affiche correctement ?
Parce que Googlebot ne reçoit pas la même chose que vous. Un rendu JavaScript qui échoue, des ressources CSS ou JS bloquées, un pare-feu qui sert du vide au robot ou un cloaking accidentel peuvent livrer une page vide à Google alors que votre navigateur affiche tout.
Quelle différence entre « Page indexée sans contenu » et un Soft 404 ?
« Page indexée sans contenu » est dans l'index, avec un contenu que Google n'a pas pu lire. Un Soft 404 n'est pas dans l'index : Google traite la page comme introuvable malgré son code 200. L'un est indexé et illisible, l'autre est exclu.
Ajouter du texte corrige-t-il ce statut ?
Seulement si la page était réellement vide. Dans les trois autres cas, rendu, serveur ou cloaking, le problème est la lecture, pas la quantité : Google reçoit du vide, et tout texte ajouté reste illisible pour lui. Diagnostiquez d'abord, enrichissez ensuite.
Le rendu JavaScript est-il toujours en cause ?
Non. Le rendu JavaScript est une cause fréquente, mais selon une clarification rapportée de John Mueller début 2026, c'est souvent le serveur, le CDN ou un pare-feu qui retourne du vide à Googlebot. Les deux familles coexistent : seul le diagnostic du HTML affiché permet de trancher.