Migration d'un site WordPress vers une architecture headless : WordPress conservé comme back-office ou remplacé par un CMS headless, front pré-généré en Next.js ou Astro, extensions requalifiées une à une, référencement préservé.
« Passer WordPress en headless » recouvre deux projets qui n'ont ni le même coût ni le même risque. Garder WordPress comme back-office : les éditeurs conservent l'outil qu'ils connaissent, le contenu est lu par le front via l'API REST native de WordPress ou via l'extension WPGraphQL, et seul l'affichage est reconstruit. Sortir de WordPress : le contenu est migré vers un CMS headless (Strapi, Directus, Payload) et WordPress est arrêté. La première voie modernise le front sans toucher aux habitudes éditoriales ; la seconde règle aussi la dette du back-office, au prix d'une migration de contenu et d'une formation des équipes.
Trois signaux justifient de se poser la question.
C'est le cœur du cadrage : en headless, le thème WordPress n'affiche plus rien, donc tout ce qui produisait du HTML doit être repris.
Pour un site vitrine de quelques dizaines de pages, sans application mobile ni autre canal, et sans équipe technique dans la durée, un WordPress mis à jour et allégé reste plus économique. Le headless se justifie quand au moins trois des six questions de notre page Migration CMS vers headless reçoivent un « oui ». Si le besoin principal est l'éditorial multi-acteurs ou le multilingue avancé, voir aussi Migration WordPress vers Drupal.
WordPress avec thème, extensions et constructeur de pages (Elementor, ACF, Yoast, formulaires)
Front pré-généré Next.js ou Astro, contenu servi par WordPress headless ou par un CMS headless
Contenus simples (articles, pages, catégories) et volonté de ne rien installer de plus côté WordPress. Le chemin le plus court.
Contenus structurés avec beaucoup de champs personnalisés et de relations : une seule requête récupère une page complète.
Back-office WordPress lui-même en fin de vie ou surchargé d'extensions : la migration règle les deux dettes à la fois. Comparatif dans Migration CMS vers headless.
Petite équipe technique qui publie elle-même, rythme de publication faible : contenus dans le dépôt de code, aucun back-office à maintenir.
Site vitrine simple, éditeurs autonomes sans appui technique : mettre à jour PHP et les extensions, retirer celles qui ne servent plus.
Estimation indicative, à confirmer au cadrage : comptez 8 à 16 semaines selon le volume de contenus, le nombre de mises en page à reconstruire (constructeurs de pages) et les intégrations tierces. Garder WordPress comme back-office se situe dans le bas de la fourchette ; en sortir pour un autre CMS, dans le haut. Équipe type : un chef de projet, deux développeurs front (Next.js ou Astro), un développeur WordPress pour l'API et la migration des contenus, un référent SEO à temps partiel.
Référencement perdu à la bascule : changement d'URL, métadonnées Yoast oubliées, redirections incomplètes.
Cartographie de toutes les URL avant le premier développement, table de redirections 301 exhaustive, métadonnées lues depuis WordPress par le front, suivi Search Console après la mise en ligne.
Aperçu éditeur cassé : en headless, le bouton « Prévisualiser » de WordPress ne montre plus la page réelle.
Mode brouillon du front (celui de Next.js) branché sur WordPress, pour que l'éditeur voie la page finale avant de publier. À prévoir dès le cadrage, pas après les plaintes.
Codes courts (shortcodes) et blocs qui produisent du HTML : le contenu arrive dans le front avec des balises que le nouveau design ne sait pas afficher.
Inventaire des shortcodes et des blocs utilisés, conversion en composants du front, tests sur un échantillon de pages de chaque type avant la migration de masse.
Délai de publication mal compris : avec un front pré-généré, une page publiée dans WordPress n'apparaît qu'après la régénération du site.
Régénération déclenchée automatiquement à chaque publication, ou régénération incrémentale des seules pages modifiées ; délai annoncé aux éditeurs avant la bascule.
Le site access-international.dev est passé de WordPress à un front Next.js en export statique le 23 avril 2026, bilingue français et anglais, avec les redirections des anciennes URL WordPress préservées. Nous n'avons pas conservé de CMS : c'est un exemple de front pré-généré, pas de WordPress headless.
Maîtrise des sites WordPress source via des projets livrés : Azur City (plateforme WordPress multi-sites pour 3 centres commerciaux) et Gnet News (portail d'actualité WordPress). Cette pratique du back-office WordPress sert à qualifier le patrimoine à migrer : extensions, champs personnalisés, taxonomies, médias.
Oui, et c'est souvent la meilleure entrée. WordPress reste le back-office des éditeurs ; le front est reconstruit à part et lit le contenu par l'API REST native ou par WPGraphQL. Seul l'affichage change.
L'API REST est intégrée à WordPress et suffit pour des contenus simples. WPGraphQL demande une extension mais récupère une page complète en une seule requête : il devient préférable dès que les champs personnalisés et les relations se multiplient.
La mise en page Elementor n'est pas exploitable telle quelle par l'API : elle est reconstruite en composants dans le front, et c'est le poste le plus lourd du chiffrage. WooCommerce en headless est un projet à part ; si la boutique fonctionne, nous recommandons en général de la laisser sur WordPress et de ne découpler que la partie éditoriale.
Il peut l'être, à condition de le traiter avant le premier développement : cartographie des URL, redirections 301 exhaustives, métadonnées reprises depuis WordPress, suivi Search Console après la mise en ligne. Aucune migration n'est à l'abri d'une variation de trafic : le suivi sert à la repérer tôt. Voir aussi notre page Migration CMS vers headless.
Le coût dépend surtout du nombre de mises en page à reconstruire (constructeurs de pages), puis du choix de garder ou non WordPress comme back-office, et des intégrations (formulaires, CRM, e-mailing). Cadrage initial gratuit, de 30 minutes à 2 heures.
Nous cadrons la trajectoire, le chiffrage et les livrables en un premier échange de trente minutes. Un POC court peut être proposé avant engagement du programme complet.
Lancer ce parcours →