Plan de redirection : refondre son site sans perdre ses positions

Entre la refonte de votre site et la migration de vos URL, le plan de redirection est le document qui protège vos positions Google et votre trafic organique. C’est aussi le grand absent de la plupart des projets : on soigne les maquettes, on négocie les délais, et les redirections arrivent en fin de chantier, bâclées la veille de la mise en ligne. Le résultat se lit ensuite dans la Search Console : impressions en chute, erreurs 404 en cascade, positions perdues qui mettront des mois à revenir, quand elles reviennent. Les checklists de migration abondent, mais elles esquivent les deux questions qui font échouer les refontes : que faire des URL sans équivalent sur le nouveau site, et à partir de quel seuil s’inquiéter après la bascule. Voici le protocole complet : construire l’inventaire, arbitrer page par page, exécuter dans le bon ordre, puis surveiller avec des seuils chiffrés.

Que doit contenir un plan de redirection avant la mise en ligne ?

Trois blocs, dans cet ordre : l’inventaire exhaustif des URL actuelles, leur qualification par la donnée, puis la correspondance vers le nouveau site. Tout le reste de la migration repose sur ce document.

Comment constituer l’inventaire exhaustif de vos URL actuelles ?

L’erreur classique consiste à partir du menu du site. Le menu montre ce que vous voulez montrer ; Google, lui, connaît tout ce qui existe : anciennes pages oubliées, doublons techniques, fichiers PDF, pages d’atterrissage de campagnes passées.

L’inventaire se construit donc par accumulation de sources, pas par mémoire. Lancez un crawl complet du site en production et exportez toutes les URL en réponse 200. Ajoutez le contenu du sitemap XML, puis l’export des pages du rapport Performances de la Search Console sur douze mois. Complétez avec les pages d’atterrissage de votre outil d’analytics sur la même période.

Dédupliquez l’ensemble dans un tableur : une ligne par URL, en incluant les variantes avec et sans barre oblique finale et les paramètres qui ont réellement capté du trafic. Ce fichier est la colonne A de votre plan. Sa qualité conditionne tout : une URL absente de l’inventaire est une URL qui mourra en silence le jour de la bascule.

Pourquoi croiser le crawl, le sitemap et Search Console ?

Parce qu’aucune source ne voit tout, et que leurs angles morts ne se recouvrent pas. Le crawl révèle ce qui est accessible par les liens internes, mais ignore les pages orphelines. Le sitemap déclare ce que le CMS croit publier, mais traîne souvent des URL mortes ou en oublie des vivantes. La Search Console montre ce qui reçoit des impressions, mais tronque les requêtes rares.

Le croisement fait apparaître les écarts, et chaque écart est une information. Une URL présente dans la Search Console mais absente du crawl est une page orpheline qui capte pourtant du trafic : elle mérite une redirection soignée. Une URL du sitemap sans aucune impression depuis un an est une candidate à la suppression assumée.

Pour les sites qui en disposent, l’analyse des logs serveur en SEO ajoute une quatrième couche : elle montre ce que Googlebot visite réellement, y compris des URL qu’aucune des trois autres sources ne mentionne.

Quelles pages méritent d’être sauvées en priorité ?

Toutes les URL n’ont pas la même valeur, et le temps de préparation est compté. Le tri se fait sur trois colonnes de données, ajoutées à votre inventaire : les clics sur douze mois, les liens externes reçus, le rôle dans le parcours de conversion.

Le haut du classement, ces pages qui cumulent trafic, liens et conversions, exige une correspondance page à page, testée individuellement avant la bascule. C’est votre patrimoine : quelques dizaines d’URL concentrent en général l’essentiel de la valeur d’un site de PME.

Cette hiérarchie éclaire aussi la conception du nouveau site : elle devrait guider la façon de structurer l’arborescence de son site avant le gel des maquettes. Une refonte qui supprime des pages performantes sans destination équivalente détruit de la valeur par design, avant même la première erreur technique. C’est précisément pour cet arbitrage qu’un consultant SEO et refonte de site doivent se rencontrer avant les maquettes, pas après.

Comment traiter les URL sans aucun équivalent sur le nouveau site ?

C’est le point de rupture des migrations. Dans une refonte, vingt à trente pour cent des anciennes URL n’ont pas de correspondance directe sur le nouveau site. Chacune exige une décision explicite.

Quel arbre de décision appliquer page par page ?

Quatre questions, posées dans l’ordre, et chaque URL orpheline trouve son sort.

Première question : une page du nouveau site répond-elle à la même intention, même sous un autre angle ? Si oui, redirection permanente vers cette page. L’équivalence se juge sur l’intention de l’internaute, pas sur le titre.

Deuxième question : la page reçoit-elle des liens externes ou du trafic régulier ? Si oui, elle justifie soit une recréation sur le nouveau site, soit une redirection vers la page thématique la plus proche. Sacrifier une URL liée revient à jeter des années d’autorité.

Troisième question : le contenu peut-il enrichir une page existante ? Si oui, fusionnez la substance dans la page de destination, puis redirigez. La redirection prend alors tout son sens : elle pointe vers un contenu qui absorbe réellement l’ancien.

Quatrième question : la page n’a ni équivalent, ni liens, ni trafic, ni matière réutilisable ? Alors elle disparaît proprement, avec un code de suppression assumée plutôt qu’une redirection de complaisance.

Pourquoi ne jamais rediriger en masse vers la page d’accueil ?

C’est le raccourci le plus tentant et le plus coûteux. Rediriger toutes les URL orphelines vers l’accueil semble propre : plus de 404, un seul réglage serveur, dossier clos.

Google traite différemment. Une redirection dont la destination n’a aucun rapport avec la page d’origine est assimilée à une erreur douce, un soft 404 : le moteur comprend que la page a disparu et que la redirection masque cette disparition au lieu de la compenser. Les signaux de l’ancienne URL ne se transmettent pas, et vous avez perdu la lisibilité d’un vrai code d’erreur.

L’internaute paie aussi : il cherchait un contenu précis, il atterrit sur une page générique, il repart. La règle est simple : une redirection se justifie par la proximité d’intention entre l’origine et la destination. Quand cette proximité n’existe pas, la redirection n’est pas la bonne réponse.

Quand un code 410 vaut-il mieux qu’une redirection ?

Le code 410 signale une disparition volontaire et définitive : cette page n’existe plus, et c’est un choix. Là où le 404 laisse planer le doute d’une erreur, le 410 assume la suppression.

Il est le bon outil pour les URL de la quatrième sortie de l’arbre : contenus obsolètes, pages de campagnes terminées, doublons techniques, tout ce qui n’a ni valeur à transmettre ni public à rattraper. Le message envoyé à Google est net : inutile de revenir, retirez cette adresse de l’index.

Ce choix a une vertu cachée : il concentre l’exploration. Chaque redirection maintenue est une URL que Googlebot continue de visiter. Un lot de 410 propres libère cette attention pour les pages qui comptent, et rend votre suivi post-migration plus lisible : les 404 restants signalent alors de vrais oublis, pas du bruit.

Comment recréer une page plutôt que sacrifier son historique ?

Certaines URL orphelines sont trop précieuses pour mourir : elles portent des liens externes acquis sur des années ou un flux de trafic régulier, mais le nouveau site n’a rien prévu pour elles.

La recréation est alors l’option la plus rentable du plan. Reprenez l’intention servie par l’ancienne page et produisez son équivalent dans la nouvelle structure : même sujet, contenu remis à niveau, adresse conforme à la nouvelle logique d’URL. Puis redirigez l’ancienne adresse vers cette recréation.

Vous conservez ainsi tout : les liens continuent de transmettre leur autorité, le trafic retrouve une destination légitime, et la page repart avec un contenu meilleur que l’original. Profitez de l’exercice pour aligner ces recréations sur une structure des URL et SEO cohérente : une hiérarchie d’adresses lisible simplifiera toutes vos migrations futures.

Comment exécuter et tester votre plan de redirection le jour J ?

Un plan parfait peut échouer à l’exécution. Le jour de la bascule se joue sur trois disciplines : l’ordre des opérations, la chasse aux chaînes, et un protocole de vérification immédiat.

Quel ordre respecter entre bascule, redirections et sitemap ?

Les redirections s’activent dans la même fenêtre que la mise en ligne du nouveau site, pas le lendemain. Chaque heure d’écart est une fenêtre où les anciennes URL renvoient des 404 à Google et aux visiteurs.

La séquence qui protège : préparez et testez les règles de redirection sur l’environnement de préproduction, en amont. Le jour J, basculez le site, activez les redirections immédiatement, puis vérifiez un échantillon manuellement. Ensuite seulement, soumettez le nouveau sitemap dans la Search Console : il déclare les nouvelles URL à explorer pendant que les redirections guident Google depuis les anciennes.

Google précise que la prise en compte d’une migration se fait URL par URL : Googlebot doit visiter chaque ancienne adresse au moins une fois pour enregistrer son transfert. Conservez donc l’ancienne propriété Search Console active : c’est elle qui montrera la décrue des anciennes URL pendant que la nouvelle propriété montera en charge.

Comment détecter les chaînes et les boucles avant qu’elles ne nuisent ?

Une chaîne de redirections enchaîne plusieurs sauts avant la destination finale ; une boucle tourne sur elle-même. Les deux naissent des couches accumulées : ancienne migration, passage en HTTPS, réécritures de barre oblique, et maintenant votre refonte par-dessus.

Le contrôle se fait avant la mise en production, à partir de votre inventaire : chargez la liste complète des anciennes URL dans un crawler en mode liste, configuré pour suivre les redirections jusqu’à leur destination finale, comme le décrit le tutoriel Screaming Frog dédié à l’audit des migrations. Le rapport de chaînes livre, pour chaque URL, le nombre de sauts, le code de chaque étape et la réponse finale. Corrigez toute chaîne en faisant pointer la première URL directement sur la dernière destination.

Quelles vérifications faire dans les deux premières heures ?

Ma liste de contrôle immédiat tient en cinq points, dans cet ordre. Testez manuellement vos vingt URL les plus précieuses, celles du haut de votre classement : chacune doit répondre en un seul saut vers la bonne destination. Vérifiez que le fichier robots.txt du nouveau site n’a pas conservé le blocage de la préproduction, l’erreur la plus destructrice qui soit. Contrôlez que les balises d’indexation de la préproduction ont sauté avec elle.

Relancez ensuite le crawl en mode liste sur l’inventaire complet et comparez au test d’avant bascule : tout écart est une règle qui n’est pas montée en production. Enfin, ouvrez le rapport de couverture de la Search Console et notez les valeurs du jour : elles serviront de point zéro pour la surveillance des semaines suivantes. Ces deux heures de rigueur coûtent moins cher que n’importe quelle récupération de positions perdues.

Quels seuils d’alerte surveiller après la migration ?

« Surveillez la Search Console » ne veut rien dire sans chiffres. Voici ma grille de lecture : des seuils explicites, à périmètre constant, pour distinguer la turbulence normale de l’incident.

Quelle baisse est normale à sept jours, et laquelle ne l’est pas ?

Une migration secoue toujours les courbes : Google réexplore, réévalue, réattribue. La question n’est pas d’éviter la fluctuation, mais de savoir laquelle exige une intervention.

Ma grille d’alerte, appliquée sur les impressions comparées à la même période avant bascule, tous appareils confondus : une baisse jusqu’à 15 % à J+7 relève de la turbulence attendue, on documente sans agir. Entre 15 et 30 %, alerte : recherchez un lot d’URL défaillant, un gabarit entier mal redirigé ou un blocage partiel du crawl. Au-delà de 30 %, incident : suspendez tout autre chantier et contrôlez le triptyque robots.txt, balises d’indexation, échantillon complet de redirections, dans cet ordre. Si rien n’en ressort, un audit technique SEO complet devient la seule voie sérieuse.

Côté 404, le zéro absolu n’existe pas : des URL parasites, vieilles adresses de spam ou paramètres exotiques, meurent toujours dans le rapport. Ma règle de tri : un 404 sur une URL qui figurait dans votre inventaire qualifié est une faute à corriger le jour même ; un 404 sur une URL hors inventaire, sans clics ni liens, est du bruit qu’on laisse s’éteindre.

Combien de temps conserver les anciennes redirections ?

Le plus longtemps possible. La documentation de Google sur les migrations est explicite : les redirections permanentes doivent rester en place pour que chaque signal soit transféré, et le moteur visite les anciennes URL à son propre rythme, sans fréquence garantie.

Ma règle de conservation : un an est un strict minimum pour l’ensemble du plan. Au-delà, deux catégories ne se débranchent jamais : les URL qui reçoivent encore des liens externes, car chaque visite via ce lien dépend de la redirection, et celles qui affichent encore des passages dans vos logs ou votre analytics.

Le nettoyage éventuel, un an ou deux après, ne concerne que les redirections devenues totalement silencieuses : zéro hit serveur, zéro lien entrant, zéro impression. Et si votre migration incluait un changement de domaine déclaré via l’outil Changement d’adresse de la Search Console, gardez en tête sa fenêtre de 180 jours : passé ce délai, Google cesse de relier l’ancien site au nouveau, et seules vos redirections continuent de faire le pont.

Une migration se juge à trente jours, pas à trois

Les trois premiers jours d’une refonte disent peu de chose : Google digère, les courbes tanguent, et la panique fait prendre de mauvaises décisions. Le verdict se lit à trente jours, sur des comparaisons à périmètre constant : impressions, positions des requêtes stratégiques, décrue des anciennes URL, montée des nouvelles.

Ce qui sépare une migration réussie d’une hémorragie tient dans le travail d’avant : un inventaire construit sur quatre sources, un arbre de décision appliqué à chaque URL orpheline, une exécution ordonnée, des seuils de contrôle posés avant la bascule. Rien de tout cela n’exige un outil coûteux. Tout exige de la méthode.

Si votre refonte approche et que le plan de redirection reste une case vide du planning, c’est le moment de sécuriser votre refonte : je construis l’inventaire, j’arbitre les URL orphelines avec vous et je pose la grille de surveillance avant la mise en ligne. La bascule devient un non-événement, et c’est exactement ce qu’elle doit être.

Sources et références

Cet article s’appuie notamment sur le guide officiel de Google consacré aux migrations de site avec changement d’URL, sur la documentation de Google relative aux redirections et à leur traitement dans la recherche et sur la page d’aide de la Search Console dédiée à l’outil Changement d’adresse. La méthode d’audit des redirections avant et après bascule a été confrontée au tutoriel Screaming Frog sur l’audit des redirections lors d’une migration et au guide Ahrefs consacré aux redirections 301.