Migrer un site WordPress vers Next.js se justifie quand le site n'en est plus un : comptes utilisateurs, tableaux de bord, parcours métier sur mesure, vrai multilingue avec RTL, ou un plafond de performance que le thème et les plugins ne laissent pas franchir. Pour un site de contenu avec des éditeurs satisfaits, un hébergement infogéré sérieux et des plugins qui font un vrai travail, WordPress reste la bonne réponse, et une refonte achète surtout une version plus chère de l'existant. Quand la migration se justifie, trois chemins existent (refonte complète, WordPress headless, migration progressive route par route), et quel que soit le choix, URL, redirections et signaux SEO doivent survivre intacts.
Quand rester sur WordPress est-il le bon choix ?
Si votre site est avant tout du contenu, que vos éditeurs apprécient l'admin, que votre hébergeur infogéré gère mises à jour et sauvegardes, et que vos plugins font un vrai travail (formulaires, réservations, adhésions, e-commerce), rester est le bon choix. Une migration coûterait des mois d'effort pour livrer un site qui fait le même travail. Nous refusons ces migrations, et nous le disons dès le premier échange.
WordPress fait tourner environ 43 % du web selon les mesures W3Techs de 2025, et ce n'est pas de l'inertie : pour une équipe éditoriale, cela reste l'outil de publication le plus productif du marché. Le référencement n'est pas un argument non plus : un WordPress bien tenu se positionne très bien, en recherche classique comme dans les réponses des IA, un point que nous détaillons dans notre guide du SEO IA sur WordPress. Si votre douleur réelle est un thème lent ou un page builder obèse, corrigez cela d'abord : c'est une fraction du coût d'une refonte.
Quels sont les vrais déclencheurs d'une migration vers Next.js ?
Quatre déclencheurs justifient le passage. Le site est devenu une application : authentification, tableaux de bord, parcours de devis ou de réservation qui se battent contre les limites des plugins. La performance a atteint un plafond infranchissable dans le thème et les plugins. Le multilingue exige un vrai routage i18n et du RTL. Ou les mises à jour de sécurité des plugins sont devenues une taxe hebdomadaire.
Le déclencheur performance mérite de l'honnêteté : un plugin de cache et un CDN règlent la majorité des problèmes de vitesse WordPress. Le plafond est réel quand les données terrain des Core Web Vitals restent mauvaises après ce travail, en général parce que le thème embarque des scripts et des styles impossibles à retirer sans le forker. Le déclencheur applicatif est le plus net que nous rencontrions : dès que vous écrivez du PHP sur mesure contre les entrailles d'un plugin pour construire des fonctionnalités produit, vous payez déjà le prix d'une application sur des fondations de CMS.
Quel chemin de migration choisir : refonte, headless ou progressif ?
Trois chemins fonctionnent en pratique. La refonte complète remplace WordPress entièrement : le résultat le plus propre et le coût initial le plus élevé. Le headless garde WordPress comme CMS derrière un front Next.js : les éditeurs conservent leur admin, vous gagnez une intégration à exploiter. La migration progressive (strangler) avance route par route et étale coût et risque.
Le headless dialogue avec WordPress via l'API REST ou WPGraphQL ; il convient aux équipes éditoriales qui ont besoin de fonctionnalités applicatives autour de leur contenu, mais prévisualisation, médias et invalidation de cache demandent chacun un câblage délibéré. Le strangler place un proxy devant le site et déplace une route à la fois, la même logique tranche par tranche que notre approche des migrations de backend sans arrêter la production : le chemin le plus sûr pour un site à fort trafic qui ne peut pas se permettre une bascule brutale.
| Critère | Rester sur WordPress | WordPress headless + front Next.js | Refonte Next.js complète |
|---|---|---|---|
| Expérience éditeur | Inchangée : l'admin que votre équipe connaît | Inchangée pour le contenu ; prévisualisation à câbler | Nouveau workflow à choisir et à apprendre |
| Plafond de performance | Borné par le thème et les plugins | Élevé : WordPress ne sert plus que le contenu | Le plus haut : vous contrôlez chaque octet |
| Charge d'exploitation | Un système, souvent infogéré | Deux systèmes plus l'intégration | Un système, mais à vous de l'opérer |
| Coût du changement | Quasi nul | Moyen | Le plus élevé |
| Quand il gagne | Site de contenu, éditeurs satisfaits | Équipe éditoriale plus besoins applicatifs | Le site est en réalité une application |
Votre douleur WordPress justifie-t-elle vraiment une migration ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Comment préserver les URL et le SEO pendant la migration ?
Construisez la carte de redirections 301 avant d'écrire la moindre ligne applicative. Exportez chaque URL qui a du trafic ou des backlinks (permaliens, archives de catégories, chemins de médias) et donnez-lui une destination explicite. Reportez ensuite métadonnées, sitemap XML et données structurées, et décidez qui édite le contenu après la bascule. Ces décisions protègent un référencement déjà payé.
Next.js gère la carte nativement via redirects() dans next.config, y compris des règles à motifs pour les permaliens datés :
// next.config.js
module.exports = {
async redirects() {
return [
// Anciens permaliens datés : /2023/05/mon-article/ devient /blog/mon-article
{
source: '/:year(\\d{4})/:month(\\d{2})/:slug',
destination: '/blog/:slug',
permanent: true, // 301
},
// Les archives de catégories retombent sur l'index du blog
{
source: '/category/:slug',
destination: '/blog',
permanent: true,
},
// Correspondances unitaires issues de l'audit d'URL
{
source: '/contact-2',
destination: '/contact',
permanent: true,
},
]
},
}Après la bascule, crawlez l'ancien sitemap et suivez chaque URL pour vérifier qu'elle atterrit sur un 200 en exactement un saut de redirection. Gardez la carte vivante au moins un an : l'autorité des liens se déplace lentement. Cette séquence est la colonne vertébrale de nos prestations de création de site quand elles partent d'un WordPress existant.
Qu'est-ce qui casse le plus souvent pendant la migration ?
Cinq choses cassent régulièrement. Les liens internes codés en dur dans le corps des articles continuent de pointer vers les anciens chemins ou l'ancien domaine. Les médias restent dans wp-content et finissent en 404. Les formulaires perdent leurs notifications et leur protection anti-spam. Les intégrations tierces (newsletter, analytics, pixels, webhooks CRM) s'arrêtent en silence. Et la question du workflow éditorial, jamais tranchée, ressurgit en « comment publie-t-on maintenant ? »
Chaque risque a un remède ennuyeux : passez un audit rechercher-remplacer sur le contenu avant l'export, migrez la médiathèque vers un stockage objet ou votre nouvelle chaîne d'assets avec des redirections pour les chemins wp-content, reconstruisez les formulaires en premier (ils sont souvent le seul point de conversion du site), et inventoriez chaque script tiers avant la bascule. Écrivez la décision éditoriale noir sur blanc : qui publie, dans quel outil, avec quelle prévisualisation. Les risques qui font mal sont ceux dont personne n'était responsable.
La checklist avant migration
- Confirmer qu'un vrai déclencheur existe (fonctionnalités applicatives, plafond de performance, i18n/RTL, fatigue des plugins) ; sinon, rester sur WordPress.
- Choisir le chemin en conscience : refonte, headless ou progressif, avec le tableau ci-dessus.
- Exporter l'inventaire complet des URL et écrire la carte 301 avant tout code applicatif.
- Trancher le workflow éditorial et le valider avec les personnes qui publient réellement.
- Inventorier formulaires, médias et intégrations tierces ; reconstruire d'abord les parcours de conversion.
- Après la bascule, crawler l'ancien sitemap et surveiller les 404 pendant un trimestre entier.