Pour ceux qui savent ce que c’est qu’un CMS headless, la réponse ne laisse aucun doute : c’est non. Mais est-ce vrai dans tous les cas ?
Nous allons tout d’abord définir ce que sont les CMS Headless, avant de nous demander en quoi cela peut avoir une influence pour le SEO. Parce que dans la pratique, quand on bascule avoir un site parfaitement SEO Compliant avec un CMS headless, ce n’est
Un CMS sans tête ? Qu’est-ce que c’est que ce truc là ?
Un CMS headless est un système de gestion de contenus qui gère uniquement le back office d’un site internet. Il ne prévoit rien pour générer le code HTML/Javascript/CSS. Oui, rien du tout, à part des API le plus souvent pour interroger le contenu qui est stocké dans les bases du CMS : articles, catégories, produits, images, etc.
On appelle cela un CMS « headless ». Un CMS « sans tête ». Le concept s’applique avec des plateformes ecommerce, qui peuvent elles aussi être conçues en mode « headless ».
Il ne faut pas confondre ce concept avec les « headless browsers » : c’est différent, mais c’est aussi « sans tête » pour d’autres raisons.
Il faut donc que le propriétaire d’un site fait avec un CMS headless utilise autre chose pour générer son code front : un autre outil ou un autre framework, ou un code développé depuis zéro !
Je sens que certains d’entre vous trouvent déjà le concept bizarre : pourquoi faire compliqué quand on peut faire simple. Par exemple, pourquoi devoir recoder tout ce que wordpress sait très bien faire, c’est à dire générer le code qui s’affiche dans le navigateur de mes internautes ? Un truc de nerd, comme ceux qui s’amusent à réécrire des systèmes d’exploitation ?
Et bien non, en fait c’est pas si bête. Il y’a plusieurs raisons qui peuvent expliquer pourquoi de plus en plus de sites basculent vers des CMS headless.
Pourquoi « guillotiner » votre CMS préféré peut s’avérer vraiment révolutionnaire…
Il y’a deux raisons principales qui rendent les CMS headless séduisants…
La première, c’est que les CMS au fil du temps sont devenus des usines à gaz très complexes. Les couches logicielles se sont empilées. Côté front office, le code généré qui est parfois (et même souvent) alourdi par des extensions et des templates plus ou moins bien écrit n’est pas le code le plus optimal. Faites l’exercice de recoder le front office d’un WordPress avec Twig et Symfony, et vous allez faire verdir tous vos indicateurs de web performance, et en particulier les Core Web Vitals. (oui ok, à condition d’avoir des bons developpeurs front sous la main, mais ça existe. Et ils travailleront d’autant mieux qu’on aura fait disparaître leurs contraintes habituelles).
La seconde, c’est que de plus en plus souvent, on souhaite fabriquer des pages de contenus en intégrant des web services via des APIs. On peut intégrer les données côté back office, mais en général cela demande des développements spécifiques lourds et complexes à maintenir. C’est plus facile de le faire côté front office, mais dans ce cas, on se heurte à l’intégration des contenus dans des templates spécifiques aux CMS : c’est un travail réservé à des spécialistes, qui auront souvent du mal à faire quelque chose de performant. Cela donne quelque chose d’aussi élégant qu’une valse dansée par un éléphant dressé.
Il y’a une troisième raison moins avouable, c’est que si vous voulez faire du Full JS (un site entièrement codé en Javascript), et bien il n’existe que des embryons de CMS en Javscript. Donc le serveur headless permet d’utiliser un CMS dont le backoffice est solide, codé en PHP/Python/Asp.net/Java etc. et de coder le reste avec AngularJS/VueJS/ReactJS. Bref votre développeur Fullstack n’a pas à réinventer la roue, le fil à couper le beurre, et l’électricité pour fabriquer un site web complexe. Merci pour lui.
Bref, si vous voulez quelque chose de plus efficient, basculer sur un CMS headless peut apparaître comme une bonne idée.
CMS headless hébergés, CMS découplés, et CMS headless SaaS
Il existe aujourd’hui de nombreux CMS Headless, que l’on peut regrouper en trois familles :
Les CMS headless hébergés
Ce sont des CMS dont le code du back office est hébergé sur vos serveurs.
Quelques exemple de CMS headless self hosted
- Cockpit : https://getcockpit.com/
- Strapi : https://strapi.io/
Les CMS headless SaaS
Cette variante est la plus populaire : le back office est hébergé sur des serveurs distants, géré par les éditeurs du CMS. Cela signifie zéro maintenance, zéro problème de scalabilité, mais éventuellement des problèmes de sécurité et de disponibilité.
Quelques exemples de CMS en Saas
- CodeDna : https://www.coredna.com/
- Contentful : https://www.contentful.com/
- Kontent.ai : https://kontent.ai
Les CMS découplés
Les CMS « découplés » sont des CMS dont on a détaché le front office du back office. Mais qui gardent des fonctionnalités permettant de coder un front office si besoin est. Par contre, le découplage est presque total, c’est à dire que le code généré côté front ne dépend pas vraiment de ce qui est stoché dans le back office. Ce qui reste ce sont des outils permettant de lire facilement les données appelables via les API du CMS. On a les avantages des deux mondes, sans les inconvénients
Les dernières versions de Drupal (la 8 et la 9) peuvent fonctionner de manière traditionnelle (on dit « monolithique »), en mode headless ou découplé.
Et alors, les CMS headless, c’est bon pour le SEO ou pas?
En théorie, un CMS headless n’a aucune influence, positive ou négative, sur le code généré côté front. Le code HTML/JS/CSS est généré par autre chose. Donc il doit être parfaitement possible de générer un code 100% compatible SEO. C’est même encore plus possible qu’avec la plupart des CMS, qui ont tous des défauts cachés en matière d’optimisation qu’il faut corriger le plus souvent avec des extensions ad hoc.
En principe, il n’y a pas de contre indication liée au SEO à basculer un site sur un CMS ou une plateforme headless.
Sauf qu’en pratique, il faut redoubler de vigilance. Car sans vous en apercevoir, vous devenez totalement dépendant de vos équipes de développement pour le respect des règles d’otpimisation SEO. Avec un CMS, la plupart des ces règles étaient embarquées dans le code produit par le CMS, donc l’essentiel était déjà là.
Mais là avec un CMS headless, vous pouvez récupérer un festival de problèmes qu’on ne trouve plus sur un brave site wordpress :
- des pages sans balises title, sans meta descriptions, avec des balises aux syntaxes originales, des H1 multiples
- des pb de rescode, d’urls dupliquées, de canonicals
- pas de sitemaps, de robots.txt
- et d’autres choses encore
Bref, j’ai déjà vu des horreurs sur des serveurs de préprod. Et quand vous dites aux coupables : « euh… les gars. C’est un site web quand même, il y’a des règles de base à respecter », on vous répond « bah quoi ? Ca fait le job non ?
Entendons nous bien, je ne dis pas que la plupart des développeurs web en 2021 ne savent pas coder proprement, et même, ne connaissent rien aux contraintes SEO… C’est bien le cas.
Le problème, c’est que dans les ESN/SSII/Agences Web, on en vient de plus en plus à mettre sur du développement web des codeurs qui viennent d’autres horizons, et qui eux ne sont pas de vrais développeurs web. Par exemple des développeurs d’application, qui ne savent pas qu’un site web qui n’a qu’une seule url (vous savez les Single Page Application), c’est une application, pas un site web, qu’une page web, ça a une balise , avec quelque chose d’unique dedans, et que c’est pas parce que son absence ne se voit pas (beaucoup) que ce n’est pas important.</p> <p>
Conclusion : si on vous propose de basculer votre site sur une plateforme ou un CMS Headless, et que vous êtes le spécialiste SEO chargé de veiller au grain, ne sortez pas votre revolver tout de suite. Vous pouvez sourire en disant par exemple « tiens, on va enfin avoir des urls propres » ou « chouette, on va s’amuser à obtenir un CLS à zéro sur toutes les pages ».
Par contre, il va falloir que vous soyez derrière l’épaule de vos dev web à surveiller à toutes les étapes, parce que cette nouvelle liberté qu’ils ont gagnée dans la conception de leur code, c’est aussi la possibilité d’écrire du code bien pourri!
C’est donc une chance de voir une progression, mais aussi d’obtenir un festival de régressions! Là je parle d’expérience sur une dizaine de dossiers à ce jour…
Si vous ne maîtrisez pas assez le code ou la gestion de projet, faites-vous accompagner par des spécialistes (pourquoi pas un consultant de Neper)