Le débat revient à chaque refonte ou changement de CMS : « le blog fait 300 clics par an, on ne va pas se casser la tête avec des 301 ». Sur le papier, ça se défend. Dans la vraie vie, c’est souvent une économie de quelques heures qui se transforme en dette sur des mois. Pas forcément visible en analytics, mais bien visible en bugs, en leads perdus, en pages qui disparaissent, en vieux liens qui deviennent des 404, et en reprise SEO qui traîne.
Le piège, ce n’est pas de changer des URLs. Le piège, c’est de confondre « peu de clics aujourd’hui » avec « peu d’impact si je casse tout ». Une URL, ce n’est pas juste une ligne dans un CMS. C’est un identifiant public qui vit dans Google, dans des mails, dans des PDFs, dans des tickets support, dans des Slack, dans des bookmarks. Et ça, même un petit site en a plus qu’il ne croit.
300 clics/an : pourquoi ce chiffre ne doit pas décider à ta place
Quand tu regardes Search Console et que tu vois 338 clics sur 12 mois, tu te dis naturellement « bon… c’est pas un actif ». Sauf que ce chiffre ne mesure pas ce que tu vas casser en changeant les URLs. Il mesure juste ce que Google t’a déjà envoyé. Or la casse, elle touche aussi les liens directs, les partages, les docs internes, les pages qui convertissent peu mais rassurent beaucoup, et surtout… la capacité de Google à retrouver le site rapidement après migration.
Autre point qui fausse la décision : une migration, ce n’est pas un événement SEO « neutre ». Si tu changes le CMS, la structure, les templates, le maillage interne, les canonical, la vitesse, parfois le rendu JS… tu changes déjà plein de variables. Ajouter par-dessus une couche de 404 inutiles, c’est s’offrir une investigation pénible le jour où ça baisse. Tu ne sauras même pas ce qui t’a plombé.
Et puis il y a le cas le plus courant : le blog « ne ranke pas »… jusqu’au jour où un article se met à ranker. Parce qu’il est evergreen, parce qu’il colle à une actu, parce qu’un gros site te linke. Si ton URL change et que tu n’as rien prévu, tu perds ce coup de chance. Le SEO, c’est souvent ça : des probabilités. Les 301, c’est un filet de sécurité.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Quand les redirections 301 sont non négociables
Il y a des cas où je ne discute même pas. Si tu as des liens externes (backlinks) vers certaines pages, ces URLs sont des points d’entrée. Tu peux avoir 0 clic SEO dessus aujourd’hui et pourtant recevoir du trafic référent, ou bénéficier d’un signal de popularité. Sans redirection, tu transformes ce lien en 404. Et une fois que c’est cassé, tu ne repars pas voir tous les sites pour leur demander de mettre à jour.
Même logique pour les pages qui ont une valeur « produit » ou « business » : une page qui convertit, une landing, un comparatif, un article qui sert de support commercial, une page souvent partagée en réponse à « tu as un lien ? ». Ce type de pages circule hors de Google. C’est typiquement là qu’une 404 fait mal, même si ton SEO est faible.
Enfin, les contenus evergreen. Les trucs qui ne sont pas « une news 2019 ». Une doc, un tuto, un glossaire, une page « comment faire X », un guide de migration, une page « erreurs fréquentes ». Ces pages ont une inertie. Si tu changes les URLs, au minimum tu dois leur donner un chemin propre, durable, et une 301 stable. C’est basique, mais c’est souvent oublié quand on refond vite.
Quand tu peux être minimaliste (sans faire n’importe quoi)
Oui, tu peux réduire le scope. Le bon minimalisme, ce n’est pas « aucune redirection ». C’est « je redirige ce qui a une valeur, et je gère proprement le reste ».
Les pages faibles, vraiment faibles, qui n’ont ni clics, ni impressions, ni liens, ni utilité business, tu peux les laisser mourir. Mais « laisser mourir » veut dire choisir. Si le contenu est supprimé sans équivalent, un 410 (Gone) est parfois plus honnête qu’une redirection vers la home. Et si tu as un contenu très proche (une nouvelle version, une page plus récente), une 301 vers ce contenu-là est logique.
Le mauvais minimalisme, c’est la redirection « aspirateur » qui envoie tout vers la page d’accueil. Google n’aime pas, les utilisateurs non plus. Et côté produit, ça crée des comportements chelous : tu cliques un lien vers un article précis, tu tombes sur la home, tu penses que le site est cassé. Si tu dois faire une redirection générique, fais-la au moins vers la catégorie la plus proche, ou vers une page hub.
Le mapping d’URLs : la méthode réaliste (celle qui tient en une demi-journée)
Le mapping, c’est juste un dictionnaire « ancienne URL → nouvelle URL ». Le danger, c’est de le traiter comme un projet parfait. Tu n’as pas besoin de couvrir 100% des cas exotiques pour avoir 90% du bénéfice.
Ce que je fais en pratique, c’est d’abord récupérer les anciennes URLs depuis plusieurs endroits, parce qu’un seul export ment toujours un peu. Un crawl du site actuel (même rapide), le sitemap actuel s’il existe, et Search Console (pages les plus cliquées, mais aussi pages qui reçoivent des impressions, et les erreurs 404 historiques). Tu merges ça, tu dédoublonnes, et tu as déjà une base sérieuse. Si tu as accès aux logs, c’est encore mieux : tu repères les URLs réellement demandées par des humains ou des bots.
Ensuite, tu essaies de repérer les patterns. Exemple classique : ancien blog en /blog/mon-article qui devient /articles/mon-article, ou des URLs avec date qui disparaît. Si 80% des URLs suivent une règle simple, tu fais une règle. Et tu réserves le mapping manuel aux exceptions, celles qui ont changé de slug, de catégorie, ou de structure.
Dernier truc que je fais toujours : je décide explicitement ce que je fais des pages supprimées. Pas au moment où les 404 remontent. Le jour du mapping. C’est ce qui évite les « on redirige tout vers la home parce qu’on panique ».
Règles vs exceptions : comment éviter le fichier de 20 000 lignes
Si tu as un blog un peu ancien, tu peux vite te retrouver à imaginer un fichier de redirections énorme. En réalité, la meilleure approche est souvent hybride : une ou deux règles globales (très sûres), et un petit fichier d’exceptions pour les slugs qui ont bougé.
Le point clé : tu dois empêcher les redirections en chaîne. Une ancienne URL qui redirige vers une URL intermédiaire, qui redirige vers la nouvelle, c’est un classique de migration faite « en plusieurs fois ». Et ça finit toujours par des bugs. Tu veux un saut, pas trois. Donc le mapping final doit pointer directement vers la destination finale.
Et attention au type de redirection. Pour une migration d’URLs « définitive », c’est 301. Une 302, c’est un message ambigu. Google sait parfois interpréter, mais tu n’as rien à gagner à jouer avec ça. Et côté cache / navigateurs / outils, c’est plus propre d’être clair.
# Exemple Nginx : règle globale + exceptions
# 1) Exceptions (les cas où le slug a changé)
map $request_uri $redirect_target {
default "";
/blog/ancien-slug-qui-a-bouge /articles/nouveau-slug;
/blog/guide-2021 /articles/guide-mis-a-jour;
}
server {
# 2) Si exception trouvée, on redirige
if ($redirect_target != "") {
return 301 $scheme://$host$redirect_target;
}
# 3) Sinon, règle globale simple (si elle est vraie pour la majorité)
rewrite ^/blog/(.*)$ /articles/$1 permanent;
}
Ce snippet n’est pas magique, mais il illustre l’idée : tu captes les cas tordus proprement, sans renoncer à une règle globale quand elle est légitime. Et surtout, tu peux versionner les exceptions, les relire, les tester, les enrichir au fil des retours 404.
Le « minimum vital » après changement d’URLs : sitemap, canonicals, maillage interne
Les 301, c’est le cœur. Mais si tu veux que ça reprenne vite, il y a trois détails qui font une grosse différence.
Le sitemap d’abord. Il doit contenir les nouvelles URLs, propres, canonicals, et retourner du 200. Pas les anciennes. Pas un mix. Et il faut le soumettre (ou le resoumettre) dans Search Console. C’est un accélérateur très sous-estimé après migration.
Les canonicals ensuite. J’ai vu des migrations où les pages redirigées avaient encore des canonicals qui pointaient vers l’ancienne structure (ou vers des URLs en http). Résultat : Google reçoit des signaux contradictoires, et toi tu passes deux semaines à te demander pourquoi l’index est bizarre. Une page nouvelle doit se canonicaliser vers elle-même, point.
Et le maillage interne. Si ton nouveau site continue à linker des anciennes URLs, tu te crées des redirections inutiles sur ton propre trafic. Pire, tu forces Googlebot à passer par des sauts, donc tu ralentis le crawl et tu gaspilles de l’énergie. Après migration, je veux que les liens internes pointent directement vers les nouvelles URLs. Les 301 sont là pour l’existant (web + historique), pas pour ton site à toi.
Tests et monitoring : ce que je regarde pour savoir si c’est “bon” (pas “à peu près”)
Avant mise en prod, le test simple consiste à prendre un échantillon d’anciennes URLs et vérifier qu’elles font bien une 301 vers la bonne destination, puis que la destination renvoie 200. Tu veux aussi vérifier qu’il n’y a pas de boucle, pas de chaîne, pas de redirection vers une URL qui redirige encore.
Après mise en prod, Search Console devient ton tableau de bord. Les rapports d’indexation et les 404 te donnent rapidement les ratés. Mais je préfère ne pas dépendre uniquement de ça : les logs serveur, même basiques, te montrent très vite quelles anciennes URLs sont encore demandées et par qui. C’est là que tu découvres les « surprises » : un lien dans une newsletter, un PDF, un vieux post LinkedIn, un partenaire qui te cite, un outil qui ping une URL précise.
Et un avertissement terrain : quand une migration part en vrille, beaucoup d’équipes corrigent en urgence en empilant des redirections sans nettoyer. Deux mois plus tard, personne n’ose toucher au fichier, et tu gardes des chaînes de redirection pour la vie. Prends une heure pour consolider. Une migration propre, c’est une migration où tu peux relire tes règles sans grimacer.
Mon avis (très assumé) : les 301 ne “valent pas le coup”… jusqu’au jour où tu en as besoin
Si tu ne fais pas de 301 parce que « ça ne vaut pas le coup », tu ne fais pas un choix SEO. Tu fais un choix de fiabilité. Et comme souvent en fiabilité, ça ne te coûte rien… tant que tu n’as pas d’incident.
Le bon compromis, c’est un mapping raisonnable, une règle globale si elle est vraie, des exceptions pour les pages importantes, et une gestion explicite des suppressions (410 ou redirection pertinente). Tu ne passes pas trois semaines, mais tu ne laisses pas non plus ton historique se transformer en cimetière de 404.
Et si tu veux aller plus loin après ça, la suite logique est simple : améliorer le maillage interne, remettre un sitemap carré, vérifier les canonicals, et profiter de la refonte pour arrêter de produire des URLs « jetables ». Parce que la meilleure redirection, c’est celle que tu n’auras jamais à écrire.
