Plan de redirection pour une refonte WordPress : conserver les contenus et les URL

Préserver les contenus et les URL ne signifie pas conserver tout l’existant. Une refonte WordPress réussie trie, redirige et améliore sans reconduire la dette technique.

Temps de lecture :

13–19 minutes
Accueil » Blog » Créer son site » Plan de redirection pour une refonte WordPress : conserver les contenus et les URL

Une refonte commence souvent par une envie de propre : nouvelle arborescence, nouveau thème, pages mieux rangées. L’intention est saine. Elle devient risquée quand « faire propre » signifie supprimer tout ce qui paraît ancien sans vérifier ce que le site a accumulé.

Faire table rase peut alors provoquer une perte inutile. Sans inventaire ni plan de redirection, la refonte risque d’abandonner des signaux SEO, une partie de l’historique associé aux URL dans Google, des habitudes de navigation et des liens profonds publiés depuis longtemps sur des sites externes.

Un site WordPress ancien contient rarement uniquement des pages visibles dans le menu. Il contient des articles, des catégories, des fichiers, des liens externes, des favoris, des URL envoyées par email et des habitudes prises par les visiteurs.

La bonne refonte ne choisit donc pas entre table rase et copie conforme. Elle examine l’existant, conserve ce qui a une utilité, corrige ce qui doit l’être et retire explicitement ce qui n’a plus de raison d’exister.

Migration technique ou refonte totale : le plan de redirection reste indispensable

Une migration organisée conserve les contenus utiles, les visiteurs et les chemins importants.

Une migration technique peut conserver l’essentiel des contenus et des URL tout en changeant le thème, le code, l’hébergement, les extensions ou les modèles de pages. Une refonte totale peut aussi revoir l’arborescence, les contenus, les catégories et les chemins. Dans les deux cas, il faut préparer la migration et formaliser un plan de redirection avant la mise en ligne.

Le plan de redirection fait le lien entre l’ancien site et le nouveau. Il indique, pour chaque ancienne URL, si elle est conservée, déplacée, fusionnée ou retirée, ainsi que la destination et l’action HTTP attendue. Pour une refonte technique, il permet de repérer les quelques URL modifiées malgré la conservation de la structure. Pour une refonte totale, il devient la carte de passage entre deux arborescences différentes.

Une refonte commence par l’inventaire des contenus et des URL

Avant de dessiner la nouvelle page d’accueil, il faut savoir ce que l’ancien site contient réellement.

L’inventaire doit couvrir les pages, les articles, les catégories, les médias importants, les types de contenus créés par des extensions et les URL qui reçoivent encore des visites ou des liens. Les statistiques sont utiles, mais elles ne montrent pas tout : un ancien PDF de tarifs de plomberie peut être utilisé depuis un document interne, une URL peut rester dans le favori d’un client ou un lien externe peut ne pas apparaître dans les outils que vous consultez.

Une première liste peut rapprocher :

  • l’ancienne URL ;
  • le type de contenu ;
  • le trafic récent connu ;
  • les liens internes et externes repérés ;
  • l’état du contenu ;
  • et la décision envisagée.

Cette étape évite de découvrir après la mise en ligne que la page la plus demandée sur les résultats de recherche, par exemple celle consacrée au dépannage d’une fuite d’eau, n’a pas été migrée, que les documents ont changé d’adresse ou que des liens importants renvoient vers des erreurs.

Chaque contenu doit recevoir une décision explicite

Tous les contenus ne méritent pas le même traitement. Pour chaque ensemble cohérent, la refonte peut décider de :

  • conserver la page telle quelle si elle reste utile ;
  • la réécrire pour corriger le fond ou la forme ;
  • la fusionner avec un contenu plus complet ;
  • la déplacer dans une structure plus claire ;
  • la retirer parce qu’elle est obsolète et sans remplacement ;
  • ou la garder accessible sans la mettre en avant dans la navigation.

Un article ancien sur le débouchage d’une canalisation n’a pas besoin d’être affiché sur la page d’accueil pour continuer à servir. Il peut être archivé, contextualisé et relié vers une information plus récente.

À l’inverse, une page réellement supprimée ne doit pas être conservée par peur de perdre quelque chose. Elle doit simplement faire l’objet d’une décision technique : redirection vers un remplacement pertinent, réponse 410 quand le retrait est assumé, ou 404 lorsque le contenu n’a pas de destination équivalente.

Le classement « garder ou supprimer » est trop pauvre pour une refonte sérieuse. Il faut aussi pouvoir améliorer, fusionner, ranger et rediriger.

Changer un slug oblige à préparer une redirection

Une URL n’est pas seulement une adresse utilisée par Google. Elle peut se trouver dans un favori enregistré il y a plusieurs années, un ancien email, un PDF, un support de formation, un forum, un annuaire ou un site partenaire.

Même si une ancienne URL reçoit peu de visites aujourd’hui, elle a pu être explorée, partagée ou citée pendant longtemps. Sa valeur SEO peut être limitée, mais elle n’est pas forcément nulle. Surtout, un visiteur qui possède encore l’adresse ne devrait pas avoir à deviner la nouvelle.

Si le slug change, la relation doit être préparée avant la bascule :

/ancien-tarif-depannage-plomberie/
→ redirection permanente
→ /services/depannage-plomberie/

Le changement peut aussi servir à remettre un contenu dans la bonne famille éditoriale. Prenons le cas d’un site de plombier : un article de blog publié jusque-là à la racine peut être déplacé sous /actualites/ :

/comment-reparer-fuite-eau/
→ redirection permanente
→ /actualites/comment-reparer-fuite-eau/

Règle de migration des articles de blog

Pour cette migration, tous les articles de blog actuellement à la racine suivent la même logique : ceux qui sont conservés gardent leur slug, avec /actualites/ ajouté devant. Le changement concerne la famille éditoriale, pas le titre ni le sujet de l’article.

Lorsqu’un article de blog n’est pas conservé, la destination se décide au cas par cas : par défaut, l’ancienne URL peut rediriger vers la page d’accueil du blog /actualites/ ; si un autre article traite le même besoin, elle peut plutôt rediriger vers cet article. Par exemple :

/ancien-article-plomberie/
→ redirection permanente
→ /actualites/

/conseil-fuite-eau-ancien/
→ redirection permanente
→ /actualites/comment-reparer-fuite-eau/

Cette règle concerne les articles de blog. Une page de présentation du plombier peut rester à la racine, par exemple /plombier-caen/. De même, une page de service déjà correctement rangée sous /services/, par exemple /services/depannage-plomberie/, n’a pas besoin d’être déplacée uniquement pour donner l’impression d’une nouvelle structure. Chaque famille de contenus doit avoir son propre chemin.

La nouvelle destination doit répondre à la même intention ou à une intention suffisamment proche. Pour un article de blog non conservé, /actualites/ constitue le point de chute par défaut lorsqu’aucun article de remplacement n’est suffisamment pertinent. En revanche, une ancienne page sur les tarifs d’un dépannage plomberie ne doit pas être envoyée vers le blog : elle doit aller vers le service correspondant ou faire l’objet d’une décision distincte.

L’URL et le fil d’Ariane doivent raconter la même arborescence

Les articles de blog changent de famille d’URL, mais gardent leur sujet et leur repère.

Une nouvelle URL ne suffit pas à organiser un site. Il faut aussi définir la place du contenu dans le fil d’Ariane, afin que la navigation, le maillage interne et la structure éditoriale donnent le même repère :

  • un article déplacé : Accueil > Actualités > Plomberie > Comment réparer une fuite d’eau ;
  • une page de présentation conservée à la racine : Accueil > Plombier à Caen ;
  • une page de service déjà bien rangée : Accueil > Services > Dépannage plomberie ;
  • une page de service plus précise : Accueil > Services > Dépannage plomberie > Fuite d’eau.

Le fil d’Ariane peut donc exprimer une relation éditoriale même lorsque l’URL reste à la racine. À l’inverse, ajouter un dossier dans l’URL sans mettre à jour le fil d’Ariane, les liens internes et les données structurées crée une arborescence incohérente. Cette vérification doit faire partie du plan de migration, au même titre que la redirection.

Une redirection protège les visiteurs autant que l’historique SEO

On parle souvent du « jus SEO » transmis par une redirection. L’image aide à comprendre, mais elle est trop limitée si elle devient le seul argument.

Une redirection protège aussi une personne qui clique sur un vieux lien, un partenaire qui n’a pas mis à jour son site ou une équipe qui utilise encore un document interne. Elle maintient une continuité entre l’ancien chemin et la nouvelle organisation.

Ces anciens liens ne sont pas toujours visibles dans les statistiques : ils peuvent venir d’un article de presse qui présente le plombier, d’un annuaire de professionnels, d’un forum de bricolage, d’un PDF de devis ou de conseils, d’un site partenaire ou d’une page très profonde du site. Si l’ancienne adresse disparaît sans réponse adaptée, le visiteur arrive sur une erreur alors que l’information existe peut-être encore ailleurs. La refonte perd alors à la fois un accès utilisateur, un lien externe et une partie de l’historique accumulé par l’ancienne URL dans Google.

Elle ne crée pas artificiellement une valeur que l’ancienne page n’avait pas. Elle évite surtout de perdre sans examen ce qui existait déjà : accès, liens, historique, repères et compréhension du remplacement.

Il faut éviter deux erreurs fréquentes : créer des chaînes de redirections et envoyer toutes les anciennes URL du site vers une même destination. Pour les articles de blog non conservés, /actualites/ peut être la destination par défaut, mais les pages de services et les autres contenus doivent être traités selon leur propre intention. Une seule redirection directe vers la destination décidée au cas par cas est plus lisible et plus fiable.

Une 404 peut devenir une 301 ou une 302, selon le cas

301, 302, 404 ou 410 : le code dépend de la décision prise pour l’ancienne page.

Une 404 signifie que la page demandée n’existe pas à cette adresse. Ce n’est pas une redirection. Lorsqu’une ancienne URL de plomberie reçoit encore des visites mais que la page a changé d’adresse, on configure une redirection pour envoyer le visiteur vers la nouvelle page. On ne transforme donc pas toutes les 404 au hasard : on vérifie d’abord si un remplacement pertinent existe.

Une 301 indique que le déplacement est permanent. C’est le bon code lorsqu’un article de blog passe de la racine à /actualites/, lorsqu’une page de service change de slug ou lorsque le domaine passe de http://plomberie-exemple.fr à https://www.plomberie-exemple.fr :

/comment-reparer-fuite-eau/
→ 301 permanente
→ /actualites/comment-reparer-fuite-eau/

Une 302 indique que le déplacement est temporaire. Elle peut servir lorsqu’une page de dépannage plomberie est momentanément remplacée par une autre pendant des travaux, une maintenance ou un test. Elle ne doit pas être utilisée pour une migration définitive, car elle indique que l’ancienne URL a vocation à revenir :

/services/depannage-plomberie/
→ 302 temporaire
→ /services/urgence-plomberie/

Si l’ancien article sur un tarif de plomberie n’a aucun contenu de remplacement et ne doit plus exister, il peut rester en 404, ou recevoir une 410 lorsque le retrait est volontaire et définitif. Il ne faut pas le rediriger vers une page sans rapport uniquement pour faire disparaître l’erreur.

Pour une migration définitive, le plan de redirection doit donc utiliser des 301. Google comprend qu’il s’agit d’un changement permanent d’adresse et peut prendre en compte les signaux associés à l’ancienne URL. Une 302 ne doit pas remplacer une 301 pour masquer une migration définitive : elle est réservée à une situation réellement temporaire et ne doit pas figurer comme solution finale dans le plan de redirection.

Autrement dit : le plan de redirection de la refonte est un plan de 301, jamais un plan de 302. La 302 reste un outil ponctuel pour une page provisoirement déplacée, pas une solution de migration.

Pour info — une pratique de référencement plutôt « grise » autour des redirections

Certains référenceurs achètent des noms de domaine expirés dans le même secteur que leur client. Le domaine le plus recherché est souvent celui d’une véritable entreprise qui a fermé, cessé son activité ou simplement oublié de renouveler son nom de domaine. Ces domaines peuvent conserver des liens externes, des contenus historiques et une réputation liée à leur ancien site. Des robots repèrent rapidement les domaines expirés, qui sont ensuite proposés sur des plateformes d’enchères.

Une fois le domaine acquis, le propriétaire peut mettre en place une 301 vers le site du client, idéalement vers la page correspondant à la même intention :

https://ancien-plombier-caen-exemple.fr/depannage-fuite-eau/
→ 301
→ https://www.plomberie-exemple.fr/services/depannage-plomberie/

L’objectif recherché est de faire comprendre aux moteurs qu’un site a changé d’adresse et de récupérer une partie des signaux, de l’historique et des liens de l’ancien domaine. C’est aussi pour cela que certains parlent de « jus » et de « prime à l’âge ».

Cette pratique est dite grise lorsqu’elle sert uniquement à manipuler les signaux de recherche. L’ancienneté du domaine ne constitue pas une prime automatique : Google peut ignorer ou neutraliser les signaux d’un domaine sans rapport, artificiel, abandonné ou rempli de liens de mauvaise qualité. Une vraie reprise d’entreprise ou une migration justifiée est très différente de l’achat d’un domaine uniquement pour rediriger ses liens vers un client.

Une redirection de domaine doit conserver le chemin demandé

Cette règle ne concerne pas seulement une migration. Elle doit rester active pendant toute la vie du site : des visiteurs, des partenaires ou des annuaires peuvent créer un lien avec une variante du domaine, sans www ou avec http au lieu de https. L’objectif est que ce lien imparfait arrive quand même sur la page demandée.

Le domaine change de forme, mais le chemin demandé reste le même.

Lorsque le site adopte une version canonique avec www, chaque adresse sans www doit donc rediriger vers la même page avec www, et non envoyer toutes les pages vers l’accueil. Il s’agit d’une normalisation permanente du domaine, pas d’un traitement ponctuel réservé au lancement.

Pour un site de plomberie qui utilise https://www.plomberie-exemple.fr/ comme domaine canonique (notez le www):

https://plomberie-exemple.fr/plombier-caen/
→ https://www.plomberie-exemple.fr/plombier-caen/

https://plomberie-exemple.fr/services/depannage-plomberie/
→ https://www.plomberie-exemple.fr/services/depannage-plomberie/

https://plomberie-exemple.fr/actualites/comment-reparer-fuite-eau/
→ https://www.plomberie-exemple.fr/actualites/comment-reparer-fuite-eau/

Il ne faut pas faire ceci :

https://plomberie-exemple.fr/plombier-caen/
→ https://www.plomberie-exemple.fr/

https://plomberie-exemple.fr/services/depannage-plomberie/
→ https://www.plomberie-exemple.fr/

La même attention est nécessaire pour le protocole https. Un ancien lien peut encore utiliser http, mais la redirection doit conserver la page appelée :

http://www.plomberie-exemple.fr/plombier-caen/
→ https://www.plomberie-exemple.fr/plombier-caen/

http://www.plomberie-exemple.fr/services/depannage-plomberie/
→ https://www.plomberie-exemple.fr/services/depannage-plomberie/

http://www.plomberie-exemple.fr/actualites/comment-reparer-fuite-eau/
→ https://www.plomberie-exemple.fr/actualites/comment-reparer-fuite-eau/

La combinaison http/https et www/sans www doit idéalement être corrigée en une seule redirection directe. Le chemin, le slug et, lorsque c’est pertinent, les paramètres utiles doivent être conservés. Une URL profonde ne doit pas perdre sa destination simplement parce que le domaine canonique change.

Cette règle corrige les variantes de domaine et de protocole ; elle ne transforme pas une URL mal saisie, une page supprimée ou un ancien slug en page valide. Ces autres cas nécessitent leur propre redirection, une 404 ou une 410 selon la décision prise.

La nouvelle structure peut être plus propre sans recopier la dette technique

Conserver les contenus et les URL utiles ne signifie pas conserver l’ancien thème, les anciennes surcharges ou toutes les extensions qui les entouraient.

La refonte peut garder un article mais le migrer vers une structure HTML plus claire. Elle peut conserver l’intention d’une page sans reprendre un constructeur qui enfermait le contenu dans des blocs propriétaires. Elle peut préserver une URL tout en supprimant une extension qui n’est plus maintenue.

Cette séparation est importante : l’historique éditorial et les chemins utiles sont une chose ; la manière technique dont l’ancien site les produisait en est une autre.

La question à poser n’est pas « Peut-on tout migrer automatiquement ? » mais « Que doit-on préserver, et quelle ancienne dépendance peut-on laisser derrière nous ? »

Le maillage interne doit être mis à jour avant et après la bascule

Une redirection externe ne remplace pas un lien interne correct. Si les nouvelles pages sont connues, les liens du menu, des catégories, des articles et des blocs de contenu doivent pointer directement vers elles.

Après la migration, vérifiez notamment :

  • les liens dans les contenus conservés ;
  • les menus et les fils d’Ariane ;
  • les liens vers les documents ;
  • les canoniques et les sitemaps ;
  • les pages qui renvoient encore vers un ancien slug ;
  • et les liens créés par les extensions ou le constructeur.

Un site qui fonctionne parce que chaque lien interne passe par deux redirections n’est pas vraiment nettoyé. La chaîne peut être invisible pour un visiteur, mais elle complique l’exploration et le diagnostic.

Le plan de redirection doit accompagner la migration

Le plan de redirection ne devrait pas être une liste improvisée le jour du lancement. Il doit être préparé en parallèle de la nouvelle arborescence, puis testé sur une copie ou un environnement de préproduction. C’est un livrable de la migration au même titre que les contenus, les menus et les réglages techniques.

Dans ce plan, chaque déplacement définitif doit être indiqué comme une redirection 301. Les éventuelles 302 temporaires doivent être documentées séparément, avec leur date de fin ou leur condition de retour, afin qu’elles ne deviennent pas par oubli la réponse permanente d’une ancienne URL.

Ancienne URLDécisionNouvelle URLAction
/comment-reparer-fuite-eau/Déplacer l’article/actualites/comment-reparer-fuite-eau/Redirection 301 + mise à jour du fil d’Ariane
/ancien-article-plomberie/Article non conservé/actualites/Redirection 301 par défaut
/conseil-fuite-eau-ancien/Article non conservé/actualites/comment-reparer-fuite-eau/Redirection 301 vers l’article pertinent
/plombier-caen/Conserver à la racine/plombier-caen/Aucune redirection ; vérifier le fil d’Ariane
/services/depannage-plomberie/Conserver le chemin/services/depannage-plomberie/Aucune redirection ; mettre à jour les liens si besoin
/fuite-eau-maison/Fusionner/actualites/comment-reparer-fuite-eau/Redirection 301
/services/ancien-tarif-plomberie/Service retiré sans remplacement410 ou 404 assumée

Le test doit vérifier les codes HTTP, la destination, l’absence de boucle, l’absence de chaîne inutile, la conservation du chemin pour les variantes http/https et www/sans www, ainsi que la cohérence du contenu vers lequel on renvoie.

Une fois le site publié, surveillez les 404, les URL encore explorées, les erreurs dans les outils de suivi et les retours des utilisateurs. Les premières semaines révèlent souvent des liens anciens que l’inventaire n’avait pas trouvés.

La bonne refonte améliore l’organisation sans effacer l’histoire du site

Une refonte WordPress réussie ne prétend pas que l’ancien site n’a jamais existé. Elle distingue ce qui mérite d’être conservé de ce qui doit disparaître, puis elle organise la transition.

Faire du propre n’oblige pas à tout mettre à la poubelle. On peut retirer une dette technique, simplifier une arborescence et moderniser un thème tout en protégeant les contenus utiles et les chemins que des personnes utilisent encore.

Le travail consiste à prendre une décision explicite pour chaque famille de contenus, à préparer les redirections pertinentes et à contrôler la bascule. C’est moins spectaculaire qu’un grand bouton « supprimer », mais beaucoup plus sûr pour les visiteurs comme pour le référencement.

Préparer une refonte WordPress sans perdre ses repères

Un inventaire des contenus et des URL permet de séparer le chantier éditorial, le chantier technique et le chantier de migration. Cette lecture évite de reproduire l’ancien site par automatisme et de supprimer des ressources utiles par impatience.

Chez Demeillat DEV, une refonte commence par ces décisions concrètes : quoi garder, quoi améliorer, quoi fusionner, quoi rediriger et quoi retirer proprement.

Besoin de refondre votre site WordPress sans perdre l’existant ?

Une refonte technique permet de repartir sur une base plus saine tout en conservant les contenus, les URL et les repères encore utiles. Préparer la migration en amont protège les visiteurs, les anciens liens et l’historique SEO du site.