Migration de WordPress vers Next.js sans perdre un seul classement.

Honnêtement ? Surtout parce que Lighthouse n'arrive jamais vraiment jusque-là.

J'ai passé pas mal de matinées à expliquer aux fondateurs pourquoi leur site Elementor, construit avec amour, plafonne à 62 en PageSpeed Insights même après trois plugins de cache, un CDN et un changement d'hébergement tout neuf. Il y a un plafond. Vous pouvez pousser un front-end WordPress classique vers les bas 80 si vous y tenez vraiment, mais chaque mise à jour de plugin est un risque de régression et chaque sortie de page builder expédie une demi-mégaoctet de plus que vous ne l'aviez demandé.

Les équipes que j'ai vues migrer se divisent en trois catégories grosso modo, et elles ne se chevauchent presque jamais.

Le bucket performance

Un site marketing SaaS en Série A, actuellement sur WP Engine, payant pour Elementor Pro plus trois packs d'add-ons. Lighthouse 64 sur mobile. INP à 380 ms. Ils ont une équipe de contenu qui sort deux posts par semaine et une équipe d'engineering qui veut livrer des flux d'onboarding, pas des patches WordPress. La refonte Next.js les amène à 96, et les engineers arrêtent de toucher à wp-admin.

Le bucket engineering

Trois engineers TypeScript. L'un d'eux assure l'on-call pour le site marketing. Ils ouvrent wp-admin une fois tous les quinze jours et jure. Tout le cirque « c'est PHP 7.4 ou 8.1, quelle version de WooCommerce l'agence nous a-t-elle laissée » est un impôt sur des gens qui expédieraient volontiers en Astro pour moitié moins de tracas. Migrez, donnez-leur un repo Next.js ou Astro avec une CI appropriée, et la rotation d'on-call rétréci.

Le bucket sécurité

Moins courant, plus décisif. Un mandat du conseil d'administration selon lequel les surfaces publiques ne doivent pas exécuter PHP. Ou un incident de sécurité qui a livré un plugin patché trois semaines trop tard. Un WordPress headless sur une origine non publique satisfait la politique sans forcer l'équipe éditoriale à apprendre un nouveau CMS. Le wp.example.com devient privé ; le front-end est juste un site statique sur Vercel. La plupart des pen tests cessent d'être intéressants.

Trois. Vraiment trois, pas la sorte de page marketing qui s'effondre toujours dans le même périmètre. Chacun convient à une équipe différente.

Chemin 1 — garder WordPress, remplacer le front-end

Headless. WP reste la surface d'édition. Yoast continue son travail dans l'admin. ACF continue son travail dans l'admin. Le site public est reconstruit en Next.js ou Astro et récupère le contenu via WPGraphQL. Les éditeurs remarquent à peine la migration le jour du lancement, sauf que la barre d'adresse affiche le nouveau domaine du front-end. C'est le chemin le plus courant que je propose ; environ deux tiers des migrations récentes ont suivi cette voie.

Quand c'est approprié : l'équipe éditoriale est heureuse dans WordPress, le problème technique est purement front-end, et tu ne veux pas migrer douze mille pages de métadonnées Yoast.

Chemin 2 — quitter WordPress complètement

Migrer tout vers Sanity, Payload, Storyblok ou Contentful. Arrêter WordPress au lancement. Base de code plus récente, modèle de contenu plus propre, zéro PHP partout. Le coût de migration est plus élevé parce que tu déplaces le contenu, pas seulement le front-end. Ça vaut le coup quand l'équipe éditoriale veut vraiment quitter WordPress, ou quand le modèle de contenu a besoin de plus de rigueur que le contenu flexible ACF ne peut en donner.

Quand c'est approprié : tu veux vraiment un CMS différent, pas juste un front-end différent.

Chemin 3 — hybride

Certains contenus restent dans WordPress, d'autres se déplacent ailleurs. Exemple réel : le blog reste dans WP parce que l'équipe éditoriale est mature et Yoast fait du vrai travail ; les pages produits passent à Payload parce que le schéma a besoin de vraies relations et validations. Le front-end est une seule application Next.js lisant depuis les deux backends. Plus d'architecture, mais parfois c'est la bonne réponse.

Quand c'est approprié : deux formes de contenu vraiment différentes sur le même site, et forcer les deux dans un seul CMS rend la vie plus difficile à quelqu'un.

C'est là que les migrations vivent ou meurent, et c'est aussi la partie que les équipes esquivent régulièrement. Sans une carte complète, tu perds ton classement le premier jour. Avec une carte partielle, tu les perds lentement sur six semaines pendant que tu te dis que la baisse n'est que de la saisonnalité.

La carte se construit à partir de trois sources indépendantes avant que du code ne soit déployé.

1. Export Search Console — chaque URL que Google a crawlée et considérée comme indexable au cours des 16 derniers mois. C'est la liste canonique de ce que Google s'attend actuellement à trouver sur votre domaine.
2. Export Ahrefs ou Semrush — chaque URL ayant au moins un domaine de référence pointant vers elle, triée par nombre de domaines de référence. Ce sont les URLs où la préservation des 301 compte le plus. Si vous servez une 404 sur une page avec 200 backlinks, vous venez de jeter 200 backlinks à la poubelle.
3. Sitemap WordPress — votre export de sitemap XML actuel. Capture les pages qui n'ont peut-être pas de backlinks ou de trafic organique mais sont toujours présentes dans la structure. Utile comme troisième passage pour trouver tout ce que les deux premiers ont manqué.

Trois listes, dédupliquées, mappées vers de nouvelles URLs, déployées en tant que 301s dans vercel.json ou netlify.toml à la limite du réseau. Pas des 302s. Pas des redirects pilotées par JavaScript. Pas une meta refresh. Les URLs réellement supprimées reçoivent un 410. Les URLs dont le slug a changé reçoivent un 301. Le linter de build échoue le déploiement si une URL pré-migration manque dans la map.

J'ai vu une migration de 5 000 pages perdre 60 % de son trafic organique en huit semaines parce que la carte de redirection était complète à 87 % et « le reste ne vaut pas la peine de s'en préoccuper ». Ces 13 % valaient la peine de s'en préoccuper. Ils le valent toujours.

Audit des plugins le jour un. Chaque plugin actif atterrit dans l'un des quatre buckets, et le bucket détermine le travail.

Reste tel quel

Plugins qui s'exécutent côté serveur et ne touchent jamais au front-end public. WP Migrate DB, BackWPup, analytics côté serveur, gestion des rôles. Ils continuent de fonctionner parce que rien dans leur rôle n'implique de rendre du HTML à un visiteur. Environ 20-25 % du nombre de plugins tombe habituellement ici.

Remplacé par du code

Plugins qui injectent du HTML ou du JavaScript dans le front-end. La plupart des plugins SEO (les transports de métadonnées, l'output front-end est personnalisé). La plupart des plugins de formulaire (remplacés par des endpoints Next.js ou par ConvertKit / HubSpot / Mailchimp). La plupart des plugins de schema (remplacés par des templates écrits à la main qui émettent du JSON-LD plus propre de toute façon). Les bannières de cookies sont réécrites en TypeScript. Environ 30-40 % du nombre de plugins.

Remplacé par un service

Plugins qui wrappent un tiers. Le plugin d'embed HubSpot devient un appel HubSpot Forms API. Le plugin de paiement Stripe devient Stripe Elements. Zapier et Make restent où ils sont parce qu'ils vivent en dehors de WordPress de toute façon. Environ 10-15 % du nombre.

Supprimé entièrement

Des plugins qui n'existent que parce que le front-end WordPress en avait besoin. Les plugins de cache (Vercel s'en charge). La plupart des plugins de sécurité (la surface d'attaque publique a disparu). Les plugins d'optimisation de performance (c'est maintenant une préoccupation du temps de build). Et le groupe toujours amusant « je n'ai aucune idée pourquoi c'est là, c'est désactivé depuis deux ans mais on ne l'a jamais supprimé ». Le nombre de plugins côté WordPress chute généralement de 70 à 80% après la migration. C'est une partie du gain.

Aperçu et brouillons

Les éditeurs cliquent sur Preview dans wp-admin. WordPress génère un token JWT de preview. Le front-end Next.js lit le token, récupère le brouillon via WPGraphQL en contournant le cache statique, et render. Les URLs de brouillon sont signées, jamais indexables, jamais cachées publiquement. L'UX de preview en un clic reste exactement comme avant. La plupart des éditeurs ne remarquent jamais le jour de la migration côté éditorial.

Commentaires, révisions, rôles

Inchangés côté back-end. Les commentaires sur les posts peuvent rester natifs à WordPress et se renderer headless via WPGraphQL, ou être remplacés par Disqus / Giscus / un système personnalisé si votre équipe l'aurait voulu de toute façon. Les révisions sont inchangées — chaque post garde son historique complet accessible depuis l'éditeur WordPress. Les rôles utilisateurs, les permissions, les configurations multi-auteurs, tout est préservé.

Yoast et Rank Math

Les deux transportent. Yoast SEO for WPGraphQL expose chaque champ — mot-clé de focus, meta titre, meta description, canonical, OG, Twitter card, schema breadcrumb — comme queryable en GraphQL. Rank Math a l'équivalent. Le layout Next.js lit la réponse typée et render des meta tags identiques à ce que Yoast ou Rank Math auraient output sur un WordPress classique. Les éditeurs continuent d'éditer dans la même UI du plugin ; la migration est invisible de leur côté.

Semaine 1 : découverte et définition du périmètre

Audit des plugins. Audit du contenu. Export Search Console + Ahrefs pour la source de la carte de redirections. Baseline de performance actuelle. Décision sur le chemin un versus deux versus hybride. Output : un SOW écrit avec un prix fixe et un calendrier de paiements par jalons. À la fin de la semaine un, vous savez exactement ce que vous payez.

Semaines 2-4 : fondation

Les repos sur votre GitHub, pas le nôtre. L'hébergement dans vos comptes. WPGraphQL (ou nouveau CMS) configuré. Scaffolding Next.js ou Astro livré. SEO linter et ingestion de la carte de redirections branchés. Design tokens migrés. À la fin de la semaine quatre, la fondation est réelle et l'équipe livre des pages.

Semaines 5-10 : construction

Templates portés, page par page. Looms quotidiens de l'ingénieur lead dans votre Slack. Appel de revue mid-build hebdomadaire. Tickets dans Linear ou Jira ou ce que vous utilisez déjà. Les cas limites attrapés au fur et à mesure. C'est le milieu ennuyeux du projet où la plupart du vrai code se fait.

Semaines 10-12 : QA pré-lancement

Cross-browser manuel. Audit mobile. Audit d'accessibilité en WCAG AA. Core Web Vitals sur vrais appareils (pas Lighthouse en lab). SEO linter au vert. Schema validator au vert. Carte de redirections vérifiée URL par URL contre l'export Search Console. Le plan de cutover écrit et répété.

Semaine 12 : lancement

Cutover DNS à une fenêtre que vous choisissez. La plupart vont un mardi ou mercredi matin, trafic faible. Le front-end tourne déjà sur un domaine de staging ; le cutover est un flip DNS. Engineering en standby 24 heures. Search Console soumis avec la nouvelle sitemap. Ahrefs et GA annotés.

Semaines 12-16 : hyper-vigilance

Surveillance quotidienne de Search Console pour les anomalies d'indexation, les avertissements de chaînes de redirection, les erreurs de schéma. Comparaison hebdomadaire du trafic par rapport à la ligne de base. Les corrections de bugs sont prioritaires sur les nouvelles fonctionnalités. À la semaine 16, le site est stable et nous procédons soit à une transmission propre, soit à un plan de maintenance continue.