Migrer un site WordPress vers Next/Vercel peut être une excellente décision technique. Je comprends très bien l’envie : un site plus maîtrisable, plus rapide à déployer, moins dépendant d'un hébergement WordPress classique et souvent plus simple à maintenir quand le contenu est essentiellement éditorial. Mais côté SEO, la migration peut aussi faire très mal si elle est traitée comme une simple refonte visuelle.
La vraie question n'est donc pas "WordPress ou Next ?". Ce que je regarderais d’abord, c’est beaucoup plus concret : comment reconstruire le site sans perdre les URLs, les images, les métadonnées, les redirections, les contenus programmés, les pages légales, les PDFs, le sitemap et le maillage interne qui font déjà vivre le site.
Pourquoi migrer WordPress vers Next/Vercel ?
WordPress reste très solide pour publier vite, gérer des auteurs, installer des extensions et travailler sans développeur à chaque changement. Mais il peut devenir lourd quand le site accumule un thème, un page builder, des plugins, des optimisations cache, des scripts marketing et des réglages serveur qui se contredisent.
Next.js et Vercel changent la logique. On passe vers un site où le rendu, les routes, les composants, les données structurées, les images et les déploiements sont gérés dans un projet plus contrôlé. Pour un site éditorial qui publie surtout des articles, comparatifs et pages guides, je trouve que le vrai gain est là : moins de dépendances obscures et des mises en production plus prévisibles.
Le gain n'est pas automatique. Un Next mal construit peut aussi être lent, fragile ou mauvais pour Google. À mes yeux, le vrai avantage apparaît quand le projet reprend ce que WordPress faisait bien, tout en retirant ce qui l'alourdissait : HTML propre, images servies correctement, liens internes maîtrisés, pages légales présentes, redirections testées, sitemap vivant et déploiement réversible.
Quand il vaut mieux rester sur WordPress
Une migration Next/Vercel n'est pas une médaille technique. Si le site dépend énormément de WooCommerce, d'un espace membre complexe, de formulaires avancés, de workflows éditoriaux multi-auteurs, de plugins métier ou d'une équipe habituée à publier dans l'admin WordPress, je réfléchirais deux fois avant de tout sortir de WordPress.
La meilleure décision est parfois hybride : garder WordPress comme source éditoriale headless, ou reconstruire seulement la partie publique qui a besoin de performance et de contrôle. Je ne sacrifierais pas l'ergonomie de publication au nom d'une architecture plus moderne si l’équipe publie tous les jours dans WordPress.
L'inventaire SEO avant de toucher au site
Avant d'écrire une ligne de code, je listerais ce qui existe. Cela inclut les articles publiés, les articles programmés, les brouillons utiles, les pages fixes, les catégories, les tags qui rankent, les PDFs, les images, les favicons, les redirections historiques, les anciennes URLs avec backlinks et les pages qui reçoivent encore du trafic.
Google recommande, dans sa documentation sur les migrations avec changement d'URL, de préparer le nouveau site, vérifier Search Console, créer un mapping d'anciennes vers nouvelles URLs, mettre à jour les liens internes, préparer un sitemap avec les nouvelles URLs et tester les redirections. Même si vous gardez le même domaine, cette logique reste très utile.
Sur un WordPress, l'export peut venir de plusieurs sources : l'export natif, la REST API, la base de données, un backup, un sitemap, un crawl Screaming Frog, Search Console et parfois Wayback Machine si certaines pages ont disparu. La REST API WordPress expose notamment les champs des articles comme les dates, le contenu, le slug, le statut ou les liens de rendu, mais elle ne remplace pas toujours les métadonnées SEO de plugins comme Rank Math ou Yoast.
Erreur fréquente : exporter seulement les articles visibles. Une migration sérieuse doit aussi chercher les éléments invisibles mais utiles : anciennes redirections, PDF indexés, pages légales, images de couverture, ALT, Open Graph, catégories, données structurées et contenus programmés.
Contenus, images, PDFs et pages oubliées
La partie la plus pénible d'une migration n'est pas toujours le texte. Ce sont les détails que personne ne voit dans la maquette : une image qui avait une URL historique, un PDF posé à la racine ou dans /wp-content/uploads/, un favicon repris par les navigateurs, une page "À propos" qui rassure, une mention légale obligatoire, ou une ancienne archive encore visitée depuis Google. C’est souvent là que les petites pertes SEO commencent.
Pour les images, il faut décider si l'on garde les anciennes URLs de type /wp-content/uploads/... ou si l'on redirige vers un nouveau dossier. Garder les anciennes URLs est souvent plus simple pour ne pas casser les images déjà référencées dans les articles, les cartes sociales ou les backlinks directs vers les médias.
Pour les PDFs, la règle est encore plus stricte : si un fichier rankait sans être vraiment lié dans le site, il faut le remettre en ligne à la même adresse ou créer une redirection propre vers sa nouvelle adresse. Un PDF peut être un actif SEO, même s'il n'apparaît dans aucun menu.
URLs, redirections et canonicals
Le mapping d'URL est le cœur de la migration. Je ne laisserais aucune ancienne URL importante sans décision claire : même URL conservée, redirection vers la nouvelle page équivalente, redirection vers une page consolidée, ou vraie 404/410 si la page n'a plus de valeur et ne doit pas être remplacée.
Il faut éviter la mauvaise facilité : tout rediriger vers la home. Google indique que rediriger beaucoup d'anciennes URLs vers une page non pertinente peut perturber les utilisateurs et être traité comme un soft 404. Une redirection doit répondre à l'intention de l'ancienne page.
Dans le vocabulaire SEO, on parle souvent de 301. Dans Next.js et Vercel, les redirections permanentes peuvent aussi être servies en 308. La documentation Next.js précise que permanent: true utilise un 308, tandis que permanent: false utilise un 307. L'idée SEO reste la même : une redirection permanente doit être réservée aux déplacements définitifs.
La documentation Vercel rappelle aussi que certains cas peuvent se gérer au niveau des redirections, du domaine, de middleware ou d'une configuration plus dynamique. Pour une migration éditoriale classique, le plus propre est souvent de garder une table de redirections lisible, testable et versionnée.
Ce que Next/Vercel doit reprendre proprement
Une version Next réussie ne doit pas seulement afficher les textes. Elle doit reprendre les comportements SEO que WordPress gérait parfois via thème, plugin ou cache. Je vérifierais donc les titres, descriptions, canonicals, Open Graph, images principales, données structurées, sitemap, robots.txt, pagination et pages catégories comme de vraies pièces du site, pas comme des décorations.
Next.js permet de générer un sitemap via un fichier spécial sitemap.js ou sitemap.ts, ce qui est pratique pour construire un sitemap à partir de données de contenu. Sa documentation indique que ce fichier suit le format XML des sitemaps et peut renvoyer un tableau d'URLs quand il est généré par code.
Le point critique, surtout après WordPress, est la cohérence des dates. Si un ancien article est profondément refondu, il peut être pertinent d'assumer la nouvelle version avec une date récente. En revanche, une migration technique ne doit pas modifier artificiellement toutes les dates. Sinon, Google, les lecteurs et les archives perdent le fil.
Lecture ToolsBoxSEO : pour moi, la meilleure migration est celle qui donne l'impression que rien n'a cassé pour le lecteur, tout en donnant plus de contrôle à l'équipe technique. Le visiteur ne doit pas sentir la plomberie.
Smoke tests avant et après bascule
Avant de changer le DNS ou l'alias de production, je parcourrais le site comme un vrai visiteur. La home, les catégories, les articles d'avis, les articles informatifs, les pages légales, le menu mobile, le footer, les images de cartes, les tableaux, les FAQ et les anciens liens doivent être testés sur desktop et mobile.
Après la bascule, le contrôle doit être encore plus simple et plus brutal : est-ce que la home répond ? Est-ce que le sitemap répond ? Est-ce que les articles importants sont en 200 ? Est-ce que les anciennes URLs redirigent ? Est-ce que les contenus programmés sortent au bon moment ? Est-ce que les covers ne sont pas recadrées n'importe comment ? Est-ce que Search Console ne remonte pas une vague de 404 inattendues ?
Ce sujet rejoint directement l’article sur Googlebot, le crawl et les limites techniques. Une migration change souvent la manière dont Google recrawl le site. Il faut donc regarder les logs, les erreurs, les sitemaps et les pages réellement servies, pas seulement la maquette.
Tableau de migration
| Élément à migrer | Risque si oublié | Traitement recommandé | Contrôle final |
|---|---|---|---|
| Articles publiés | Perte de trafic et 404 sur URLs historiques. | Conserver les slugs quand c'est possible, sinon mapper vers une URL équivalente. | Crawl complet + sitemap + test des pages fortes. |
| Images et covers | Images cassées, cartes sociales moins propres, archives moins crédibles. | Copier les médias utiles et garder les URLs /wp-content/uploads/ si elles sont déjà utilisées. | Contrôle visuel desktop/mobile des articles et archives. |
| PDFs indexés | Perte d'un actif qui pouvait ranker seul. | Remettre le fichier en ligne ou créer une redirection directe vers sa nouvelle adresse. | Test HTTP + recherche dans Search Console. |
| Redirections historiques | Backlinks gaspillés et mauvaises expériences utilisateur. | Importer les anciennes règles utiles dans une table versionnée. | Test par lot, en vérifiant status et destination. |
| Pages légales et À propos | Perte de confiance, site incomplet, signaux faibles côté crédibilité. | Recréer des pages simples, propres, accessibles depuis le footer et le menu si nécessaire. | Parcours mobile + liens footer + indexabilité. |
| Données structurées | FAQ, breadcrumb ou produit non repris après migration. | Centraliser les composants JSON-LD au lieu de coller du code au hasard. | Test rich results / inspection du HTML généré. |
Verdict ToolsBoxSEO
Migrer WordPress vers Next/Vercel peut être très intéressant pour un site éditorial ou un média de niche qui veut reprendre la main sur le rendu, les performances, les composants et les déploiements. Mais ce n'est pas une solution magique. Le SEO ne se transfère pas parce que le nouveau site est moderne.
Le bon ordre, je le garderais toujours dans cette logique : inventaire, mapping, export, reconstruction, redirections, sitemap, tests visuels, smoke tests HTTP, bascule progressive, puis suivi Search Console. Si ces étapes sont respectées, Next/Vercel peut devenir un socle plus propre que WordPress. Si elles sont bâclées, le site peut perdre exactement ce qu'il avait mis des mois à construire.
Mon avis est donc prudent : migrer oui, mais seulement si l'on accepte de traiter le projet comme une migration SEO, pas comme un changement de thème. Une refonte peut embellir le site. Une vraie migration doit préserver ce qui ranke.
FAQ
Est-ce que Next/Vercel ranke mieux que WordPress ?
Non, pas automatiquement. Google ne récompense pas un framework pour son nom. Next/Vercel peut aider si le site est plus rapide, plus propre, mieux structuré et plus stable, mais un WordPress bien optimisé peut très bien ranker.
Faut-il garder les mêmes URLs qu'avant ?
Oui, quand c'est possible. Je garderais les mêmes slugs et les mêmes chemins dès que cela ne crée pas de problème. Quand une URL change, il faut prévoir une redirection permanente vers la page équivalente la plus pertinente.
Que faire des anciennes images WordPress ?
Si elles sont utilisées dans les articles ou déjà référencées, le plus simple est souvent de conserver leur chemin public de type /wp-content/uploads/.... Sinon, il faut au minimum vérifier que les anciennes URLs importantes ne cassent pas.
Les redirections Next en 308 posent-elles un problème SEO ?
Non, une redirection 308 est une redirection permanente. Beaucoup de SEO disent encore "301" par habitude, mais l'important est d'utiliser une redirection permanente cohérente et de pointer vers une page vraiment équivalente.
Faut-il déployer avant de changer les DNS ?
Oui. Je testerais une URL de preview ou un domaine temporaire, avec le rendu, les redirections, le sitemap, les images et les pages importantes, puis seulement ensuite je basculerais le domaine principal.
Combien de temps faut-il surveiller après migration ?
Les premiers jours sont critiques pour les erreurs visibles, mais je continuerais le suivi SEO plusieurs semaines. Il faut regarder Search Console, les logs, les 404, les redirections et l'évolution des pages importantes.