Une page qui tombe en 404 un vendredi soir, trois jours avant une campagne payante. Je connais la scène. Sur mon propre site, une refonte de catégories avait cassé 62 URL d'un coup. Personne ne s'en était aperçu pendant onze jours. Onze jours à envoyer du trafic payant vers des pages mortes.
Voilà pourquoi gérer les erreurs 404 et les redirections 301 n'est pas une tâche de fin de projet qu'on coche à la va-vite. C'est une discipline de fond. Et dans 90 % des cas, ce qui casse n'est pas technique : c'est un manque de méthode.
Points clés à retenir
- Une 404 signale que la ressource demandée n'a pas été trouvée ; le code est défini par le protocole HTTP.
- La 301 préserve le trafic et l'autorité d'une URL déplacée — à condition de viser une page équivalente.
- Rediriger toutes les 404 vers l'accueil est une fausse bonne idée que Google déconseille explicitement.
- Les analyseurs de liens cassés ne détectent que les liens internes : ils passent à côté de la majorité des 404 réelles.
- Une chaîne de redirections A → B → C dilue et ralentit le crawl. On la corrige systématiquement.
- Le code 410 Gone est l'alternative propre à la 404 pour une page définitivement supprimée.
Erreurs 404 et redirections 301 : ce que la plupart des sites ratent
D'abord, un cadrage. Que signifie l'erreur 404 ? Dans le World Wide Web, elle signale que la ressource demandée, généralement une page web, n'a pas été trouvée. Le navigateur affiche alors un message du type « pas trouvé » ou « not found ». Le numéro 404 est défini par la liste des codes du protocole HTTP.
Et son origine ? Elle est double. Soit un lien mort pointe vers une ressource supprimée ou déplacée vers une autre adresse. Soit l'adresse a été mal saisie, par l'internaute dans son navigateur ou par le webmaster au moment de concevoir sa page. Dans les deux cas, le serveur répond correctement — c'est la ressource qui manque, pas le serveur qui échoue.
Pourquoi une accumulation de 404 finit par coûter cher
Une 404 isolée n'est pas un drame. Cent, c'est un signal. Le robot d'exploration dépense son budget de crawl sur des impasses, les visiteurs tombent dans des culs-de-sac, et les liens externes qui pointaient vers vous s'évaporent sans que personne ne le remarque.
Le vrai piège, je l'ai vécu. On lance un audit avec un outil d'analyse de liens cassés — type Broken Link Checker sur WordPress — et on se croit couvert. Sauf que ces outils ne trouvent que les liens à l'intérieur d'un site donné. Ils ignorent les 404 provoquées par des liens venus d'autres sites. Résultat : ils manquent une part très large des erreurs réelles. Traduction concrète : votre audit interne voit peut-être 15 % du problème.
Le reste se lit ailleurs. Dans la Search Console, le rapport « Pages » liste les URL en 404 découvertes par le robot — y compris celles que vos outils internes ne verront jamais.
Comment résoudre le problème d'erreur 404 ?
La démarche tient en quatre temps, et l'ordre compte.
- Inventorier : croiser les 404 remontées par la Search Console avec votre crawl interne. Ne travaillez pas sur une seule source.
- Trier : chaque URL tombe dans une des trois cases ci-dessous. C'est l'étape que tout le monde saute, et c'est celle qui décide de tout.
- Traiter : 301 si un équivalent existe, 410 si la page est morte pour de bon, page 404 personnalisée sinon.
- Revérifier : recontrôler les codes HTTP renvoyés, pas seulement l'affichage visuel.
L'arbre de décision que j'utilise
Trois questions, dans cet ordre.
- La page a-t-elle un équivalent sémantique réel ? → 301 vers cette page.
- La page est-elle supprimée définitivement, sans remplaçant ? → 410 Gone. C'est plus net qu'une 404 : le robot comprend que la disparition est intentionnelle.
- Ni l'un ni l'autre, ou contenu qui reviendra ? → laissez la 404 vivre, mais soignez-la : navigation, recherche interne, liens vers les contenus proches.
Une chose sur laquelle je ne bougerai pas : la tentation de tout envoyer vers l'accueil. Google déconseille explicitement de rediriger toutes les 404 vers la page d'accueil. Et c'est logique. Un visiteur qui cherchait une fiche produit précise et atterrit sur votre home page ne trouve pas ce qu'il veut — il repart. La redirection masque le problème au lieu de le résoudre.
Comment faire une redirection 301 ?
Techniquement, c'est une ligne. Sur Apache, dans le fichier .htaccess :
Redirect 301 /ancienne-url/ https://exemple.fr/nouvelle-url/
Sur Nginx, une directive return 301 dans le bloc serveur. Sur WordPress, un plugin de redirection fait le travail sans toucher au serveur. Sur SPIP, il existe également une extension dédiée aux redirections 301. Peu importe l'outil : ce qui compte, c'est ce que vous mettez à droite de la flèche.
Les erreurs que je vois le plus souvent sur les 301
La première est de rediriger vers une page faible. Une 301 transmet l'autorité de l'ancienne URL — si vous l'envoyez vers une page sans rapport, vous gaspillez ce signal. J'ai fait cette erreur sur une migration de blog : 40 articles redirigés en vrac vers la catégorie parente. Résultat des mois plus tard, des positions perdues que j'ai mis des semaines à récupérer. Le mapping mérite du temps.
La deuxième, ce sont les chaînes de redirection. A redirige vers B, B vers C. Chaque saut coûte un aller-retour et complique le crawl. Pire : la boucle A → B → A, qui fait échouer la requête. On corrige en pointant toujours directement vers la destination finale.
La troisième : oublier l'ordre des règles. Une règle générique placée avant une règle spécifique l'écrase. Sur une migration en masse, ça se traduit par des dizaines d'URL qui partent au mauvais endroit sans que rien ne le signale.
Le mapping en masse, sans se tromper
Pour une migration sérieuse, exportez votre plan de redirection dans un tableur : ancienne URL, nouvelle URL, code, date de mise en production. Les correspondances régulières et les règles wildcard font le gros du travail quand les URL suivent un motif stable. Testez sur un environnement de recette avant la production. Et vérifiez les codes avec un simple appel direct — pas l'affichage dans le navigateur.
| Situation | Code recommandé | Effet |
|---|---|---|
| Page déplacée, équivalent clair | 301 | Transmet trafic et autorité vers la nouvelle URL |
| Page supprimée définitivement | 410 | Signale une disparition intentionnelle |
| URL mal saisie, contenu existant ailleurs | 404 + page personnalisée | Le visiteur est guidé, pas perdu |
| URL temporairement indisponible | 302 | Redirection provisoire, pas de transmission d'autorité |
Mesurer, surveiller, et ne plus jamais subir
Une fois le nettoyage fait, le plus dur commence : ne pas laisser la situation se dégrader à nouveau. Sur mon site, j'ai instauré une revue mensuelle. Dix minutes. Le rapport « Pages » de la Search Console, filtre sur les 404, et je regarde si de nouvelles URL apparaissent.
Les indicateurs qui comptent vraiment :
- le nombre de 404 découvertes par période, et sa tendance ;
- les 301 suivies — leur nombre ne doit pas grossir indéfiniment ;
- les redirections en chaîne, à traquer à chaque déploiement.
La dernière fois que j'ai fait cet exercice, deux chaînes de redirection traînaient depuis une ancienne refonte. Elles pointaient vers une page qui n'existait plus. Personne ne l'avait vu. Ni l'équipe technique, ni moi.
Il y a quelque chose d'un peu ironique dans tout ça. On passe des heures à optimiser des balises et des contenus, et une redirection oubliée peut annuler une partie du travail en silence. Alors la prochaine fois que vous déployez une refonte, posez-vous une seule question : qui vérifie les codes HTTP après la mise en production ? Si la réponse est « personne en particulier », vous savez ce qu'il vous reste à faire.
