Headless CMS et Jamstack

Un headless CMS (CMS « sans tête ») est un système de gestion de contenu qui n'a pas de couche de présentation : il stocke le contenu et le distribue par une API à n'importe quel front-end, site web, application mobile ou autre. La Jamstack est une architecture qui découple ce front-end des données et de la logique métier, et le prégénère en pages statiques au moment de la construction du site, servies depuis un CDN. Souvent combinés, les deux apportent de la vitesse et de la sécurité, et déplacent vers l'équipe de développement des responsabilités SEO qu'un CMS classique prenait en charge.

Définition détaillée du headless CMS

Un CMS traditionnel, WordPress, Drupal ou Joomla dans leur usage courant, réunit dans un seul logiciel le stockage du contenu, son interface d'édition et sa présentation : le thème produit les pages HTML que voit le visiteur. Un headless CMS retire cette dernière couche. Sanity, éditeur d'une de ces solutions, le définit comme « un système de gestion de contenu qui sépare l'endroit où le contenu est stocké (le corps) de l'endroit où il est présenté (la tête) ». Le contenu est modélisé en champs structurés, saisi dans une interface d'administration, puis exposé par une API (REST ou GraphQL) que n'importe quel front-end vient interroger : un site web, une application mobile, une borne, un assistant.

Le marché compte des solutions hébergées en SaaS (Contentful, Sanity, Storyblok, Hygraph, Prismic) et des solutions à installer (Strapi, Directus, Payload). Les CMS traditionnels peuvent aussi fonctionner de cette manière : WordPress expose depuis sa version 4.7 une API REST qui, selon sa documentation, permet « d'amener le contenu WordPress dans des applications entièrement séparées » et d'y construire « une nouvelle expérience front-end interactive ». On parle alors de WordPress headless ou découplé. Sanity distingue les deux termes : un CMS headless n'a jamais de couche de présentation attachée, un CMS découplé en conserve une (le thème) tout en exposant son contenu par API.

Les motivations sont connues : un même contenu diffusé sur plusieurs canaux, une liberté totale de technologie côté front-end, une administration éditoriale qui n'a plus à héberger ni à sécuriser le site public, et une séparation nette des rôles entre rédacteurs et développeurs.

Définition détaillée de la Jamstack

Le terme Jamstack (à l'origine JAMstack, pour JavaScript, APIs, Markup) a été forgé par Mathias Biilmann, cofondateur de Netlify, qui l'a présenté à la conférence Smashing Conf en 2016. Le site jamstack.org, édité par Netlify, la définit comme « une approche architecturale qui découple la couche d'expérience web des données et de la logique métier ». Son principe : tout le front-end est prégénéré en pages statiques et en ressources optimisées lors d'une étape de construction (build), puis déployé sur un CDN ; ce qui reste dynamique est confié à des API appelées par JavaScript depuis le navigateur ou par des fonctions serverless.

Cloudflare en donne la lecture la plus concrète : « autant de HTML que possible est prégénéré et stocké dans un CDN », au lieu d'être produit à chaque requête par une application serveur monolithique. Le serveur d'application disparaît, ou se réduit à des services appelés à la demande. Les générateurs de sites statiques (Hugo, Eleventy, Jekyll, Gatsby, Astro) et les frameworks hybrides (Next.js, Nuxt, SvelteKit) sont les outils de cette construction, et un headless CMS en est la source de contenu la plus courante : à chaque publication, un signal (webhook) déclenche une reconstruction du site.

La Jamstack est le cas d'usage type du rendu statique décrit dans la définition du SEO JavaScript : un fichier HTML par URL, produit à l'avance. Elle se distingue de la SPA, où le HTML est construit dans le navigateur, même si un site Jamstack peut embarquer des composants interactifs qui ne s'exécutent que côté client.

Les avantages de performance

L'article « Rendering on the Web » de web.dev résume ce que le rendu statique apporte : un First Contentful Paint rapide, un TTFB constant et bas puisque le serveur n'a rien à calculer, et, tant que le JavaScript côté client reste limité, un temps de blocage réduit et donc un meilleur INP. Le HTML prégénéré se déploie sur plusieurs CDN et bénéficie de leur cache en périphérie. Ces gains se lisent dans les Core Web Vitals et dans la tenue à la charge : une page statique servie par un CDN ne s'effondre pas sous un pic de trafic.

La sécurité suit la même logique : sans serveur d'application exposé, sans base de données accessible depuis le site public, la surface d'attaque se réduit à l'hébergeur de fichiers et aux API appelées. La contrepartie est structurelle, et web.dev la nomme : le rendu statique « doit générer un fichier HTML pour chaque URL possible », ce qui devient difficile, voire impossible, quand les URL ne sont pas prévisibles ou que le site compte un très grand nombre de pages. Un catalogue de plusieurs centaines de milliers de références, des pages de résultats de recherche ou des contenus personnalisés relèvent du rendu serveur ou de solutions hybrides (régénération incrémentale, rendu à la demande mis en cache), que Next.js et Nuxt proposent page par page.

Les points de vigilance SEO

Un site Jamstack bien construit est, pour un moteur, le cas le plus simple qui soit : du HTML complet dès la réponse du serveur, sans dépendance au rendu JavaScript. Les difficultés viennent de ce que le CMS ne fait plus, et que le front-end doit reprendre.

• Le rendu. Tout dépend de ce qui est réellement prégénéré. Un front-end React ou Vue branché sur un headless CMS mais construit en rendu client est une SPA, avec les enjeux d'indexation d'une SPA : le contenu n'est visible qu'après exécution du JavaScript par Google, et pas du tout par les robots qui ne le rendent pas. Le test : désactiver JavaScript et vérifier que le contenu, les liens et les métadonnées sont présents.
• Les métadonnées. Dans un CMS traditionnel, une extension (Yoast, Rank Math) génère title, meta description, canonical, hreflang, Open Graph et données structurées. En headless, ces champs doivent exister dans le modèle de contenu et le front-end doit les écrire dans le HTML de chaque page. Une pagination, un filtre ou une page de tag oubliés dans le gabarit sortent sans title ni canonical.
• Les redirections et les codes d'erreur. Il n'y a plus de serveur d'application pour renvoyer une redirection 301 ou un code 404 : ces règles se déclarent dans la configuration de l'hébergeur ou du CDN, et doivent être versionnées avec le site. Un hébergement de fichiers mal réglé répond 200 avec la page d'accueil sur toute URL inexistante, ce qui produit des soft 404 en série.
• Le sitemap et le robots.txt sont des fichiers générés à la construction, à partir de la liste des pages produites. Un contenu publié dans le CMS mais absent du build n'existe ni sur le site ni dans le sitemap.
• La fraîcheur. Entre la publication dans le CMS et la mise en ligne, il y a une reconstruction, dont la durée croît avec le nombre de pages. Un site d'actualité ou un catalogue à prix mouvants doit s'assurer que le déclenchement est automatique et que le délai reste acceptable, ou passer à la régénération incrémentale.
• Les images. Le CMS headless livre des URL d'images brutes ; le redimensionnement, les formats modernes, les attributs alt, width et height et le lazy loading reviennent au front-end ou à un service d'images tiers.
• Le domaine et l'aperçu. Les environnements de prévisualisation (branches déployées sur des sous-domaines de l'hébergeur) doivent être bloqués à l'indexation, sous peine de créer des copies complètes du site.

Exemples d'architectures

Trois configurations résument les usages courants. Un site vitrine ou un blog : contenu dans un headless CMS ou dans des fichiers Markdown, génération avec Hugo, Eleventy ou Astro, hébergement sur Netlify, Vercel, Cloudflare Pages ou GitHub Pages, reconstruction à chaque publication ; c'est le cas le plus favorable, pour la vitesse comme pour le SEO. Un site éditorial à fort volume : WordPress conservé pour l'édition et exposé par son API REST, front-end Next.js ou Nuxt avec rendu statique pour les pages stables et régénération incrémentale pour les articles récents. Un site e-commerce : catalogue dans une plateforme commerce exposée par API, contenu éditorial dans un headless CMS, front-end hybride avec rendu serveur pour les pages produit et statique pour les pages de contenu, où le contrôle des métadonnées, des redirections et de la navigation à facettes demande le plus de rigueur.

Dans tous les cas, la question à poser avant de choisir cette architecture n'est pas celle de la vitesse, acquise, mais celle de l'équipe : qui écrira les métadonnées, qui tiendra le fichier de redirections, qui vérifiera le rendu. Ce que l'extension SEO d'un CMS faisait par défaut devient une spécification à écrire et à recetter.

FAQ

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

Ni l'un ni l'autre : il est neutre. Le CMS ne produit plus de HTML, donc tout ce qui compte pour un moteur (contenu dans la réponse serveur, title, canonical, redirections, sitemap) dépend du front-end qu'on lui associe. Un front-end en rendu statique ou serveur donne un site très rapide et simple à indexer ; un front-end en rendu client recrée les difficultés d'une SPA.

Quelle est la différence entre headless CMS et Jamstack ?

Le headless CMS est un outil : un dépôt de contenu exposé par API. La Jamstack est une architecture : un front-end découplé, prégénéré en pages statiques et servi par un CDN. Un site Jamstack utilise souvent un headless CMS comme source, mais peut aussi partir de fichiers ; un headless CMS peut alimenter autre chose qu'un site Jamstack, une application mobile par exemple.

WordPress peut-il être utilisé en headless ?

Oui. Son API REST, intégrée depuis la version 4.7, expose articles, pages, médias et taxonomies en JSON, et des extensions ajoutent une API GraphQL. L'administration WordPress reste l'outil d'édition, et un front-end séparé (Next.js, Nuxt, Astro) génère le site. Les extensions SEO de WordPress ne produisent plus le HTML : leurs champs doivent être récupérés par l'API et écrits par le front-end.

Un site Jamstack est-il forcément statique ?

Le HTML des pages l'est, mais pas l'expérience : des appels d'API depuis le navigateur ou des fonctions serverless prennent en charge la recherche, les formulaires, le panier ou les commentaires. Les frameworks hybrides permettent aussi de mêler pages statiques et pages rendues à la demande quand le nombre d'URL rend la prégénération complète impraticable.

Où gérer les redirections sur un site Jamstack ?

Dans la configuration de l'hébergeur ou du CDN (fichier de redirections, règles de routage), versionnée avec le code du site. Faute de serveur d'application, une redirection écrite en JavaScript dans la page n'est vue qu'au rendu et ne remplace pas une redirection 301 HTTP.

En résumé

• Headless CMS : un système de gestion de contenu sans couche de présentation, qui stocke le contenu et le distribue par API à n'importe quel front-end.
• Jamstack : une architecture (JavaScript, APIs, Markup) qui découple le front-end des données et le prégénère en pages statiques servies par un CDN ; terme forgé par Mathias Biilmann (Netlify) et présenté en 2016.
• Performance : TTFB constant, FCP rapide, tenue à la charge et surface d'attaque réduite ; limite structurelle sur les sites à très grand nombre d'URL, contournée par les rendus hybrides.
• Vigilance SEO : rendu réellement prégénéré, métadonnées à modéliser et à écrire par le front-end, redirections et codes 404 déclarés chez l'hébergeur, sitemap généré au build, environnements d'aperçu bloqués.
• WordPress headless : possible par son API REST, l'administration restant l'outil d'édition et le front-end reprenant ce que les extensions SEO faisaient.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !