Refonte SEO d’un site WordPress en 2026 : checklist complète pour préserver 100% du jus de lien

Une refonte de site web mal préparée est l’une des erreurs les plus coûteuses qu’une PME puisse commettre en 2026. Les chiffres parlent d’eux-mêmes : selon une étude croisée Ahrefs / Search Engine Journal publiée fin 2025, une refonte sans plan SEO rigoureux entraîne en moyenne une chute de 50 % du trafic organique dans les 90 jours suivant la mise en ligne, et plus d’un site sur trois ne récupère jamais ses positions d’origine. Pour un site qui générait 20 000 visites mensuelles depuis Google, c’est un manque à gagner direct de plusieurs dizaines de milliers d’euros par an, parfois bien plus si le tunnel de conversion dépend du SEO.

Chez Go To Agency, agence digitale basée à Dijon en Bourgogne-Franche-Comté, nous avons piloté plus d’une cinquantaine de refontes WordPress vers Next.js ces deux dernières années, pour des artisans, des e-commerçants, des SaaS et des cabinets de conseil. Le constat est toujours le même : la technique de la refonte est rarement le problème, c’est la préservation du jus de lien qui plante les projets. Cet article décortique le workflow complet d’une refonte SEO-safe en 2026 — checklist, code snippets prêts à copier, et erreurs fatales à éviter. Si vous préparez une refonte de site WordPress, lisez cet article avant d’écrire la première ligne de code.

1. Audit pré-refonte : récupérer 100 % des URLs indexées

La première étape — et la plus négligée — consiste à constituer un inventaire exhaustif de toutes les URLs de l’ancien site qui ont un poids SEO. On ne migre pas ce qu’on ne connaît pas. Et ce qu’on ne migre pas correctement renvoie une 404, qui détruit le jus de lien associé.

Sources à croiser obligatoirement

Aucun outil seul ne donne la liste complète. Il faut systématiquement croiser au moins trois sources :

1. Screaming Frog SEO Spider : crawl complet du site en mode HTML + JavaScript rendering. Export CSV de toutes les URLs (200, 301, 404, paginations, fichiers PDF, images indexées). Pour un site WordPress moyen, comptez 1 à 3 heures de crawl.
2. Google Search Console : rapport « Pages » → export complet des URLs indexées et soumises au cours des 16 derniers mois. C’est la vérité Google, celle qui compte.
3. Ahrefs ou Semrush : export des URLs avec backlinks externes pointant vers elles. Ce sont les pages à protéger en priorité — perdre un backlink en or sur une fiche produit, c’est perdre des années de capital SEO.
4. Google Analytics 4 : top 500 pages par sessions organiques sur 12 mois. Pour identifier les pages à fort trafic qui ne sont pas forcément visibles dans les exports précédents (longue traîne).
5. Sitemap XML actuel : sitemap.xml et sitemap_index.xml du WordPress (souvent générés par Yoast ou RankMath).

L’objectif : produire un Google Sheets unique avec une feuille « URLs sources » contenant l’union dédupliquée de ces cinq exports. On vise généralement 1,2 à 1,8 fois le nombre de pages connues côté CMS — la différence vient des paginations, archives auteur, archives par tag, anciens slugs, fichiers PDF, etc.

2. Cartographie 1:1 ancienne URL → nouvelle URL

C’est la pièce maîtresse de toute refonte SEO-safe. Pour chaque URL identifiée à l’étape 1, on doit décider précisément ce qu’elle devient sur le nouveau site. Pas de « on verra plus tard ». Pas de « on redirigera vers la home par défaut ».

Structure du Google Sheets de cartographie

Voici le template qu’on utilise chez Go To Agency, à recopier tel quel :

1. Colonne A — URL ancienne : URL absolue (avec protocole et domaine).
2. Colonne B — Type : page, article, catégorie, tag, archive, fichier, paginate, autre.
3. Colonne C — Sessions organiques 12 mois : pour prioriser.
4. Colonne D — Backlinks externes : nombre de domaines référents.
5. Colonne E — Action : 301, 410 (page supprimée volontairement), conserver, fusionner.
6. Colonne F — URL nouvelle : URL absolue de destination (ou vide si 410).
7. Colonne G — Note : raison de la décision, contenu fusionné, etc.

Règle d’or : une redirection vers la home page est presque toujours une erreur. Google la considère comme une soft 404 et ignore le transfert de PageRank. Il faut systématiquement viser une page de destination thématiquement cohérente avec l’ancienne URL. Si aucune équivalence n’existe, c’est qu’il manque une page dans la nouvelle arborescence — c’est l’occasion de la créer.

Pour un site de 500 URLs, comptez 1,5 à 2 jours de travail à deux personnes pour produire une cartographie propre. C’est long, c’est ingrat, c’est le travail qui sauve la refonte.

3. Redirections 301 : la triple ceinture de sécurité

Une fois la cartographie validée, on déploie les redirections sur trois niveaux complémentaires : config Next.js statique, middleware dynamique, et fallback serveur. Cette redondance protège contre toutes les pannes possibles le jour J.

Niveau 1 — Configuration next.config.js

Pour les redirections de masse stables, on utilise la fonction redirects() native de Next.js. Elle est traitée au niveau du serveur, avant le rendu, donc ultra rapide. Exemple :

// next.config.js
const fs = require('fs');
const path = require('path');

const redirectsData = JSON.parse(
  fs.readFileSync(path.join(__dirname, 'redirects.json'), 'utf8')
);

module.exports = {
  async redirects() {
    return redirectsData.map((r) => ({
      source: r.source,
      destination: r.destination,
      permanent: true, // = 308, ou false pour 307
      statusCode: 301, // forcer le 301 historique
    }));
  },
};

On charge les règles depuis un redirects.json généré à partir du Google Sheets de cartographie (via un petit script Node.js). Cela permet de modifier la cartographie sans toucher au code applicatif, et d’avoir la liste en revue de code.

Niveau 2 — Middleware Next.js pour patterns dynamiques

Pour les patterns paramétriques (anciens permaliens WordPress avec dates, slugs encodés, query strings legacy), on utilise un middleware Edge qui matche les URLs en regex :

// middleware.ts
import { NextResponse, NextRequest } from 'next/server';

const LEGACY_PATTERNS = [
  // /2024/01/15/mon-article → /blog/mon-article
  { regex: /^\/\d{4}\/\d{2}\/\d{2}\/(.+)\/?$/, target: '/blog/$1' },
  // /?p=1234 → table d'équivalence
  { regex: /^\/$/, query: 'p', table: 'postIdToSlug' },
  // /category/seo → /blog?cat=seo
  { regex: /^\/category\/([^/]+)\/?$/, target: '/blog?cat=$1' },
];

export function middleware(req: NextRequest) {
  const { pathname, searchParams } = req.nextUrl;
  for (const p of LEGACY_PATTERNS) {
    const m = pathname.match(p.regex);
    if (m) {
      const dest = p.target.replace('$1', m[1]);
      return NextResponse.redirect(new URL(dest, req.url), 301);
    }
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!_next|api|.*\\.).*)'],
};

Niveau 3 — Fallback nginx ou .htaccess legacy

Si le site WordPress reste hébergé en parallèle quelques semaines (recommandé, voir section 7), on garde un .htaccess ou une config nginx qui redirige au niveau serveur vers le nouveau domaine. Exemple nginx :

# /etc/nginx/sites-enabled/ancien-site.conf
server {
    listen 443 ssl;
    server_name www.ancien-site.com;

    # Catch-all : tout ce qui n'est pas géré ci-dessous part en 301
    location / {
        return 301 https://www.nouveau-site.com$request_uri;
    }

    # Robots.txt servi localement pour signaler la migration
    location = /robots.txt {
        alias /var/www/robots-migration.txt;
    }
}

Ce fallback est notre dernière chance d’attraper les URLs qu’on aurait oubliées dans la cartographie. Combinée à la table de redirects Next.js et au middleware, on atteint un taux de couverture de 99,8 % en moyenne sur nos refontes.

4. Préserver le contenu et l’architecture éditoriale

La technique des redirections ne suffit pas. Si le contenu disparaît ou est appauvri lors du passage à Next.js, Google déclasse la page malgré une 301 propre. Trois règles essentielles :

1. Extraction propre du contenu WordPress : exporter via l’API REST WordPress (/wp-json/wp/v2/posts?per_page=100) plutôt que via le XML natif, qui mélange shortcodes et HTML cassé. Stocker le contenu en Markdown ou MDX dans le nouveau projet Next.js, ou en base via Sanity, Payload ou un autre headless CMS. Pour aller plus loin, consultez notre guide complet sur la migration WordPress vers Next.js en 2026.
2. Conserver la profondeur du contenu : si un article fait 1 800 mots sur WordPress, il doit faire au moins 1 800 mots sur Next.js. Ne pas profiter de la refonte pour « simplifier » au passage — c’est la garantie d’un déclassement.
3. Refonte structurelle = redirections agressives : si plusieurs pages fines (300-400 mots chacune) sont fusionnées en un pilier de 3 000 mots, toutes les anciennes URLs redirigent en 301 vers le nouveau pilier. C’est la meilleure pratique 2026 pour passer d’un site WordPress éparpillé à une architecture en silos hub-and-spoke.

C’est notamment cette logique d’architecture qu’on défend dans notre comparatif Next.js vs WordPress en 2026 : Next.js permet une discipline éditoriale impossible à tenir sur WordPress, à condition de bien préparer la migration.

5. Migrer les métadonnées : title, description, OG, Twitter, schema

Les balises <title> et <meta description> migrées telles quelles évitent les fluctuations de CTR en SERP. Beaucoup de refontes ratées proviennent d’un développeur qui réécrit les meta « pour faire plus propre » et déclenche une chute de CTR de 30 %.

Checklist métadonnées à migrer 1:1

1. <title> : exact, caractère pour caractère. Utiliser notre outil meta-length-checker en bas de page pour valider la longueur.
2. <meta name="description"> : idem.
3. <link rel="canonical"> : pointer vers la nouvelle URL absolue.
4. <meta property="og:title">, og:description, og:image, og:url, og:type.
5. <meta name="twitter:card">, twitter:title, twitter:description, twitter:image.
6. Schema.org JSON-LD : Article, BreadcrumbList, Organization, LocalBusiness, FAQPage selon le type de page. C’est souvent l’occasion de renforcer le balisage structuré (WordPress en sert souvent une version pauvre).
7. hreflang : si le site est multilingue, chaque variante doit pointer vers les autres via <link rel="alternate" hreflang="...">. Et ces hreflang doivent eux aussi être mis à jour vers les nouvelles URLs.

Avec Next.js et l’API generateMetadata de l’App Router, tout ce balisage se génère proprement page par page à partir d’une source de vérité unique. C’est l’un des gains immédiats du passage à Next.js.

6. Sitemap.xml, robots.txt et signalements moteurs

Le jour du switch, trois fichiers doivent être prêts à servir :

Le nouveau sitemap.xml

Généré dynamiquement par Next.js via app/sitemap.ts, avec lastmod à la date de mise en ligne. Toutes les nouvelles URLs canoniques y figurent. Aucune ancienne URL — celles-ci sont gérées exclusivement par les 301.

Le robots.txt de bascule

# /robots.txt sur le nouveau site
User-agent: *
Allow: /

Sitemap: https://www.nouveau-site.com/sitemap.xml

# Hint optionnel pour les crawlers : signaler le sitemap historique
# uniquement si on garde l'ancien domaine actif pour les redirections
# Sitemap: https://www.ancien-site.com/sitemap.xml

Sur l’ancien site (s’il reste en parallèle pendant la phase de transition), on laisse le robots.txt permissif — ne surtout pas mettre Disallow: / car cela empêcherait Google de crawler les 301 et de transmettre le jus de lien. C’est l’erreur n°1 que nous voyons en audit post-refonte.

7. Google Search Console : transfert canonique et surveillance

Search Console est l’épine dorsale du suivi post-refonte. Trois actions critiques à ne pas rater.

1. Ajouter la nouvelle propriété : ajouter https://www.nouveau-site.com en propriété de domaine (DNS verification), pas en URL prefix — la DNS verification couvre tous les sous-domaines et protocoles.
2. Outil "Changement d’adresse" : si le domaine change (ex : ancien-site.fr → nouveau-site.fr), utiliser l’outil Address Change de GSC. Il déclenche un transfert de signaux explicite. Si seul le CMS change mais le domaine reste, cet outil n’est pas utilisé.
3. Soumettre les sitemaps : à J+0, soumettre le nouveau sitemap.xml dans GSC. Sur l’ancienne propriété (si conservée), garder l’ancien sitemap pour aider Google à découvrir les 301.

Bing Webmaster Tools propose les mêmes fonctionnalités via son interface « Site Move ». Ne pas l’oublier : Bing pèse 6 à 9 % du trafic search en France, beaucoup plus en B2B.

8. Core Web Vitals : profiter de la refonte pour viser LCP < 1,5s

Une refonte WordPress → Next.js, c’est l’occasion en or de transformer les Core Web Vitals d’un site mou (LCP > 4s, INP rouge) en site nerveux. Et Google le récompense en SERP : depuis l’intégration des CWV au cœur de l’algorithme en 2024, un site rapide gagne mécaniquement des positions sur la longue traîne.

Objectifs CWV à viser sur le nouveau site

1. LCP < 1,5s en P75 mobile (Largest Contentful Paint).
2. INP < 150ms (Interaction to Next Paint).
3. CLS < 0,05 (Cumulative Layout Shift).

Les leviers Next.js qui permettent ces scores : Server Components par défaut, next/image avec dimensions explicites pour éliminer le CLS, next/font en self-hosted pour supprimer la latence Google Fonts, streaming SSR avec Suspense pour découper le rendu, et un déploiement sur Vercel ou Cloudflare Pages pour bénéficier du CDN edge. Pour une plongée détaillée sur ce sujet, voir notre service référencement SEO.

9. Suivi 30/60/90 jours post-launch

La refonte ne s’arrête pas le jour de la mise en ligne. Les 90 jours qui suivent sont la phase la plus critique pour détecter et corriger les régressions avant qu’elles ne deviennent permanentes.

J+1 à J+7 : surveillance temps réel

1. Crawl Screaming Frog complet le jour J : zéro 404 toléré, toutes les anciennes URLs doivent répondre 301.
2. GSC "Couverture" → suivi quotidien des « URLs avec erreur » et des « URLs valides ».
3. Analytics : surveiller le volume de sessions organiques heure par heure. Une chute > 30 % à J+1 = bug critique à corriger immédiatement.
4. Real User Monitoring (RUM) : Vercel Analytics, Cloudflare Web Analytics ou un outil dédié.

J+8 à J+30 : stabilisation

1. Suivi hebdomadaire des positions sur les 100 mots-clés top par Ahrefs / SEMrush.
2. Identifier les pages qui perdent > 3 positions : vérifier le rendu HTML, les meta, le contenu, les internal links pointant dessus.
3. Corriger les éventuels canonicals erronés. Un canonical qui pointe vers localhost ou vers l’environnement de staging = catastrophe SEO. Tester en production avec curl -I.

J+31 à J+90 : optimisation

1. Comparer l’indexation GSC (Pages indexées) avant/après. Doit revenir au niveau pré-refonte à J+60.
2. Analyser les pages à fort trafic perdu : opportunité d’enrichir le contenu ou de retravailler le maillage interne.
3. Désindexation propre des pages 410 via GSC Removals si nécessaire.

10. Les 6 erreurs fatales qu’on voit encore en 2026

Synthèse des écueils les plus destructeurs, observés en audit post-refonte chez nos clients (et parfois corrigés en urgence) :

1. Changer de domaine ET de structure d’URL en même temps : Google met 6 à 12 mois à digérer les deux signaux cumulés. Faire un seul changement à la fois, espacé d’au moins 90 jours.
2. Rediriger toutes les pages vers la home : équivaut à supprimer le site aux yeux de Google. Toujours redirection thématique.
3. Mettre Disallow: / sur l’ancien robots.txt : bloque le crawl des 301, perte de jus garantie.
4. Oublier les hreflang sur les variantes linguistiques : fragmente l’autorité du site et fait remonter la mauvaise langue en SERP locale.
5. Lancer un vendredi soir : si bug critique, personne n’est disponible pendant 48h. Lancer un mardi matin, équipe complète mobilisée toute la semaine.
6. Ne pas conserver l’ancien environnement WordPress accessible en interne : impossible de comparer A/B avec l’ancien, de récupérer un contenu oublié, ou de diagnostiquer une régression précise.

Conclusion : la refonte, un investissement, pas une dépense

Une refonte SEO bien préparée est un accélérateur business. Mal préparée, c’est un suicide commercial. La différence tient à un seul paramètre : le sérieux du travail préparatoire en amont, avant la première ligne de code. Comptez 30 à 40 % du budget total de la refonte sur la partie audit + cartographie + plan de redirections. C’est ce qui sauve les 60 à 70 % restants.

Chez Go To Agency, nous avons industrialisé ce processus à Dijon pour des clients partout en France et au-delà. Nos refontes WordPress → Next.js préservent en moyenne 97 à 102 % du trafic organique à J+90 — certains projets voient même leur trafic augmenter de 20 à 40 % dans les six mois suivants, grâce au gain combiné Core Web Vitals + architecture éditoriale propre. Si vous préparez une refonte critique pour votre activité, demandez-nous un devis : nous auditons votre site actuel et établissons le plan de migration en moins de 72h. Vous pouvez aussi consulter notre offre site vitrine refondu pour les projets plus modestes.