Migrer un site WordPress vers Next.js sans perdre son SEO

Une migration WordPress → Next.js est avant tout un projet de gestion du risque SEO. Le gain technique (TTFB, Core Web Vitals, architecture headless) ne compense rien si le trafic organique chute de 30 % pendant six mois. Voici la méthode à suivre, dans l'ordre.

1. Cartographier l'existant avant de coder quoi que ce soit

Avant d'ouvrir un seul fichier .tsx, exportez l'intégralité des URLs indexées et des métadonnées associées.

• Crawlez le site avec Screaming Frog ou Sitebulb en mode "liste" à partir du sitemap XML, pas seulement en crawl classique (certaines pages orphelines ne sont accessibles que via sitemap).
• Exportez : URL, statut HTTP, canonical, title, meta description, balises hreflang, données structurées (JSON-LD), et le nombre de backlinks internes/externes par URL (via Search Console + Ahrefs/Semrush).
• Croisez avec Google Search Console : la Coverage Report vous donne la liste réelle des pages indexées, souvent différente du sitemap déclaré.

Ce fichier CSV devient votre référentiel de vérité. Toute page absente de ce référentiel après migration doit être justifiée (dépréciée volontairement) ou corrigée.

2. Construire la table de redirections 301 avant le développement front

C'est l'étape la plus souvent bâclée. Une migration CMS change presque toujours la structure d'URL (WordPress avec permaliens /%postname%/ vs routing Next.js par app/[slug]/page.tsx).

Règles à respecter :

• 1 ancienne URL = 1 redirection 301, jamais de redirection vers la homepage par défaut. Une 301 massive vers / est interprétée par Google comme une perte de contenu et dilue le PageRank transmis.
• Implémentez les redirections au niveau edge, pas en client-side :

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/blog/ancien-article-wordpress',
        destination: '/articles/nouveau-slug',
        permanent: true,
      },
    ]
  },
}

• Si le volume dépasse quelques centaines d'entrées, ne stockez pas la table dans next.config.js (rebuild nécessaire à chaque ajout). Passez par un Edge Middleware avec lookup dans une table Redis/Vercel KV, ou un service de redirections dédié en amont (Cloudflare Rules, Vercel Edge Config).
• Testez chaque redirection avec curl -I avant mise en prod, pas via navigateur (masque les chaînes de redirections 301→301→200).

3. Reproduire fidèlement la couche SEO on-page avec l'API Metadata de Next.js

WordPress génère automatiquement titles, meta descriptions, Open Graph et JSON-LD via Yoast ou RankMath. Rien de tout cela n'existe par défaut dans Next.js — vous devez le reconstruire explicitement.

// app/articles/[slug]/page.tsx
export async function generateMetadata({ params }): Promise<Metadata> {
  const post = await getPost(params.slug)
  return {
    title: post.seoTitle,
    description: post.seoDescription,
    alternates: { canonical: `https://example.com/articles/${params.slug}` },
    openGraph: { images: [post.ogImage] },
  }
}

Points de contrôle non négociables :

• Sitemap XML dynamique via app/sitemap.ts, généré à partir de la même source de données que le contenu, avec lastModified réel (pas la date de build).
• robots.txt identique en logique (mêmes directives disallow) via app/robots.ts.
• Données structurées JSON-LD réinjectées manuellement (Article, BreadcrumbList, FAQPage) — WordPress les génère, Next.js ne les devine pas.
• Conservez la structure de heading (H1 unique par page, hiérarchie H2/H3 identique) : un simple changement de composant React qui rend un <div> à la place d'un <h2> casse le balisage sémantique sans qu'aucun test unitaire ne le détecte.

4. Exploiter le rendu Next.js pour améliorer, pas juste préserver, les Core Web Vitals

L'argument business de la migration repose sur la performance — vérifiez-le avant le lancement.

• Privilégiez SSG (generateStaticParams) pour les contenus éditoriaux peu volatils, avec revalidation ISR (revalidate: 3600) plutôt qu'un rendu 100% dynamique.
• Remplacez toutes les