La semaine dernière, un client m'appelle, paniqué. Son trafic organique a chuté de 38 % en six jours. Il n'a pas touché à son contenu, n'a pas changé de serveur, rien. Après deux heures dans ses logs, j'ai trouvé le coupable : une redirection 301 qui pointait vers une autre redirection, qui pointait elle-même vers une page supprimée. Trois sauts, une 404 à l'arrivée. Google avait fini par ignorer poliment tout le circuit.
Les redirections 301 sont censées régler des problèmes. Mal posées, elles en créent. Et c'est presque toujours la même poignée d'erreurs qui revient, quel que soit le site, quel que soit le CMS. Voici celles que je vois le plus souvent, comment les détecter, et pourquoi certaines d'entre elles sont invisibles jusqu'au jour où elles coûtent cher.
Points clés à retenir
- Une 301 mal câblée perd son efficacité et n'a aucun effet négatif visible immédiatement. C'est là le piège.
- Une 301 qui pointe vers une page 404 annule le bénéfice de la redirection.
- Les chaînes de redirections diluent le signal à chaque saut supplémentaire.
- Une 302 utilisée comme redirection permanente est une erreur courante et coûteuse.
- Un audit mensuel des liens cassés prend vingt minutes et évite la plupart de ces situations.
- La redirection se fait côté serveur. Jamais en JavaScript.
Erreur n°1 : rediriger une URL… vers une page 404
Ça paraît absurde. Ça arrive tout le temps.
Le scénario classique : vous refondez un site, vous listez vos vieilles URL, vous les faites pointer vers les nouvelles. Sauf qu'une des nouvelles URL n'existe pas encore au moment où la redirection est mise en place. Ou pire, elle a existé, puis elle a été renommée six mois plus tard sans que personne pense à la redirection qui pointait dessus.
Pourquoi cette erreur reste invisible
Du point de vue du visiteur, tout a l'air normal. Il était sur une vieille URL, il atterrit sur une page. Il ne sait pas que la page est une 404 si elle est habillée comme le reste du site. Le problème, c'est que Google, lui, le sait. Et cette 301 qui mène à une 404 est traitée exactement comme si vous n'aviez rien configuré : le signal se perd.
Sur un ancien projet e-commerce, j'ai migré 340 URL vers une nouvelle arborescence. Neuf mois plus tard, je refais un crawl par curiosité. 27 redirections sur 340 pointaient vers une 404. Presque 8 %. Je les ai corrigées en une heure. Résultat sur les trois mois suivants : +14 % de clics organiques sur les pages concernées. Pas spectaculaire, mais gratuit.
Comment détecter ces redirections dormantes
Crawl complet du site avec une vérification du code de réponse final. Vous filtrez sur les URL qui renvoient 404 mais qui reçoivent du trafic entrant (via vos logs ou la Search Console). Toute URL dans cette intersection est une redirection cassée ou manquante. La procédure prend vingt minutes par mois si vous la faites régulièrement.
Erreur n°2 : les chaînes de redirection en cascade
Une redirection appelle une redirection qui appelle une redirection. C'est le cas de mon client de la semaine dernière. Ça arrive pour une raison simple : personne ne tient une carte centrale des redirections. Chacun en pose de son côté quand il en a besoin.
Comment se forme une chaîne, en pratique
Étape un : vous renommez la page /services en /prestations. Vous posez une 301. Étape deux, huit mois plus tard : vous refondez le site et décidez que /prestations devient /offres. Nouvelle 301. Étape trois : la page /offres est fusionnée avec /tarifs. Encor une 301.
Le visiteur qui clique sur un vieux lien partagé en 2023 traverse maintenant trois sauts. Chaque saut ajoute une requête HTTP. Chaque saut dilue légèrement le signal transmis. Et certains crawlers abandonnent après un certain nombre de redirections enchaînées.
| Type de configuration | Requêtes HTTP | Signal transmis | Effet utilisateur |
|---|---|---|---|
| 301 directe (source → cible finale) | 1 | Quasi total | Immédiat |
| Chaîne de 2 sauts | 2 | Dégradé | Ralenti |
| Chaîne de 3 sauts ou plus | 3+ | Fortement dégradé | Sensible ou abandonné |
| 301 vers 404 | 1 | Perdu | Page morte |
| Boucle de redirection | Infinie | Aucun | Erreur navigateur |
La règle à appliquer pour éviter les chaînes
Une seule règle : chaque redirection doit pointer directement vers sa destination finale actuelle. Quand vous créez une nouvelle redirection, vous devez aussi mettre à jour toutes les redirections existantes qui pointaient vers l'ancienne cible pour qu'elles pointent vers la nouvelle. C'est fastidieux. C'est la seule façon de garder un système propre.
Si vous utilisez un fichier .htaccess, tenez un commentaire de date sur chaque ligne et vérifiez manuellement le fichier à chaque migration. Si vous gérez les redirections via un plugin (Redirection, Yoast Premium, etc.), leur interface de détection de chaînes est votre meilleure amie. Ne l'ignorez pas.
Erreur n°3 : confondre 302 et 301
Une redirection 302 et une redirection 301 ne disent pas la même chose. Et la différence n'est pas cosmétique.
Ce que chaque code signifie vraiment
- 301 (Moved Permanently) : « Cette page a déménagé définitivement. Mets à jour tes favoris et transfère le jus. »
- 302 (Found / Moved Temporarily) : « La page est ici pour l'instant, mais l'URL d'origine reste la bonne. Ne transfère rien, ne change rien. »
- 307 : même intention que 302, mais garantit que la méthode HTTP est conservée (utile pour des POST).
- 308 : équivalent permanent de 307.
L'erreur typique que je vois chez 90 % des équipes techniques que j'accompagne : utiliser une 302 pour une refonte, en se disant qu'on verra plus tard. Plus tard n'arrive jamais. Et Google continue de considérer l'ancienne URL comme la version canonique. Résultat : la nouvelle URL ne se positionne pas, et l'ancienne reste dans les résultats avec son contenu fantôme.
Il y a un cas légitime pour la 302 : A/B test, page de maintenance, redirection géographique temporaire. En dehors de ces cas, si vous avez l'intention que le changement dure, c'est une 301.
Erreur n°4 : la gestion du www vers non-www (et l'inverse)
Le choix entre www.monsite.com et monsite.com importe peu. Ce qui compte, c'est de choisir, et de s'y tenir.
Le vrai problème arrive quand les deux versions coexistent sans règle claire. Vous avez des liens entrants qui pointent vers la version avec www, d'autres vers la version sans, et votre serveur répond 200 sur les deux. Pour Google, ce sont deux sites distincts avec deux contenus identiques. Il en choisit un comme canonique et ignore l'autre. Mais ce choix ne correspond pas forcément à celui que vous voulez, et vous perdez le bénéfice des liens pointant vers la version écartée.
La configuration à poser une fois pour toutes
Une règle de redirection unique qui couvre absolument toutes les URL entrantes de la variante non choisie. Attention aux pièges : la règle doit gérer HTTPS et HTTP, et elle doit être posée avant toute autre règle de votre fichier .htaccess, sinon elle peut être court-circuitée. Testez toujours http://www.monsite.com, http://monsite.com, https://www.monsite.com et https://monsite.com — les quatre doivent aboutir à la même URL finale.
J'ai déjà vu une config qui redirigeait correctement HTTP vers HTTPS mais laissait passer la variante www en HTTP vers www en HTTPS sans jamais corriger le www. Une chaîne invisible pour le visiteur, mais bien réelle dans les logs Googlebot.
Erreur n°5 : rediriger en JavaScript
Vous avez déjà vu ce code : une balise window.location placée dans le <head> d'une page. Ça fonctionne pour l'utilisateur. Ça ne fonctionne pas pour Google.
Le JavaScript est exécuté par Googlebot, oui, mais avec un budget de crawl limité et une file d'attente. Une redirection JS peut mettre des semaines à être traitée, ou ne jamais l'être si la page est considérée comme peu prioritaire. Pendant ce temps, la page source reste indexable et la cible ne reçoit pas le signal.
La redirection se fait côté serveur : règles de rewrite dans la configuration du serveur (Nginx, Apache), en-têtes HTTP dans la config de votre hébergement, ou module de redirection natif de votre CMS. Le JS est une solution de dernier recours, jamais un choix par défaut.
La méthode que j'utilise pour auditer redirections et liens cassés
Un audit trimestriel suffit dans la plupart des cas. Concrètement :
- Crawl complet du site avec un outil qui suit les redirections et reporte le code final.
- Export des URL avec 301, 302, 404 et 5xx.
- Croisement avec les données de la Search Console sur les 16 derniers mois : les URL qui reçoivent encore des impressions mais qui redirigent sont prioritaires.
- Correction des chaînes (toute redirection en plus d'un saut est à raccourcir).
- Mise à jour des redirections qui pointent vers des 404.
Ce processus m'a fait passer, sur un projet à 1 800 URL, de 47 chaînes problématiques à zéro en deux sessions de travail. Le trafic n'a pas bondi. Mais les pages cibles ont commencé à se positionner sur des requêtes qu'elles ne touchaient pas avant. Parfois, le SEO consiste simplement à enlever les cailloux du chemin.
Faut-il vraiment corriger tous les liens cassés ?
Non. Priorisez par trafic entrant réel. Un lien cassé que personne ne visite n'a aucun impact mesurable. Un lien cassé qui reçoit 400 visites par mois depuis un article invité, c'est une correction urgente. La règle simple : corrigez d'abord les 404 qui ont des backlinks, ensuite celles qui ont du trafic, oubliez le reste.
Combien de temps Google met-il à intégrer une nouvelle 301 ?
Variable. Sur des pages peu crawlées, comptez plusieurs semaines. Sur des pages importantes avec du trafic régulier, quelques jours suffisent souvent. Si vous ne voyez aucun changement après un mois, ce n'est pas un problème de délai. C'est un problème de configuration.
Reposez la question autrement : est-ce que la redirection est bien détectée par un crawl ? Si la réponse est non, le temps ne réglera rien.
Le vrai piège avec les redirections, ce n'est pas de mal les configurer la première fois. C'est de ne plus jamais les regarder après. Un site vivant génère des redirections en permanence, par petites touches, sans plan d'ensemble. Et un jour, quelqu'un vous appelle parce que le trafic a chuté de 38 % en six jours. Ce quelqu'un, ce sera peut-être vous. Sauf si vous ouvrez votre fichier .htaccess ce soir et que vous regardez ce qui s'y trouve vraiment.