Ces 2 dernières années, je suis intervenu sur 4 sites internet post-migration dont le trafic avait largement décroché jusqu’à -70% à la suite d’une migration conduite par une agence (voire plusieurs) web et SEO aux compétences discutables.
Plus récemment, j’ai redirigé un site de 6 000 pages sans constater de pertes durables de positionnement ou de trafic (à part dans les 4 semaines qui ont suivies le temps que tout se stabilise). Ces dernières expériences m’ont donc amené à créer ce guide pour vous guider dans le plan de redirection et éviter de détériorer votre référencement naturel.
Certes, le plan de redirection semble être en apparence un exercice puisqu’il suffit de lister des URLs “source” et indiquer les URLs de “destination” vers lesquelles les rediriger.
Mais dans le plan de redirection, il y a de nombreux détails qui peuvent rapidement coûter chers si on manque d’expérience ou si on va un peu trop vite. On ne réalise pas la quantité d’erreurs qui peuvent se glisser dans une migration, même simplement technique, et qui peuvent endommager votre référencement si le plan de redirection n’a pas été correctement pensé et si un “bon” expert SEO n’a pas été impliqué suffisamment en amont.
Et même à titre personnel, je me réfère encore aujourd’hui à ma checklist malgré les dizaines de migrations et de plans de redirection que j’ai créé et/ou suivis depuis 10ans.
J’espère que vous saurez apprécié ce guide qui est structuré en 4 parties :
Définition d’un plan de redirection ; Identification des situations dans lesquelles un tel plan est recommandé ; Comment créer son plan de redirection ; Les erreurs les plus courantes post-migration. Vous pouvez vous rendre directement à la section qui vous intéresse en utilisant le sommaire.
Définition d’un plan de redirection Le plan de redirection est un document qui permet de répertorier l’ancien emplacement d’un contenu d’une part, et d’indiquer son nouvel emplacement d’autre part. Ce qui, une fois implémenté, permettra de rediriger automatiquement l’internaute ou le robot d’exploration (crawler ). Cela permet notamment :
De préserver le trafic en redirigeant automatiquement les internautes vers les bonnes URLs ; De préserver de fait l’expérience utilisateur en leur épargnant l’erreur 404 puisque ceux-ci arriveront donc sur le contenu initialement souhaité ; De transférer la puissance SEO d’un ancien emplacement vers le nouvel emplacement ; De ne pas gâcher son crawl budget en condamnant les robots à une 404 ; D’accélérer l’indexation des nouvelles pages web ; D’assurer la continuité “business ”. En résumé, grâce à un plan de redirection, l’utilisateur n’est pas affecté par un contenu qui ne serait plus disponible sur un ancien emplacement et l’autorité de l’ancien emplacement est transférée vers le nouvel emplacement.
Les 8 situations qui nécessitent un plan de redirection Au cours de ma carrière, débutée en 2014 dans le SEO, j’ai réalisé des dizaines de plans de redirection et j’ai tenté de rattraper les erreurs de dizaines d’agences web, agences SEO, ou autres freelances suite à des migrations catastrophiques.
Selon moi, vous devez créer un plan de redirection dès que vous êtes dans une des situations suivantes :
Restructuration complète ou partielle d’un site web ; Refonte technique (changement de CMS ou d’un framework Javascript) ; Refonte graphique d’un site web mais qui induit une restructuration des contenus ; Fusion de deux sites web notamment dans le cadre d’un rachat ; Scission de deux sites web ; Modification d’une URL (changement du path ou de la catégorie par exemple) ; “Chasse” aux contenus dupliqués (ou très similaires) qui résulte en la fusion de plusieurs contenus en un ; Migration technique d’un sous-domaine vers un autre, la suppression d’un sous-dossier, voire la migration de liens d’un protocole http vers un protocole https. Restructuration complète ou partielle : assez typique d’une nouvelle stratégie marketing ou de contenu dans une entreprise. L’équipe marketing adopte par exemple une stratégie de contenu orientée par target persona ou par étapes dans le cycle de décision et cela induit de restructurer tout le blog en créant de nouvelles catégories, répertoires, etc. Même chose en e-commerce en cas de refonte de votre catalogue typiquement.
Refonte technique : typiquement, la mise en place d’un CMS “du marché” qui ne permet pas de structurer les catégories et sous-catégories de la même manière. Ou la mise en place du concept de répertoire et d’arborescence sur un site en Javascript qui repose sur un CMS en headless . Je vous conseille d’ailleurs la lecture de mon guide sur le javascript SEO pour éviter tout problème futur notamment d’indexation.
Refonte graphique : Théoriquement, une simple refonte graphique ne doit pas avoir d’impact sur la structure d’un site web. Mais je n’ai encore jamais vu un rebranding ou même une “simple modernisation de la charte graphique” qui ne résulte pas en la suppression de quelques pages voire une restructuration.
Fusion de deux sites web (ou plus) : Ce qui paraissait évident quelques années plus tôt d’isoler les marques et les plateformes le semble moins aujourd’hui. On se retrouve alors à fusionner plusieurs sites entre eux sous un domaine principal. Et cela peut vite être une bérézina car le domaine principal correspond à un persona particulier avec une navigation particulière donc souvent la fusion implique une refonte graphique ainsi qu’une restructuration au moins partielle.
Scission de deux sites web : Je l’ai vu, je l’ai fait, je persiste à penser que c’est une erreur. Typiquement, une société se spécialise dans deux activités et pense que la seconde activité aura plus de chances de réussir en standalone et donc opère une migration d’une partie des contenus du site primaire vers le site secondaire.
Mon jugement sur le fait que ce soit une erreur relève plus de la stratégie de croissance globale de l’entreprise qu’uniquement d’une vision SEO. Selon moi, les deux seules raisons valables de faire une scission sont les suivantes :
La revente d’une partie de l’activité ou d’une des marques ; Le risque réputationnel (contamination) entre les marques en cas de scandales (je l’ai beaucoup vu dans l’industrie pharmaceutique, les hydrocarbures, et la chimie). Modification d’une URL : suite à un changement de catégorie par exemple, ou lorsque vous repassez après un de vos content writers qui n’a pas mis en place le bon slug . Même si le changement est mineur, je vous invite à toujours répertorier l’ensemble des modifications d’URL du site au cours du temps. Cela peut vous éviter plus tard de vous retrouver avec des “boucles de redirection”.
Chasse aux contenus dupliqués : Alors, il y a effectivement les contenus dupliqués (par exemple entre une version http et https, ou www et sans sous-domaine) qu’il convient de rediriger vers une seule version à part si vous avez une canonique, mais il y a aussi les contenus très similaires que vous pouvez fusionner. Il arrive en effet qu’avec le temps, on puisse écrire deux contenus sur une même thématique et Google finit par ne plus savoir quelle URL rank et cela peut même pénaliser les deux pages.
On retrouve aussi le cas sur des FAQ ou knowledge base . Parfois, chaque URL correspond à une question et l’ensemble de la page contient à peine 100-300 mots. Il est dans ce cas intéressant de regrouper plusieurs contenus sur la même thématique ensemble afin que la page ait plus de chance d’être indexée par Google et devienne ainsi accessible depuis les résultats de recherche pour les internautes.
Migration technique d’emplacement : Généralement moins risqués qu’une restructuration ou une refonte technique, la migration consiste simplement à modifier l’emplacement de plusieurs pages en les passant par exemple de :
http:// à https:// (activation SSL) ; blog.domaine.fr à domaine.fr/blog/ (cette migration peut devenir un cauchemar en vrai) ; Ou encore en migrant d’un emplacement sans sous-domaine à un emplacement avec un sous-domaine. Bonus : les redirections “combo”. Ce sont mes migrations préférées car elles présentent vraiment des opportunités pour se perdre et rater son fichier de redirection. Imaginez simplement que vous faites plusieurs changements d’emplacement en même temps. Dernière en date pour ma part, migrer de https://domaine.fr/fr/slug à https://www.domaine.fr/categorie/slug. On retrouve ici la suppression d’un répertoire, l’ajout d’un sous-domaine, la restructuration en répertoire selon un nouveau customer journey , et la fusion de contenus. C’était chouette.
Comment créer son plan de redirection ? Bien évidemment, le plan de redirection dépend des situations. Si votre migration est simplement d’un protocole http à https et que rien d’autre ne change, la création de votre plan de redirection peut être très rapide et la complexité limitée.
Néanmoins, je vous partage ci-dessous ma méthode qui me permet de construire une vision d’ensemble du site internet et de sa performance afin de faire une migration parfaite . Cela permet d’aller plus loin et de considérer d’autres dimensions telles que la performance des contenus par exemple. Je vous rassure, je ne parle pas ici de faire un audit SEO mais simplement de construire un plan de redirection ainsi qu’une stratégie de migration intelligents et pérennes .
Étape #1 : identifier les types de redirections nécessaires Il existe deux types de redirection selon le motif de modification des URLs que vous avez, la durée des redirections, et l’implémentation technique : nous parlons habituellement de redirections server-side ou de redirections client-side .
Les redirections server-side
301 redirection permanente ; 302 redirection temporaire ; 303 voir autres ; 307 redirection temporaire sans changement de méthode ; 308 redirection temporaire sans changement de méthode ; Redirection permanente 301 : La redirection 301 est la redirection que l’on utilise en général lors d’une migration SEO pour indiquer à un navigateur et des robots d’exploration que le contenu présent sur une page A est maintenant disponible sur une page B et que ce changement est permanent.
La redirection 301 est aussi supposée transférée le “link juice ” et plus largement l’autorité SEO qu’avait historiquement la page A. De cette manière, si 20 backlinks pointaient vers votre page A, la page B profiterait de cette puissance-ci et donc de l’autorité grâce à la redirection 301.
Redirection permanente sans changement de méthode 308 : Plus rare, la redirection 308 est similaire à la redirection 301. La seule différence est technique et réside dans le fait que la redirection 308 conserve la méthode initialement employée. C’est-à-dire que si votre navigateur avait fait une requête GET pour obtenir la page A, la méthode suivante employée restera une GET. Alors que dans le cadre d’une 301, la méthode peut être modifiée dans l’intervalle.
Redirection temporaire 302 : La redirection 302 “Found” est une redirection dite temporaire. Son utilisation permet à tout user-agent (internaute ou robot) d’être redirigé vers la nouvelle URL.
La notion de temporaire est très importante car en règle générale, Google conservera l’URL “historique” indexée (la page A) et n’indexera pas la page B.
Ce type de redirection est utile et utilisée dans plusieurs situations :
Rediriger un utilisateur vers la bonne page par rapport à sa localisation ; Rediriger vers une page avec une offre commerciale de courte durée ; Tester une nouvelle fonctionnalité sur une page B sans affecter l’indexation de la page A ; Collecter des retours utilisateurs sur un nouveau design. Notez que si votre redirection temporaire 302 reste “trop longtemps”, celle-ci peut alors être considérée comme la version canonical de la page par Google et ainsi votre page B pourrait être indexée en lieu et place de la page A. Nous n’avons malheureusement aucune indication de ce que Google considérerait comme “trop longtemps”. Il est même arrivé que des URLs nouvellement redirigées en 302 soient directement indexées… Les voies de Google sont impénétrables…
Redirection temporaire sans changement de méthode 307 : La redirection 307 est à la 302, ce que la 308 est à la 301. En d’autres termes, côté utilisateur et crawler , la 307 est aussi traitée comme une redirection temporaire. Et comme pour la 308, la méthode spécifiée est conservée.
Redirections 301 et 302 versus 308 et 307 Je me permets de vous partager cet arbre de décision qui a été créé par Michael Kropat et qui vous apportera normalement les réponses que vous désirez. Je me permets toutefois de préciser que pour des SEO, le changement de méthode ne vous concerne généralement pas.
L'arbre de décision pour déterminer quelles redirections utiliser. Si tout cela vous semble trop compliqué, passez au paragraphe suivant. En tant que SEO, dites-vous que 302 = 307 et 301 = 308.
Redirection “Voir autres” 303 : Rare et peu probable que vous l’utilisiez en SEO, nous retrouvons généralement cette redirection après des soumissions de formulaires afin de rediriger l’utilisateur vers une “thank you page ” qui ne lui permettrait pas de revenir à la précédente étape du formulaire avec le bouton retour une fois le formulaire soumis.
Maintenant, passons aux redirections client-side : il en existe deux :
La redirection en meta refresh ; Et la redirection JS . Une redirection meta refresh , n’est pas réellement une redirection. En fait, on spécifie dans le <head> d’une page, qu’après un certain délai, le navigateur doit charger une nouvelle URL (la page B). Le délai est fixé en millisecondes et si ce délai est égal à 0, alors la redirection est considérée comme permanente par Google.
Concernant la redirection Javascript, je me permets de vous renvoyer à mon article dédié Redirections Javascript & SEO sur lequel je partage les deux méthodes pour créer de telles redirections ainsi que leurs limitations pour le référencement naturel.
De manière générale, il faut éviter les redirections client-side car elles seront très probablement mal interprétées par les crawlers . Bien que l’utilisateur soit effectivement redirigé vers le bon contenu, les robots d’exploration pourront ne pas “voir” la redirection en question et considérer votre page A comme une soft 404 .
En général et par mon expérience, lors de migrations, le type de redirection plébiscité est la redirection permanente et plus précisément la redirection 301 (bien que la 308 serait tout aussi efficace). Les redirections temporaires (302 et 307) étant plus exceptionnelles et généralement limitées à quelques URLs pour une période de temps limitée à quelques semaines.
Étape #2 : Identifier et lister toutes les URLs sources Sur le papier, je vous concède que cela paraît simple. Il suffit de lister dans un tableur type Excel ou Google Spreadsheet l’ensemble des URLs déjà existantes et que l’on souhaite rediriger.
Premier conseil que je me permets de vous partager : ne vous limitez pas aux URLs extraites de votre sitemap .
Pour créer cette liste initiale, vous devez vous reposer sur plusieurs sources afin de vous rapprocher le plus possible de l’exhaustivité et aussi d’identifier certains problèmes que vous ne souhaiteriez pas reproduire post-migration.
Parmi les sources d’URLs pour construire votre plan de redirection, je vous conseille les suivantes :
Le sitemap de votre site internet ; La liste des pages obtenue grâce à une exploration avec un outil tel que Screaming Frog ; La liste des URLs recensées dans votre outil de web analytics (ex : GA4, PostHog, etc.) et qui reçoivent du trafic peu importe le canal sur les 90 derniers jours ; La liste des URLs recensées dans la Google Search Console que ce soit au niveau de l’indexation comme au niveau des erreurs sur les 180 derniers jours ; La liste des pages recevant un backlink toujours selon la Google Search Console ; La liste de vos URLs recevant au moins un backlink selon Majestic SEO, Ahrefs, SEMrush, et Babbar. Et je vous conseille de vous baser sur plusieurs outils car ils n’ont pas le même historique ni le même index. De mon côté, j’ai une préférence pour Majestic SEO que je trouve généralement plus complet. A l’issue de cette étape, vous devez avoir tableau qui liste dans la première colonne l’ensemble des URLs, et dans les autres colonnes :
Le slug ; La catégorie (si c’est pertinent) ; Le trafic organique des 90 derniers jours ; Le trafic depuis les campagnes emails sur les 90 derniers jours ; Le trafic direct des 90 derniers jours ; Le trafic en referal des 90 derniers jours ; Le trafic en paid des 90 derniers jours (ça vous évitera d’oublier les landing pages de vos campagnes marketing. C’est du déjà vu) ; Étape #3 : identifier les URLs à rediriger L’avantage de la vue que vous obtenez à l’issue de l’étape #2 est qu’elle vous apporte une vision d’ensemble des pages existantes et de leur importance voire contribution. Nous allons donc au-delà du simple plan de redirections. Ceci vous permet de ne pas seulement considérer la migration, mais aussi de faire un éventuel nettoyage voire de repérer des erreurs à ne pas répéter dans le futur.
De mon côté, voici les quelques règles que je suis pour arbitrer quelles URLs conserver :
Toutes celles recevant au moins un backlink pertinent (pas des backlinks spammy donc) ; Toutes les URLs ayant reçues plus de 10 visites organiques au cours des 90 derniers jours selon votre outil de web analytics (ex : GA4, PostHog, etc.) ; La liste des URLs recevant du trafic depuis d’autres sources telles que les réseaux sociaux, l’email, etc. selon votre outil de web analytics ; La liste des URLs ayant reçu plus de 20 clicks au cours des 90 derniers jours selon la Google Search Console ; Je rentre maintenant dans les détails pour bien me faire comprendre.
Les URLs ayant reçu au moins un backlink pertinent sont donc des pages qui reçoivent une certaine puissance à partir de domaines externes. C’est pour cette raison que je préfère rediriger la page en question quand bien même elle ne recevrait pas ou peu de trafic .
Les URLs ayant reçues plus de 10 visites organiques au cours des 90 derniers jours ont une utilité puisque ces dernières ont donc déjà acquis une certaine autorité. Qui plus est, si ces pages sont situées entre les positions 5 et 20, elles deviennent les parfaites candidates pour être retravaillées post-migration et tenter de se positionner dans le top 3.
Concernant les URLs qui n’ont pas généré de trafic organique, j’ai 3 scenarii :
Le contenu est en noindex pour des raisons légitimes et dans ce cas il faudra tout de même le rediriger ne serait-ce que pour l’expérience utilisateur ; Le contenu est trop court et “pauvre” mais il y a possibilité de fusionner plusieurs contenus qui traitent du même sujet. Dans ce cas, je redirige l’ancienne url vers la nouvelle url où les différents contenus ont été agrégés. Le contenu est trop court et/ou “pauvre” et/ou alors dépassé, il n’y a aucun intérêt à le migrer, dans ce cas je passe la page en code “410 Gone ” ce qui signifie que le contenu n’est plus disponible sur le serveur et ne le sera probablement plus jamais. Second conseil : les redirections n’ont de sens que si vous redirigez une page A vers une page B qui traite de la même thématique. Si vous êtes simplement en train de modifier la structure de votre site, le sujet ne se posera pas. Mais ce que j’observe souvent lorsqu’on veut supprimer un contenu, c’est qu’on redirige généralement l’ancienne URL vers une page qui n’est souvent pas pertinente (vers la page d’accueil par exemple). Sachez que dans ce genre de situations, Google ne va probablement pas considérer cela comme une redirection, mais comme une soft 404 . Par conséquent, lorsque vous supprimez un contenu car celui-ci n’est simplement plus pertinent, si vous ne pouvez le rediriger vers un contenu similaire, envoyez alors un code 410.
Au sujet des pages recevant du trafic depuis des sources autres qu’organique , c’est important de consulter ces pages dans le détail afin de comprendre pourquoi leurs objectifs. Par exemple, si ce sont des contenus pour des abonnés à la newsletter , vous souhaiterez sûrement les conserver et rediriger les internautes. Si ce sont des URLs présentes dans un livre blanc qui semble toujours être lu de temps à autre, le raisonnement reste le même. L’objectif est aussi d’identifier les landing pages que vous utilisez pour vos campagnes de paid marketing mais qui sont en noindex et donc que vous n’auriez pas vu ressortir dans les rapports de la GSC, de votre outil de web analytics , de votre sitemap, voire même du crawl “maison” que vous auriez effectué.
Enfin, par rapport aux URLs qui génèrent des clics selon le rapport de performance de la Google Search Console
Étape #4 : Mapper les URLs Maintenant que vous avez l’ensemble des pages que vous voulez rediriger, que vous avez échangé avec vos équipes marketing au sujet des pages qui ne sont pas performantes, et que vous avez une vision claire du nombre de pages à rediriger, il ne vous reste qu’à mettre en face le “chemin” de la nouvelle URL.
Un travail simple mais qui peut être fastidieux surtout si les changements sont complexes (par exemple, succession d’une bascule de http à https, ajout d’un sous-domaine, restructuration de répertoire, etc.), si vous devez dépublier des contenus en plus, etc.
Étape #5 : Tester le plan de redirection Si cela est possible, implémentez votre fichier de redirection au niveau serveur ou du côté de votre CMS selon ce qui est le plus simple et accessible pour le maintenir dans le temps .
Si pour certaines raisons vous ne pouvez automatiser vos tests et que le nombre de redirections à tester est trop important, concentrez-vous sur les pages majeures en termes de trafic .
Étape #6 : Réalisez la migration et déployer le plan de redirection Et faites-le de nuit idéalement. Bien sûr, si vous travaillez avec une équipe technique, synchronisez-vous avec eux. Mais ce que je vous recommande c’est d’identifier les heures où vous avez le moins de trafic et de choisir ce créneau pour implémenter votre plan de redirection.
Une fois le plan de redirection implémenté, lancez des crawls avec des outils tels que Screaming Frog pour vérifier que vous n’avez pas d’erreurs 404. Si tout semble bon, pensez à soumettre de nouveau vos sitemaps à Google et Bing.
Les 8 erreurs les plus courantes sur les plans de redirection En 10 ans, j’en ai vu (et j’en ai fait) des erreurs. Je vous présente quelques-unes qui ne touchent pas tant aux migrations mais plutôt à la conception et l’implémentation des plans de redirection.
1. Avoir des chaînes de redirection :
Typiquement, vous redirigez :
URL A vers URL B ; URL B vers URL C. Dans ce cas, vous devriez plutôt implémenter les deux redirections suivantes :
URL A vers URL C ; URL B vers URLC. 2. Oublier les redirections d’images :
Selon votre industrie ou vos secteurs, les images peuvent être des sources intéressantes de trafic. Ne les oubliez pas dans vos plans de redirection.
3. Rediriger des pages supprimées vers la page d’accueil ou les catégories :
Je l’ai expliqué plus haut mais c’est une habitude qu’il faut abandonner. Si vous ne pouvez rediriger l’URL d’origine vers une URL qui traite d’une thématique très proche, il vaut mieux envoyer un code HTTP 410 Gone .
4. Oublier les pages dédiées aux utilisateurs ou celles dédiées aux campagnes marketing :
Je l’ai vu, je l’ai vécu, je l’ai fait aussi. On fait la migration, d’un point de vue SEO tout semble parfait, mais très vite on s’aperçoit qu’on a oublié de répliquer les landing pages dans le nouveau site que l’on vient de migrer. Ou alors qu’on a oublié les pages utilisateurs (l’espace client par exemple).
5. Oublier de mettre à jour son robots.txt :
L’erreur bête mais possible. Vous oubliez de modifier votre robots.txt et vous finissez par bloquer l’indexation de pans entiers de votre site nouvellement migré. Alors rassurez-vous, la Search Console devrait vous remonter le problème, mais ce n’est pas dit que vous la traitiez en priorité.
6. Négliger les balises canonical ou hreflang :
Selon le socle technique de votre plateforme, il se pourrait que vos développeurs (ou vous-même ayez à implémenter aussi un système de correspondance pour être certain que les balises canonical et les hreflang
7. Supprimer les bases de données de l’ancien site alors que toute la migration n’a pas encore été finalisée :
Nous faisions une migration progressive, bloc par bloc, et pour une raison qui m’échappe, l’agence web a débranché l’ancienne plateforme et supprimé la base de données. Nous n’avions alors migré que 50% des contenus. Résultat, perte de trafic de 50% le temps que nous réparerions le tout en utilisant l’historique de la wayback machine . A la fin, il nous manquait toujours 20% des contenus mais la perte de trafic avait été limitée à 15%.
Partagez votre avis, vos questions, vos recommandations ci-dessous