Passer un site WordPress traditionnel vers une architecture headless avec Next.js m'a paru, au départ, comme un pari risqué : gagner en performance et en flexibilité sans sacrifier le référencement naturel. Après plusieurs migrations et expérimentations, j'ai mis au point une méthode pragmatique pour conserver (et souvent améliorer) le SEO pendant la transition. Je vous partage ici mon guide pas à pas, les pièges à éviter et les choix techniques qui ont fait la différence.
Pourquoi utiliser WordPress en headless avec Next.js ?
Avant tout, j'aime être clair sur les motivations. WordPress reste un excellent CMS pour la gestion de contenu, l'édition et l'écosystème de plugins. Next.js, lui, apporte : rendu côté serveur (SSR), génération statique (SSG), ISR (Incremental Static Regeneration), et une stack front moderne. Ensemble, ils permettent de bénéficier d'un éditeur familier tout en offrant un front ultra-rapide et optimisé pour le SEO.
Choix de l'API : REST ou GraphQL ?
WordPress expose deux principales manières de récupérer le contenu : l'API REST native et WPGraphQL (plugin tiers). J'ai opté majoritairement pour WPGraphQL car :
Les requêtes sont plus précises : on récupère uniquement les champs nécessaires.La structure est plus prévisible et facile à versionner côté front.Meilleure performance réseau pour gros volumes de contenu.Cependant, la REST API reste viable pour des projets simples. Si vous avez un plugin ou une intégration qui ne fonctionne qu'avec REST, c'est aussi un bon choix.
Architecture proposée
Voici l'architecture que j'utilise régulièrement :
WordPress (WP Admin) → contenu, médias, SEO meta (Yoast/Rank Math).WPGraphQL / REST → endpoint accessible depuis Next.js.Next.js (Vercel/Netlify/Cloud) → rendu SSG/SSR/ISR selon le type de page.CDN (Cloudflare / Vercel CDN) pour la distribution des assets.Étapes concrètes de migration
Je détaille ci-dessous les étapes dans l'ordre logique :
1. Audit SEO et inventaire des pages : listez toutes les URLs indexées (Search Console, Screaming Frog), les pages à fort trafic, et les contenus avec backlinks. C'est la feuille de route pour mapper les redirections et préserver le positionnement.2. Préparez WordPress : installez WPGraphQL (ou laissez REST). Assurez-vous que les méta SEO (Yoast, Rank Math) restent accessibles via l'API — WPGraphQL SEO est un plugin utile pour exposer ces champs.3. Mirror du contenu : configurez Next.js pour récupérer les contenus. Pour les pages qui évoluent peu, je privilégie SSG + ISR. Pour les pages dynamiques (resultats de recherche, tableaux de bord), j'utilise SSR.4. Gestion des balises meta et données structurées : Next.js doit reproduire toutes les balises meta (title, meta description, canonical, open graph, twitter card) présentes dans WordPress. Utilisez des composants Head (next/head) et récupérez les champs SEO depuis l'API.5. Sitemaps & robots.txt : générez un sitemap dynamique dans Next.js ou servez le sitemap WordPress existant. Mettez à jour le fichier robots.txt si nécessaire et assurez-vous qu'il pointe vers le nouveau sitemap.6. Redirections 301 : configurez toutes les redirections des anciennes URLs vers les nouvelles. Gardez un mapping exact pour les pages indexées et les URLs avec trafic. Sur Vercel/Netlify, utilisez les règles de redirection ou configurez au niveau du CDN/serveur proxy.7. Prévisualisation & workflow éditorial : mettez en place le mode preview pour permettre aux rédacteurs de visualiser leurs modifications avant publication. Next.js propose un mode preview basé sur cookies et des routes API pour déclencher la preview.8. Tests avant bascule : déployez sur un domaine de staging et comparez les signaux SEO (rendered HTML, balises meta, sitemap, canonicals). Utilisez Search Console pour valider l'accès des bots et Lighthouse/Pagespeed pour mesurer les améliorations.9. Basculement & monitoring : swap du DNS vers la nouvelle version en prenant en compte le TTL. Surveillez les impressions/clicks via Google Search Console, les erreurs 404, et les fluctuations de trafic pendant quelques semaines.Points techniques essentiels pour ne pas perdre son SEO
Voici les éléments qui m'ont permis de conserver les positions :
Rendu côté serveur (SSR) / SSG : Google et les autres moteurs lisent mieux les pages pré-rendues. Evitez une application entièrement client-side pour les pages indexables.Conserver les balises canonical : les canonicals doivent rester identiques si l'URL ne change pas; sinon configurez-les vers la nouvelle URL.Structured data (JSON-LD) : transposez toutes les données structurées de WordPress vers Next.js. Cela inclut article, breadcrumb, organisation, product, etc.Maintenir les URL : si possible, conservez les mêmes permaliens. Changer d'URL augmente le risque de perte de trafic et demande des redirections 301 correctes.Sitemaps dynamiques : générez un sitemap en temps réel pour inclure les nouvelles pages et les mises à jour (Next.js + getStaticPaths ou un endpoint /sitemap.xml).Exemples de pièges rencontrés
J'ai rencontré plusieurs problèmes lors de mes migrations — en voici les plus fréquents :
Meta tags générées uniquement côté client : résultat = contenu vide pour les bots. Solution : SSR/SSG et hydratation après rendu.Images non optimisées et absence d'attributes srcset : baisse de performance. Utilisez next/image ou un CDN adapté pour servir des formats modernes (AVIF, WebP).Perte des URL canoniques ou des balises Open Graph : impact sur le partage social et indexation. Vérifiez systématiquement la page rendue côté serveur.Outils et plugins que j'utilise
| Sur WordPress | WPGraphQL, WPGraphQL JWT Auth (auth), WPGraphQL SEO (expose Yoast), Advanced Custom Fields (ACF) + ACF to GraphQL |
| Sur Next.js | next/head, next/image, ISR, getStaticProps/getStaticPaths, react-helmet si nécessaire |
| Hosting & CDN | Vercel (déploiement facile + ISR), Netlify, Cloudflare Pages. CDN (Cloudflare) pour assets |
| Monitoring & SEO | Google Search Console, Google Analytics / GA4, Lighthouse, Screaming Frog, Sentry pour erreurs JS |
Gestion du contenu dynamique et des previews
Le workflow éditorial est souvent la source d'inquiétude. Pour que les rédacteurs continuent à travailler confortablement :
Activez le mode Preview dans Next.js en créant un endpoint API qui valide un secret et met un cookie de preview ; utilisez les données preview pour fetcher les contenus non publiés depuis WPGraphQL.Conservez l'interface d'administration WordPress intacte ; les éditeurs ne voient pas la différence et n'ont pas besoin d'apprendre un nouvel outil.Métriques à surveiller après migration
Après la mise en production, suivez scrupuleusement les indicateurs suivants :
Impressions & CTR dans Google Search Console.Positions pour les mots-clés stratégiques.Pages indexées vs sitemap.Volume d'erreurs 4xx/5xx.Vitesse et Core Web Vitals (LCP, CLS, FID/INP).Si vous souhaitez, je peux vous fournir un checklist téléchargeable des étapes et des règles de redirection à appliquer, ou un exemple de mapping getStaticPaths / getStaticProps avec WPGraphQL. Dites-moi ce qui vous aiderait le plus pour démarrer votre migration.
