# Cabinet d’expertise BTP : le trafic revient après un headless mal indexé

> Retour d'expérience sur un site vitrine passé en architecture headless dont le rendu n'était pas équivalent pour les robots, et sur ce qui a permis de récupérer le trafic perdu.

- Auteur : Clément Hadrot
- Publié le : 2024-12-07
- Mis à jour le : 2024-12-07
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/cabinet-expertise-btp-trafic-headless-mal-indexe/

## L’essentiel

- Un rendu visuel correct mais invisible pour les robots d'indexation
- Un diagnostic centré sur la comparaison du HTML brut et du rendu final
- Un plan de correction en trois temps pour retrouver le trafic perdu

« Pourquoi le trafic organique s'effondre-t-il alors que le nouveau site est visuellement identique à l'ancien ? » C'est la question posée par un cabinet d'expertise technique du bâtiment, quelques semaines après le passage de son site vitrine vers une architecture headless, séparant un rendu front-end en JavaScript d'un contenu géré côté WordPress via l'API REST. Ce billet ne traite pas le choix technique du framework front-end retenu, un sujet distinct déjà tranché en amont du projet, mais uniquement le diagnostic et la correction du problème d'indexation qui a suivi.

En deux mois, le trafic organique du site était retombé à environ 40 % de son niveau initial, une chute progressive plutôt qu'un effondrement brutal, ce qui a d'abord retardé la prise de conscience du problème : chaque semaine semblait un peu moins bonne que la précédente, sans qu'aucun signal isolé ne déclenche immédiatement l'alerte.

## Le diagnostic : un rendu correct pour l'œil, incomplet pour le robot

La première vérification a consisté à comparer le code source brut renvoyé par le serveur, tel qu'un robot d'indexation le reçoit avant exécution du JavaScript, avec le rendu final affiché dans un navigateur. Cette comparaison a révélé un écart net : le HTML brut ne contenait qu'une coquille minimale, avec un conteneur vide destiné à être rempli par le JavaScript côté client, tandis que l'ensemble du contenu réel, textes des prestations, présentation des chantiers réalisés, coordonnées, n'apparaissait qu'après exécution complète du script.

Bien que Google soit capable, dans une certaine mesure, d'exécuter du JavaScript lors de l'exploration, ce traitement s'effectue en deux temps : une première exploration du HTML brut, puis un rendu différé, parfois avec un délai de plusieurs jours, pour les pages nécessitant l'exécution du script. Ce délai supplémentaire, combiné à un rendu parfois incomplet lors de cette seconde passe, explique en grande partie la dégradation observée.

## Confirmer l'hypothèse avec les outils Google

> L'essentiel à retenir : Un rendu visuel correct mais invisible pour les robots d'indexation ; Un diagnostic centré sur la comparaison du HTML brut et du rendu final ; Un plan de correction en trois temps pour retrouver le trafic perdu

L'outil d'inspection d'URL de la Search Console a permis de confirmer le diagnostic, en affichant côte à côte le code source récupéré par Googlebot et le rendu obtenu après exécution du JavaScript par ses systèmes. Sur plusieurs pages de prestations testées, le contenu textuel principal, pourtant bien visible pour un visiteur humain, restait absent ou tronqué dans le rendu final observé par cet outil, confirmant que le problème ne relevait pas d'une simple lenteur mais d'une exécution incomplète du script côté serveur d'indexation.

## Le plan de correction en trois temps

### 1. Mettre en place un rendu côté serveur

La correction principale a consisté à faire générer, côté serveur, un HTML déjà complet pour chaque page, plutôt que de laisser le navigateur ou le robot reconstruire le contenu entièrement côté client. Cette étape a nécessité une adaptation de l'architecture front-end existante pour produire un rendu initial statique, hydraté ensuite par le JavaScript pour les interactions dynamiques.

### 2. Vérifier l'équivalence de contenu page par page

Chaque type de page (accueil, prestations, chantiers réalisés, contact) a été vérifié individuellement pour s'assurer que le contenu présent dans le HTML brut correspondait bien à ce qu'un visiteur voyait à l'écran, sans dépendre exclusivement de l'exécution du script pour afficher les éléments jugés stratégiques comme les titres, descriptions de prestations et données de contact.

### 3. Resoumettre les pages corrigées et suivre la reprise

Une fois les corrections déployées, les principales pages ont été resoumises via l'outil d'inspection d'URL pour accélérer leur réexploration, plutôt que d'attendre le passage naturel de Googlebot. Le suivi de la couverture d'indexation dans les semaines suivantes a confirmé un retour progressif du contenu correctement reconnu par Google.

## Ce que ce cas illustre plus largement

Une architecture headless n'est pas en soi défavorable au référencement : de nombreux sites l'utilisent avec un rendu côté serveur bien conçu, sans aucune perte d'indexation. Le problème rencontré ici ne venait pas du choix de séparer front-end et back-end, mais de l'absence de vérification que le rendu initial livré au robot était équivalent à celui perçu par un visiteur humain, une équivalence qui aurait dû être testée avant la mise en production, pas découverte deux mois plus tard sur les courbes de trafic.

## En résumé

Ce retour d'expérience rappelle qu'une architecture headless exige une vérification systématique de l'équivalence entre le HTML brut renvoyé au robot et le rendu final affiché au visiteur, avant toute mise en production. L'outil d'inspection d'URL de la Search Console reste, dans ce type de diagnostic, le moyen le plus direct de confirmer ce que Google voit réellement, plutôt que de se fier uniquement à l'apparence du site dans un navigateur.