Migrer WordPress vers Next.js sans perdre le SEO

Migrer WordPress vers Next.js est un projet produit et technique, pas un simple « lift and shift ». Next.js change le rendu, le déploiement, parfois le modèle éditorial. Le SEO, lui, dépend surtout de la continuité des URLs, de la clarté des signaux (canoniques, titres, données structurées) et de la capacité des robots à redistribuer l’historique vers les nouvelles pages. Traitez ces sujets comme des critères d’acceptance du go-live, au même titre que le design ou le formulaire de contact.

Dès le cadrage, nommez un responsable du mapping d’URL et un responsable du monitoring post-launch. Sans propriétaire, les 301 deviennent « on verra après » et le après n’arrive jamais. Fixez aussi le périmètre : même domaine ou nouveau domaine, conservation des slugs blog, sort des pages légales, traitement des UTM et des landings campagne encore actives.

Clarifiez ce que « sans perdre le SEO » signifie pour vous. En pratique, cela veut dire : limiter les 404 sur les URLs à trafic ou à backlinks, conserver des métadonnées cohérentes, reposer des sitemaps propres, et observer Search Console pendant une fenêtre de 90 jours. Cela ne veut pas dire « garder le même trafic la semaine suivante » : une refonte modifie souvent maillage, contenus et vitesse d’exploration.

Refusez les promesses de position. Une migration bien menée réduit le risque de perte ; elle ne garantit ni un maintien, ni une hausse. Votre engagement crédible porte sur la méthode, la couverture des redirections et le plan de remédiation, pas sur un classement.

Construisez un inventaire exhaustif avant d’écrire la première route Next.js « jolie ». Sources à croiser : crawl complet (Screaming Frog ou équivalent), export XML sitemap, liste des contenus WordPress (posts, pages, CPT, taxonomies), Search Console (pages indexées, pages avec impressions), analytics (landings), fichier de redirections déjà en place, backlinks connus si disponibles.

Pour chaque URL, capturez au minimum : statut HTTP actuel, titre, meta description, canonical déclarée, présence dans le sitemap, volume d’impressions ou de sessions si connu, type de contenu, et décision de migration. Un tableur simple suffit. L’important est la complétude, pas l’outil.

Attention aux URLs « invisibles » : pièces jointes PDF, pages de tags vides, archives de date, previews builder, paramètres de pagination, versions AMP résiduelles, URLs http encore linkées en interne. Sur WordPress, les permaliens et les plugins de redirection ont souvent créé une archéologie. Si vous ne la cartographiez pas, Next.js la découvrira sous forme de tickets paniqués après cutover.

Priorisez. Toutes les URLs n’ont pas le même poids. Une page service avec backlinks et impressions mérite une URL stable ou une 301 chirurgicale. Une page tag sans contenu peut fusionner vers la catégorie parente. Documentez les abandons : un 410 assumé sur une URL morte vaut parfois mieux qu’une 301 vers une homepage fourre-tout qui dilue le signal.

Le mapping transforme l’inventaire en décisions. Règle saine : conserver le path lorsqu’il reste pertinent (/blog/mon-article/ reste /blog/mon-article/). Changer pour « faire plus propre » sans bénéfice utilisateur est un luxe cher. Si vous changez, chaque ancienne URL stratégique doit pointer en 301 vers la meilleure URL équivalente, en une seule étape si possible.

Évitez les chaînes de redirections (A→B→C) et les boucles. Évitez aussi la 302 temporaire pour un déménagement durable : pour un relocation d’URL pérenne, la documentation Google Search Central pointe vers des redirections permanentes côté utilisateurs et moteurs. En Next.js, vous pouvez déclarer des redirects dans la configuration, via des fonctions de redirection, ou à la couche edge / reverse proxy. Choisissez un seul endroit source de vérité pour ne pas dupliquer des règles contradictoires.

Générez les règles à partir du tableur, pas à la main dans la précipitation du vendredi soir. Automatisez la génération d’un fichier redirects à partir du mapping validé. Puis testez un échantillon : top impressions, top backlinks, top conversions, et un tirage aléatoire. Vérifiez le code final, l’URL finale, et l’absence de passage par une 404.

Prévoyez les cas WordPress pénibles : slash final vs non, http vs https, www vs apex, uppercase, index.php, filtres d’URL de boutique WooCommerce, endpoints REST inutiles exposés au public. Normalisez d’abord sur l’ancien site si possible, puis migrez un jeu d’URL déjà propre. Moins de variantes = moins de 301 = moins d’erreurs.

Les landings pubs actives méritent un traitement VIP. Une campagne Google Ads qui pointe vers une URL morte le lundi du go-live coûte plus cher qu’un sprint de mapping. Alignez marketing et tech sur la date de bascule et sur la mise à jour des URL de destination.

WordPress + Yoast ou Rank Math gérait souvent titles, descriptions, canoniques et schémas. Sur Next.js, ces signaux deviennent du code et du contenu maîtrisés : metadata API App Router, composants structurés, éventuellement un CMS headless. Ne partez pas du principe que « le nouveau design suffit ». Recensez pour chaque template (accueil, page, article, fiche mission, catégorie) quels champs SEO sont requis.

Reprenez les titles et descriptions qui fonctionnaient, sauf s’ils sont trompeurs après refonte. Un title migrate pour coller à une nouvelle promesse éditoriale : oui. Un title vidé parce que personne n’a branché la metadata : non. Vérifiez la longueur et la cohérence h1 / title sans copier-coller mécanique. Les canoniques doivent pointer vers l’URL finale https choisie, sans variantes.

Pour le JSON-LD, reconstituez l’essentiel : Organization, WebSite, BreadcrumbList, Article ou FAQ lorsque le contenu le justifie. Inutile de coller dix schémas décoratifs. Mieux vaut peu de données structurées exactes que beaucoup de markup obsolète hérité d’un plugin. Validez avec les outils de test Google sur un échantillon de templates.

Les balises robots, le sitemap.xml et le robots.txt font partie du cutover. Publiez un sitemap des URL canoniques nouvelles, soumettez-le, retirez les anciennes URL du sitemap. Vérifiez que vous n’indexez pas les previews Vercel, les environnements de staging, ou des routes techniques. Une fuite d’indexation de staging pendant une migration ajoute du bruit inutile.

Migrer l’HTML généré par Divi, Elementor ou un thème surchargé n’est pas migrer le contenu. Nettoyez : titres réels, listes sémantiques, images avec alt, liens internes mis à jour vers les nouvelles URL. Un export brut colle souvent des shortcodes, des classes builder et des ancres mortes. Prévoyez un budget éditorial, pas seulement un budget dév.

Le maillage interne change avec l’IA de navigation. Si vous passez d’un blog WordPress dense à un hub plus sélectif, certaines pages perdent des liens internes. Compensez pour les URLs stratégiques : modules « articles liés », hubs thématiques, liens depuis les pages services. Le crawl découvre ce que vous liez ; les 301 ne remplacent pas un maillage vivant.

Les médias méritent un plan. Les URLs wp-content/uploads/ sont fréquemment backlinkées ou citées. Soit vous reverse-proxyez /wp-content/uploads vers le stockage moderne, soit vous redirigez fichier par fichier les assets critiques, soit vous acceptez des 404 médias après inventaire. Ignorer les PDF et dossiers de presse est une erreur classique de refonte « pure front ».

Côté WooCommerce ou catalogue, les filtres à paramètres, les pages produits discontinués et les catégories vides demandent des règles explicites. Une boutique mal nettoyée avant migration double le travail de 301. Archivez ou redirigez avant de reconstruire le catalogue dans Next.js ou dans un headless.

Le jour J, enchaînez dans un ordre écrit : bascule DNS ou reverse proxy, activation des 301, vérification du sitemap, vérification de la canonical racine, test smoke des top URL, test du formulaire, test du consentement cookies, surveillance des logs 404. Gardez l’ancien WordPress accessible en interne quelque temps (accès restreint) pour comparer contenus et rattraper un oubli.

Préparez un rollback réaliste. Si la bascule est DNS, documentez le TTL anticipé. Si c’est un reverse proxy, documentez le retour arrière. Un rollback SEO n’est pas seulement « remettre WordPress » : ce sont aussi les 301 inverses et la communication aux campagnes. Sans plan, la moindre frayeur prolonge une demi-migration toxique.

Instrumentez les 404 dès la première heure. Une table des 404 les plus hit, reliée au mapping, permet de créer des 301 manquantes en continu. Assignez une personne à cette file pendant les deux premières semaines. C’est moins glamour que le nouveau hero ; c’est ce qui protège le SEO.

Informez les parties prenantes : ads, emailing, partenaires qui deep-linkent, équipes commerciales avec PDF à URLs. La technique ne rattrape pas un QR code imprimé vers une ancienne landing si personne n’a été prévenu.

Après cutover, ouvrez une période de surveillance active d’environ 90 jours. Dans Search Console, suivez : couverture / pages indexées, erreurs 404, anomalies d’exploration, évolution des impressions et clics par page, éventuels messages de traitement. Comparez des cohortes d’URL migrées à l’identique versus URL changées.

Attendez-vous à de la volatilité. Les moteurs redistribuent le crawl, retraitent les 301, rafraîchissent les snippets. Une baisse temporaire d’impressions sur certaines requêtes n’est pas automatiquement un échec de migration ; une explosion de 404 sur des URL à historique, si. Votre tableau de bord doit séparer « bruit de redistribution » et « rupture technique ».

Planifiez des points hebdomadaires les quatre premières semaines, puis bi-hebdomadaires. Chaque point produit : top nouvelles 404, 301 ajoutées, pages désindexées inattendues, contenus à enrichir si le snippet montre un écart promesse / page. Gardez une backlog SEO post-migration distincte du backlog feature, sinon elle disparaît.

Au-delà de Search Console, corrélez avec analytics et logs serveur. Une chute de trafic brand avec des 301 saines oriente vers le message ou la saisonnalité. Une chute alignée sur des 404 oriente vers le mapping. Cette discipline évite les débats idéologiques « Next.js a cassé le SEO » quand le vrai problème est une table de redirections incomplète.

À 90 jours, faites un rétrospective : couverture du mapping initial, dette restante, pages à réécrire, opportunités de maillage. Capitalisez dans le vault projet pour la prochaine migration. La méthode s’améliore ; les serments de trafic, non.

Next.js ne protège pas d’une dette éditoriale. Sans règles de slug, sans revue de metadata, sans contrôle des landings one-shot, vous recreusez le même chaos dans un autre dépôt. Définissez qui crée les URLs, qui valide les redirections lors d’un renommage, qui retire une page de l’index.

Documentez le fichier de mapping comme un livrable versionné. Quand une URL change six mois plus tard, on ajoute une 301 ; on ne « casse pas pour faire plus joli ». Les équipes marketing doivent savoir que renommer un slug a un coût SEO et un coût tech.

Si le contenu revient via un CMS headless, branchez dès le début les champs SEO et les previews. Recoller Yoast mentalement après coup produit des pages élégantes indexées avec des titles génériques. Le template Next.js doit rendre difficile l’oubli, pas seulement possible le remplissage.

Enfin, gardez la lucidité : une migration réussie est une migration dont les risques ont été listés, réduits et surveillés. Ce n’est pas une migration magiquement neutre pour toutes les requêtes. Votre crédibilité auprès du client se joue sur la transparence du plan, pas sur un slogan de continuité parfaite.

Protéger le SEO lors d’un passage WordPress → Next.js, c’est surtout protéger la continuité des URL et la qualité des signaux : inventaire, mapping, 301 testées, métadonnées et JSON-LD rebranchés, sitemap propre.

Les builders et l’archéologie de permaliens sont des risques projet : budgétez le nettoyage éditorial et les médias, pas seulement le front. Le cutover sans filet 404 ni responsable monitoring est un pari.

Surveillez Search Console environ 90 jours, séparez bruit de redistribution et ruptures techniques, bouclez les 301 manquantes vite. Aucune méthode ne garantit le maintien des positions ; une méthode solide limite les pertes évitables et donne un plan de remédiation.

Versionnez le mapping, gouvernez les slugs après go-live, et refusez de reconstruire dans Next.js la dette que vous venez de quitter côté WordPress.