De WordPress à Next.js : privilégier l'approche « headless » ou opter pour une migration propre.

Ce qui est transféré de WordPress vers Next.js, et ce qui ne l’est pas?

Vos articles, pages, catégories, balises, médias et utilisateurs sortent sous forme de données. Mais pas votre thème, vos extensions ni le contenu généré par les shortcodes. Avant de planifier le développement, interrogez l’API REST : elle liste les URL /wp/v2/posts, /wp/v2/pages, /wp/v2/categories, /wp/v2/tags, /wp/v2/media et /wp/v2/users, ce qui vous montre quels types de contenu renvoient réellement du JSON.

Votre couche de mise en page reste sur place. Si vos rédacteurs ont construit des pages avec des blocs ou un constructeur de pages, votre champ « corps » contient du HTML brut ou du balisage de blocs à analyser, par exemple en le convertissant en « Portable Text » dans Sanity, en séparant les mises en page visuelles en champs structurés. Formulaires et curseurs sont à recréer, de même que le balisage venu des plugins. Vos métadonnées SEO doivent aussi avoir une voie d’export : WPGraphQL expose les titres et descriptions Yoast via son champ « seo ».

Ouvrez /wp-json/ sur votre domaine. Regardez ensuite le code source de votre page : en quelques minutes (parfois moins), vous verrez quelles données manquent. Et l’évaluation lit les mêmes signaux publics. Elle relève votre balisage et vos en-têtes, ainsi que vos données structurées, avant que vous ne validiez le code.

Comment planifiez-vous la structure des URL et les redirections afin de préserver votre trafic de recherche ??

Commencez par le plan de redirection : associez chaque ancienne URL à une nouvelle URL, puis créez des redirections permanentes côté serveur, afin que votre trafic de recherche arrive sur les bonnes pages. Google demande de faire correspondre les anciennes URL aux nouvelles et d’éviter les chaînes de redirection (les fameuses cascades de 301). Il demande aussi d’envoyer un nouveau plan du site, et de suivre le trafic des deux côtés. Sans plan, vous naviguez à vue.

Dans Next.js, écrivez vos règles dans l’option « redirects » du fichier next.config.js. Mais testez-les avant. La valeur « permanent: true » renvoie un statut 308, que les navigateurs et les robots d’indexation gardent en cache indéfiniment : vérifiez donc chaque règle avant de la déployer. Les modèles de chemin s’appliquent depuis la racine. « /old-blog/:slug » ne correspondra pas à « /old-blog/a/b », et vos URL imbriquées demandent donc des règles explicites. Le routeur est bien plus strict qu’il n’en a l’air.

Gardez vos redirections actives pendant au moins un an. Retirez les balises « noindex » et les règles « disallow » du robot.txt restées sur l’environnement de préproduction (un grand classique des oublis). Faites aussi pointer vos balises « canonical » vers les nouvelles URL. Si votre backend « headless » demande aux moteurs de recherche de rester à l’écart, le champ SEO de chaque article peut renvoyer la balise « noindex », et vos URL Yoast peuvent afficher l’hébergeur de votre CMS. Ces restes de préproduction sabotent un lancement en silence.

Comment transférer le contenu depuis WordPress : exportation, API ou exploration ??

Dès que votre site dépasse quelques pages, migrez votre contenu via l’API : l’API REST renvoie au format JSON vos articles et vos pages, ainsi que vos balises, catégories et médias. Et pour les données absentes des points d’API, l’extraction du code HTML rendu reste votre recours. Autre option, reprendre le modèle d’API de Sanity : lancez un script CLI qui interroge l’API REST, crée des documents, puis pagine jusqu’à ce que les réponses cessent d’arriver.

La liste des médias renvoie 10 éléments par page par défaut. Votre script doit donc définir les paramètres « page » et « per_page » dans une boucle de récupération. Les outils de Sanity regroupent les mutations par lots. Ils tournent par défaut en mode « à sec » et valident vos documents par rapport à votre schéma Studio : vous voyez les erreurs avant d’enregistrer les données. Rendez votre script idempotent avec des identifiants déterministes, et téléchargez les ressources en parallèle en limitant la concurrence avec p-limit. Un script impossible à relancer sans risque finit toujours par faire peur.

Si un éditeur de pages génère votre balisage, parcourez le rendu et analysez le code HTML, puis comparez le nombre total d’enregistrements à votre liste d’URL de référence. Repérez les données manquantes avant le lancement. Après coup, ce sont vos lecteurs qui essuieront les plâtres.

Quels sont les avantages pour vos rédacteurs sur Next.js par rapport à WordPress ??

Si vous passez en « headless », vos rédacteurs gardent l’interface d’administration WordPress ; si vous transférez votre contenu, ils utilisent un nouvel éditeur (Sanity Studio ou Contentful). Dans les deux cas, ils perdent l’espace de travail visuel de votre thème et de votre constructeur de pages. Ce qu’ils modifient devient des champs : ils remplissent des formulaires au lieu de retoucher la page telle que vos lecteurs la voient. Le choc des habitudes est bien réel.

Vos rédacteurs vous interrogeront d’abord sur les aperçus. Créez dans Next.js une route d’aperçu qui récupère le contenu provisoire, puis testez-la avant le lancement avec votre rédacteur le plus lent. Avec l’ISR, la première requête après votre fenêtre de revalidation affiche encore l’ancienne page pendant que la régénération est en cours. Prévenez votre équipe avant qu’elle ne vienne vous signaler un faux problème.

Autre limite que vous sentirez vite : les plugins. Vos plugins de référencement et de redirection, comme ceux de formulaires, ne fonctionnent plus sur la nouvelle interface utilisateur. Vous devez donc recréer chaque fonction sous forme de champ ou de service, ou encore de règle de routage. Mais en échange, vous obtenez une interface que vos rédacteurs ne peuvent plus casser lors d’une mise à jour de plugin.

Combien de temps dure une migration de WordPress vers Next.js, et quels sont les facteurs qui déterminent l'ampleur de la tâche ??

La durée de votre migration dépend du nombre d’URL, des types de contenu, de la médiathèque, des intégrations et des paramètres régionaux. Aucun audit public ne peut vous donner une date sûre. Mais vous pouvez relever chaque variable depuis l’extérieur : le plan du site donne le nombre d’URL, les routes /wp-json/ exposent les types de contenu, et les formulaires comme les scripts signalent les intégrations. Commencez par cet inventaire, puis chiffrez l’effort.

Chaque facteur grossit les autres. Beaucoup d’URL avec un seul type de contenu demandent surtout des redirections. Peu d’URL réparties sur plusieurs types de contenu demandent plutôt un modèle de schéma. Si vos pages de liste de médias affichent 10 éléments par défaut, une grosse bibliothèque produit des milliers de requêtes, et chaque paramètre régional en plus multiplie les URL à faire correspondre. Je planifie et pilote ce type de migration, et le même constat revient souvent : l’installation n’est presque jamais ce qui prend le plus de temps. Le vrai travail, c’est de décider ce que votre contenu doit devenir.

ISR met à jour le contenu statique en cache sans reconstruire tout le site. So vos délais de déploiement ne s’allongent pas à mesure que votre nombre de pages augmente.

Dans quels cas ne devez-vous pas passer de WordPress à Next.js ??

Ne changez pas de système si votre site fonctionne correctement, si vos éditeurs l’utilisent sans difficulté et si aucun problème lié à l’application, à la personnalisation ou à l’éditeur ne serait réglé par une nouvelle interface. Gardez votre site actuel tant que les faits ne disent pas l’inverse. Commencez par l’évaluation gratuite : si votre score se situe entre 80 et 100, la version actuelle ne bloque pas le site, et une refonte grignoterait votre budget tout en exposant votre trafic de référencement, pour un gain faible.

WordPress « headless » n’a du sens comme étape intermédiaire que si vos rédacteurs doivent garder leur administration et que votre interface publique pose problème. Sinon, vous exploitez deux systèmes : WordPress pour le contenu et Next.js pour les pages. Et vous devez corriger, héberger et surveiller les deux. Si vous choisissez cette transition, adaptez la pile technique à votre site : Astro pour un site de contenu ou de marketing, Next.js avec Sanity ou Contentful si vous gérez une application, un système de personnalisation ou une grande équipe éditoriale. Chaque option vous fait abandonner ce que vos rédacteurs connaissent : l’interface visuelle, les plugins et un espace d’administration hébergé (les trois, pas seulement l’un d’entre eux).

Vos questions, nos réponses.

À lire ensuite.

1. 01Alternatives à WordPressRestez, optez pour le mode « headless » ou changez de plateforme : c'est à vos pages d'en décider.
2. 02De WordPress vers AstroPages prédéfinies, contenu au format Markdown ou dans un CMS « headless ».
3. 03Audit SEO Next.jsMode de rendu, métadonnées, coût d'hydratation.
4. 04Audit SEO de CMS headlessRendu, URL canoniques, aperçus, données structurées du modèle.