L’architecture headless s’est imposée dans beaucoup de refontes récentes, et elle traîne deux réputations opposées : celle d’être moderne et performante, celle d’être un piège pour le référencement. Aucune des deux n’est exacte. Une architecture headless n’est ni bonne ni mauvaise en soielle déplace simplement un certain nombre de responsabilités, et le référencement se joue entièrement sur la façon dont ces responsabilités sont assumées.
Ce que veut dire headless
Dans une architecture traditionnelle, un même système gère le contenu et sa présentation. Vous rédigez un article dans une interface, et ce même logiciel génère la page HTML envoyée au visiteur.
Dans une architecture headless, ces deux fonctions sont séparées. D’un côté, un système de gestion de contenu qui stocke et expose les données via une interface de programmation. De l’autre, une application distincte qui consomme ces données et produit l’affichage. Le premier n’a plus de « tête »d’où le nom.
Les avantages sont réels : un même contenu peut alimenter un site, une application mobile et un affichage en magasin ; les équipes techniques choisissent librement leurs outils ; les performances peuvent être excellentes.
La contrepartie l’est tout autant : tout ce que le CMS traditionnel faisait automatiquementgénérer les balises de titre, produire un sitemap, gérer les redirections, renvoyer les bons codes de réponsedoit désormais être explicitement construit. Rien n’est perdu, mais rien n’est acquis. C’est le point sur lequel insiste Jimenez Julien avant chaque refonte de ce type : l’architecture ne dégrade rien par elle-même, elle transfère la charge du référencement technique vers l’équipe de développement.
Pourquoi le SEO se joue sur le rendu
C’est le point central, et il vaut la peine d’être formulé simplement.
Ce qui est indexé, c’est ce que le serveur envoie lors du premier appel. Si le contenu est présent dans cette réponse initiale, tout se passe normalement. S’il doit être reconstitué par l’exécution de scripts dans le navigateur, il entre dans une file d’attente de rendu, avec un délai variable et une fiabilité moindrenulle sur la plupart des moteurs autres que Google, et sur les systèmes qui alimentent les réponses génératives.
Un principe simple, à rappeler à chaque projet de ce type : la question n’est pas « quelle technologie utilisez-vous » mais « qu’y a-t-il dans le HTML de la première réponse ». Toute l’architecture doit être évaluée à cette aune, et la réponse se vérifie en trente secondes avec un affichage du code source.
Concrètement, cela oriente le choix du mode de rendu, et ce choix doit être fait au moment de la conceptionpas trois mois après la mise en ligne, quand le trafic n’arrive pas.
Les points à cadrer dès la conception
Quatre sujets doivent figurer au cahier des charges. Traités a posteriori, ils coûtent dix fois plus cher.
Mode de rendu et pages concernées
Décidez explicitement, gabarit par gabarit, ce qui est rendu côté serveur ou généré statiquement, et ce qui peut rester côté client.
La règle qui fonctionne : tout ce qui doit être trouvé passe par un rendu serveur ou une génération statique. Pages d’accueil, listings, fiches, contenus éditoriaux, pages de service. Ce qui peut rester côté client : espaces authentifiés, tableaux de bord, configurateurs, tout ce qui suppose déjà une action de l’utilisateur.
Documentez cette répartition. Sans document, elle dérive au fil des sprints.
Maîtrise des métadonnées par les équipes éditoriales
C’est la régression la plus fréquente, et la plus pénible à vivre au quotidien.
Dans une architecture mal cadrée, les balises de titre et de description sont générées automatiquement à partir du titre de l’article, sans possibilité de les modifier. Les équipes qui pouvaient les ajuster page par page perdent cette main.
Exigez donc, dès la spécification : des champs dédiés pour la balise de titre, la description, la balise canonique, l’indexabilité de la page, et les métadonnées de partage social. Ces champs doivent être éditables dans l’interface de gestion de contenu, avec des valeurs par défaut sensées lorsqu’ils sont laissés vides.
URL, redirections et codes de réponse
Trois mécanismes que le CMS traditionnel fournissait et qu’il faut reconstruire.
La structure d’URL doit être décidée et stable, avec une gestion propre des accents, de la casse et des caractères spéciaux. Prévoyez le comportement en cas de modification du titre d’un contenu : l’URL change-t-elle, et si oui, une redirection est-elle créée automatiquement ?
Un système de redirections administrable, permettant d’ajouter une correspondance sans intervention technique. Sans lui, chaque suppression de page devient un ticket pour l’équipe de développement.
Les codes de réponse corrects : une page inexistante doit renvoyer un véritable 404, pas un 200 affichant un message d’erreur. C’est l’un des défauts les plus courants des applications construites sur ces architectures, et il produit des soft 404 en masse.
Sitemaps et données structurées
Les deux doivent être générés automatiquement à partir du contenu réel, et se mettre à jour à chaque publication.
Un sitemap statique, déposé une fois puis oublié, devient obsolète en quelques semaines. Prévoyez une génération dynamique, découpée par type de contenu, avec des dates de dernière modification exactes.
Pour les données structurées, définissez les types applicables par gabarit et intégrez leur génération au modèle de page, plutôt que de compter sur une saisie manuelle qui ne sera jamais faite.
Ce qui casse le plus souvent
Cinq défauts reviennent dans la quasi-totalité des recettes techniques de ce type de projet.
Les liens sans balise <a href>. Une navigation construite avec des éléments cliquables qui déclenchent une fonction de routage n’est pas explorable. Chaque destination doit être atteignable par une véritable balise de lien avec une URL réelle, même si le routage est ensuite intercepté côté client.
La navigation non explorable. Menus déroulants, filtres, pagination construits entièrement en JavaScript : les sections concernées deviennent inaccessibles aux robots.
Les métadonnées figées. Toutes les pages partagent la même balise de titre ou la même description, souvent celle définie dans le gabarit racine.
Les aperçus de partage absents. Les métadonnées destinées aux réseaux sociaux ne sont pas interprétées par les plateformes lorsqu’elles sont injectées par script. Un lien partagé apparaît alors sans titre, sans image et sans description.
La pagination en défilement infini sans alternative. Le contenu au-delà du premier écran n’est jamais atteint.
Qui fait quoi
La séparation des responsabilités est source de malentendus. Clarifiez-la par écrit.
Relève du développement : le mode de rendu, la génération des sitemaps, le système de redirections, les codes de réponse, la présence des balises de lien, l’intégration des champs de métadonnées dans les gabarits, la génération des données structurées.
Relève de l’éditorial : le contenu des balises de titre et de description, le choix d’indexer ou non une page, les textes alternatifs des images, la structure des titres dans le contenu, le maillage interne.
L’erreur classique consiste à laisser le référencement « à l’équipe technique » ou « à l’équipe marketing ». Il se situe précisément à l’intersection, et c’est cette zone qui reste orpheline dans la plupart des projets.
La recette SEO avant mise en ligne
Onze points à faire valider par l’équipe technique, sur un échantillon couvrant chaque gabarit.
Le contenu principal figure-t-il dans le HTML de la première réponse ? Les balises de titre, de description et la canonique sont-elles présentes dès ce HTML, et différentes d’une page à l’autre ? Les liens de navigation utilisent-ils de vraies balises avec href ? Une page inexistante renvoie-t-elle un vrai code 404 ? Le système de redirections est-il opérationnel et administrable ? Le sitemap se génère-t-il automatiquement, et ne contient-il que des URL valides ? Les données structurées sont-elles produites par gabarit ? Les métadonnées de partage social sont-elles dans le HTML initial ? Les fichiers de script et de style sont-ils autorisés à l’exploration ? La pagination dispose-t-elle de vraies URL accessibles sans JavaScript ? Les équipes éditoriales peuvent-elles modifier les métadonnées sans passer par le développement ?
Onze réponses affirmatives, et l’architecture est saine. Une seule réponse négative mérite d’être traitée avant la mise en ligne : après, elle coûtera un projet à part entière.