Migration WordPress vers Next.js : préserver le SEO sans bloquer la refonte

Figer les invariants, pas l’ancien site

Préserver le SEO ne signifie pas reproduire le thème WordPress, garder chaque extension ou copier le même balisage ligne par ligne. Cela signifie conserver ce qui aide un utilisateur et un moteur à comprendre, trouver et utiliser les pages qui ont une valeur.

Avant le premier composant Next.js, l’équipe écrit les invariants du projet :

• les URL qui doivent rester identiques et celles qui peuvent changer ;
• l’intention et les éléments essentiels de chaque page stratégique ;
• les règles de canonicale, d’indexation, de pagination et de variantes linguistiques ;
• les données structurées réellement justifiées par le contenu visible ;
• les liens internes qui rendent les contenus accessibles ;
• la mesure de référence : clics, impressions, pages d’entrée, conversions et erreurs d’exploration.

Cette liste libère la refonte. L’équipe peut changer la grille, les composants, le CMS, la navigation et le mode de rendu tant qu’elle prouve le respect des invariants. Elle peut aussi supprimer ou fusionner une page faible si sa destination répond mieux au besoin et si la redirection est pertinente.

La décision de migrer doit déjà avoir été prise avec une méthode comparable à la grille WordPress vers Next.js. Le présent runbook commence après cette décision ; il ne transforme pas une préférence technique en justification SEO.

Porte 1 — Inventaire et correspondance

L’inventaire est un registre, pas un simple export de sitemap. Il réunit toutes les URL observables : sitemap WordPress, exploration interne, pages vues dans l’analytics, pages d’entrée, URL liées depuis l’extérieur, médias indexés, anciennes redirections et variantes découvertes dans Search Console. Les URL orphelines ou non indexées peuvent encore porter des liens, des campagnes ou des usages.

Chaque ligne contient au minimum :

Champ	Question à trancher
URL source	Quelle adresse répond aujourd’hui et avec quel statut ?
Type et intention	Article, page, archive, outil, média : quel besoin sert-elle ?
Signaux observés	Entrées, clics, liens, conversions ou rôle de navigation connus
Décision	Conserver, réécrire, fusionner, rediriger ou retourner une vraie suppression
Destination	URL finale pertinente, sans chaîne intermédiaire
Preuve	Contenu, statut, canonicale, liens et mesure à contrôler
Propriétaire	Qui corrige et qui accepte l’écart ?

Une URL n’entre dans le lot que si sa destination et sa preuve sont connues. Cette règle évite les redirections massives vers l’accueil, les pages oubliées et les décisions prises pendant la bascule.

Google recommande une correspondance entre les anciennes et nouvelles URL et des redirections permanentes côté serveur vers les destinations finales. Sa documentation sur les migrations de site déconseille les redirections non pertinentes vers une page unique et invite à limiter les chaînes.

Le registre doit aussi signaler les fonctions qui ne sont pas visibles dans un sitemap : recherche interne, formulaires, flux RSS, pages auteurs, archives, paramètres de campagne et téléchargements. Leur traitement relève parfois de l’expérience ou de la conformité plus que du classement, mais leur rupture affecte directement la valeur du site.

Porte 2 — Parité sur le rendu final

Une fiche « développée » n’est pas une preuve. Le contrôle porte sur la réponse HTTP et le HTML réellement servis dans un environnement proche de la production. Pour chaque modèle de page, comparez un échantillon représentatif, puis automatisez les contrôles déterministes.

Contenu et intention

Le titre, le chapô, les sections essentielles, les médias utiles et les réponses recherchées doivent être présents. La formulation peut évoluer ; l’intention ne doit pas être perdue dans une réécriture esthétique. Vérifiez également auteurs, dates, légendes, tableaux, listes et fichiers à télécharger.

Indexation et canonicalisation

Contrôlez le code de statut, l’URL canonique absolue, les directives robots, les variantes linguistiques et les pages paginées. L’API de métadonnées Next.js permet notamment de déclarer canonicales et directives robots. Le fait que le framework sache les générer ne garantit pas que la valeur métier choisie est correcte : une canonicale vers l’environnement de prévisualisation reste une erreur.

Liens et navigation

Les liens importants doivent exister dans le HTML et conduire directement à la bonne destination. Google documente comme explorables les liens utilisant un élément d’ancrage avec un attribut href résoluble. La page sur les liens explorables rappelle aussi l’importance d’un texte d’ancrage descriptif. Un gestionnaire de clic JavaScript sans destination n’est pas un substitut équivalent.

Données structurées

Validez le JSON-LD rendu, son type et sa cohérence avec le contenu visible. Une migration est une bonne occasion de retirer les propriétés inventées, obsolètes ou sans preuve. Ne conservez pas un balisage uniquement parce qu’une extension WordPress le produisait.

Images et expérience

Testez les URL d’images, dimensions, formats, textes alternatifs, recadrages et partages sociaux. Comparez les métriques de terrain disponibles et les tests de laboratoire, mais diagnostiquez les causes : réponse serveur, ressource principale, scripts tiers, mise en page et interaction. Next.js fournit des outils ; la performance résulte de l’ensemble livré.

Cette porte produit un rapport par modèle de page. Les erreurs partagées, par exemple une canonicale de base ou un composant de lien, sont corrigées dans le socle. Les écarts spécifiques restent attachés aux URL concernées.

Porte 3 — Répétition générale

La répétition générale exécute le vrai plan sur une copie récente des contenus, avec les mêmes étapes que la production. Elle mesure le temps, les échecs et la capacité de retour arrière.

1. Geler le registre du lot. Toute nouvelle URL ou modification éditoriale est tracée pour éviter qu’un export ancien remplace une correction récente.
2. Importer ou connecter le contenu. Contrôler les totaux par type, les identifiants, les slugs, les relations, les auteurs et les médias.
3. Générer les règles de redirection. Tester chaque source, le statut permanent, la destination finale et l’absence de boucle.
4. Explorer l’environnement cible. Chercher erreurs 4xx/5xx, URL non canoniques, liens cassés, pages sans titre, contenus trop différents et ressources bloquées.
5. Comparer un échantillon humain. Desktop, mobile, navigation au clavier, partage social, formulaire, recherche, impression si elle compte.
6. Simuler la bascule et le retour. Chronométrer les opérations et vérifier que les contenus créés pendant la fenêtre ne disparaissent pas.

Les redirections peuvent être déclarées dans la configuration Next.js ou dans une couche en amont. La documentation des redirections Next.js distingue notamment redirections permanentes et temporaires. Le choix du lieu dépend du volume, de l’infrastructure et de la responsabilité opérationnelle ; le test doit porter sur le résultat HTTP public.

La répétition est validée quand les écarts restants sont connus, attribués et acceptables. Une phrase comme « le sitemap a l’air bon » ne remplace pas le nombre d’URL attendues, le nombre testé, les différences trouvées et les corrections rejouées.

Porte 4 — Bascule et observation

Le jour de la bascule, réduisez les changements concurrents. Évitez de modifier simultanément le domaine, toutes les URL, le contenu, le modèle de mesure et la plateforme si ces changements peuvent être séquencés. Google recommande explicitement de changer une chose à la fois lorsque c’est possible.

Le journal de bascule doit contenir l’heure, la version, l’opérateur, le dernier état WordPress, l’empreinte des règles de redirection, la procédure de retour et les vérifications suivantes :

• résolution DNS ou routage attendu ;
• réponses 200 sur les pages prioritaires et 301/308 sur les anciennes URL déplacées ;
• absence de chaîne ou boucle sur un échantillon automatisé ;
• canonicales, robots et sitemap en environnement public ;
• navigation, recherche, formulaires, analytics et consentement ;
• journaux d’erreur, taux de 404/5xx et latence ;
• marqueurs de contenu au début, au milieu et à la fin des modèles sensibles.

Après la bascule, soumettez le nouveau sitemap, inspectez des URL représentatives et observez l’ancien comme le nouveau périmètre. Google précise que le traitement s’effectue URL par URL et peut prendre du temps. Une variation temporaire n’est ni une preuve d’échec ni une raison pour arrêter la surveillance.

Définissez avant la mise en ligne les critères de retour : hausse brutale des erreurs serveur, perte de fonctions de conversion, pages prioritaires inaccessibles, mauvais blocage robots, redirections erronées ou données structurées systématiquement invalides. Le trafic organique, plus lent à réagir, ne peut pas être l’unique déclencheur immédiat.

Traiter les écarts sans figer la refonte

Tous les écarts n’ont pas la même gravité. Classez-les :

• bloquant pour le lot : URL stratégique sans destination, page noindex par erreur, contenu principal absent, formulaire essentiel cassé, boucle ou redirection non pertinente ;
• corrigeable avant bascule générale : média secondaire absent, donnée structurée facultative incomplète, ancre interne à améliorer ;
• amélioration après stabilisation : réécriture d’un passage, nouvelle illustration, optimisation additionnelle sans régression par rapport à la référence.

Cette classification empêche deux excès : lancer malgré une perte essentielle ou bloquer toute la refonte pour un détail sans impact. Les contrôles automatisés gagnent à reprendre les principes de mesure de la fiabilité d’une automatisation : résultat utile, erreurs silencieuses et reprise.

La protection du SEO ne suffit pas si la nouvelle page n’aide pas l’utilisateur à agir. Une page peut conserver son titre et ses mots-clés tout en perdant son chemin vers le contact, l’inscription ou l’information attendue. Le diagnostic de ce qui empêche un site de générer des contacts complète utilement la vérification.

Savoir quand la migration est terminée

Conservez les redirections durablement. Google recommande au moins un an dans sa documentation sur les migrations, et l’expérience utilisateur peut justifier de les garder davantage. Mettez à jour les liens internes pour éviter de dépendre des redirections et corrigez en priorité les liens externes qui apportent des visites significatives lorsque vous pouvez contacter leur propriétaire.

La revue hebdomadaire suit peu d’indicateurs : anciennes URL encore demandées, erreurs par modèle, pages exclues de l’index, écarts de clics et d’impressions sur des groupes comparables, conversions par page d’entrée et changements de canonicale détectés. Chaque alerte doit avoir une action et un responsable.

Si votre migration présente un registre volumineux ou des règles difficiles à arbitrer, vous pouvez présenter le périmètre à Forge Labs en indiquant les URL, les sources de données et les seuils déjà retenus. L’objectif de l’échange est de clarifier la preuve de bascule, pas de promettre un classement.

La migration se termine lorsque les anciennes URL n’apportent plus de surprise, que les nouveaux modèles tiennent leur promesse, que les signaux techniques restent cohérents et que l’équipe sait diagnostiquer puis corriger un écart sans dépendre de l’ancien système.

Sources officielles

• Google Search Central — Site Moves and Migrations, préparation, redirections, canoniques et suivi.
• Google Search Central — Redirects and Google Search, types de redirection et signal canonique.
• Google Search Central — Make your links crawlable, structure des liens.
• Next.js — generateMetadata, canonicales, robots et métadonnées.
• Next.js — redirects, configuration des redirections.