Accueil › Comment migrer un site Gutenberg (Block Editor) vers du statique

Guide WordPressEscape

Comment migrer un site Gutenberg (Block Editor) vers du statique

Le HTML propre et structuré en blocs de Gutenberg en fait un excellent candidat pour un site statique — mais WordPress ajoute encore une lourde surcouche. Ce guide explique comment migrer un site Gutenberg (Block Editor) vers une architecture statique sans perdre vos mises en page, vos URLs, votre SEO ni la facilité de modification du contenu.

Pourquoi les sites Gutenberg sont des candidats idéals pour le statique

L’éditeur de blocs Gutenberg produit un HTML bien plus propre et structuré que les constructeurs de pages WordPress traditionnels, ce qui en fait une excellente base pour un site statique. Au lieu de tableaux profondément imbriqués, de styles inline et de shortcodes propriétaires, la plupart des blocs Gutenberg natifs génèrent des balises sémantiques comme <section>, <h2> et <figure> qui peuvent être reliées directement à des templates statiques rapides. Cela signifie que le contenu et les mises en page que vous avez déjà construits dans l’éditeur de blocs sont beaucoup plus faciles à préserver lorsque vous migrez vers un générateur statique comme Hugo. Vous n’êtes pas en train de vous battre contre des couches d’anciens markups juste pour conserver votre design.

Cependant, même si la sortie de vos blocs est relativement propre, votre site Gutenberg hérite toujours de tout le surcoût runtime de WordPress. Chaque chargement de page déclenche l’exécution de PHP, des requêtes vers la base de données, des hooks de plugins et la logique du thème — même si le résultat rendu est essentiellement statique. Sur un site WordPress de taille moyenne typique, cela peut représenter des centaines de requêtes et des dizaines d’appels de plugins par requête, qui augmentent le Time To First Byte (TTFB) et le risque de pannes ou de ralentissements lorsque le trafic grimpe. L’éditeur de blocs améliore l’expérience d’édition, mais il ne change pas l’architecture serveur sous-jacente.

La génération statique résout ce problème en transformant chaque page rendue par Gutenberg en un fichier HTML préconstruit servi depuis un nœud de content delivery network (CDN) proche du visiteur. Bien réalisée, cette approche fait tomber le TTFB à quelques dizaines de millisecondes et élimine totalement les principaux goulots d’étranglement de performance de WordPress. Chez WordPressEscape, par exemple, nous reconstruisons régulièrement des sites basés sur Gutenberg en Hugo sur l’edge de Cloudflare, avec des scores PageSpeed dans les 90 et un TTFB autour de 30 ms, tout en préservant les mises en page en blocs. La clé est de traiter les blocs comme du contenu structuré que l’on peut mapper, et non comme des blobs HTML opaques aplatis une fois pour toutes puis oubliés.

Si vous utilisez déjà Gutenberg, vous avez une longueur d’avance : votre contenu est probablement plus portable et mieux structuré que celui de sites construits avec des shortcodes ou des constructeurs de pages complexes. Le travail de migration consiste surtout à faire correspondre les blocs à des templates statiques, à gérer les block patterns et blocs réutilisables, et à s’assurer que vos URLs, vos métadonnées et vos signaux SEO survivent à la transition. La contrepartie est que vous perdez le rendu dynamique en temps réel de PHP, mais vous gagnez une pile de delivery infiniment plus simple, plus rapide et plus sécurisée. Pour la majorité des sites orientés contenu, c’est un compromis très avantageux.

Quel surcoût Gutenberg continue de porter depuis WordPress

Gutenberg fonctionne à l’intérieur de WordPress, donc même si l’éditeur lui-même encourage un contenu moderne et structuré, chaque page est toujours servie par le cycle de requête classique de WordPress. Lorsqu’un visiteur arrive sur une URL, WordPress démarre PHP, charge des dizaines de fichiers core, exécute le thème, appelle chaque plugin actif et interroge la base de données pour les articles, options, menus et blocs. Cela se produit à chaque requête, même si le résultat final est du HTML statique sans personnalisation. Vous pouvez facilement perdre 100 à 300 ms rien que dans ce traitement backend avant que le premier octet ne quitte le serveur.

Beaucoup de sites Gutenberg traînent aussi un surcoût front-end lié aux assets du thème et des plugins. Styles globaux, gros bundles CSS, multiples fichiers JavaScript pour les blocs et les interactions, sans parler des polices et bibliothèques d’icônes, se chargent même sur des pages simples. Alors que la sortie de Gutenberg reste assez légère, la combinaison des plugins, de la bibliothèque de blocs et des scripts spécifiques au thème peut aboutir à des pages avec des dizaines de requêtes HTTP et plusieurs centaines de kilooctets de JavaScript inutilisé. Le navigateur doit analyser et exécuter tout cela, ce qui impacte des métriques comme le First Contentful Paint et le Cumulative Layout Shift.

Les contraintes de sécurité et de maintenance restent également présentes, quelle que soit la propreté de vos blocs. Vous devez toujours corriger le core WordPress, mettre à jour les plugins et gérer les thèmes pour éviter les vulnérabilités connues. Chaque plugin qui enregistre un bloc peut ajouter ses propres endpoints PHP, handlers Ajax et tables de base de données à maintenir et sécuriser. Pour les équipes qui veulent simplement publier du contenu, c’est une charge non négligeable et une source fréquente d’incidents. Une architecture statique élimine cette surface d’attaque en ne servant que des fichiers préconstruits et quelques APIs minimales et contrôlées.

En pratique, nous voyons des sites basés sur Gutenberg qui paraissent propres côté front-end mais souffrent toujours d’un TTFB élevé, de performances irrégulières sous charge et de conflits périodiques entre plugins. Lorsque nous les migrons vers Hugo sur l’edge de Cloudflare via WordPressEscape, nous supprimons complètement la couche WordPress runtime. Le HTML des blocs devient une entrée pour des templates et partials statiques, et WordPress est définitivement retiré une fois la migration terminée. La différence de complexité est considérable : au lieu de gérer une application PHP et une base de données, vous gérez des fichiers statiques et un éditeur simple. C’est précisément pour cela que Gutenberg est un excellent candidat pour le statique — parce que le principal frein vient de l’environnement dans lequel il tourne.

Comment le HTML des blocs Gutenberg se mappe vers des templates Hugo statiques

Le cœur de toute migration Gutenberg → statique est le mapping des blocs : vous avez besoin d’une méthode systématique pour transformer le HTML et les attributs générés par chaque bloc en représentations dans les templates de votre générateur statique. Heureusement, les blocs Gutenberg sont explicites sur leur structure, ce qui rend ce processus maîtrisable plutôt que de relever de la devinette. Un bloc typique produit un markup reconnaissable comme <div class="wp-block-image">… ou <ul class="wp-block-list">, assorti d’attributs data qui indiquent l’alignement, les styles ou le comportement responsive. Les générateurs statiques comme Hugo peuvent cibler ces motifs et appliquer un style équivalent via CSS et des partials.

Une approche efficace consiste à catégoriser les blocs de votre site en trois groupes : blocs de contenu core, blocs de layout et blocs personnalisés. Les blocs de contenu core incluent les paragraphes, titres, listes, images, galeries et citations — ils se mappent généralement en un pour un vers des éléments HTML standards et sont simples à reproduire dans les templates Hugo. Les blocs de layout comme colonnes, groupes ou cover blocks demandent plus de soin, car ils définissent la structure et les styles d’arrière-plan. Les blocs personnalisés, qu’ils proviennent de plugins ou de développements sur mesure, peuvent nécessiter des partials dédiés et du CSS spécifique dans le site statique pour obtenir un rendu similaire.

Pendant une migration, vous pouvez traiter chaque article ou page comme un document dont le HTML des blocs est analysé et conservé. Pour les migrations simples, vous pouvez exporter le HTML rendu tel quel et l’associer à des fichiers de contenu Hugo, en laissant un template de base gérer les wrappers globaux et la navigation. Pour des migrations plus raffinées, vous pouvez analyser les commentaires de blocs et métadonnées afin de reconstruire les hiérarchies de blocs comme données structurées. Cela vous permet de rendre les blocs différemment selon le contexte, d’optimiser le CSS pour certains types de blocs et éventuellement de retirer des wrappers spécifiques à Gutenberg tout en conservant la mise en page visuelle.

Le processus de WordPressEscape pour les sites Gutenberg s’appuie fortement sur cette discipline de mapping des blocs. Nous identifions chaque type de bloc utilisé sur le site, concevons des partials Hugo qui reproduisent leur sortie, puis injectons le HTML existant des blocs et leurs attributs dans ces partials. L’avantage, c’est que vous n’avez pas à reconstruire vos pages à la main ; vos mises en page actuelles en blocs restent en place, mais elles sont rendues par un générateur statique plutôt que par WordPress. Une fois le build Hugo exécuté, l’edge de Cloudflare sert ces pages avec des scores PageSpeed autour de 95 et une CLS stable à 0, grâce à un CSS prévisible et un HTML précomputé. Du point de vue de l’éditeur, les layouts sont identiques — la différence se situe uniquement dans la façon dont ils parviennent au visiteur.

Gestion des blocs réutilisables et des block patterns dans une refonte statique

Les blocs réutilisables et les block patterns sont deux des fonctionnalités les plus puissantes de Gutenberg, et ils demandent une attention particulière lorsque vous migrez vers un site statique. Un bloc réutilisable est en pratique un fragment de contenu partagé pouvant apparaître dans plusieurs articles ou pages, tandis que les block patterns sont des mises en page de blocs préconfigurées que vous pouvez insérer puis personnaliser à chaque utilisation. Tous deux existent au niveau du contenu, pas du thème, donc vous devez préserver leur comportement dans l’environnement statique pour éviter de dupliquer le contenu ou de perdre en flexibilité éditoriale.

Pour les blocs réutilisables, l’exigence clé est qu’une modification à un endroit se répercute partout où ce bloc est utilisé. Dans WordPress, Gutenberg gère cela en stockant les blocs réutilisables comme des posts séparés et en insérant des références dans le contenu. Dans un setup Hugo statique, vous pouvez reproduire cette logique en traitant les blocs réutilisables comme des partials ou des fichiers de données. Le contenu de chaque page référence le bloc via un identifiant, et Hugo rend la dernière version de ce bloc dans chaque page au moment du build. Lorsque vous mettez à jour le bloc réutilisable via votre éditeur, le build suivant met automatiquement à jour toutes les pages concernées, ce qui préserve ce comportement de source unique de vérité.

Les block patterns sont légèrement différents : ce sont des templates de layout plutôt que du contenu partagé. Une fois inséré dans une page, un pattern devient partie intégrante de l’arbre de blocs de cette page. Migrer les patterns signifie surtout s’assurer que les structures de blocs qu’ils génèrent se rendent toujours correctement dans le site statique. Comme les patterns ne sont que des combinaisons de blocs, votre stratégie de mapping des blocs les couvre dès lors que chaque type de bloc sous-jacent dispose d’un équivalent statique. Vous n’avez pas besoin d’un concept séparé de « pattern » au moment du build ; vous devez simplement préserver les mises en page résultantes des blocs.

WordPressEscape gère les blocs réutilisables et les patterns en exportant leurs définitions pendant la migration et en les connectant à ESC’dashboard — l’éditeur façon WordPress qui se place au-dessus de Hugo sans aucun WordPress en-dessous. Les blocs réutilisables deviennent des fragments éditables dans le dashboard, reliés à des partials ou données Hugo. Les patterns deviennent des presets de configuration que vous pouvez réinjecter dans de nouvelles pages. Du point de vue des éditeurs, vous conservez des contenus réutilisables et des mises en page basées sur des patterns ; du point de vue du système, tout est résolu en fichiers statiques que Cloudflare peut servir instantanément. Cette approche conserve les gains de productivité de l’ère Gutenberg tout en supprimant les dépendances runtime à WordPress.

Outils d’export statique DIY vs suppression complète de WordPress

Il existe deux grandes stratégies pour transformer un site Gutenberg en site statique : utiliser un outil d’export DIY tout en conservant WordPress comme backend caché, ou procéder à une refonte complète et supprimer WordPress entièrement. Des outils comme Simply Static et des plugins similaires entrent dans la première catégorie. Ils parcourent ou exportent vos pages WordPress existantes vers des fichiers HTML plats que vous déployez ensuite sur un hébergement statique. WordPress reste installé, souvent protégé derrière une connexion ou un domaine alternatif, et continue de servir de système de gestion de contenu. Cette approche est séduisante car elle est incrémentale et familière, mais elle présente plusieurs limites importantes.

Premièrement, les exports DIY sont généralement basés sur des instantanés. Ils génèrent du HTML statique à partir de l’état actuel de votre site, mais n’offrent pas intrinsèquement un workflow robuste pour les mises à jour incrémentales, le mapping des URLs ou la gestion de relations complexes de contenu comme les blocs réutilisables. C’est à vous de garantir que chaque URL est exportée, que les formulaires et la recherche fonctionnent, et que les redirections sont correctement configurées. Si votre site compte des dizaines ou des centaines de milliers d’URLs, les exporters basés sur le crawling peuvent manquer des cas limites, du contenu privé ou des routages particuliers, avec à la clé des liens qui servent un ancien contenu ou cassent totalement.

Deuxièmement, conserver WordPress comme backend caché signifie que vous n’avez pas supprimé ses obligations de maintenance et de sécurité. Vous devez toujours corriger les plugins, gérer l’hébergement et surveiller les vulnérabilités et problèmes de performance. Si votre base de données ou votre couche PHP tombe, vous ne perdez pas forcément votre front-end statique immédiatement, mais vous perdez la capacité de mettre à jour le contenu jusqu’à réparation du backend. Pour les organisations qui cherchent à simplifier leur stack et réduire le risque opérationnel, cette approche semi-statique ne résout qu’une partie du problème.

WordPressEscape se situe à l’autre extrémité du spectre : nous supprimons WordPress de manière permanente après avoir migré le site vers Hugo sur l’edge de Cloudflare. Au lieu d’exporter le HTML via un plugin et de laisser le CMS tourner, nous reconstruisons les URLs, les mises en page en blocs et les métadonnées sous forme de contenu et de templates Hugo, puis nous restituons les capacités d’édition via ESC’dashboard. À la différence des outils DIY, ce processus est conçu pour garantir qu’aucune URL ne soit perdue et que même les sites extrêmement volumineux — par exemple notre propre propriété de 528 854 pages — soient intégralement préservés. La contrepartie est une migration plus impliquante, mais le résultat est une architecture entièrement statique, sans instance WordPress cachée à maintenir.

Étape par étape : migrer un site Gutenberg vers Hugo statique

Un processus de migration structuré permet de préserver vos mises en page, vos URLs et votre SEO lors du passage du contenu Gutenberg vers un site Hugo statique. À haut niveau, vous pouvez découper le travail en phases de découverte, d’export, de refonte, de validation et de bascule. Chaque phase comporte des tâches spécifiques qui gardent la migration maîtrisée plutôt que bricolée. Même si vous choisissez finalement un service managé comme WordPressEscape, comprendre ces étapes vous aidera à évaluer le travail et à repérer les raccourcis susceptibles de créer des problèmes plus tard.

Commencez par la phase de découverte. Faites l’inventaire de vos types de contenu (articles, pages, custom post types), taxonomies et usages de blocs sur le site. Identifiez les templates critiques, les pages d’atterrissage clés et tous les blocs Gutenberg personnalisés fournis par des plugins ou votre thème. Documentez votre structure d’URLs, y compris les formats de permaliens, les archives de catégories, de tags et d’auteurs. Recensez les éléments SEO comme les titres, méta-descriptions, balises canonicals et données structurées. Cela vous donne une carte de tout ce qui doit exister dans la version statique.

Vient ensuite l’export. Pour un site plus modeste, vous pouvez utiliser l’API REST WordPress ou un plugin pour extraire tous les posts et leur HTML de blocs vers du JSON ou des fichiers plats. Pour les sites plus volumineux, il vous faut un processus d’export robuste capable de gérer des centaines de milliers d’URLs sans timeout — c’est là que des outils ou services spécialisés sont utiles, car les plugins standards atteignent souvent leurs limites. L’objectif est de sortir votre contenu brut et vos structures de blocs de WordPress dans un format cohérent et lisible par machine, accompagné des métadonnées critiques.

Puis vous reconstruisez dans Hugo. Définissez des types de contenu qui reflètent votre structure WordPress et créez des templates qui mappent la sortie des blocs Gutenberg vers des partials et layouts Hugo. Implémentez des règles d’URL qui correspondent exactement à vos permaliens existants afin que chaque ancienne URL pointe vers la page statique correspondante. Intégrez les métadonnées SEO, les balises open graph et tout markup schema nécessaire. Une fois le site Hugo construit avec succès, déployez-le sur votre CDN — dans le cas de WordPressEscape, sur l’edge de Cloudflare — et commencez la validation. Utilisez des contrôles automatisés et une revue manuelle pour vérifier que les pages clés s’affichent correctement, que les performances atteignent vos objectifs (par exemple, des scores PageSpeed autour de 94+ et un TTFB proche de 30 ms), et qu’aucune URL ne renvoie de 404 inattendu.

Éditer le contenu après migration : vivre sans WordPress

Une des principales préoccupations des utilisateurs de Gutenberg face à une migration statique est de savoir comment ils modifieront le contenu une fois WordPress supprimé. Les générateurs statiques comme Hugo sont traditionnellement basés sur des fichiers : vous validez des fichiers Markdown ou HTML dans un dépôt, lancez un build puis déployez. Ce workflow est idéal pour les développeurs mais nettement moins confortable pour les éditeurs non techniques habitués à l’interface visuelle de l’éditeur de blocs. Combler cet écart nécessite une couche d’édition familière qui fonctionne entièrement sur du contenu statique en coulisse.

Certaines configurations DIY résolvent ce point en conservant WordPress comme backend caché. Les éditeurs continuent d’utiliser Gutenberg, et un plugin exporte périodiquement le HTML mis à jour vers le front-end statique. Comme indiqué plus tôt, cela préserve l’expérience d’édition mais maintient la surcouche opérationnelle de WordPress. À l’inverse, des solutions de CMS headless peuvent fournir une interface web et pousser le contenu dans Hugo via des APIs, mais elles demandent généralement un travail d’intégration sur mesure et ne reproduisent pas toujours l’expérience exacte des blocs Gutenberg.

WordPressEscape répond au problème d’édition avec ESC’dashboard, un éditeur façon WordPress qui se place au-dessus du site Hugo statique. Les éditeurs se connectent au dashboard, gèrent articles, pages et contenus réutilisables, et utilisent une interface en blocs pour le layout. Lorsqu’ils enregistrent leurs modifications, le système met à jour les fichiers de contenu Hugo sous-jacents et déclenche un nouveau build. Aucune instance WordPress n’est impliquée — pas de PHP, pas de MySQL — mais le ressenti est volontairement proche de Gutenberg, afin que les équipes puissent basculer sans devoir se former à des outils centrés sur les développeurs. Le résultat est une architecture statique qui conserve une forte capacité d’itération et reste accessible aux éditeurs non techniques.

Si vous concevez votre propre solution, vous devrez choisir entre une édition orientée développeurs (modification directe des fichiers Hugo), une intégration avec un CMS headless ou la création d’un dashboard personnalisé. Le compromis se fait essentiellement entre contrôle et confort. Beaucoup de petites équipes sont à l’aise avec des workflows de type Git pour les changements de contenu, tandis que les organisations plus grandes bénéficient d’un éditeur dédié qui masque les détails d’implémentation. L’idée essentielle est qu’un site statique ne signifie pas « sans interface graphique » — cela signifie simplement que l’interface édite des fichiers plutôt qu’une application runtime pilotée par une base de données.

Préserver les signaux SEO et la structure d’URLs pendant la migration

Une migration vers le statique peut être neutre côté SEO, voire bénéfique, si vous traitez les URLs et les métadonnées comme des actifs de premier plan. La règle principale est simple : ne changez pas vos URLs sauf en cas de nécessité absolue. Pour un site Gutenberg qui passe sur Hugo, cela implique de configurer le routage Hugo pour reproduire exactement vos permaliens WordPress actuels. Si un article de blog est actuellement accessible à l’adresse /2023/05/15/post-name/, la version statique doit répondre au même chemin avec un contenu équivalent. Cela préserve l’autorité des liens, évite des redirections inutiles et garantit que les moteurs de recherche n’ont pas à réapprendre toute la structure de votre site.

La préservation des métadonnées est tout aussi importante. Les titres, méta-descriptions, balises canonicals et données open graph doivent être exportés depuis WordPress puis injectés dans vos templates Hugo. Si vous utilisez un plugin SEO, vous pouvez généralement en extraire les données via la base de données WordPress ou l’API pendant la migration. Les données structurées (par exemple JSON-LD schema.org) doivent également être recréées dans l’environnement statique. Comme les pages statiques sont préconstruites, vous pouvez souvent simplifier cette logique et éviter la complexité de la couche plugin, mais la sortie doit rester conforme à ce que les moteurs attendent.

Les sites statiques améliorent souvent les performances, ce qui influe indirectement sur le SEO. Un TTFB plus rapide, une CLS faible et des scores PageSpeed plus élevés améliorent l’expérience utilisateur et peuvent soutenir la stabilité ou la progression des classements. Lorsque WordPressEscape migre des sites Gutenberg, le résultat typique sur l’edge de Cloudflare est des scores PageSpeed autour de 94+ et une CLS stable à 0, avec un TTFB proche de 30 ms. Ces métriques contribuent à maintenir ou renforcer la visibilité, à condition que le contenu et les liens restent cohérents. L’hébergement statique réduit aussi le risque de downtime, ce qui constitue un autre avantage SEO pratique.

Pour vérifier la préservation du SEO, vous devez effectuer des crawls pré- et post-migration, comparer la couverture d’indexation et suivre les données de vos outils type Search Console. Surveillez les variations d’impressions, de clics et de position moyenne, et investiguez tout nouveau 404 ou soft 404. Si de légers changements d’URLs sont inévitables, mettez en place des redirections 301 des anciens chemins vers les nouveaux, en les documentant soigneusement. Dans les migrations à grande échelle, les systèmes comme ceux de WordPressEscape sont conçus pour garantir zéro perte d’URL — y compris sur des sites comptant des centaines de milliers de pages — afin de minimiser le risque SEO. Investir du temps dans la planification SEO en amont réduit considérablement les mauvaises surprises après la bascule.

Coûts, compromis et moments où la migration statique de Gutenberg a du sens

Migrer un site Gutenberg vers du statique n’est pas qu’une décision technique ; c’est un choix de coûts et de stratégie. Côté avantages, les sites statiques réduisent fortement les dépenses d’hébergement, éliminent le travail continu de mise à jour de WordPress et des plugins, et diminuent le risque d’incidents de sécurité. Pour de nombreux sites riches en contenu, les gains de performance à eux seuls — TTFB autour de 30 ms, PageSpeed dans les 90 et zéro layout shift — justifient le projet, surtout lorsque même de petites améliorations de classement se traduisent par des impacts business mesurables. À grande échelle, servir du HTML préconstruit depuis un CDN est bien moins coûteux et plus prévisible que de faire monter en charge PHP et des bases de données.

Les compromis se concentrent sur les fonctionnalités dynamiques et la flexibilité. Si votre site Gutenberg repose sur de la personnalisation côté serveur, des tableaux de bord utilisateurs complexes ou du rendu de données en temps réel, une approche entièrement statique exigera une réarchitecture autour d’APIs ou de fonctions serverless. Les formulaires de contact, la recherche et les commentaires auront besoin d’implémentations alternatives qui ne dépendent pas des comportements intégrés de WordPress. Beaucoup de sites utilisent déjà des services externes pour ces fonctionnalités, ce qui simplifie la migration, mais il est crucial d’inventorier les dépendances pour ne pas perdre de briques essentielles.

Sur le plan des coûts, les exports DIY sont peu chers en outils mais peuvent être chronophages et sujets aux erreurs, en particulier pour les gros sites. Vous économisez sur les frais de prestataires mais investissez davantage de temps interne pour gérer les exports, vérifier les URLs, traiter les nuances SEO et maintenir le backend WordPress caché. Les services managés comme WordPressEscape facturent la migration et la plateforme mais livrent une architecture entièrement statique avec WordPress définitivement supprimé, une expérience d’édition familière via ESC’dashboard et des garanties sur la préservation des URLs. Pour les petites équipes avec des sites simples, le DIY peut suffire. Pour les organisations avec des centaines de milliers de pages ou des enjeux SEO importants, une migration professionnelle réduit le risque.

Les sites Gutenberg sont particulièrement de bons candidats pour le statique lorsque le contenu est principalement informationnel, que les mises en page sont basées sur des blocs plutôt que du PHP sur mesure, et que l’entreprise valorise la stabilité et la vitesse plutôt qu’une personnalisation runtime poussée. Si votre équipe apprécie l’éditeur de blocs mais subit l’overhead permanent de WordPress, une refonte statique sur Hugo combinée à un éditeur façon WordPress peut offrir le meilleur des deux mondes : une diffusion rapide et sécurisée avec une expérience d’édition moderne. La décision finale consiste à arbitrer entre l’effort de migration immédiat et la simplicité opérationnelle ainsi que les performances à long terme.

Questions fréquemment posées

Supprimer WordPressConserver vos URLs + classementsStatique · PageSpeed dans les 90Éditeur ESC'dashboard