Il est impossible de garantir qu'une refonte WordPress n'entraînera aucune fluctuation SEO. Il est en revanche possible de limiter fortement les risques : inventorier les URLs et les pages utiles, conserver les adresses importantes, préparer les redirections permanentes, reprendre les contenus et métadonnées, tester la nouvelle version puis surveiller l'exploration et les performances après la mise en ligne.
Pourquoi une refonte peut-elle faire perdre du trafic ?
Google ne voit pas une nouvelle maquette comme un simple changement visuel. Une migration peut simultanément modifier :
- les URLs ;
- la structure des titres ;
- le contenu principal ;
- les liens internes ;
- les balises canonical ;
- les données structurées ;
- la vitesse et le rendu mobile ;
- le sitemap et les règles d'exploration ;
- les réponses du serveur.
Lorsqu'un grand nombre de signaux changent le même jour, les moteurs doivent réexplorer et réévaluer le site. Les pertes les plus évitables viennent souvent de pages oubliées, de redirections absentes, de contenus raccourcis sans analyse ou d'une nouvelle version inaccessible aux robots.
Avant la migration : construire une photographie de référence
La préparation commence avant d'écrire le nouveau site.
Exporter toutes les URLs connues
Il faut croiser plusieurs sources : crawl du site, sitemap, export de la Search Console, données analytics et, si possible, liste des pages recevant des liens externes. Aucune source isolée ne fournit nécessairement une liste complète.
Pour chaque URL, relevez au minimum :
- son statut HTTP ;
- son titre et sa description ;
- son titre principal ;
- sa canonical ;
- son trafic organique ;
- ses conversions éventuelles ;
- les liens internes et externes importants ;
- la destination prévue après migration.
Identifier les pages qui ont réellement de la valeur
Une page peut avoir peu de trafic mais répondre à une objection commerciale importante. À l'inverse, une ancienne page indexée peut être devenue inutile. La décision de conserver, fusionner ou supprimer doit combiner les données de recherche et la connaissance métier.
Conserver un état des performances
Notez la date de référence et exportez les clics, impressions, CTR et positions des principales pages et requêtes. Conservez aussi les mesures de performance web et les conversions. Sans état initial, il devient difficile de distinguer une conséquence de la migration d'une tendance déjà engagée.
Faut-il conserver les mêmes URLs ?
Oui, autant que possible lorsque les pages gardent le même sujet. Changer une URL sans raison ajoute un risque et oblige les moteurs comme les visiteurs à passer par une redirection.
Une nouvelle URL peut être justifiée lorsque l'ancienne est trompeuse, lorsque plusieurs pages sont fusionnées ou lorsque l'architecture doit être profondément simplifiée. Dans ce cas, chaque ancienne adresse utile doit pointer vers la destination la plus proche, et non systématiquement vers la page d'accueil.
Comment préparer les redirections ?
La table de redirection doit être construite et testée avant la mise en ligne.
| Ancienne situation | Action recommandée |
|---|---|
| Même contenu, même sujet | Conserver l'URL si possible |
| URL modifiée | Redirection permanente vers la nouvelle URL équivalente |
| Deux pages fusionnées | Rediriger les deux anciennes vers la page consolidée |
| Page supprimée avec remplaçant pertinent | Rediriger vers ce remplaçant |
| Page supprimée sans équivalent | Retourner un statut 404 ou 410 assumé |
Évitez les chaînes de redirections : l'ancienne URL doit atteindre directement sa destination finale. Les redirections doivent rester actives suffisamment longtemps pour les utilisateurs, les liens externes et les moteurs.
Quels éléments reprendre sur chaque page ?
Une reconstruction fidèle doit contrôler au minimum :
- le contenu principal et son intention ;
- un titre principal clair ;
- le title et la meta description ;
- la canonical ;
- les attributs alternatifs utiles des images ;
- les liens internes ;
- les données structurées réellement applicables ;
- les éléments de conversion ;
- le statut d'indexation souhaité.
Il ne s'agit pas de recopier mécaniquement toutes les erreurs de l'ancien site. Les éléments doivent être conservés lorsqu'ils sont utiles et corrigés lorsqu'ils sont incohérents.
Comment tester la nouvelle version avant la bascule ?
La prévisualisation doit rester inaccessible à l'indexation tout en étant testable par l'équipe. Avant l'ouverture, vérifiez :
- que toutes les pages attendues répondent correctement ;
- que les anciennes URLs importantes ont une destination ;
- que les canonicals pointent vers le domaine final ;
- que les formulaires fonctionnent réellement ;
- que les liens internes ne pointent pas vers l'environnement de test ;
- que le sitemap contient uniquement des URLs finales indexables ;
- que le fichier robots.txt n'interdit pas le site de production ;
- que les pages d'erreur utilisent le bon statut HTTP ;
- que le rendu mobile et les performances sont acceptables.
Checklist du jour de mise en ligne
- sauvegarder l'ancienne version et les exports ;
- déployer la version validée ;
- activer et tester les redirections ;
- contrôler la page d'accueil et les pages prioritaires ;
- tester les formulaires et les conversions ;
- vérifier robots.txt, sitemap et canonicals ;
- soumettre le sitemap dans la Search Console ;
- annoter la date de migration dans les outils de mesure ;
- vérifier les journaux et les erreurs 404.
Que surveiller après la migration ?
Les premières vérifications doivent être rapprochées, puis s'espacer lorsque la situation se stabilise.
Les premiers jours
Contrôlez les erreurs serveur, les pages introuvables, les redirections, les formulaires et les problèmes de rendu. Vérifiez que les moteurs peuvent explorer les pages prioritaires.
Les premières semaines
Suivez l'indexation, les clics, les impressions, les requêtes, les conversions et les Core Web Vitals. Analysez les évolutions page par page plutôt qu'un chiffre global isolé.
À J+30, J+60 et J+90
Comparez les périodes en tenant compte de la saisonnalité et des évolutions déjà présentes avant la migration. Documentez les problèmes rencontrés et les corrections : ces données permettront d'améliorer les prochaines migrations.
Les erreurs les plus fréquentes
- changer toutes les URLs pour les rendre plus « propres » ;
- rediriger toutes les anciennes pages vers l'accueil ;
- oublier une version avec ou sans slash final ;
- laisser une directive
noindexou un blocage robots de préproduction ; - supprimer des contenus positionnés sans solution de remplacement ;
- modifier simultanément le domaine, l'architecture, les contenus et la marque sans nécessité ;
- mesurer uniquement la vitesse et oublier les conversions ;
- déclarer la migration terminée le jour de la mise en ligne.
Une migration vers Next.js est-elle différente ?
Les fondamentaux SEO restent les mêmes : des pages accessibles, un contenu utile, des URLs stables et des réponses HTTP correctes. Next.js peut faciliter la génération statique, les métadonnées et les performances, mais une mauvaise implémentation peut toujours créer des pages absentes, du contenu uniquement côté client ou des canonicals incorrectes.
Avant de choisir la technologie, vérifiez d'abord si le site doit réellement être remplacé grâce à notre guide site WordPress lent : optimiser ou refaire ?. Le budget et le périmètre sont détaillés dans combien coûte une migration WordPress ?.
En résumé
Préserver le référencement d'un site WordPress exige de préparer la migration comme un changement de système, pas comme une simple mise en ligne. Conservez les URLs utiles, mappez les redirections, reprenez les contenus et métadonnées, testez la version finale et suivez les données plusieurs semaines. La méthode Seconde Vie WordPress intègre ces contrôles avant et après la bascule.