Migrer un site WordPress vers Next.js : guide complet

J'ai fait une bonne douzaine de migrations WordPress → Next.js ces trois dernières années. À chaque fois, le même schéma : enthousiasme au début, panique au milieu quand on réalise l'ampleur des redirections à faire, soulagement à la fin quand on voit les scores Lighthouse passer de 40 à 95. Voici ce que j'ai appris à la dure et qui vous évitera de perdre votre trafic organique pendant la bascule.

La question à se poser avant toute chose

Est-ce que vous migrez par frustration ou par stratégie ? Beaucoup de dirigeants veulent migrer parce que "WordPress c'est vieux" ou "mon développeur préfère React". Mauvaises raisons. Les vraies bonnes raisons : performance qui plombe vos conversions, failles de sécurité récurrentes, maintenance qui vous coûte plus cher que prévu, besoin d'UX plus riche que ce que WordPress permet.

Si votre WordPress tourne bien, que Lighthouse est correct, que vos rédacteurs sont à l'aise, que le SEO performe — ne migrez pas. La migration coûte 6 à 15 k€ minimum, pour un gain potentiel qui doit être quantifiable. Faites d'abord un audit lucide.

Étape 1 : l'audit qui sauve votre SEO

Avant d'écrire la moindre ligne de Next.js, on audite l'existant. Screaming Frog sur tout le site pour avoir la liste complète des URLs. Export Google Search Console des 12 derniers mois pour identifier le top 50 des pages qui génèrent du trafic organique (ces URLs sont intouchables, elles DOIVENT avoir leur équivalent côté Next).

Pendant qu'on y est : inventaire des plugins (il y en a toujours plus qu'annoncé), des custom post types, des taxonomies, des formulaires (Gravity Forms vs Contact Form 7 vs WPForms, c'est pas pareil à migrer), des intégrations externes (Mailchimp, HubSpot, etc).

Full rewrite ou headless WordPress ?

Option A : on quitte WordPress définitivement

Contenu migré vers MDX (dans le repo Git) ou vers un CMS headless moderne (Sanity, Payload CMS). Moins de 100 pages, équipe éditoriale d'accord pour changer d'outil. Avantage : architecture propre et moderne. Inconvénient : courbe d'apprentissage pour les rédacteurs, 3-4 semaines de grincements de dents.

Option B : WordPress headless

WordPress reste le CMS (vos rédacteurs sont heureux, ils changent rien), le front devient 100 % Next.js qui consomme l'API REST ou GraphQL de WordPress. Best of both worlds. Mon choix par défaut pour les sites à gros volume éditorial (blogs, magazines en ligne, sites corporates avec équipe com dédiée).

Piège d'Option B : WP doit rester accessible publiquement pour que Next le query. Exposez uniquement les endpoints API, bloquez /wp-admin derrière un VPN, et surtout gardez WordPress à jour côté sécurité quand même.

Étape critique : les redirections 301

C'est LÀ que 80 % des migrations perdent leur trafic. L'ancienne URL /2024/03/mon-article-sympa doit rediriger vers /blog/mon-article-sympa (ou quelle que soit votre nouvelle structure). Chaque ancienne URL a une destination. Pas de "on verra pour les vieilles pages".

J'utilise deux techniques : le middleware Next.js pour les patterns (date-based → slug-based), et le next.config.ts redirects pour les URLs individuelles irrégulières. Je génère la map de redirections à partir de l'export Screaming Frog et de la nouvelle structure. Testez en staging avec un crawler avant la bascule. Chaque 404 est du trafic perdu.

La bascule : planifier un mardi matin

Règle de terrain : jamais migrer un vendredi. Jamais. Vous basculez mardi ou mercredi matin, vous avez 3-4 jours pour détecter les problèmes avant le weekend. J'ai fait une fois une bascule un vendredi soir "parce que moins de trafic". On a passé le weekend à éteindre des incendies. Jamais plus.

Checklist de bascule : staging validé, redirections testées avec crawler, Search Console prêt pour resubmit du sitemap, DNS TTL baissé 48h avant (300 secondes), plan de rollback prêt (pointer le DNS sur l'ancien serveur). Et surveillance intensive des 48h suivantes.

Le post-mortem SEO qu'on ne vous explique pas

Dans les 2-4 semaines post-migration, vous AUREZ une chute de 10 à 30 % du trafic organique. Normal. Google met du temps à re-crawler votre nouveau site, à valider les redirections, à recalculer vos positions. Ne paniquez pas à J+5.

Par contre, si au bout de 6 semaines la chute dépasse 50 % ou ne se résorbe pas, vous avez un problème. Vérifiez dans cet ordre : robots.txt (souvent mal configuré après migration), sitemap soumis et accepté, redirections 301 complètes (sans chaînes), Core Web Vitals, données structurées Schema.org préservées. Une de ces 5 choses est quasi toujours le coupable.