WordPress, Webflow, Framer ou Astro : quel outil pour un site de contenu en 2026
WordPress, Webflow, Framer ou site statique ? En 2026, la barrière du code est tombée. Reste à choisir le moteur le plus rapide pour Google. Comparatif honnête et mon choix, prouvé sur Wildcat.
La réponse courte :
Pour un site de contenu, un blog ou un site vitrine en 2026, le meilleur choix par défaut est un site statique généré avec Astro. Pas parce que c’est à la mode, mais pour une raison datée : la métrique qui compte le plus aujourd’hui pour Google est l’INP (la réactivité de la page à chaque clic), et l’INP se joue sur le JavaScript. Or Astro envoie zéro JavaScript par défaut. Il gagne donc le terrain exact où la bataille SEO 2026 se dispute.
Le reste de cet article explique pourquoi la question a changé, comment se comparent WordPress, Webflow, Framer et Astro, et à quel moment chacun reste le bon choix. Parce que « le statique gagne » n’est vrai que si on précise pour quoi.
Ce qui a changé en 2026 : la question n’est plus « est-ce que je sais coder »
Avant, choisir sa technologie web supposait un arbitrage entre « je sais coder » et « je ne sais pas ». La barrière technique définissait le choix.
Cette barrière est tombée. Avec Claude Code, Cursor et les assistants du même type, n’importe qui génère un site fonctionnel en quelques prompts. Le code n’est plus le facteur limitant.
Ce qui reste, c’est une question de résultat : quel moteur produit la page finale la plus propre et la plus rapide pour Google et pour ton visiteur ?
Et ça change tout, parce que Google ne juge pas ton code. Il juge ce qui arrive dans le navigateur. Ton code influe sur ce résultat, évidemment. Mais le critère de décision, ce n’est pas l’élégance du code : c’est la page rendue. La bonne question à se poser, à chaque projet, est donc : quel outil me donne le meilleur résultat final, pour ce cas précis ?
Rappel utile : le SEO technique compte, mais moins qu’avant
Le SEO se divise en trois piliers : le SEO technique (la santé de ton site), le SEO on-page (ton contenu) et le SEO off-page (ce qui pointe vers toi de l’extérieur). Cet article traite du premier.
Un point honnête d’abord : le SEO technique n’est plus le nerf de la guerre qu’il a été. Les technologies ont progressé, tout est mieux optimisé par défaut, et même quelqu’un qui n’est pas développeur peut produire, avec l’IA, un site correctement performant. Ce qui reste vrai, c’est qu’on peut encore optimiser tout ce qui est optimisable. Le but n’est pas d’obtenir un 100/100 pour la beauté du score, mais d’offrir la meilleure expérience possible à Google et à tes visiteurs, point par point.
L’INP : la métrique qui tranche désormais
Google mesure la performance avec les Core Web Vitals, et te les expose via PageSpeed Insights. En 2026, un changement pèse lourd : l’INP (Interaction to Next Paint) est passé à poids égal avec les autres signaux.
Concrètement, l’INP mesure le temps que met ta page à réagir quand un visiteur clique sur quelque chose. Tu cliques sur un bouton, il se passe un délai avant que le résultat apparaisse : plus ce délai est long, plus le score est mauvais. Un bon INP se situe sous les 200 ms. Et cette métrique est fondamentalement une métrique JavaScript : plus ta page charge de JavaScript, plus elle risque de bloquer le fil principal du navigateur et de rater le seuil.
Deux détails datés rendent ce point sérieux plutôt que cosmétique :
L’INP est aujourd’hui la Core Web Vital la plus souvent ratée. Une grande part des sites échoue encore le seuil des 200 ms.
Google agrège désormais les Core Web Vitals à l’échelle du domaine entier. Autrement dit, quelques pages lourdes tirent vers le bas le classement de tout le site, même des pages qui, seules, passaient. La performance n’est plus un problème page par page : c’est un problème d’architecture.
C’est là que le choix du moteur devient décisif. Si ton outil t’impose du JavaScript partout, tu pars avec un handicap sur la métrique la plus importante de l’année.
Astuce pratique : tu peux voir ton INP en direct. Clic droit sur ta page, « Inspecter », onglet Performances des DevTools de Chrome, et clique sur les éléments de ta page : Chrome affiche l’Interaction to Next Paint mesurée à chaque interaction.
Le comparatif neutre : WordPress, Webflow, Framer, statique
Avant mon choix, voici les quatre familles telles qu’elles sont vraiment. Le périmètre : sites vitrines, blogs, sites de contenu, affiliation. Pas l’e-commerce, qui est un autre débat.
WordPress — le standard historique
WordPress, c’est environ 40 % du web. Sa première force est là : tout le monde connaît. Quand tu proposes du WordPress à un client, il est rassuré. Côté SEO, le contrôle est total via des extensions, et pour un très gros volume de contenu géré par des non-développeurs, il reste difficile à battre.
Le revers : c’est lourd. Le moteur inclut beaucoup de choses dans chaque page, les extensions empilent du JavaScript, et la base de données est sollicitée à chaque visite. Sans configuration sérieuse (cache serveur, CDN), les Core Web Vitals s’effondrent — et avec l’agrégation à l’échelle du domaine, ça devient un risque systémique. À l’usage, le tableau de bord est lent et surchargé d’informations qui ne servent à rien au client final.
Pour qui : un non-technique qui doit publier tous les jours, seul, sans jamais toucher au code.
Webflow — le constructeur visuel pro
Webflow, c’est la version design des éditeurs de site. Je l’ai beaucoup utilisé avant de migrer. Sa force : pour qui a un œil de designer, on va très loin dans la personnalisation, le HTML produit reste propre, et l’hébergement est correct sans rien configurer. La gestion SEO de base (301, sitemap, canonical, balises multilingues) est native, ce qui le place au-dessus de Framer sur ce terrain.
Les limites : le vendor lock-in. Tu dépends de l’infrastructure Webflow, sans accès serveur, et tu peux difficilement reprendre ton site pour l’héberger ailleurs. Le jour où le SEO exige quelque chose que Webflow ne prévoit pas, tu es bloqué. Et l’abonnement, autour de 20 $ par mois pour un site de base, grimpe vite.
Pour qui : un besoin de design soigné, un blog de taille moyenne, et l’envie d’une solution clé en main quitte à perdre en liberté.
Framer — le design d’abord
Framer fait beaucoup de bruit, et c’est mérité. C’est proche de Figma : des personnes non techniques produisent des sites très propres, très vite, avec de belles animations. La bibliothèque de templates est excellente et souvent gratuite. Pour une landing page de conversion, difficile de faire mieux en rapidité.
Mais pour une stratégie de contenu, les trous sont structurels. Framer embarque du JavaScript non désactivable (une base lourde avant même ton contenu), ce qui est le pire terrain possible face à l’INP. Et côté SEO, le contenu est plus limité que Webflow, qui l’est déjà plus que WordPress. Comme les autres, tu es locked-in et tu paies l’hébergement chez eux.
Pour qui : la plus belle landing page possible, rapidement, avec peu d’articles.
Le statique (Astro) — la performance par construction
Un site statique génère toutes ses pages au moment de la publication. Le serveur ne fait ensuite que servir des fichiers déjà prêts. Résultat : la vitesse par défaut, la sécurité par absence de surface d’attaque (pas de base de données connectée au front, pas d’administration à protéger), la liberté totale sur le code, et un hébergement quasi gratuit même en cas de pic de trafic.
La contrepartie historique, c’était « il faut un développeur ».
C’est précisément ce point que 2026 fait sauter : l’IA écrit l’Astro à ta place, et un CMS branché en surface règle la publication pour un client non technique (j’y reviens plus bas).
Pour qui : la performance maximale, le contrôle total, le multilingue, les cocons SEO chirurgicaux. Le cas de Wildcat, et mon choix par défaut.
Il n’y a pas de meilleur outil dans l’absolu
C’est important, et ça vaut plus qu’une nuance polie : le meilleur outil dépend de ton besoin. Un tableau de décision rapide :
Publier seul, tous les jours, sans jamais voir de code → WordPress.
Le plus beau site possible, orienté landing, peu d’articles → Framer.
Du no-code propre, un CMS solide, la tranquillité, le lock-in accepté → Webflow.
La perf maximale, le contrôle, le multilingue, et l’IA pour écrire le code → Astro.
Une vraie web app ou un annuaire dynamique massif → Next.js / Nuxt (voir plus bas).
Pourquoi Astro pour un site de contenu
Astro est un framework open source, racheté par Cloudflare début 2026. Le projet reste ouvert, désormais adossé à un des plus gros acteurs de l’edge. Voici les points qui font la différence, en clair.
Le statique, expliqué simplement. Un site classique (WordPress) fonctionne avec une base de données interrogée à chaque visite : tu demandes une page, le serveur va chercher les informations et les assemble en direct. Astro fonctionne à l’envers. Tu écris tout ton contenu, puis, au moment de publier, Astro génère toutes les pages une par une. Chaque page est prête avant qu’un visiteur arrive. Il n’y a plus d’attente serveur : la page s’affiche instantanément parce qu’elle est déjà construite. C’est la source de sa rapidité.
Les Islands : du dynamique, mais ciblé. Le statique n’interdit pas l’interactif. Si une section précise a besoin de contenu qui change (un compteur, un appel serveur), tu déclares cette section comme une « island » : un îlot de JavaScript, uniquement là où c’est nécessaire. Le reste de la page reste en HTML pur. Tu ne paies le JavaScript que sur les zones qui en ont vraiment besoin. C’est exactement ce qui protège ton INP.
Le contenu en Markdown, validé au build. Sur Astro, tes articles sont des fichiers Markdown : du texte, des titres, des listes. Astro les transforme en pages selon un gabarit que tu définis. Et surtout, tu poses des règles que chaque article doit respecter : un titre, un H1, une description, un résumé, une catégorie prise dans une liste fermée, une date, une image de couverture. Si un article ne respecte pas ces règles, le site refuse de se construire. La conséquence est puissante : ton site en production ne peut, par construction, jamais avoir une meta manquante ou une catégorie hors sujet. La qualité SEO est garantie au moment de la génération, une fois, au lieu d’être vérifiée à chaque visite. (Si tu veux de l’interactif dans un article précis — un quiz par exemple — tu passes ce fichier en MDX, la variante de Markdown qui accepte des composants.)
Tu possèdes ta data, et l’hébergement est quasi gratuit. Tout ton site n’est que des pages HTML et CSS. Pas de base de données, pas de dépendance à une plateforme. Tu peux l’héberger sur Netlify ou Vercel gratuitement, même avec du trafic. Le seul coût réel d’un site statique, c’est le nom de domaine. Pour un client, c’est un argument concret : la maintenance technique tend vers zéro.
Un CMS pour le client, sans WordPress. « Mais si mes fichiers sont sur mon ordinateur, comment mon client publie ses articles ? » Avec un CMS headless. J’utilise Sanity : un petit module à brancher, cinq minutes de mise en place, et le client accède à un studio propre où il gère coachs, articles, produits, avis — uniquement les champs que tu as décidé de lui exposer. Quand il publie, ça relance la génération du site, et sa page apparaît. Toute la logique de base de données est gérée par le CMS ; toi, tu récupères juste l’information au build.
La limite d’Astro, et pourquoi pas Next.js
Le seul cas où le statique coince, c’est le très gros volume. Si tu as 100 000 pages, chaque nouvelle publication oblige à régénérer l’ensemble, et le build s’allonge (mais c’est risible, c’est vraiment pour lui trouver un défaut). Pour référence, un déploiement de contenu sur Wildcat prend environ 1 min 20. Pour un site de taille normale, ce n’est pas un sujet.
Et Next.js ? C’est un standard de l’industrie, mais pour une web app ou un site massivement dynamique. Pour un site de contenu, c’est un marteau-pilon : tu te bats avec le cache serveur, la frontière client/serveur, l’hydratation, pour un bénéfice SEO qu’Astro te donne sans la complexité. On veut des pages HTML rapides, pas une usine.
Ce qu’il faut retenir
En 2026, coder un site ne coûte plus rien. Ce qui coûte, c’est de choisir le mauvais moteur, parce que Google juge la page rendue, pas ton code. Pour un site de contenu, le statique via Astro gagne le terrain qui compte le plus cette année (l’INP), tout en te laissant la liberté, la sécurité et un coût d’hébergement proche de zéro. Ce n’est pas le seul bon choix pour tout : c’est le bon choix par défaut pour un site de contenu, une fois que l’IA a effacé la barrière du code.
Cet article accompagne l’épisode 5 du build-in-public de Wildcat, où je montre chaque point directement sur le vrai site. Si tu veux voir comment j’applique tout ça pour rendre une PME visible sur Google et dans les réponses des IA, c’est là que je bosse : jonlabs.ch.