Six mois. C'est le temps qu'il m'a fallu pour comprendre que ma migration de blog n'était pas ratée — juste à moitié finie. Le site était en ligne, tout fonctionnait, les visiteurs arrivaient. Sauf que d'anciens articles continuaient à rendre des 404 à des gens qui avaient mis mes liens en favori depuis 2019, et que Google, lui, avait très bien remarqué.
La redirection 301, tout le monde en parle comme d'une formalité technique. On la coche, on l'oublie, on passe à autre chose. C'est exactement le piège dans lequel je suis tombé. Voici ce que j'ai appris en réparant les dégâts, avec les chiffres, les outils, et une méthode qui m'aurait fait gagner cinq semaines.
Points clés à retenir
- Une redirection 301 est permanente : elle signale qu'une page a changé d'adresse et transfère l'essentiel du référencement vers la nouvelle URL.
- Un plan de redirection (tableau ancienne URL → nouvelle URL) se prépare avant la mise en ligne, pas après.
- On redirige une par une vers l'équivalent le plus proche. Jamais tout en bloc vers l'accueil.
- Les chaînes de redirection (A→B→C) gaspillent du jus SEO et se cassent facilement. À traquer.
- On garde les 301 en place le plus longtemps possible, idéalement indéfiniment.
- La vraie bataille commence après la migration : crawl, logs, Search Console, suivi des positions.
Gérer les redirections 301 après migration : ce que personne ne t'explique
La plupart des articles sur le sujet s'arrêtent au moment où tu colles tes règles dans le .htaccess. Félicitations, tu as redirigé. Mais qu'est-ce qui se passe la semaine suivante ? Le mois suivant ?
Bon, commençons par le vocabulaire, parce que c'est là que beaucoup se perdent.
Une 301, c'est permanent. Point.
Quand un serveur renvoie un code 301, il dit à Google et au navigateur : « cette page a déménagé pour de bon, va voir à la nouvelle adresse ». C'est une information transférée vers la nouvelle URL, ce qui distingue la 301 d'une 302 (temporaire), qui n'envoie pas le même message aux moteurs.
Concrètement, quand j'ai migré mon blog de monsite.fr vers monsite.com, j'ai généré un fichier de redirections à partir d'un export de mon sitemap. Erreur de débutant : j'ai fait ça en une heure, sans relire. Résultat, 340 URL pointaient vers des pages qui n'existaient pas. Google a mis environ trois semaines à me le signaler dans Search Console. Trois semaines pendant lesquelles j'aurais pu corriger.
Le plan de redirection : l'étape que tout le monde saute
Avant de toucher à quoi que ce soit, tu construis un tableau. Deux colonnes, au minimum : ancienne URL à gauche, nouvelle URL à droite. Si tu as des milliers de pages, tu ajoutes une colonne « priorité » et une colonne « statut ».
Pourquoi insister là-dessus ? Parce que la correspondance ancienne → nouvelle URL, c'est elle qui détermine si tu transfères du jus SEO ou si tu le jettes. Si tu rediriges l'article « guide du référencement local » vers ta page d'accueil, tu ne transfères rien d'utile. Le contenu de l'ancienne page n'a pas d'équivalent sur l'accueil, donc l'utilisateur atterrit sur une page qui ne répond pas à sa recherche. Il repart. Le signal envoyé à Google est mauvais.
Ma règle, après deux migrations : chaque ancienne URL va vers l'équivalent le plus proche. Si aucun équivalent n'existe, tu as trois options :
- Recréer le contenu (idéal, mais coûteux en temps)
- Rediriger vers une page de catégorie pertinente
- Laisser la page renvoyer une 404 propre si le contenu n'a vraiment plus lieu d'être
La troisième option est contre-intuitive. On croit qu'une 404 est toujours une catastrophe. Non : une 404 acceptable vaut mieux qu'une redirection trompeuse.
Comment éviter les redirections vers un site web ?
La question revient souvent, et elle mérite une réponse claire : on n'évite pas les redirections, on évite les redirections mal faites. Une 301 est un outil, pas un problème en soi. Ce qu'on veut éviter, c'est la redirection qui n'aurait pas dû exister, celle qui envoie l'utilisateur n'importe où, celle qui crée une boucle, celle qu'on a oublié de tester.
Les erreurs qui coûtent le plus cher
Voici celles que j'ai commises, et celles que j'ai vues commettre autour de moi.
| Erreur | Conséquence | Correctif |
|---|---|---|
| Tout rediriger vers la page d'accueil | Perte de pertinence, rebond élevé, jus SEO dilué | Rediriger vers l'équivalent le plus proche de chaque page |
| Chaînes de redirection (A→B→C) | Perte de jus à chaque saut, risque de boucle | Rediriger directement A→C |
| Redirections non testées avant mise en production | 404 silencieuses, découvertes trop tard | Crawl complet de l'ancien site et vérification des codes de réponse |
| 301 remplacées par des 302 par erreur | Signal de permanence non transmis | Vérifier les codes HTTP dans les en-têtes serveur |
| Redirections supprimées trop tôt | Backlinks cassés, visiteurs perdus | Les conserver le plus longtemps possible |
Le point le plus important de ce tableau, c'est le dernier. J'ai vu des collègues retirer leurs 301 six mois après la migration, « parce que Google a compris ». Sauf que Google, lui, ne t'a pas prévenu qu'il avait fini de traiter les choses. Et les backlinks, eux, ne se mettent pas à jour tout seuls. Si un vieux lien pointe vers une URL morte, le jus est perdu, point. La recommandation est claire : on garde les 301 le plus longtemps possible, voire indéfiniment.
Vérifier les redirections après mise en ligne : la partie que j'ai ratée
C'est ici que j'ai perdu cinq semaines. La mise en ligne s'était bien passée. Les redirections fonctionnaient sur les 200 pages que j'avais testées manuellement. Mais j'avais 1 400 pages au total.
Les outils et méthodes qui m'ont sauvé
Un crawl complet de l'ancien domaine, URL par URL, avec relevé des codes de réponse. J'utilise Screaming Frog pour ça (version gratuite jusqu'à 500 URL, payante au-delà). Il te sort une liste de tout : les 301 correctes, les 302 qui devraient être des 301, les 404, les chaînes, les boucles. Sur mes 1 400 pages, 340 étaient en 404 et 62 en chaîne. Je ne l'aurais jamais vu sans crawler.
Deuxième outil : les logs serveur. Ceux de mon hébergeur m'ont montré que certains bots crawlaient encore d'anciennes URL six semaines après la migration, à la recherche de pages disparues. Sans cette lecture, j'aurais continué à croire que tout était réglé.
Troisième : Google Search Console. Section « Pages » → « Non indexées » → filtre sur les 404 et les erreurs de redirection. Les données arrivent avec quelques jours de retard, mais c'est la source la plus fiable pour voir ce que Google voit vraiment. J'y ai passé un quart d'heure chaque lundi pendant deux mois. Chiant. Indispensable.
Combien de temps avant de voir les effets ?
Franchement, personne ne te donnera un chiffre précis, moi compris. D'après mon expérience, il faut compter entre deux et six semaines pour que les positions se stabilisent après une migration bien exécutée. Sur mon site, certaines pages ont retrouvé leur position initiale en dix jours. D'autres ont mis deux mois. Une poignée n'est jamais remontée, parce que le contenu redirigé n'avait pas d'équivalent satisfaisant.
Corollaire : ne touche à rien pendant cette période. Chaque modification que tu fais en pleine fenêtre d'observation brouille les signaux. C'est dur de ne pas s'agiter. Mais c'est la bonne stratégie.
Cas particuliers : quand le volume change tout
Gérer des milliers de redirections en masse
À partir de plusieurs milliers d'URL, écrire les règles à la main devient intenable. Deux approches :
- Générer les règles à partir d'un CSV, avec un script côté serveur ou un outil dédié du CMS. C'est ce que j'ai fini par faire pour mes 1 400 pages, en écrivant un petit script Python qui transformait mon tableau en règles Apache.
- Utiliser le moteur de règles de ton CMS ou framework, quand il en a un, pour éviter d'écrire du
.htaccessà rallonge.
Attention aussi aux règles génériques du type « tout ce qui commence par /blog/ va vers /articles/ ». Ça marche pour 80 % des cas, et ça casse les 20 % restants sans prévenir. Je l'ai fait, et j'ai découvert trois mois plus tard que ma page /blog/contact/ pointait vers /articles/contact/ qui n'existait pas. Chaîne cassée. Perte sèche.
Le cas des pages qu'on supprime volontairement
Toute migration soulève la même question : je redirige ou je supprime ? Ma règle, après deux ans à bidouiller ça : si la page a reçu du trafic organique ou des backlinks dans les douze derniers mois, tu rediriges. Sinon, tu peux la supprimer proprement — mais tu le documentes quelque part, pour ne pas te demander six mois plus tard pourquoi telle URL renvoie une 404.
Un détail que personne ne mentionne et que j'ai appris à la dure : les redirections ne se gèrent pas que depuis le serveur. Si tu utilises un CDN ou un pare-feu applicatif, certaines règles peuvent être court-circuitées. Vérifie les deux couches. J'ai perdu une journée à me demander pourquoi trois redirections ne fonctionnaient pas — c'était mon CDN qui interceptait avant le serveur.
Ce qui reste quand tout est réglé
J'ai fini par mettre en place cette routine, et je ne la lâche plus : un crawl mensuel de l'ancien domaine, une lecture rapide des erreurs Search Console tous les lundis, et un tableau de suivi des positions des 20 pages les plus stratégiques. C'est vingt minutes par semaine. Ça m'a coûté cinq semaines de rattrapage pour ne pas l'avoir fait plus tôt.
La vérité, c'est qu'une redirection 301 n'est pas un problème à résoudre une fois pour toutes. C'est une dette qu'on surveille. On la contracte au moment de la migration, on la rembourse en la maintenant en vie, et on arrête seulement le jour où on est sûr que plus personne — ni humain, ni robot — ne cherchera l'ancienne adresse. Ce jour-là n'arrive probablement jamais. Tant mieux : c'est le signe que ton site a une histoire, des liens qui traînent depuis des années, et des gens qui s'en souviennent.
