Un client m'appelle un jour, paniqué : « Google m'affiche une erreur 404 sur ma page de vente. » Je vais voir. La page en question, une 301 propre, pointait vers une autre 301. Qui pointait vers une URL qui n'existait plus. Trois sauts pour arriver nulle part. Le lien avait été « corrigé » six mois plus tôt par un stagiaire qui voulait bien faire.
Voilà le vrai sujet. Pas la 404 en elle-même. Les redirections qu'on empile sans regarder, et qui finissent par casser la chaîne. Corriger les erreurs 404 et les redirections pour le SEO, ce n'est pas un nettoyage ponctuel : c'est un chantier qu'on rouvre tous les six mois, sinon il se rebouche tout seul.
Points clés à retenir
- Une 404 n'est pas un bug. C'est une réponse valide pour une page réellement supprimée. Google attend ce code.
- La 301 transfère l'autorité. La 302 non. Confondre les deux coûte des positions, silencieusement.
- Une chaîne de redirections (A → B → C) dilue le signal. Un saut, pas deux.
- Tout rediriger vers l'accueil est une non-réponse. C'est le réflexe le plus courant et le plus coûteux.
- On ne corrige pas 400 erreurs. On en corrige 15, bien choisies.
- Une redirection qui pointe vers une 404 est pire qu'une 404 seule.
Pourquoi une 404 et une redirection ne posent pas le même problème
On les met souvent dans le même sac. C'est une erreur de diagnostic, et elle coûte cher.
La 404 : un signal, pas une panne
Quand une URL renvoie un code 404, le serveur dit deux choses : « cette ressource n'existe pas » et « je te le dis clairement ». Le visiteur voit une page, Google enregistre l'information et retire l'URL de son index au bout d'un moment.
Le problème n'est donc jamais la 404 en tant que telle. Le problème, c'est une 404 sur une URL qui recevait du trafic ou des backlinks. Là, vous perdez quelque chose : une visite, un lien entrant qui pointait vers un contenu disparu, une page qui convertissait.
Et c'est mesurable, ça. Sur un site de e-commerce que j'ai suivi, une page catégorie supprimée par erreur générait encore 180 visites par mois via des liens externes. Deux mois plus tard, zéro. Le trafic n'a pas été « perdu » par Google : il a été coupé par une décision interne que personne n'avait documentée.
Redirection temporaire ou permanente : le choix qu'on bâcle
Ici, la plupart des guides s'arrêtent à « utilisez une 301 ». C'est insuffisant. Le code que vous envoyez a un sens, et Google le lit.
| Code | Signification | Transfère l'autorité ? | Usage typique |
|---|---|---|---|
| 301 | Déplacé définitivement | Oui | Ancienne URL → nouvelle URL après refonte |
| 302 | Déplacé temporairement | Non | Test A/B, maintenance courte |
| 307 | Redirection temporaire, méthode HTTP préservée | Non | Formulaires, appels API |
| 308 | Redirection permanente, méthode préservée | Oui | Migration d'API, POST conservé |
La distinction 307/308 existe pour une raison précise : elle garantit que la méthode HTTP (POST, PUT…) n'est pas transformée en GET au passage. Sur un tunnel de commande, ça change tout. J'ai vu un formulaire de paiement perdre ses données de session parce que la redirection était en 302 : le POST devenait un GET, et le client arrivait sur une page vide.
La règle que j'applique : 301 sauf raison explicite de garder la méthode. Le reste est du bricolage.
Chaînes, boucles et soft 404 : les trois pièges que personne ne surveille
Une redirection isolée est inoffensive. Trois redirections en cascade, c'est une fuite.
La redirection en chaîne
Chaque saut ajoute une latence et dilue le signal transmis. Si la page A redirige vers B, qui redirige vers C, qui redirige vers D, le navigateur fait quatre requêtes. Le robot d'exploration aussi. Et à chaque étape, une partie du jus passe à la trappe.
La cause est presque toujours la même : on redirige vers une URL qui redirige déjà. Refonte en 2023, refonte en 2025, et la première redirection n'a jamais été mise à jour.
Ce que je fais systématiquement : après chaque migration, je liste toutes mes redirections et je vérifie qu'aucune cible n'est elle-même une source. Un saut. Jamais deux.
La redirection qui pointe vers une 404
Celle-là est vicieuse parce qu'elle ne se voit pas dans les outils de surveillance classiques. Vous avez bien une règle de redirection, elle s'exécute, elle répond un code 301. Sauf que la destination a été supprimée entre-temps.
Résultat : Google suit la redirection, atterrit sur une 404, et conclut que la chaîne entière est morte. Votre ancienne URL, qui avait de l'autorité, transmet maintenant cette autorité à rien.
Un contrôle par échantillonnage suffit : prenez vingt redirections au hasard chaque trimestre, ouvrez-les, regardez où vous atterrissez. Sur le dernier audit que j'ai mené sur un site de 4000 URL, 11 % des redirections aboutissaient à une 404 ou à une autre redirection. Onze pour cent. Personne ne l'avait vu.
Le soft 404 : le faux ami
Une soft 404, c'est une page qui répond 200 (tout va bien) mais dont le contenu dit « désolé, cette page n'existe pas ». Google détecte ce décalage et finit par traiter la page comme introuvable, tout en la gardant dans son index plus longtemps qu'une vraie 404.
Le cas typique : un CMS qui affiche une page de résultats vide avec un joli message. Ou une page produit sans stock affichée comme une page normale. Techniquement, votre serveur ne signale rien. Fonctionnellement, la page ne sert personne.
Comment décider quoi corriger en premier (et quoi laisser tomber)
Voici le piège dans lequel je suis tombé au début. Un outil me remonte 600 erreurs 404. Je me dis : je vais toutes les traiter. Trois semaines plus tard, j'en avais corrigé 120 et j'avais rien gagné de visible.
Le problème ? La majorité de ces 404 concernaient des URL qui n'avaient jamais reçu une seule visite. Corriger ça ne sert à rien.
Ce qui compte, c'est ce qui a une valeur mesurable :
- Les URL qui ont des backlinks externes — un lien cassé sur un site tiers, c'est de l'autorité qui part en fumée
- Les URL avec du trafic dans vos anciens rapports, même faible
- Les pages qui étaient des points de conversion (panier, formulaire, inscription)
- Les URL issues d'une migration récente, où le mapping est encore frais
Et celles qu'on laisse en 404 volontairement : les pages de test, les anciens paramètres d'URL, les archives de catégories sans contenu réel. Maintenir une 404 propre est plus sain que de tout rediriger vers l'accueil.
Ce fameux « tout rediriger vers la page d'accueil » : Google traite ça comme une soft 404. La redirection est techniquement valide, sémantiquement absurde. L'utilisateur cherchait une chaussure, il arrive sur une homepage qui vend des chaussures, des sacs et des ceintures. Il repart.
Le cas de la migration : le plan qui évite 90 % des dégâts
Une refonte sans plan de redirection, c'est une perte de trafic programmée. Je l'ai vécue une fois. Un site vitrine migré de 80 pages, aucune redirection préparée. Le trafic organique a mis trois mois à revenir à son niveau d'avant. Trois mois pour un site qu'on aurait pu rediriger en une après-midi.
Le mapping ancienne → nouvelle URL
Avant de toucher à quoi que ce soit, listez toutes les URL de l'ancien site, puis associez chacune à sa destination. Une ligne par URL. L'opération est rébarbative, il n'y a pas de raccourci honnête.
Deux règles que je m'impose :
- Un mapping doit être 1 pour 1 quand c'est possible. Pas de catégorie entière renvoyée vers une seule page.
- Quand aucune équivalence n'existe, mieux vaut une 404 qu'une redirection hors sujet.
Le contrôle après migration
Rediriger, c'est bien. Vérifier après, c'est mieux. Ce que je contrôle dans les jours qui suivent :
- Les codes de réponse réels (301, pas 302 ni 200)
- L'absence de chaînes
- L'absence de boucles (A → B → A, qui fait planter le navigateur)
- Le sitemap : il ne doit plus contenir la moindre ancienne URL
Une boucle de redirection, franchement, c'est le pire des cas. Le navigateur abandonne au bout d'une vingtaine de sauts, l'utilisateur voit une erreur générique, et Google enregistre un échec. Ça arrive plus souvent qu'on ne le croit, surtout quand deux extensions de redirection WordPress se marchent dessus.
Les erreurs que je vois revenir à chaque audit
« J'ai mis un plugin, le problème est réglé »
Un plugin détecte les liens cassés. Il ne décide pas quoi en faire. La décision reste humaine, et c'est là que 80 % de la valeur se crée.
« Je redirige tout en 302, comme ça je pourrai changer d'avis »
Sauf que la 302 ne transfère pas l'autorité. Si vous savez que le changement est définitif — et après une refonte, il l'est — utilisez une 301.
« Personne ne clique sur ces vieilles URL »
Les humains, peut-être. Les robots, si. Un lien cassé sur un site partenaire reste crawlable pendant des années.
Sur ce sujet, j'ai un avis tranché : la maintenance des redirections devrait être une tâche planifiée, au même titre que la sauvegarde. Pas un chantier qu'on ouvre quand le trafic chute. Une fois par trimestre, une heure, un tableur. C'est tout.
La question n'est pas de savoir si vous avez des 404. Vous en avez. La question est de savoir lesquelles vous avez choisi de garder.
