Choisir un CMS pour le SEO : la bonne méthode

Choisir un CMS en pensant d'abord au SEO part souvent d'une prémisse fausse : que la plateforme elle-même décide si un site se positionne ou non. Ce n'est pas le cas pour l'immense majorité des sites. WordPress, Shopify, Webflow, PrestaShop, une version récente de Wix, un CMS maison bien construit : chacun peut porter un site qui atteint la première page, et chacun peut tout aussi bien porter un site invisible. La différence ne vient presque jamais du logiciel.

Les articles qui classent les CMS par « niveau de SEO-friendliness », avec une note sur dix et un vainqueur en haut du tableau, vendent généralement quelque chose : un thème, une extension, une prestation de migration, ou la plateforme elle-même qui sponsorise le comparatif. Ce n'est pas un hasard si le vainqueur change selon qui écrit l'article. Ce que ces classements passent sous silence, c'est que le contenu et les liens expliquent l'essentiel du résultat, et qu'aucun CMS ne les produit à votre place.

Le mythe du classement « CMS le plus SEO-friendly »

Un comparatif qui promet de désigner le CMS le plus SEO repose sur une hypothèse implicite : qu'il existerait un logiciel capable de faire remonter un site presque tout seul. Ce logiciel n'existe pas. Un moteur de recherche explore et indexe du HTML, peu importe ce qui l'a généré en amont. Ce qui détermine un classement, ce sont des signaux de pertinence et d'autorité : la page répond-elle mieux à l'intention de recherche que les autres résultats en lice, d'autres sites jugent-ils ce contenu assez utile pour y faire un lien, le site dans son ensemble traite-t-il le sujet avec une réelle profondeur. Aucune de ces trois choses ne dépend du CMS.

On observe régulièrement des sites sur des plateformes réputées « mauvaises pour le SEO » dépasser des concurrents installés sur des plateformes réputées irréprochables, simplement parce que les premiers ont investi dans le contenu et l'acquisition de liens, quand les seconds ont coché une case technique en pensant que le travail était terminé.

• Un site WordPress mal structuré, au contenu superficiel et sans aucun lien entrant, se positionnera moins bien qu'un site Squarespace resserré sur son créneau et documenté en profondeur.
• Un CMS développé en interne, sans optimisation technique particulière, peut tout de même dominer une requête de longue traîne si personne d'autre n'a encore écrit un contenu aussi complet sur le sujet.

Ce qui différencie réellement les plateformes

Si le CMS ne décide pas du résultat final, il façonne quand même le terrain de jeu : ce que vous pouvez faire sans effort, ce que vous devez batailler pour obtenir, et ce qui reste tout simplement hors de portée. Voici les points qui finissent, en pratique, par causer de vrais problèmes.

• Le contrôle sur la structure des URLs, et surtout la possibilité de la modifier sans casser l'historique. Un CMS qui impose un identifiant numérique dans l'URL, ou qui régénère le chemin à chaque changement de catégorie, prive d'un des leviers les plus simples : une URL lisible et stable dans le temps.
• La gestion des redirections. Renommer une page, fusionner deux articles, réorganiser une arborescence : tout cela produit des URLs mortes si la plateforme ne permet pas de poser des redirections 301 proprement, en masse au besoin, sans repasser par un développeur à chaque fois.
• Le contrôle sur les titres, les meta descriptions, la hiérarchie des titres et les données structurées. Certaines plateformes imposent un format de titre non modifiable, dupliquent le H1 avec le titre technique de la page, ou n'offrent aucun moyen d'ajouter du balisage schema.org sans toucher au code. Prises isolément, ces limites semblent mineures ; combinées, elles réduisent nettement ce qu'on peut faire pour clarifier le sujet de chaque page.
• La façon dont la plateforme restitue le contenu. Un site rendu côté serveur envoie un HTML déjà complet à la première requête. Un site qui construit sa page côté client, en JavaScript, oblige les robots à exécuter ce script avant de voir le contenu réel. Les moteurs savent le faire, mais avec un délai et un budget de calcul plus élevés, et tous les outils d'aperçu ou de partage n'en sont pas capables. Sur un petit site l'effet passe souvent inaperçu ; sur un site qui publie beaucoup, un rendu majoritairement côté client peut ralentir la découverte de nouvelles pages.
• Un plafond de vitesse propre à la plateforme. Certains environnements imposent des scripts tiers, un poids de page ou une architecture qui rendent difficile d'atteindre de bons temps de chargement, quel que soit le soin apporté par ailleurs. D'autres laissent une marge de manœuvre quasi totale. Ce plafond ne devient visible qu'après plusieurs mois d'usage, une fois que thème, extensions et contenu accumulé pèsent réellement sur les performances.
• La gestion du sitemap XML et du fichier robots.txt. Un sitemap qui se met à jour automatiquement, qui exclut les pages à faible valeur — filtres, panier, recherche interne — et qui reste synchronisé avec ce qui est publié, simplifie l'exploration. Une plateforme qui génère un sitemap statique jamais régénéré, ou qui interdit toute modification du robots.txt, oblige à contourner le problème par des moyens détournés.
• La prise en charge de l'internationalisation. Ce point pèse davantage pour un site francophone que pour un site qui ne vise que le marché anglophone : dès qu'on publie en plusieurs langues, ou qu'on cible plusieurs pays francophones — France, Belgique, Suisse, Québec, Afrique francophone —, la plateforme doit savoir gérer les balises hreflang, limiter le contenu dupliqué entre variantes linguistiques et permettre une structure d'URL par langue cohérente. Un site qui ne vise que les États-Unis n'a souvent jamais à résoudre ce problème ; un site francophone qui vise plusieurs marchés y est confronté presque par défaut.
• L'accès au code source brut. Pouvoir ouvrir le HTML généré, ajouter une balise canonical spécifique à une page, injecter un script de mesure, corriger une erreur de balisage à la main quand l'interface ne le permet pas. Certaines plateformes fermées interdisent tout accès de ce type : tout doit obligatoirement passer par leur interface, avec les limites qu'elle impose.

Les questions à se poser avant de choisir

Avant de comparer des fonctionnalités, il vaut mieux répondre à quelques questions concrètes sur la manière dont le site sera réellement utilisé. Ce sont elles, bien plus qu'un tableau de notes, qui orientent vers la bonne famille de plateformes.

• Qui va éditer le contenu au quotidien, et quel est son niveau technique ? Une équipe marketing non technique a besoin d'une interface simple, où changer un titre ou publier un article ne demande pas d'ouvrir du code. Une équipe avec des développeurs disponibles en permanence peut absorber une plateforme plus exigeante en échange d'un contrôle plus fin.
• Le site a-t-il besoin de quelques dizaines de pages, ou de plusieurs centaines, voire davantage ? Une vingtaine de pages statiques se gère bien sur presque n'importe quelle plateforme, y compris les plus simples. Un site qui doit absorber des centaines de pages produit, de catégories ou d'articles a besoin d'une architecture d'URL, d'un système de gabarits et d'une gestion du maillage interne pensés pour l'échelle dès le départ.
• Combien de langues sont ciblées, aujourd'hui et dans les deux prochaines années ? Un site monolingue peut se permettre une plateforme sans gestion native du multilingue. Un site qui doit ou devra gérer plusieurs langues a intérêt à choisir une plateforme où cette gestion est pensée dès la conception, plutôt qu'ajoutée après coup avec une extension approximative.
• Existe-t-il déjà un site en place, avec un historique d'URLs, de positionnements et de liens entrants accumulés au fil du temps ? Si oui, la question centrale n'est plus seulement « quelle plateforme choisir », mais « quelle plateforme me permet de préserver cet historique pendant la transition ». C'est un critère à part entière, souvent plus déterminant que n'importe quelle fonctionnalité.

Le headless : tout contrôler, tout assumer

Une architecture headless sépare la gestion du contenu de sa restitution : le CMS stocke et organise le contenu, un système séparé — souvent un framework JavaScript moderne — se charge de l'afficher. L'attrait est réel : contrôle total sur le HTML produit, liberté complète sur la structure des URLs, absence des contraintes imposées par un thème ou un système de gabarits standard.

Ce contrôle a un prix, et ce prix, c'est la responsabilité de tout ce que le CMS traditionnel gérait auparavant en arrière-plan. Le rendu côté serveur ou la génération statique ne viennent plus gratuitement : ils doivent être mis en place et maintenus. Le sitemap ne se génère plus tout seul. Les redirections, les balises canonical, les données structurées, tout ce qui était une case à cocher dans l'interface d'un CMS classique devient une ligne de code à écrire, tester et faire vivre. Une équipe qui a les ressources techniques pour assumer cela obtient un contrôle qu'aucune plateforme fermée n'offre. Une équipe qui n'a pas ces ressources hérite, sans le vouloir, exactement des problèmes de rendu côté client décrits plus haut, avec en plus l'absence du filet de sécurité qu'un CMS établi fournit par défaut.

Le coût de migration, le vrai verrou

Changer de CMS quelques mois après l'avoir choisi paraît anodin sur le papier : exporter le contenu, l'importer ailleurs, republier. En pratique, c'est rarement aussi simple, et c'est précisément ce coût de sortie qui rend la décision initiale plus lourde qu'elle n'en a l'air.

Chaque migration expose le site au même ensemble de risques : les URLs changent de forme, ce qui impose de cartographier et poser des redirections une par une pour ne pas perdre l'historique de positionnement ; les gabarits doivent être reconstruits, souvent différemment ; les données structurées doivent être réimplémentées ; l'import du contenu abîme fréquemment la mise en forme, les liens internes et les métadonnées associées à chaque page ; l'équipe doit se réapproprier une nouvelle interface. À cela s'ajoute un risque presque systématique de baisse temporaire de trafic pendant la transition, le temps que les moteurs redécouvrent le site sous sa nouvelle forme. C'est cette accumulation de coûts, plus que le prix d'une licence ou d'un abonnement, qui fait d'un CMS un choix difficile à revenir en arrière une fois le contenu accumulé pendant des années.

Changer de CMS, ou changer de stratégie de contenu ?

Il existe de vraies raisons de changer de plateforme : un plafond de vitesse qu'aucun réglage ne permet de dépasser, une impossibilité structurelle de poser des redirections propres, une architecture qui empêche d'ajouter les données structurées nécessaires, une équipe qui ne peut plus rien publier sans passer par un développeur pour la moindre modification. Dans ces cas-là, la plateforme est un blocage réel, identifiable et documentable.

Mais il existe une confusion tout aussi fréquente : un site qui ne se positionne pas parce que son contenu est générique, redondant avec des dizaines de pages similaires ailleurs sur le web, ou tout simplement trop mince pour répondre à l'intention de recherche. Dans ce cas, changer de CMS ne change rien au fond du problème : les mêmes pages, transportées sur une nouvelle plateforme avec de nouvelles URLs, produiront le même résultat, avec en prime la baisse temporaire de trafic inhérente à toute migration.

Avant d'attribuer une contre-performance au CMS, il vaut mieux vérifier honnêtement si les pages concernées apportent quelque chose que la concurrence n'apporte pas déjà. Si la réponse est non, le problème à résoudre est éditorial, pas technique — et aucune migration, aussi soignée soit-elle, ne le résoudra à la place d'un contenu réécrit avec plus de profondeur.