Migration de WordPress vers Next.js : changer de plateforme sans perdre son référencement

Cela en vaut la peine quand WordPress est devenu le problème, pas simplement parce qu’il est ancien. Les déclencheurs habituels sont un empilement d’extensions que personne ne maîtrise vraiment, des mises à jour qui attendent des mois et des besoins de connexion ou de droits d’accès pour lesquels le cœur de WordPress n’a pas été conçu. Si le site est à jour, utilise quelques extensions bien maintenues et que votre équipe modifie des pages chaque jour, renforcer WordPress coûte généralement moins cher et comporte moins de risques qu’une migration.

• De nombreuses extensions s’empilent pour gérer la connexion, les formulaires, les espaces membres ou les paiements, chacune avec son propre calendrier de mises à jour.
• Personne n’est responsable des mises à jour, si bien que les correctifs du cœur, du thème et des extensions attendent des semaines ou des mois.
• Vous avez besoin de MFA, de SSO ou de droits par rôle conçus dans le produit plutôt qu’ajoutés par des extensions.
• Le contenu change rarement, ou une équipe de développement le gère déjà.
• Le site est devenu un portail ou une application que WordPress peine à faire tourner.

Restez sur WordPress et renforcez-le dans le cas inverse : supprimez les extensions inutilisées, choisissez un hébergeur infogéré réputé, appliquez les correctifs en quelques jours, conservez des sauvegardes et placez un pare-feu applicatif web devant le site. Une faille de sécurité seule justifie rarement une migration. Quand une faille du cœur comme CVE-2026-87902 apparaît, la première tâche est de mettre à jour ; la migration est une décision distincte que vous pouvez prendre sereinement ensuite. Nos guides sur la sécurité de WordPress face à un site sur mesure et sur CVE-2026-87902 traitent les deux sujets.

Il existe deux voies principales. Dans la première, WordPress reste en CMS headless : les rédacteurs gardent l’administration WordPress, et un front-end Next.js récupère le contenu et construit les pages publiques. La documentation développeur de WordPress présente son API REST comme un moyen d’intégrer le contenu WordPress dans des applications entièrement séparées, utilisable depuis tout langage capable d’envoyer des requêtes HTTP et de lire du JSON. Dans la seconde voie, WordPress est abandonné et le contenu passe dans un autre CMS headless ou dans une interface d’administration sur mesure conçue pour votre équipe.

Le headless est souvent la première étape la plus légère, mais il conserve une administration WordPress à mettre à jour et à protéger. Une refonte complète supprime WordPress et coûte plus cher au départ. Choisissez selon qui modifie le contenu, à quelle fréquence, et quelle part de l’ancien système vous acceptez de garder en service.

Voici le processus que nous suivons pour les migrations WordPress. Chaque étape produit un document écrit, afin que rien ne dépende de la mémoire le jour du lancement.

1. 1

   Auditer le site

   Recenser chaque page, type de contenu, formulaire, rôle utilisateur et extension, et noter ce que chaque extension apporte réellement à l’activité. Rassembler les URL actuelles depuis le sitemap, un crawl et la Search Console pour ne pas oublier les pages qui ont du trafic ou des liens entrants.

2. 2

   Associer les anciennes URL aux nouvelles

   Donner à chaque ancienne adresse une destination dans un seul tableur : articles, pages, archives de catégories et d’étiquettes, pages d’auteur, flux et fichiers médias sous /wp-content/uploads/. Chaque ligne devient une redirection permanente.

3. 3

   Reconstruire et décider comment le contenu sera édité

   Reconstruire les gabarits en Next.js et choisir entre WordPress headless, un autre CMS headless ou une administration sur mesure, selon qui modifie le contenu et à quelle fréquence.

4. 4

   Transférer le contenu, les utilisateurs et les données

   Importer les articles, pages, médias et comptes, comparer à la main un échantillon avec l’ancien site et reconstruire la connexion avec le modèle d’accès dont vous avez besoin, comme des droits par rôle, la MFA ou le SSO.

5. 5

   Lancer et surveiller

   Basculer, tester les redirections, soumettre le nouveau sitemap et suivre dans la Search Console les erreurs et les pages manquantes. Après le lancement, les mises à jour des dépendances et la surveillance se poursuivent dans le cadre de la mission.

Google traite un changement de plateforme qui modifie les URL comme un déplacement de site. Son guide Search Central sur les déplacements de site avec changement d’URL (mis à jour le 20 août 2026) recommande des redirections permanentes côté serveur, comme 301 ou 308, une correspondance complète entre anciennes et nouvelles URL, et de conserver les redirections aussi longtemps que possible, au moins un an. Il précise aussi que, pour un site de taille moyenne, il peut falloir quelques semaines ou plus avant que Google affiche les nouvelles URL à la place des anciennes : quelques fluctuations après le lancement sont donc normales.

• Redirigez chaque ancienne URL directement vers la nouvelle page la plus proche. Évitez les chaînes de redirections et n’envoyez pas de nombreuses anciennes URL vers la page d’accueil.
• Dans Next.js, déclarez les redirections dans next.config avec permanent: true, qui renvoie un code 308. La documentation de Next.js signale que les hébergeurs peuvent limiter cette liste (Vercel en autorise 1 024) et suggère une table de redirections lue par Proxy à partir de 1 000.
• Donnez à chaque nouvelle page une balise canonical qui pointe vers elle-même. Dans Next.js, elle se définit avec alternates.canonical dans la Metadata API.
• Générez un sitemap des nouvelles URL avec app/sitemap.ts et soumettez-le dans la Search Console ; conservez l’ancien sitemap jusqu’à ce que le nouveau ait été soumis.
• Utilisez des redirections côté serveur, pas en JavaScript. La documentation de Google sur les redirections indique de n’utiliser les redirections JavaScript que si les redirections côté serveur ou par meta refresh sont impossibles.
• Gardez le site validé dans la Search Console, consultez chaque semaine après le lancement les rapports d’indexation et de sitemaps, et mettez à jour les liens internes pour que le site ne dépende pas de ses propres redirections.

Conservez le même nom de domaine si vous le pouvez. Changer de plateforme et de domaine en même temps rend les problèmes plus difficiles à identifier. Si le domaine doit changer, le guide de Google ajoute aux étapes l’outil de changement d’adresse de la Search Console.

WordPress multisite fait tourner plusieurs sites à partir d’une seule installation. La documentation de WordPress décrit des réseaux fondés sur des chemins (sous-répertoires) ou sur des domaines (domaines ou sous-domaines), où chaque site conserve ses propres tables de contenu et où seule la table des utilisateurs est partagée. Cela détermine le plan.

• Traitez chaque site comme une migration à part entière, avec sa propre table de correspondance des URL, son sitemap et ses vérifications dans la Search Console.
• Décidez tôt si les utilisateurs partagés restent dans un seul système de comptes ou sont séparés par site, et comment les administrateurs du réseau géreront ensuite l’ensemble des sites.
• Recensez les extensions et thèmes activés sur tout le réseau, car une seule extension peut porter des fonctions sur chaque site.
• Une seule application Next.js peut servir plusieurs domaines, et ses redirections peuvent filtrer sur le nom d’hôte : un même code peut donc contenir les tables de redirections de tous les sites.
• Migrez d’abord un site, surveillez son trafic de recherche pendant quelques semaines, puis migrez les autres.

Que vous fassiez appel à une équipe locale ou à distance, par exemple une entreprise britannique qui travaille avec une agence dans un autre pays, obtenez ces réponses par écrit avant de signer.

• La table complète des redirections fait-elle partie du périmètre écrit, et qui la vérifie après le lancement ?
• Comment notre équipe modifiera-t-elle et publiera-t-elle le contenu après le lancement, et la formerez-vous ?
• Quelles extensions seront reconstruites, lesquelles remplacées par un service et lesquelles abandonnées ?
• Comment les comptes utilisateurs et les connexions sont-ils transférés, et que verront les utilisateurs lors de leur première connexion ?
• Le domaine et les URL resteront-ils identiques, et pendant combien de temps surveillerez-vous le référencement après le lancement ?
• Qui est propriétaire du code, de l’hébergement, du CMS et des comptes du nom de domaine ?
• Quelles heures de notre journée de travail se recoupent avec les vôtres, et sous quel délai répondez-vous ?
• Qui met à jour les dépendances après le lancement, et est-ce prévu au contrat ?
• Pouvons-nous voir des migrations ou des plateformes de contenu que vous avez réalisées ?

Les délais et les coûts dépendent davantage du contenu et des URL que du code. Les principaux facteurs sont :

• Le nombre de gabarits de page distincts et de types de contenu personnalisés.
• Le nombre d’URL à rediriger, archives et fichiers médias compris.
• Les formulaires, paiements, espaces membres et intégrations CRM ou ERP que les extensions prenaient en charge.
• Le maintien de WordPress comme CMS headless ou son remplacement.
• Les comptes utilisateurs et le modèle de connexion, surtout avec MFA ou SSO.
• Les réseaux multisite et les langues supplémentaires, chacun avec ses propres URL.

Les chiffres publiés varient beaucoup et viennent surtout d’agences. À titre d’exemple, Kolonell, un studio web qui travaille à distance, a publié le 8 octobre 2026 une estimation pour les petites entreprises britanniques : de 13 000 £ à 30 000 £ hors TVA pour un passage à Next.js headless, sur 10–14 semaines (environ 2 semaines d’audit et de cadrage, 6–8 semaines de développement et de migration, et 2–4 semaines de tests et de mise en ligne progressive). Considérez-le comme le tarif d’une agence, pas comme un prix de marché. Certaines agences vendent un sprint de migration à prix fixe ; demandez ce qu’il comprend, en particulier les redirections et la formation des rédacteurs.

Nous ne publions pas de tarifs fixes. Notre consultation gratuite commence par les problèmes que vous rencontrez aujourd’hui, pas par une refonte : un appel de 30 minutes avec un ingénieur, une revue de votre site WordPress avec une recommandation de mise à jour, de renforcement ou de migration, et une recommandation écrite avec une estimation approximative du coût. Si rester sur WordPress est la meilleure réponse, c’est ce que dira la recommandation.

• Service de migration WordPress vers Next.js (en anglais)
• WordPress ou site sur mesure : migrer est-il plus sûr ? (en anglais)
• Faille WordPress CVE-2026-87902 : que faire (en anglais)
• Qu’est-ce qu’un CMS headless ?
• Réserver une consultation gratuite et une revue WordPress (en anglais)

• Google Search Central: Site moves with URL changes (updated 20 August 2026)
• Google Search Central: Redirects and Google Search (updated 14 April 2026)
• Next.js docs: redirects in next.config.js (updated 30 June 2026)
• Next.js docs: How to handle redirects in Next.js (updated 19 August 2026)
• Next.js docs: sitemap.xml file convention (updated 18 August 2026)
• Next.js docs: generateMetadata, alternates and canonical (updated 19 August 2026)
• WordPress Developer Resources: REST API Handbook (accessed 1 November 2026)
• WordPress Developer Resources: Multisite (accessed 1 November 2026)
• Kolonell: WordPress to Next.js migration cost for UK SMBs, agency estimate (8 October 2026)