« Explorée, actuellement non indexée » : ce statut, affiché pour près de la moitié des pages d’une start-up dans le rapport de couverture de Search Console, est apparu quelques semaines après la migration du site vers une architecture WordPress headless, où le contenu géré en back-office est restitué par une application front en React.
Le symptôme initial était sans ambiguïté : les impressions organiques, jusque-là stables, avaient chuté de 71 % en huit semaines, sans qu’aucune pénalité manuelle ne soit signalée dans Search Console et sans qu’aucune modification volontaire du contenu n’ait été effectuée par l’équipe éditoriale.
Diagnostic : un rendu qui ne se termine pas à temps
L’outil d’inspection d’URL de Search Console permet de visualiser précisément ce que Googlebot voit après rendu. Sur plusieurs pages testées, le rendu capturé montrait une coquille de page quasiment vide, avec seulement l’en-tête et le pied de page présents, le corps de l’article restant chargé dynamiquement par une requête JavaScript déclenchée après le chargement initial.
Googlebot exécute bien le JavaScript, mais dans une file d’attente de rendu séparée de l’exploration initiale, avec un délai qui peut aller de quelques secondes à plusieurs jours selon la charge du moteur à ce moment. Si le contenu principal n’est disponible qu’après ce rendu différé, et que ce rendu échoue ou expire avant que le contenu ne soit complètement chargé, Google se retrouve avec une version appauvrie de la page, jugée insuffisamment substantielle pour être indexée.
Vérifier l’écart entre HTML brut et rendu final
Pour confirmer cette hypothèse, une comparaison directe a été faite entre le code source brut renvoyé par le serveur (visible via curl) et le DOM final après exécution du JavaScript (visible via les outils de développement du navigateur) :
curl -s https://exemple-startup.fr/produit/nom-produit | grep -c "<p>"
# résultat : 0 paragraphe présent dans le HTML brut
Zéro paragraphe dans le HTML brut confirmait que l’intégralité du contenu textuel dépendait de l’exécution complète du JavaScript côté client, sans aucun filet de sécurité pour un robot qui ne parviendrait pas à mener ce rendu à son terme dans le temps imparti.
Correctif : basculer vers un rendu côté serveur
La solution retenue n’a pas été de renoncer à l’architecture headless, dont les bénéfices en termes de vitesse d’interface pour l’utilisateur restaient réels, mais d’ajouter une couche de rendu côté serveur pour les robots et pour le premier affichage. L’application front a été migrée vers un mode de rendu hybride, générant le HTML complet de la page dès la réponse serveur, puis hydraté ensuite par React côté client pour l’interactivité.
// côté application front, récupération des données WordPress
// avant le rendu serveur de la page
const donnees = await fetch(
`https://exemple-startup.fr/wp-json/wp/v2/posts/${id}`
).then(r => r.json());
// le HTML complet, contenu inclus, est alors généré
// avant d'être envoyé au navigateur ou au robot
Ce changement garantit que le code source brut de la page contient déjà l’intégralité du texte de l’article, sans dépendre de l’exécution ultérieure du JavaScript pour que le contenu principal existe.
Prévention pour les futures évolutions du front
Le correctif technique ne suffit pas à lui seul si aucune vérification systématique n’accompagne les futures mises à jour de l’application front. Une checklist a été intégrée au processus de déploiement :
- Vérifier via
curlque le contenu principal figure bien dans le HTML brut de chaque nouveau type de page - Comparer le nombre de mots visibles côté rendu serveur et côté rendu client complet
- Tester l’outil d’inspection d’URL de Search Console sur un échantillon avant mise en production définitive
Cette vérification ne concerne que le contenu et sa disponibilité pour l’indexation, sans intervenir sur les choix de design de l’interface, qui restent du ressort exclusif de l’équipe produit.
Résultats après le rétablissement du rendu serveur
Le rapport de couverture a montré une résorption progressive du nombre de pages « explorée, actuellement non indexée » sur les six semaines suivant le déploiement du rendu serveur. Les impressions organiques ont retrouvé un niveau proche de celui d’avant migration, avec un délai de récupération cohérent avec le temps nécessaire à Google pour réexplorer et réévaluer les pages concernées.
Une architecture headless n’est jamais le problème en soi. Le problème apparaît quand le contenu principal n’existe qu’après un rendu que le robot n’a aucune garantie de mener à son terme.
En résumé
Face à une chute d’impressions après une migration headless, le réflexe à adopter est de comparer systématiquement le HTML brut et le rendu final capturé par l’outil d’inspection d’URL. Si l’écart révèle un contenu absent du HTML brut, un rendu côté serveur, même ajouté a posteriori, reste le correctif le plus fiable pour rétablir une indexation équivalente à celle d’un site rendu classiquement.
