Une partie du contenu venait d'un autre CMS

Le site reposait sur plusieurs outils. Une partie des contenus était gérée dans un CMS utilisé en headless : il servait à préparer et à fournir les contenus, mais ne possédait pas de site public propre. Leur affichage se faisait sur le site e-commerce.

Dans ce cas précis, le JavaScript de la page allait récupérer les données auprès du CMS, puis les insérait dans la page.

Pour les visiteurs, le contenu s'affichait rapidement grâce au cache, sans flash ni zone vide perceptible. Le chargement côté navigateur ne présentait donc pas de défaut visible.

Le diagnostic dans la Search Console

Pour comprendre les mauvaises performances, j'ai inspecté le rendu des pages dans la Search Console. Les contenus en question n'y apparaissaient pas. Les zones qui les accueillaient étaient vides.

Ce qui rendait ce constat étonnant, c'est que les pages étaient bien indexées et apparaissaient déjà sur certains mots-clés, même si leurs positions restaient mauvaises. Une page peut pourtant être indexée à partir d'un contenu incomplet. Des éléments accessibles à Google, comme la balise title, peuvent lui donner des indications sur son sujet sans que le texte chargé depuis le CMS soit disponible. La présence dans les résultats ne garantissait donc pas que Google avait accès à l'ensemble du contenu.

Dans le détail de l'inspection, Search Console signalait bien des ressources bloquées par robots.txt. Je connaissais bien celui du site principal : aucune de ses règles ne pouvait expliquer le blocage de ces ressources. Il fallait donc regarder quel hôte les servait et quelles règles s'y appliquaient.

À partir de là, le diagnostic changeait. Avant de retravailler ces textes ou de chercher à mieux les positionner, il fallait comprendre pourquoi Google ne les récupérait pas.

La capacité de Google à exécuter JavaScript ne suffisait pas : il fallait aussi qu'il puisse récupérer les données appelées par les scripts. Son indexation s'appuie notamment sur le HTML obtenu après ce rendu. Si une ressource nécessaire reste inaccessible, le contenu qui en dépend peut manquer dans la page rendue.

Le blocage se trouvait du côté du CMS

Le CMS n'avait pas vocation à recevoir du trafic organique et n'était pas suivi dans la Search Console. J'ai donc consulté directement le robots.txt de son domaine. Il bloquait Google, y compris l'accès aux ressources qui fournissaient les données aux pages e-commerce.

Le CMS n'avait pas de front public à référencer. Le bloquer pouvait donc sembler sans conséquence pour le SEO. Pourtant, il participait bien à l'affichage du site : Google avait besoin de récupérer ses contenus pour compléter les pages.

Le navigateur d'un visiteur pouvait faire ces requêtes. Google, lui, devait respecter les restrictions d'exploration. Le cache et la vitesse de chargement ne résolvaient pas ce problème d'accès.

Une page peut ainsi être accessible alors qu'une ressource dont elle dépend ne l'est pas. Les règles du robots.txt s'appliquent à l'hôte qui sert chaque ressource, pas seulement à l'adresse de la page que l'on veut référencer. C'est ce qui rendait ce blocage moins évident à repérer.

Autoriser la récupération, sans indexer les URL techniques

J'ai levé le blocage qui empêchait Google de récupérer ces contenus. J'ai aussi ajouté des directives noindex dans les en-têtes HTTP des réponses concernées, avec X-Robots-Tag.

X-Robots-Tag: noindex

Il fallait distinguer deux objectifs : laisser Google récupérer les ressources publiques nécessaires aux pages, et éviter que les URL techniques du CMS apparaissent elles-mêmes dans les résultats de recherche. Les pages e-commerce, elles, devaient rester indexables.

L'en-tête HTTP permet de transmettre cette consigne sans dépendre d'une balise dans une page HTML. Mais Google doit pouvoir accéder à la réponse pour la lire.

Ce que j'en ai retenu

Après cette correction, le trafic organique des pages concernées a nettement progressé.

Ce cas m'a surtout appris à remonter la chaîne de chargement. Dans une architecture de ce type, le diagnostic doit aussi porter sur l'origine des contenus et sur les conditions qui permettent à Google de les récupérer.

Quand une partie d'un site reste peu visible sans raison évidente, comparer le contenu attendu avec le HTML rendu par Google est un point de départ concret. L'outil d'inspection d'URL permet d'examiner ce rendu et les ressources chargées. Dans ce cas, c'est cette vérification qui m'a conduit au bon endroit : le CMS qui alimentait les pages.