Comment migrer un site wordpress vers next.js headless tout en conservant le référencement et les redirections actives

Passer un site WordPress vers Next.js en mode headless est souvent perçu comme un saut technique majeur — et pourtant, c’est un excellent moyen d’améliorer performance, contrôle UX et maintenabilité. J’ai déjà accompagné plusieurs migrations de ce type et ce qui revient toujours est la même priorité : conserver le référencement naturel et l’intégralité des redirections. Ci‑dessous je partage une méthode concrète, éprouvée, et les pièges à éviter.

Pourquoi migrer vers Next.js en headless sans casser le SEO

Next.js apporte rendu côté serveur (SSR), génération statique (SSG), ISR (revalidation), et une grande souplesse pour construire des expériences performantes. Mais migrer signifie changer l’URL, les balises meta ou la vitesse de rendu — ce qui peut impacter le trafic si on ne prépare pas correctement le transfert. Mon objectif est de garder les gains (performance, dev DX) tout en évitant une chute de trafic organique.

Avant de commencer : audit et inventaire

Ne partez pas au hasard. Faites un inventaire complet du site WordPress :

Liste des URL publiques (pages, articles, catégories, tag, archives).

Backlinks et pages qui génèrent du trafic organique (Google Search Console, Ahrefs, SEMrush).

Redirections existantes (wp-redirection, .htaccess).

Contenus riches : schema.org, FAQ, breadcrumbs, données structurées.

Fichiers médias et chemin d’accès (uploads/...).

Sitemap.xml et robots.txt actuels.

Je recommande d’exporter la liste d’URL via un crawler (Screaming Frog) et d’exporter la Search Console pour identifier les URL qui comptent le plus.

Choix techniques : comment connecter WordPress et Next.js

Plusieurs approches :

WPGraphQL

REST API

Headless CMS alternatif (Strapi, Sanity, Contentful) si vous voulez quitter WordPress. Attention, migration de contenu nécessaire.

Dans la plupart des migrations que j’ai réalisées, WPGraphQL + Next.js (avec getStaticProps / getServerSideProps ou App Router) donne le meilleur compromis pour disposer des champs personnalisés et des performances.

Conserver la structure d’URL et planifier les redirections

La règle d’or : conserver les mêmes permaliens si possible. Si vous modifiez la structure, mappez chaque ancienne URL vers la nouvelle via des 301. Voici le plan que j’utilise :

1) Tenter de reproduire identiquement les slugs et chemins (ex : /2024/06/mon-article).

2) Si changement nécessaire, établir un fichier de correspondance (CSV) : ancienne_url,nouvelle_url.

3) Implémenter les redirections 301 côté serveur (Nginx, Vercel rewrites/redirects, Netlify _redirects) plutôt que JavaScript.

Pour Vercel, la configuration de redirection se fait dans vercel.json ; pour Netlify, dans un fichier _redirects. Si vous gérez votre propre serveur, placez les règles dans la conf Nginx/Apache.

SEO technique : métadonnées, canonicals, hreflang

Ne négligez pas les balises meta. Next.js permet de gérer les meta tags au niveau de la page — je veille à :

Importer toutes les méta existantes (title, meta description, meta robots) depuis WordPress et les rendre dynamiques.

Conserver les balises rel="canonical" pour éviter le contenu dupliqué.

Reproduire ou améliorer les balises hreflang si vous avez un site multilingue.

Exporter et ré-appliquer les données structurées (schema.org) et les JSON-LD sur les pages concernées.

Astuce : build un petit script Node qui parcourt vos pages WordPress pour extraire title, description, canonical, schema et qui les injecte dans la génération Next.

Gestion des images et médias

Conserver les URLs d’images est souvent critique pour le SEO et les performances. Options :

Servir les médias depuis le même domaine (conserver /wp-content/uploads) en les copiant vers le CDN ou bucket S3 et en conservant les chemins.

Utiliser Next/Image avec un loader pointant vers votre CDN ou votre bucket.

Vérifier les attributs alt — ce sont des éléments SEO importants ; exportez-les et réappliquez-les.

Sitemap, robots.txt et Search Console

Avant le lancement :

Générez un nouveau sitemap.xml à partir du site Next.js (plusieurs packages existent) qui reflète l’architecture finale.

Conservez (ou mettez à jour) robots.txt.

Soumettez le nouveau sitemap dans Google Search Console.

Surveillez via la Search Console les erreurs d’exploration après mise en production (404, erreurs de serveur).

Tester en staging et préparer le basculement

J’insiste sur une mise en place en staging avec un sous-domaine (staging.mondomaine.tld) pour :

Vérifier le rendu SSR/SSG et les balises meta visibles côté serveur.

Tester la vitesse (Lighthouse, WebPageTest) et le rendu mobile.

Simuler le crawl (Screaming Frog) pour s’assurer qu’il n’y a pas de 404 inattendues.

Préparez un plan de rollback : conservez le WordPress opérationnel et maintenez les redirections pendant la période de test en prod (mode blue/green).

Monitoring post‑migration

Les premières semaines sont cruciales :

Surveillez le trafic via Google Analytics et Search Console — comparez page par page.

Regardez les impressions/clics sur les pages clefs ; corrigez vite les pages qui perdent du trafic.

Analysez les 404 et ajoutez des redirections 301 si nécessaire.

Vérifiez les performances Core Web Vitals et adressez les problèmes (images non optimisées, CLS, LCP).

Checklist pratique

Audit initial	Crawler, GSC, sitemap, redirections existantes
API	WPGraphQL ou REST API configurée
URL	Conserver slugs ou préparer fichier mapping pour 301
Méta & Schema	Exporter et réappliquer titles, descriptions, JSON-LD
Media	Migrer images, conserver alt et chemins ou config CDN
Sitemap & robots	Générer, soumettre à GSC
Redirections	Implémenter 301 côté serveur (Vercel/Netlify/Nginx)
Staging	Test SSR, SEO, mobile, crawl
Monitoring	Surveiller GSC, Analytics, logs

Derniers conseils issus de mon expérience : priorisez les pages à fort trafic pour la conservation exacte des slugs et du contenu; automatisez l’extraction des métadonnées depuis WordPress plutôt que de tout ressaisir; et ne confiez pas les redirections à un JS client — les moteurs de recherche ont besoin de redirections 301 côté serveur. Si vous hébergez sur Vercel, vous avez des outils natifs pour ISR et des fichiers de redirection; pour Netlify, le fichier _redirects est votre ami.

Si vous voulez, je peux vous aider à générer le fichier CSV de mapping à partir de votre site WordPress (en m’indiquant l’accès au crawl export), ou vous préparer une checklist technique adaptée à votre hébergeur (Vercel, Netlify, ou serveur dédié). Vous me dites ce dont vous disposez et je vous fournis la prochaine étape concrète.