Migrer de WordPress vers Next.js : méthode et calendrier type

Une migration de WordPress vers Next.js prend huit à seize semaines pour un site d'entreprise de taille moyenne. Le travail se répartit ainsi : deux semaines d'inventaire et de décisions, quatre à dix semaines de conception et de développement, une semaine de bascule, et deux semaines de surveillance. La partie technique n'est pas le point difficile. Ce qui décide de la réussite, c'est l'inventaire de départ et le plan de redirections, qui sont aussi les deux étapes qu'on cherche le plus souvent à raccourcir.

Les trois décisions à prendre avant d'écrire une ligne

1. Que devient le contenu ?

Trois voies, avec des conséquences différentes.

WordPress reste, en mode découplé. L'administration WordPress continue d'exister, Next.js consomme son API. L'équipe éditoriale ne change pas ses habitudes. Vous gardez la maintenance de WordPress, la sécurité de son administration et sa base.

Le contenu migre vers un système moderne. Payload, Sanity, Strapi ou équivalent. Vous quittez complètement WordPress. C'est plus de travail au départ, et c'est le seul chemin qui supprime réellement la dette. Le choix entre ces outils est traité dans notre article sur les CMS découplés.

Le contenu passe dans le dépôt. Pour un site dont les pages changent rarement, les contenus vivent dans des fichiers versionnés. Le plus simple à maintenir, le moins souple pour une équipe non technique.

Notre recommandation par défaut : le second chemin, sauf si l'équipe éditoriale est nombreuse et que le changement d'outil est un risque organisationnel réel.

2. Que reprend-on, exactement ?

C'est la décision la plus rentable du projet et la plus inconfortable.

Un site WordPress de sept ans porte des centaines de pages dont une partie ne reçoit plus rien. Reprendre tout revient à payer pour transporter ce qu'on jettera, et à hériter d'une structure de navigation qui ne correspond plus à l'entreprise.

La règle que nous appliquons : toute page qui reçoit du trafic organique sur douze mois, qui reçoit des liens externes, ou qui a une utilité commerciale claire, est reprise. Le reste est examiné à la main.

Attention à la nuance : ne pas reprendre une page n'exonère pas de la rediriger. Une adresse qui reçoit des visites ou des liens doit mener quelque part de pertinent.

3. Quelle stratégie de rendu ?

Next.js permet plusieurs modes, et il faut choisir page par page.

Statique pour tout ce qui ne change pas à la minute : pages de service, articles, pages de droit. C'est le plus rapide et le plus robuste.

Statique avec revalidation pour ce qui change sans urgence : un blog, un portfolio. La page est servie depuis le cache et se régénère à intervalle défini.

Rendu à la demande pour ce qui dépend de la requête : une recherche, un espace connecté.

L'erreur courante consiste à tout rendre à la demande par habitude, ce qui donne un site plus lent qu'un WordPress bien mis en cache. Et l'erreur symétrique consiste à tout figer, ce qui oblige à redéployer pour corriger une virgule.

Le calendrier réel

Semaines 1 et 2, l'inventaire. Export complet des adresses depuis le sitemap et depuis la base. Export de la Search Console sur douze mois. Recensement des extensions actives et de ce que chacune fait réellement, des types de contenu personnalisés, des champs personnalisés, des formulaires, des intégrations. Décision sur ce qui est repris.

Cette étape produit deux livrables : la liste de ce qui est repris, et le tableau de correspondance entre les anciennes adresses et les nouvelles. Tout le reste du projet s'appuie dessus.

Semaines 3 à 6, la conception. Maquettes des gabarits, modélisation du contenu dans le nouveau système, arbitrages sur la navigation. Sur une simple migration technique sans refonte visuelle, cette phase se réduit fortement.

Semaines 5 à 12, le développement. Construction des gabarits, mise en place du système de contenu, migration des données, intégration des formulaires et des outils tiers. La migration des données est un script, pas une saisie, et il doit être rejouable autant de fois que nécessaire.

Semaine 13, la préparation. Fichier de redirections finalisé, relecture des pages qui portent le trafic, recette complète des formulaires et des parcours, mesure de performance de référence.

Semaine 14, la bascule. Changement de DNS, activation des redirections, soumission du sitemap, vérification immédiate des vingt pages principales.

Semaines 15 et 16, la surveillance. Exploration complète du site, suivi de la couverture et des positions, correction des adresses manquantes. Aucune modification de fond pendant cette période.

Le plan de redirections

C'est le seul poste où une erreur se paie en trafic perdu, et il mérite d'être décrit précisément.

Une redirection par adresse, permanente. Le code 301 transmet le référencement acquis. Une redirection temporaire ne le fait pas.

Une destination pertinente, jamais l'accueil. Rediriger tout vers la page d'accueil est traité comme une page introuvable déguisée. Une page sans équivalent va vers la rubrique parente.

Pas de chaînes. Une adresse qui redirige vers une adresse qui redirige perd de la valeur et du temps. Écrivez les redirections vers la destination finale.

Les cas particuliers de WordPress. Les pages d'archive par catégorie, par étiquette, par auteur et par date. Elles sont souvent indexées et souvent oubliées. Les images aussi : les adresses de la médiathèque sont indexées et reçoivent du trafic.

Le sujet est traité en détail dans notre article sur la conservation du SEO pendant une refonte.

Ce qui se passe mal, et pourquoi

Le site est reproduit à l'identique. On refait les mêmes pages, la même navigation, les mêmes défauts, avec une technologie plus récente. Le résultat est plus rapide et pas meilleur. Une migration est le seul moment où on peut trancher, il faut s'en servir.

Les formulaires sont oubliés. Sur WordPress, ils viennent d'une extension qui gère l'envoi, le stockage et les notifications. En partant, tout ça doit être reconstruit, et c'est un poste à part entière.

Le contenu est migré mécaniquement. Le HTML de WordPress porte l'échafaudage de son éditeur : conteneurs de mise en page, paragraphes vides, styles en ligne. Le reprendre fidèlement revient à importer la dette qu'on voulait quitter. La conversion doit nettoyer, et signaler ce qu'elle n'a pas su traduire plutôt que de l'abandonner en silence.

L'équipe n'est pas formée. Un nouveau système de contenu demande une prise en main. Sans elle, l'équipe ne publie plus, et le site se fige.

Questions fréquentes

Combien coûte une migration de WordPress vers Next.js ?

Le coût dépend du nombre de gabarits, du volume de contenu à reprendre et des intégrations existantes, pas du nombre de pages. Une migration technique sans refonte visuelle est nettement moins chère qu'une refonte complète. Nos projets de refonte commencent à 5 000 euros hors taxes, et une migration avec reprise du design existant se situe en dessous d'une refonte complète.

Peut-on garder l'administration WordPress ?

Oui, en mode découplé : WordPress continue de servir de back-office et Next.js consomme son API. C'est la voie la moins perturbante pour une équipe éditoriale habituée. Sa limite est qu'elle conserve la maintenance et la surface d'attaque de WordPress, donc une partie de ce qu'on voulait quitter.

La migration fait-elle perdre du référencement ?

Une baisse temporaire pendant la réexploration est normale, de deux à six semaines. Une perte durable vient du plan de redirections ou d'une réduction du contenu. Un site migré avec des adresses conservées ou correctement redirigées, et un contenu au moins équivalent, retrouve puis dépasse généralement son niveau grâce au gain de performance.

Combien de temps l'ancien site doit-il rester accessible ?

Le site n'a pas besoin de rester en ligne, mais gardez une sauvegarde complète, base comprise, pendant au moins un an. Elle sert à retrouver un contenu oublié, une adresse manquante, ou une donnée de formulaire. C'est une assurance qui ne coûte que du stockage.

Pour aller plus loin

Le point de départ de cette réflexion est souvent la lenteur, dont les causes sont décrites dans notre article sur les sites WordPress qui ralentissent. La question de savoir si Next.js est justifié pour votre cas est traitée dans l'article sur Next.js pour un site vitrine. Nous menons ces migrations de bout en bout, c'est l'objet de notre page migration WordPress vers Next.js.