Un client m'appelle un mardi matin, paniqué. Il a refait son site le week-end, tout est plus beau, plus rapide. Et le lundi, ses sessions organiques ont chuté de 62 %. Sa première phrase : « J'ai dû casser quelque chose chez Google. » Non. Il a juste renommé ses URLs sans rien brancher derrière. Les vieilles adresses renvoyaient une 404 bien propre, et Googlebot, poliment, est reparti.
Configurer les redirections 301 sans perdre de trafic, c'est rarement un problème de code. C'est un problème de méthode. On sait tous coller une ligne dans un .htaccess. Ce qu'on rate, c'est la cartographie avant, l'audit des chaînes après, et tout ce qui se passe entre les deux.
Points clés à retenir
- Une 301 transfère la valeur SEO, mais uniquement si la destination répond en 200 et reste stable dans le temps.
- Googlebot suit jusqu'à environ 10 sauts au total, mais seulement 5 par tentative de crawl — au-delà, la chaîne est abandonnée.
- Le mapping anciennes → nouvelles URLs se construit avant la mise en ligne, jamais pendant.
- Une redirection interne (une page de votre site qui pointe vers une autre via 301) gaspille du budget de crawl pour rien.
- Les pages sans équivalent valide doivent renvoyer une 410 ou une 404, pas une 301 vers la page d'accueil.
Pourquoi une 301 bien posée perd quand même du trafic
Il y a un mythe tenace : la 301 « transfère 100 % de l'autorité ». Faux dans les faits, et c'est important de le dire clairement. Une redirection permanente est un signal, pas un interrupteur. Google doit recrawler l'ancienne URL, voir la 301, crawler la nouvelle, puis réévaluer son classement avec le nouvel historique. Ce cycle prend du temps. Sur les projets que j'ai suivis, la reconsolidation complète se joue entre quelques jours pour un petit site et plusieurs semaines pour un gros catalogue.
Le problème ?
La perte vient presque jamais du protocole lui-même. Elle vient de trois erreurs humaines qui se glissent dans la précipitation.
Les trois erreurs que je vois le plus souvent
La première : rediriger tout le trafic vers la page d'accueil. C'est le réflexe du développeur pressé. Une page produit obsolète envoie vers /, point. Résultat, Google comprend que la page n'existe plus vraiment et la remplace… par la home, qui ne cible rien de comparable. Vous perdez la longue traîne.
La deuxième, plus sournoise : les chaînes. A redirige vers B, B redirige vers C, C existe enfin. Trois sauts. Googlebot suit, mais à chaque saut il consomme une tentative. Sur un site avec 40 000 URLs et un crawl budget serré, ça suffit à retarder l'indexation de tout le reste.
La troisième, mortelle : la 301 vers une 404. On change une URL, on pose la redirection, et on oublie que la cible elle-même est cassée ou mal orthographiée. Le crawler touche la 301, la suit, tombe sur une 404, et considère la chaîne comme invalide. Perte nette, définitive.
Cartographier les URLs avant la migration
Voilà la partie que personne ne montre dans les tutoriels, et c'est pourtant 80 % du boulot.
Vous ne pouvez pas rediriger ce que vous n'avez pas listé. Donc, avant de toucher au serveur, il faut deux colonnes : toutes les anciennes URLs qui recevaient du trafic ou des backlinks, et leurs équivalents sur le nouveau site. Un crawl complet (Screaming Frog, Sitebulb, peu importe) vous sort la liste brute. Je récupère toujours en plus les URLs de la Search Console, car elles contiennent des pages qui ne sont plus liées nulle part mais reçoivent encore des clics.
Comment faire correspondre quand rien ne correspond
Toutes les pages n'ont pas d'équivalent direct. Trois cas, trois traitements.
- Correspondance 1:1 évidente —
/ancien-produit→/nouveau-produit. Simple. - Fusion de plusieurs pages en une seule — redirigez chacune vers la page consolidée. C'est sain, Google gère.
- Aucun équivalent, page réellement supprimée — servez une 410 Gone. Pas une 301 vers la home. La 410 dit clairement « cette ressource n'existe plus », et Google retire l'URL proprement.
Cette troisième règle est celle que je vois le plus violée. Continuer à rediriger une page morte vers un contenu non pertinent, c'est envoyer un signal de qualité médiocre. Mieux vaut l'assumer.
| Situation | Code à utiliser | Effet sur le trafic |
|---|---|---|
| URL renommée, même contenu | 301 | Transfert progressif de la valeur |
| Contenu supprimé, plus jamais recréé | 410 | Retrait propre, pas de perte de qualité |
| Page en maintenance temporaire | 302 | Ne transmet pas la valeur |
| Fusion de 5 pages en 1 | 301 × 5 | Consolidation vers la page cible |
Où poser les redirections (et où ne surtout pas le faire)
Une règle non négociable : jamais en JavaScript. Une redirection côté client arrive après le rendu, quand le crawler a déjà commencé à traiter la page. Google finit souvent par la comprendre, mais avec du retard et de l'incertitude. On perd du temps, donc du classement.
Le bon endroit, c'est le serveur. Concrètement :
- Nginx — directive
return 301ourewrite, dans la config du bloc serveur. - Apache / .htaccess —
Redirect 301ouRewriteRuleen mode permanent. - CMS — un plugin de redirections applique la 301 au niveau HTTP si le module serveur est correctement branché. Vérifiez-le, ne le supposez pas.
- CDN — possible pour des règles en masse, mais attention à ne pas empiler deux couches qui créent des chaînes invisibles.
Le piège, justement, c'est l'empilement. Sur un projet il y a deux ans, j'avais un serveur qui posait la 301 vers une URL que Cloudflare redirigeait à son tour vers une troisième. Personne ne voyait le problème à l'écran, tout fonctionnait. Mais le crawler, lui, comptait les sauts.
Que faire des chaînes de 301
Combien de sauts avant que ça casse ? La limite généralement citée est d'environ 10 sauts au total, mais seulement 5 par tentative de crawl. En pratique, au-delà de 2, vous n'êtes plus dans le confort.
Détecter les chaînes est simple : la plupart des crawlers signalent les redirections qui pointent vers d'autres redirections. C'est une colonne dans l'export, on la filtre, on la corrige. La correction consiste à écraser la chaîne — la première URL redirige directement vers la destination finale. Toujours.
Spoiler : si vous faites une seule chose après avoir lu ceci, faites ça. C'est là que se cachent les gains les plus mesurables.
Cas particuliers : www, HTTP/HTTPS, paramètres et pagination
Ces redirections-là sont souvent oubliées parce qu'elles ne viennent pas d'un changement de contenu, mais d'un changement d'infrastructure.
Canonicalisation www et protocole
Vous choisissez une version canonique de votre domaine et vous y redirigez tout le reste en 301. Une seule. Si http://exemple.com, http://www.exemple.com et https://www.exemple.com répondent tous en 200, vous duplicatez votre propre contenu et diluez vos signaux. La redirection vers la version HTTPS canonique règle le problème.
Paramètres d'URL et pagination
Les paramètres de tracking (?utm_source) ne doivent pas être redirigés — ils doivent être ignorés côté canonique. En revanche, les paginations d'anciennes catégories qui disparaissent doivent pointer vers la nouvelle pagination correspondante, page par page si possible. Rediriger toutes les pages paginées vers la page 1 de la catégorie est un raccourci qui fonctionne à moitié : vous gardez le trafic, vous perdez le classement des contenus profonds.
Vérifier après la mise en ligne
Un outil de crawl relancé sur l'ancien site détecte les 301 cassées, les chaînes, les redirections vers des erreurs. Faites-le deux fois : une fois à J+1, pour attraper les erreurs grossières, une fois à J+15, quand les vraies conséquences apparaissent dans les rapports de couverture.
Ce que vous cherchez :
- Les 301 qui pointent vers autre chose qu'un 200.
- Les chaînes de plus de 2 sauts.
- Le maillage interne — et c'est le point que personne ne mentionne. Si vos propres liens de navigation pointent encore vers les anciennes URLs, vous forcez chaque visiteur interne à traverser une redirection. Corrigez les liens, pas seulement les redirections. Un lien en dur vers la nouvelle URL, c'est un saut en moins à chaque passage de Googlebot.
Combien de temps garder les 301
La réponse honnête : indéfiniment, ou au moins tant que les backlinks externes pointent encore vers les anciennes URLs — et vous ne contrôlez pas ça.
On m'a souvent dit qu'au bout de quelques mois on pouvait retirer. Je le déconseille. Une 301 coûte quasi rien en ressources et sert de filet. Sur un site dont j'ai migré la structure il y a plus de deux ans, je conserve encore toutes les redirections actives. Rien ne le justifie de les enlever, à part une propreté esthétique dont personne ne profite.
Ce que je retire, en revanche, ce sont les 301 qui n'ont plus aucun lien entrant, plus aucun clic, depuis longtemps. Mais je vérifie avant.
Une dernière chose. Le vrai indicateur, ce n'est pas le rang de vos redirections dans une checklist. C'est la courbe de vos impressions dans les semaines qui suivent. Si elle remonte en cloche, la migration s'est bien passée. Si elle stagne ou continue de descendre, regardez vos chaînes et vos destinations invalides, dans cet ordre.
Et la prochaine fois que quelqu'un panique parce que son trafic s'effondre après un changement d'URL, posez une seule question : avez-vous testé ce que renvoie l'ancienne adresse ? Dans mon cas, ce mardi matin, c'était une 404. Une ligne dans le .htaccess a suffi. Le reste n'était qu'une question de patience.
