Auditez un site sur CMS headless, là où le SEO se joue vraiment.

Un CMS headless est-il bon ou mauvais pour le SEO ??

Votre CMS « headless » n’est ni bon ni mauvais pour le SEO : tout dépend de l’interface que vous servez. Un serveur qui génère le HTML vous aide. Mais une application qui tourne uniquement côté client vous pénalise. Ouvrez le code source de l’une de vos URL d’article (directement dans le navigateur), puis cherchez-y le titre, la balise canonique et le corps du texte. Ils y figurent ? Le robot d’indexation les récupère aussitôt. À la place, vous tombez sur un `div` vide et une pile de scripts ? Alors le robot ne voit rien tant qu’il n’a pas rendu votre page, et ce retard d’indexation pèse lourd.

Passer au « headless » n’améliore pas votre SEO d’office. Balises canoniques, métadonnées, données structurées, liens internes, rendu : tout cela dépend désormais du code que votre équipe écrit et maintient (souvent sans filet). Les sites rendus côté client sans équipe SEO dédiée ont souvent moins de pages indexées ; vérifiez si le vôtre en fait partie. Et ces pertes, vous risquez de ne les découvrir qu’après la chute de vos positions, quand les erreurs sont déjà bien installées. L’évaluation regarde ce que vos pages livrent réellement et vous montre tout de suite où se situe votre site.

Où se joue le SEO dans une stack headless ou Jamstack ??

Votre SEO se règle dans votre interface, pas dans votre CMS. Le CMS stocke le contenu structuré et le sert via une API. Mais le code Next.js, Astro ou Remix que vous déployez produit le rendu, le routage et tout ce qu’un robot d’indexation lit sur vos pages. Prenez une page et suivez son titre. Repérez le champ « titre SEO » dans votre CMS, puis cherchez dans le modèle la ligne qui l’affiche. Introuvable ? Alors ce champ ne sert qu’à décorer l’écran.

Regardez de près la jonction entre votre API et votre rendu : c’est là que le SEO « headless » casse le plus souvent. Votre modèle peut attendre un champ que votre éditeur ne remplit jamais. Côté front-end, une balise canonique est parfois générée sans tenir compte de la modification de l’éditeur. Et les valeurs par défaut du modèle finissent souvent par n’appartenir à personne : votre CMS ne rend plus les pages, tandis que votre équipe front-end suppose que le CMS s’occupe du SEO. Résultat, vos développeurs doivent recréer les métadonnées, les plans de site, les données structurées et les liens internes qu’un CMS traditionnel gérait depuis son interface. Mais personne n’a prévu cette tâche dans la feuille de route.

Comment le rendu du front-end détermine-t-il ce que reçoivent les robots ??

Votre rendu décide de ce qu’un robot d’indexation récupère sur votre site : un HTML complet, ou une coquille vide qu’il doit remplir en exécutant du JavaScript. Affichez votre page avec JavaScript désactivé (une simple option à couper dans le navigateur). Dans la réponse, cherchez ensuite le titre et le corps du texte, puis les liens de navigation, la méta-description et la balise canonique. Il en manque un ? Vous pariez alors que tous les robots exécuteront correctement votre JavaScript, ce qui n’est pas toujours le cas. Et ce pari échoue rarement en silence.

Google traite votre application web JavaScript en trois temps : l’exploration, le rendu, puis l’indexation. Si votre contenu n’apparaît qu’après le rendu, vous dépendez de l’étape du milieu (celle que vous contrôlez le moins). Une partie de votre visibilité repose donc sur un traitement que vous ne maîtrisez pas. Alors vérifiez sans attendre si vos modèles vous mettent dans cette situation.

Deux points de votre modèle comptent, et vous pouvez vérifier les deux. D’après Google, le meilleur endroit pour votre balise canonique reste le HTML, et la canonique définie par votre JavaScript doit correspondre à celle du HTML d’origine. Une balise « noindex » dans votre page ? Google peut alors ne pas la rendre du tout, et le JavaScript censé retirer cette balise ne s’exécutera peut-être jamais. Le rendu dynamique (si vous l’utilisez) reste un contournement, pas une stratégie durable. Pour vos pages, Google recommande le rendu côté serveur, le rendu statique ou, avec « hydration », le rendu côté client. Mais ne vous fiez à personne pour savoir lequel vous utilisez. Ouvrez votre propre code source et vérifiez par vous-même.

Pourquoi les URL canoniques et les slugs divergent-ils entre le CMS et le site ??

Vos URL canoniques et vos slugs divergent parce que votre CMS stocke une valeur, votre route en fabrique une autre, et rien dans votre pile ne compare les deux. Vérifiez la balise canonique dans le code source de trois pages produit. Les trois pointent vers la même URL ? Alors votre modèle l’a codée en dur ou l’hérite. Vos rédacteurs, eux, perdent aussi leurs anciens outils de gestion. Dans un CMS traditionnel, vous pouviez modifier les balises canoniques, les redirections, les méta-descriptions et le schéma sans ouvrir de ticket. Et votre configuration « headless » a peut-être supprimé ces outils intégrés sans que personne ne s’en aperçoive.

Une redéfinition dans votre CMS ne change rien si votre modèle ne la lit pas. Le modèle de cours de Sanity prévoit un objet SEO facultatif : quand un titre SEO est renseigné, il remplace le champ « titre de la page », et `generateMetadata` de Next.js l’affiche ensuite. Sans cette étape, le champ ne sert à rien. Avant de vous y fier, vérifiez que cet appel existe dans votre modèle. Votre plan du site peut aussi dater : généré au déploiement, il ne reflète jamais un article modifié il y a une heure. Regardez sa date de création.

Quelles configurations headless laissent fuiter des URL de prévisualisation et de préproduction dans l'index ??

Vous les rendez visibles quand votre prévisualisation ou votre staging est hébergé sur un serveur public, sans en-tête « noindex » ni authentification. Le cas le plus simple à repérer : un sous-domaine de staging sur un domaine personnalisé. Commencez par le vôtre : envoyez une requête vers votre URL de staging, puis cherchez « X-Robots-Tag: noindex » dans les en-têtes de réponse. Sur Vercel, vos déploiements « Preview » ajoutent cet en-tête par défaut. Mais si vous associez un domaine personnalisé comme staging.example.com à votre branche hors production, Vercel ne l’ajoute pas, un détail facile à rater. Ajoutez-le vous-même.

« Noindex » est une consigne, pas un verrou. Toute personne qui possède votre URL peut ouvrir votre aperçu. Pour exiger une authentification avant le chargement de la page, utilisez la fonctionnalité « Deployment Protection » de Vercel. Les URL d’aperçu de votre CMS headless demandent le même traitement : ajoutez une balise meta « noindex » ou un en-tête d’autorisation, afin que vos brouillons ne soient pas indexés comme des pages publiées. Ne comptez pas non plus sur le fichier robots.txt : Google doit explorer votre page pour y lire l’attribut « noindex », et il ne le prend pas en charge dans ce fichier. Il ne peut donc pas être votre seule protection.

Comment auditer un site headless depuis l'extérieur ??

Vous auditez votre site « headless » depuis l’extérieur, en lisant le contenu qu’il renvoie : le robot d’indexation ne voit pas autre chose que cette page renvoyée. Lancez l’évaluation gratuite sur votre page d’accueil, elle analysera jusqu’à huit autres pages de votre site. Elle vérifie vos en-têtes de réponse et votre balisage, vos données structurées, vos titres, le poids de vos scripts et de vos images, ainsi que vos signaux robots et canoniques. Au final, vous obtenez une note sur 100 pour votre site, avec, pour chacun de vos huit piliers pondérés, les éléments qui l’expliquent.

Prévoyez environ deux minutes, sans frais. Vous indiquez une adresse e-mail professionnelle et vous recevez une seule fois le lien vers votre rapport. Vous pouvez lancer trois analyses par heure et par connexion. Mais le relevé reste limité : l’outil ne se connecte pas à votre site, ne consulte pas vos statistiques, n’analyse pas les données de performance sur le terrain et n’interroge pas votre équipe. Vous obtenez donc un rapport sur vos pages, pas sur le processus qui les produit. En revanche, vous pouvez vérifier si chaque page échantillonnée a sa propre URL canonique, une méta-description, un schéma et un corps de texte généré par le serveur. Comparez chacune à vos modèles.

Vos questions, nos réponses.

À lire ensuite.

1. 01Audit SEO Next.jsMode de rendu, métadonnées, coût d'hydratation.
2. 02Analyse SEO AstroÎles, collections de contenu, données structurées, Core Web Vitals.
3. 03Réparation de site webHors service, piraté ou en panne : ce qui subsiste, ce qu'il faut reconstruire.