Refonte de site : le plan de correspondance qui évite la chute

Une refonte ne fait pas chuter le référencement. Ce sont les anciennes adresses abandonnées sans redirection qui le font. La distinction n’est pas théorique : elle sépare les refontes qui traversent la bascule sans décrochage de celles dont le trafic met un an à revenir.

Le document qui fait cette différence s’appelle le plan de correspondance. Il associe chaque URL de l’ancien site à celle qui la remplace, et il se construit avant la mise en ligne, jamais après. Un site refondu sans ce document perd en une nuit l’antériorité que ses pages avaient accumulée, quelle que soit la qualité du nouveau design.

Cet article décrit comment le construire, comment vérifier la bascule, et ce qui se perd malgré tout.

Qu’est-ce qui fait chuter le trafic après une refonte ?

Quatre causes, par ordre de fréquence.

Les URL changées sans redirection. Un moteur qui demande une ancienne adresse reçoit une page introuvable. La page disparaît de l’index, et les liens externes qui pointaient vers elle ne mènent plus nulle part.

La redirection massive vers l’accueil. C’est l’erreur commise avec les meilleures intentions : plutôt que de laisser des pages introuvables, on renvoie tout vers la page d’accueil. Le résultat est identique à une suppression, les signaux ne sont pas transférés, et le visiteur qui cherchait une page précise atterrit sur une page générique.

Le changement simultané de trop de choses. Refonte du design, migration de plateforme, changement de structure d’URL et réécriture des contenus le même jour rendent tout diagnostic impossible. Quand le trafic baisse, plus rien ne permet de savoir laquelle des quatre décisions en est la cause.

Les contenus amaigris au passage. Une refonte s’accompagne souvent d’un raccourcissement des textes, au nom de l’épure. Les pages perdent alors ce qui les faisait répondre à une requête, et le classement suit.

Comment construire un plan de correspondance ?

1. Relever l’existant, exhaustivement

Le relevé doit couvrir toutes les URL que Google connaît, pas seulement celles du menu. Quatre sources se recoupent :

• L’ancien sitemap XML, qui donne les pages que le site déclarait lui-même.
• La Search Console, rapports Pages et Performances, qui donne les pages réellement indexées et celles qui reçoivent des impressions.
• Les journaux du serveur, qui révèlent les URL encore demandées, y compris celles oubliées depuis des années.
• Un crawl complet du site actuel, qui trouve les pages atteignables par les liens internes.

Google recommande explicitement de commencer par les URL importantes trouvées dans les sitemaps et les journaux serveur. Ce sont aussi celles qui portent les liens externes.

2. Associer chaque adresse à sa destination

Un tableau à deux colonnes suffit : ancienne URL, nouvelle URL. Une ligne par page, sans exception.

La règle d’association est simple à énoncer et exigeante à tenir : chaque ancienne page pointe vers l’équivalent le plus proche en intention, pas vers la page qui lui ressemble le plus visuellement. Un article de blog sur un sujet précis se redirige vers l’article équivalent, pas vers la liste du blog.

3. Décider du sort des pages sans équivalent

Trois cas, trois traitements.

Situation	Traitement	Effet
La page a un équivalent	Redirection 301 vers cet équivalent	Les signaux sont transférés
Le contenu est fusionné dans une autre page	Redirection 301 vers la page qui absorbe	Les signaux sont transférés
La page disparaît sans remplaçante	Code 410, ou 404	Sortie propre de l’index

Le deuxième cas mérite une attention particulière : une refonte est l’occasion de fusionner des pages qui se faisaient concurrence sans qu’on l’ait vu. Le repérage se fait avant la bascule, avec la méthode décrite dans notre article sur la cannibalisation SEO.

Le code 410 signale une suppression définitive. Il accélère la sortie de l’index par rapport à un 404, qui laisse Google revenir vérifier plusieurs fois. Sur une page réellement supprimée, c’est le signal honnête.

4. Écrire les redirections

Google recommande les redirections permanentes côté serveur, codes 301 ou 308. Ce sont les seules qui servent de signal pour désigner la nouvelle adresse comme version de référence. Les redirections côté client, par meta refresh ou JavaScript, sont un dernier recours : le rendu peut échouer.

Deux règles complètent le choix du code.

Rediriger directement vers la destination finale. Si une page a déjà été déplacée par le passé, la nouvelle règle doit pointer vers l’adresse actuelle, pas vers la redirection intermédiaire. Google déconseille les chaînes de plus de trois sauts, et chaque saut ajoute une latence pour le visiteur.

Écrire des règles par motif quand c’est possible. Une refonte qui déplace tout un répertoire se traite par une règle unique plutôt que par cinquante lignes. Moins de règles, moins d’occasions d’en oublier une.

Comment vérifier les redirections après la mise en ligne ?

La vérification ne consiste pas à ouvrir quelques pages dans un navigateur. Elle consiste à rejouer le plan de correspondance et à contrôler le code de réponse de chaque ancienne URL.

Une commande suffit pour une vérification unitaire :

curl -s -o /dev/null -w "%{http_code} → %{redirect_url}\n" https://exemple.fr/ancienne-page

La réponse attendue est 301 suivie de la destination prévue au plan. Trois anomalies à traquer :

1. Un code 200 sur une ancienne URL : la redirection n’a pas été appliquée, deux versions de la page coexistent.
2. Un code 302 : la redirection est temporaire, le signal n’est pas transmis.
3. Une destination différente du plan : une règle plus large intercepte l’URL avant la règle prévue.

Contrôlez ensuite le nouveau sitemap, les canoniques de chaque page, et l’absence de liens internes pointant encore vers les anciennes adresses. Un site qui se redirige lui-même en interne fonctionne, mais fait travailler l’exploration pour rien.

Dans la Search Console, l’outil de changement d’adresse ne sert qu’aux migrations de domaine, pas aux changements de structure interne ni au passage de HTTP à HTTPS.

Que perd-on et que garde-t-on lors d’une refonte ?

Élément	Après une migration correcte
Liens externes	Conservés, via la redirection
Antériorité de l’URL	Transférée à la nouvelle adresse
Positions	Retrouvées après une période d’instabilité
Historique Search Console	Rompu : les nouvelles URL repartent sans données
Partages sociaux comptabilisés	Perdus, ces compteurs suivent l’URL exacte

L’instabilité des positions pendant quelques semaines est normale : Google réévalue les nouvelles adresses avant de leur rendre leur rang. Google indique qu’un site de petite ou moyenne taille voit la majorité de ses pages migrer en quelques semaines, davantage pour un site volumineux.

Cette période demande d’être annoncée avant la bascule. Un client qui découvre une baisse sans y avoir été préparé conclut à un échec au bout de dix jours et demande un retour en arrière, ce qui aggrave le problème en imposant une seconde migration.

Quelles erreurs coûtent le plus lors d’une refonte ?

Supprimer les redirections trop tôt. Google demande de les conserver au moins un an. Les liens externes, eux, ne se mettent jamais à jour : une redirection retirée casse définitivement un lien obtenu il y a trois ans.

Oublier les ressources. Images, PDF, flux RSS ont des URL et reçoivent des liens. Un plan de correspondance qui ne couvre que les pages HTML laisse tomber tout le reste.

Changer d’URL sans nécessité. Chaque changement coûte une redirection à maintenir pendant des années. Une structure d’URL ne se refond que si elle est réellement défaillante, jamais par goût.

Bloquer le nouveau site pendant la préparation, et oublier de le débloquer. Un Disallow: / laissé dans le robots.txt de la préproduction, recopié en production le jour de la bascule, rend le site entier invisible. C’est l’erreur la plus coûteuse de la liste, et elle passe inaperçue plusieurs semaines.

Vérifier l’intention plutôt que le résultat. Une règle de redirection écrite n’est pas une règle appliquée. Une configuration serveur peut être ignorée, écrasée par une règle plus large, ou déposée dans le mauvais répertoire. Seule la réponse HTTP réellement renvoyée fait foi.

Quand un plan de correspondance est-il inutile ?

Un site pas encore publié n’a rien à rediriger. C’est le moment où une structure d’URL se change gratuitement, et c’est le seul.

Kerith a fait ce choix pour son propre site en août 2026 : la page de service, initialement à l’adresse /seo, a été déplacée vers /consultant-seo/ avant toute mise en ligne, pour que le mot-clé figure dans l’URL et que les pages locales à venir puissent se ranger dessous. Aucune redirection n’a été nécessaire, aucun signal n’a été transféré, parce qu’il n’y en avait aucun à transférer.

La même décision prise trois mois après la publication aurait imposé des redirections à maintenir pendant des années. Avant la mise en ligne, une structure d’URL est un choix ; après, c’est une dette.

Par où commencer une refonte de site ?

1. Relever toutes les URL existantes avant de toucher au site, en croisant sitemap, Search Console, journaux serveur et crawl.
2. Écrire le plan de correspondance ligne à ligne, et le faire valider avant la bascule.
3. Vérifier chaque redirection par sa réponse HTTP après la mise en ligne, pas par un coup d’œil dans le navigateur.

Une refonte se prépare pendant qu’il est encore temps de changer d’avis. Si la vôtre est prévue, décrivez votre situation : l’état des lieux et le plan de correspondance font partie de l’audit technique, et la réponse arrive sous 48 heures ouvrées.