Aujourd'hui, j'ai testé un framework Javascript pour le SEO

On le sait, WordPress propulse une grosse partie du web.¹

WordPress is used by 61.8% of all the websites whose content management system we know. This is 43.5% of all websites

Le récent craquage de Matt Mullenweg, son cofondateur, a été l’occasion pour moi de tester autre chose après avoir installé, déployé, mis à jour des centaines de WordPress (le 1er doit dater de 2008 👴🏻). Bref il était temps.

Entendu nous, cela reste un outil robuste, très versatile et encore bien adapté à plein de projets.

Ce qui m’intéressait est de voir comment les frameworks JS ont évolué, sous l’aspect SEO et maintenance. Comme Googlebot a toujours été mauvais et/ou lent pour interpréter le JS, ces frameworks ont longtemps été boudés par les SEO.

Mes premiers projets nécessitait une étape de pré-rendering du HTML via des services externes (ce qui ajoutait des coûts ou de la complexité); ou les premières versions ne le permettait simplement pas et on se retrouvait avec un site web qui ne ranke pas dans Google (et accessoirement des clients pas contents).

Ce qui est cool, c’est que maintenant les solutions existent.

SSR et SSG

Derrière ces 2 acronymes se trouvent ce qui nous a manqué aux débuts d’Angular, React et Vue.js pour ne citer que les plus connus.

SSR (Server-Side Rendering) : le framework va générer les pages HTML dynamiquement sur le serveur à chaque requête utilisateur, en récupérant les données nécessaires et en construisant la page avant de l’envoyer au navigateur. Nickel côté SEO car le HTML généré est envoyé, donc tout est lisible pour les robots des moteurs. L’inconvénient est que c’est un peu plus lourd (et passe la charge à votre serveur)

SSG (Static Site Generation) : ici le framework va directement générer toutes les pages HTML au moment d’une étape de build, et créer un répertoire de fichiers statiques (1 par page). Cela permet un site ultra rapide, un hébergement simplifié, au prix d’une flexibilité moindre puisqu’il faut lancer cette commande de build à chaque mise à jour. Si le contenu bouge peu, cela reste idéal.

Tous les principaux framework proposent l’une ou l’autre de ces solutions (voire les 2).

Les principaux noms à connaître :

• NextJS (basé sur React)
• NuxtJs (basé sur Vue)
• Astro (qui motorise ce blog)
• Svelte
• Angular
• Gatsby

Pour les sites de contenu pur, j’ai une préférence pour le SSG car cela reste imbattable en termes de performances, et permet une surface d’attaque bien plus réduite (on n’expose que du HTML, pas de failles PHP ou d’injection SQL à craindre).

Pour du ecommerce, évidemment ce n’est pas la même histoire, entre les stocks, les paniers persistants, comptes clients, … mais une approche hybride est possible.

Et les CMS headless dans tout ça ?

On a parlé des frameworks front qui s’occupent de rendre les contenus, mais pas de leur gestion à proprement parler.

C’est là qu’interviennent les CMS headless comme Contentfull, Prismic ou Strapi. Ce sera l’objet de mon prochain test

À l’inverse des CMS monolithiques comme WordPress ou Drupal, ou en SaaS (de wix à webflow), le choix du CMS headless n’aura pas d’impact direct côté SEO, puisque c’est le framework front qui gère le rendu HTML.