Il y a trois ans, j'ai pris le blog d'un client, 400 articles, 60k visites organiques mensuelles, huit années de PageRank accumulé, et je l'ai migré vers un beau front-end Next.js. En six semaines, nous avions perdu 34% de ce trafic. Non pas parce que le nouveau site était lent. Non pas parce que le contenu avait disparu. Parce que j'ai été négligent sur quatre points spécifiques que je vais vous montrer dans cet article pour que vous ne repetiez pas mon erreur.
WordPress headless avec Next.js est vraiment brillant pour la performance et l'expérience développeur. Mais Google s'en fiche de votre score Lighthouse si vos balises canonical sont mal configurées, votre sitemap XML pointe vers l'ancien domaine, et vos données structurées ont disparu quelque part entre WPGraphQL et getStaticProps. La migration elle-même, c'est la partie dangereuse. Bien la réussir, c'est surtout une question de discipline, pas de magie.
---
Pourquoi Cette Migration Casse le SEO en Première Lieu
Voilà ce que la plupart des tutoriels passent sous silence : WordPress fait un énorme travail SEO pour vous sans que vous le réalisiez. Yoast ou Rank Math génère vos balises meta. Le cœur de WordPress gère votre structure de permaliens. Votre thème sort probablement une forme de balisage schema. Votre sitemap XML se régénère automatiquement à chaque publication.
Quand vous tirez la couche contenu dans Next.js via l'API WPGraphQL et que vous la servez depuis un nouveau front-end, toute cette infrastructure devient votre problème à reproduire. Chaque. Seul. Élément.
L'autre problème est la structure des URLs. La plupart des sites WordPress ont /category/post-slug/ ou /year/month/post-slug/ ou simplement /post-slug/. Next.js vous offre une toile vierge pour le routage. Cette toile vierge est un cimetière de classements si vous ne la planifiez pas soigneusement.
Les Deux Modes de Défaillance que Je Vois Constamment
Le premier concerne les équipes qui migrent aussi les URLs et qui cassent quand même les choses, généralement parce que les redirections sont appliquées de façon inégale ou que le nouveau sitemap se met en ligne avant les redirections. Le second concerne les équipes qui changent intentionnellement la structure des URLs (souvent pour la nettoyer) et qui traitent la mise en correspondance des redirections comme une arrière-pensée. Les deux sont réparables. Aucun n'est acceptable.
---
Auditez Avant de Toucher à Quoi que Ce Soit
N'écrivez pas une seule ligne de code Next.js avant d'avoir un inventaire complet des URLs. J'utilise Screaming Frog, je crawle le site WordPress en direct, j'exporte chaque URL indexable, et je la déverse dans une feuille de calcul. Pour un site de 400 pages, c'est peut-être une heure de travail. Pour un site de 4 000 pages, c'est toujours une heure, parce que l'outil le fait automatiquement.
Ce que vous capturez :
- Chaque URL canonique actuellement indexée
- Le statut HTTP de chacune (identifier les 404s et les 301s qui existent déjà)
- Le titre meta et la description pour chaque page
- Quelles pages ont des données structurées (utilisez le Rich Results Test ou inspectez simplement la source)
- Liens internes entrants, pour que vous sachiez quelles pages renvoient vers quelles pages
Récupérez également vos 50 meilleures pages de Google Search Console triées par clics. Ce sont celles que vous ne pouvez pas vous permettre de rater. Signalez-les dans la feuille de calcul. Traitez-les comme des dépendances en production.
Seahawk avait un client e-commerce fin 2022 -- un magasin WooCommerce de 1 200 produits migrant vers une configuration headless. Nous avons passé deux jours complets sur l'audit avant d'écrire du code. Le client pensait que nous gaspillions du temps. Nous avons sauvé ses 90k sessions organiques mensuelles.
---
Configurer WordPress en tant que véritable CMS Headless
Cette partie est surtout directe. Installez WPGraphQL et exposez votre contenu via l'API GraphQL. Mais il y a quelques points sur lesquels il vaut la peine d'être délibéré.
Gardez Yoast (ou Rank Math) en fonction du côté WordPress
Même si vous ne servez plus WordPress comme front-end public, gardez votre plugin SEO actif. WPGraphQL for Yoast SEO (ou l'extension Rank Math équivalente) expose tous les métadonnées SEO, titres, descriptions, URLs canoniques, données OG, directives robots, directement via l'API GraphQL. Cela signifie que vous pouvez les interroger depuis Next.js et les rendre exactement comme Yoast l'a voulu.
C'était la leçon de cette baisse de trafic en 2019 que j'ai mentionnée. J'avais supposé que nous pourrions régénérer les titres à partir du titre du post + le nom du site dans Next.js. Nous pourrions. Mais Yoast avait personnalisé manuellement les meta titres pour environ 80 des posts les plus performants, et nous avons tout effacé. Huit semaines pour récupérer.
Désactiver le Front-End WordPress avec Prudence
Une fois que vous êtes prêt à diriger le trafic vers Next.js, vous ne voulez PAS que WordPress serve son propre front-end en même temps. Contenu en double à grande échelle. La façon la plus propre est de définir un robots.txt sur votre installation WordPress à Disallow: / pendant que votre site Next.js se met en ligne, puis finalement de firewall l'URL WordPress pour qu'elle ne soit accessible qu'en interne ou via VPN.
Ne sauter pas l'étape robots.txt. J'ai vu des équipes bloquer WordPress au niveau du CDN et découvrir ensuite que Googlebot avait une route en cache. Cela prend des mois pour nettoyer.
---
Reproduire la Structure d'URL Exactement
Ma forte recommandation par défaut : conservez vos URLs identiques. Même slug, même structure de permalink, même comportement de trailing slash. Plus les routes Next.js reflètent les routes WordPress, moins vous avez besoin de redirects, et moins vous prenez de risques.
Les routes dynamiques de Next.js rendent cela facile. Si vos articles WordPress vivent à /blog/[slug], créez pages/blog/[slug].js. C'est bon.
Ça devient compliqué avec les archives de catégories, les pages d'auteur, les pages de tags, et les archives paginées (/blog/page/2/). WordPress génère tout cela automatiquement. Dans Next.js vous les construisez vous-même. Beaucoup d'équipes déprioritisent ces éléments et se demandent ensuite pourquoi la couverture de crawl a chuté.
Voici ma checklist numérotée pour la parité d'URL :
- Articles/pages uniques, correspondance exacte du slug, y compris tout sous-dossier
- Archives de catégories, recréer /category/[slug]/ avec getStaticPaths récupérant toutes les catégories depuis WPGraphQL
- Archives d'étiquettes, idem que ci-dessus, ne les sautez pas si elles génèrent du trafic organique
- Archives par auteur, vérifiez d'abord la Search Console ; s'ils reçoivent zéro clics, vous pouvez les rediriger en 301 vers la page d'accueil
- Archives paginées, /blog/page/[num]/ vaut la peine d'être conservé si vous avez beaucoup d'articles
- Pages de pièces jointes, presque toujours les rediriger en 301 vers l'article parent ; ce sont des poids morts en SEO dans WordPress aussi
- URLs de flux, /feed/ devrait être redirigé en 301 vers votre nouveau flux RSS si vous en avez un, ou retourner 410 sinon
---
Redirections : la partie que tout le monde sous-estime
Si vous changez l'une des URLs, ce que je déconseille, mais c'est parfois nécessaire, votre carte de redirection doit être construite avant le lancement et testée dans un environnement de staging.
Dans Next.js, les redirections se trouvent dans next.config.js. Pour les petits sites (moins de 200 redirections) c'est acceptable. Pour tout ce qui est plus gros, mettez-les dans un fichier JSON et importez-le, ou utilisez un middleware pour les gérer dynamiquement. Le middleware edge de Vercel est excellent pour les grandes tables de redirections parce qu'il s'exécute avant que la page soit rendue, zéro pénalité de latence.
Le format dans next.config.js :
``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``
permanent: true envoie un 301. Utilisez-le pour tous les changements d'URL authentiques. N'utilisez pas 302 (temporaire) à moins que vous ayez vraiment l'intention de le rétablir, Google les traite très différemment.
Testez chaque redirect avant le lancement. J'utilise un simple script bash qui boucle dans la feuille de calcul et curl chaque ancienne URL en vérifiant une réponse 301 vers la bonne destination. Ça prend dix minutes à écrire, ça vous épargne des heures de panique post-lancement.
---
Meta Tags, Canonical URLs, et Structured Data dans Next.js
C'est là que la plupart des migrations perdent des points silencieusement. Le contenu est là, les URLs fonctionnent, mais les signaux SEO sont faux.
Meta Tags
Utilisez next-seo. C'est le standard. Passez-lui les données que vous avez interrogées depuis WPGraphQL Yoast. Votre _app.js reçoit une config DefaultSeo, et chaque page reçoit un composant NextSeo avec les surcharges spécifiques à la page. Récupérez le titre, la description, le titre OG, l'image OG, l'URL canonique et les directives robots directement de la réponse GraphQL Yoast, ne les réinventez pas.
Un truc qui pose problème : les URLs canoniques. Dans WordPress, Yoast les définit automatiquement. Dans Next.js, vous devez passer la canonique explicitement. Si vous l'oubliez, Next.js affichera les pages sans balise canonique, et si vous avez des query strings quelque part (pagination, filtres), vous vous retrouverez avec des problèmes de contenu dupliqué plus vite que prévu.
Données structurées
Les thèmes et plugins WordPress produisent souvent du JSON-LD automatiquement. Cela disparaît en headless. Vous devez le reconstruire. Pour les articles, utilisez le schéma Article. Pour les produits, Product. Pour les entreprises locales, LocalBusiness. Je les écris comme des composants React qui acceptent des props et retournent une balise <script type="application/ld+json">. Un composant par type de schéma, réutilisé dans toute l'application.
Vérifiez chaque type de schéma que vous aviez auparavant dans le Rich Results Test avant la migration. Documentez-les. Recréez-les. Testez les nouveaux avec le même outil après le lancement.
Le sitemap XML
N'utilisez pas une sitemap statique. Générez-la dynamiquement. Pour les petits sites, getServerSideProps sur une route /sitemap.xml fonctionne. Pour les gros sites avec des milliers d'articles, générez la sitemap au moment de la construction via un script personnalisé et mettez-la dans le dossier public/. Vercel l'exécute à chaque déploiement, votre sitemap est toujours à jour.
Soumettez la nouvelle URL du sitemap à Google Search Console le premier jour du lancement du nouveau site. Pas le troisième jour. Le premier jour.
---
Suivi post-lancement (La fenêtre de 90 jours)
La migration ne s'arrête pas au lancement. Elle s'arrête quand vos classements se sont stabilisés, ce que la documentation de Google suggère peut prendre de quelques semaines à quelques mois selon le budget de crawl et l'autorité du site.
Ce que je consulte chaque jour de la semaine pendant le premier mois :
- Google Search Console → Rapport de couverture pour les nouveaux 404 ou les URL « Exclues » qui ne devraient pas l'être
- Search Console → Performance, comparez les clics et les impressions semaine après semaine pour vos 50 meilleures pages
- Re-crawl de Screaming Frog du nouveau site pour détecter les 404 internes ou les balises canoniques mal configurées
- Core Web Vitals, oui, le site Next.js devrait être plus rapide, mais vérifiez-le dans les données terrain (CrUX), pas seulement dans Lighthouse
Si vous constatez une baisse significative lors des deux ou trois premières semaines, ne paniquez pas immédiatement. Il y a presque toujours une courte fluctuation tandis que Google effectue le re-crawl et la ré-indexation. Ce que vous recherchez, c'est une baisse soutenue au-delà de la semaine quatre. C'est le signal qu'il y a un problème structurel.
Fin 2022, projet différent de celui de l'e-commerce, nous avons lancé une migration Next.js pour un blog SaaS et avons constaté une baisse de 20 % des impressions la deuxième semaine. Il s'est avéré que notre sitemap généré dynamiquement incluait des pages avec noindex parce que nous n'avions pas filtré correctement la requête WPGraphQL. Corrigé en quatre heures. Les classements se sont rétablis en trois semaines. La surveillance l'a détecté avant que ça s'aggrave.
---
FAQ
Combien de temps prend une migration WordPress vers Next.js ?
Honnêtement, ça dépend surtout de la complexité du site, pas du nombre de posts. Un site brochure de 100 pages avec des URLs propres peut être fait correctement en deux à trois semaines. Un blog de 2 000 posts avec des custom post types, des champs ACF et une intégration WooCommerce, c'est un projet de six à huit semaines minimum si tu fais le travail SEO correctement en parallèle du développement. Ne laisse personne te dire que c'est un boulot de week-end.
Dois-je utiliser le Pages Router ou l'App Router dans Next.js ?
Depuis mi-2024, j'utilise par défaut l'App Router pour les nouveaux projets. Mais si votre équipe est plus à l'aise avec le Pages Router et que cette migration est sensible au temps, utilisez ce que vous connaissez. Les implications SEO sont minimes, les deux supportent la génération statique, le rendu côté serveur et les routes dynamiques. Le package next-seo supporte maintenant l'App Router aussi.
Dois-je entièrement m'éloigner de l'hébergement WordPress ?
Non. WordPress peut rester sur son hôte existant, WP Engine, Kinsta, Cloudways, peu importe celui que vous utilisez, et servir purement comme API de contenu. Le front-end Next.js se déploie sur Vercel ou Netlify. Les deux communiquent via HTTP. Certains clients préfèrent même ça parce que l'équipe éditoriale garde l'admin WordPress qu'elle connaît déjà.
Qu'en est-il des extensions WordPress qui affectent le SEO, comme les redirections gérées dans Redirection ?
Exportez-les avant de migrer. L'extension Redirection propose une exportation CSV. Prenez toutes ces redirections existantes et ajoutez-les à votre next.config.js ou au middleware edge. Ne supposez pas qu'elles se reporteront automatiquement, ce ne sera pas le cas, parce qu'elles vivent dans la base de données WordPress et Next.js ne sait pas qu'elles existent.
Mon classement Google va-t-il baisser peu importe quoi ?
Il y a presque toujours une certaine volatilité à court terme. Une migration bien exécutée sans changements d'URL, avec des redirections appropriées (si nécessaire), des métadonnées répliquées et des données structurées, et un sitemap résoumis devrait se stabiliser en quatre à six semaines. Les baisses que j'ai vues qui ont duré des mois étaient toutes causées par des erreurs techniques spécifiques, pas par la migration elle-même.
---
La migration n'est pas la partie difficile. La partie difficile, c'est la discipline de faire chaque étape ennuyeuse et sans glamour, l'audit, la cartographie des redirections, la recréation du schéma, avant d'écrire un code Next.js élégant. Faites-le dans le bon ordre et vous sortirez de l'autre côté avec un front-end plus rapide et les mêmes classements avec lesquels vous avez commencé. Possiblement de meilleurs, une fois que les améliorations Core Web Vitals se répercutent.