Corriger les pages 404 et les liens cassés utilement

Temps de lecture estimé : 6 min · Publié le 29 septembre 2026

Distinguer les sources de l’erreur

URL fictive séparée en cible HTTP GET /guide-demo/?lang=fr et fragment #documents à retrouver dans la page rendue. — Illustration · Exemple fictif : la requête de navigation conserve la query lang=fr ; le fragment #documents sert ici à viser un élément HTML dans le navigateur. Un 200 ne vérifie pas cet élément.

Relevez l’URL demandée, la page qui y conduit, la fréquence et la date. Une faute dans un lien interne se corrige à la source ; un ancien lien externe peut nécessiter une redirection ; une adresse inventée n’appelle pas forcément une nouvelle page.

Vérifiez les variantes avec ou sans slash, les anciennes campagnes et les fichiers téléchargés. Les journaux serveur et les outils de suivi révèlent des cas différents. Priorisez les adresses liées depuis le site ou réellement demandées.

Exercice fictif : le lien /guide-demo/?lang=fr#documents doit ouvrir une section HTML. La cible de la requête HTTP de navigation contient /guide-demo/?lang=fr ; le fragment #documents est traité séparément par le navigateur. Un statut 200 peut donc être correct alors que l’élément id="documents" a disparu du HTML rendu. Un contrôle limité au statut ne détecte pas cette rupture de destination.

Testez séparément la réponse HTTP, le contenu obtenu et l’endroit promis par le lien. Pour une ancre HTML classique, vérifiez l’identifiant dans la page rendue et son arrivée au clavier, y compris après traduction. Corrigez le lien source ou rétablissez un identifiant stable lorsque cela reste pertinent. Une règle serveur ne peut pas choisir sa redirection à partir d’un fragment absent de la cible de requête ; ne confondez pas ce cas avec un routage applicatif géré en JavaScript.

URL et provenance enregistrées.
Lien interne corrigé à la source.
Priorité liée à l’usage réel.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Page, contenu et ancre : trois vérifications différentes
Observation fictive	Ce que le résultat établit	Contrôle ou correction
URL de page en 404	Le serveur signale une ressource introuvable	Corriger la source ou choisir un remplacement réellement équivalent
Page en 200, id="documents" absent	La page répond, mais la section promise manque	Vérifier le HTML rendu et corriger le lien ou son identifiant
Page en 200 dans une autre langue	Le succès HTTP ne valide pas la langue attendue	Contrôler destination et libellé dans chaque édition
301 puis 200 vers une page sans rapport	La redirection aboutit, sans prouver l’équivalence	Comparer le contenu final avec l’intention du lien

Choisir le bon statut et la bonne destination

Si un contenu a un équivalent clair, redirigez directement vers lui. Si la page a disparu sans remplacement, conservez un vrai statut 404 ou 410 selon le cas et proposez une navigation utile. Rediriger toutes les erreurs vers l’accueil fait perdre le contexte.

Évitez les chaînes et boucles de redirection. Lors d’une migration, utilisez une table de correspondance des anciennes et nouvelles URL. Le guide de migration détaille cette décision.

Équivalent réel avant redirection.
Statut d’absence conservé si nécessaire.
Aucune chaîne ou boucle.

Aider la personne sur la page d’erreur

La page 404 doit dire simplement que l’adresse ne correspond à aucun contenu, puis proposer des accès fiables : navigation principale, recherche, catégories ou contact selon le site. Ne promettez pas que la page reviendra si ce n’est pas décidé.

Testez la page d’erreur sur mobile et au clavier. Elle doit conserver le bon statut HTTP, un titre clair et des liens qui fonctionnent. Une jolie illustration ne remplace pas une issue concrète.

Message clair et non culpabilisant.
Liens de sortie fonctionnels.
Statut HTTP correct.

Surveiller après les changements

Après une publication, un renommage ou une suppression, contrôlez les liens internes, le sitemap et quelques anciennes adresses importantes. Faites un nouveau passage quelques jours plus tard : des liens provenant de courriels, favoris ou partenaires peuvent apparaître.

Notez la correction et son résultat. Une URL qui reçoit encore des visites peut signaler un lien externe à faire modifier ou un besoin de contenu. Le guide d’exploitation éditoriale aide à planifier les retraits.

Contrôle après mise en ligne.
Anciennes URL testées.
Corrections documentées.

Choisir une réparation pertinente

Fiches reliées par un fil dont une connexion est interrompue — Choisir une destination qui répond encore à la demande initiale.

Cas proposé : un ancien lien renvoie vers l’accueil après la disparition d’une offre. Le visiteur arrive sur une page valide mais ne retrouve pas la réponse attendue.

Cherchez une destination équivalente ou expliquez clairement le retrait. Vérifiez liens entrants, état du serveur et parcours final ; une redirection réussie ne démontre pas une équivalence de contenu.

Identifier l’intention du lien
Justifier la destination choisie
Tester l’arrivée et le contenu

Comparer l’aperçu et la page
Préparer les aperçus de partage de ses pages

Documents de référence

MDN : HTTP 404 Not Found
W3C WAI : Menus Tutorial · Source consultée 2026-10-13
IETF : RFC 3986, Fragment · Source consultée 2026-10-23

Contenu mis à jour le 23 octobre 2026

Lire une réponse HTTP avant de corriger la page

Choisissez une situation pour distinguer le sens du statut, le contrôle utile et le piège à éviter. Ce lecteur explique des cas : il ne teste aucune adresse.

Choisir une réponse selon la situation de la ressource

Le statut reçu et le contenu affiché doivent raconter la même chose.

200Page disponible

Ce que cela signifie: La requête a réussi ; pour une page HTML, examinez aussi le contenu retourné.
Contrôle à effectuer: Vérifiez le titre, le contenu principal et la langue, puis la canonical et les directives d’indexation.
Point de vigilance: Une page « introuvable » renvoyée en 200 peut devenir une soft 404. Le succès HTTP ne garantit pas l’indexation.

301 / 308Déplacement permanent

Ce que cela signifie: 301 et 308 indiquent une nouvelle adresse permanente. 308 préserve explicitement la méthode et le corps ; avec 301, un client peut transformer POST en GET.
Contrôle à effectuer: Ouvrez l’ancienne URL et contrôlez Location, la destination pertinente et l’absence de chaîne ou de boucle.
Point de vigilance: Ne redirigez pas toutes les anciennes pages vers l’accueil. Pour un formulaire, vérifiez aussi la méthode attendue à destination.

302 / 307Déplacement temporaire

Ce que cela signifie: 302 et 307 indiquent un changement temporaire. 307 préserve la méthode et le corps ; avec 302, un client peut transformer POST en GET.
Contrôle à effectuer: Vérifiez que la destination est accessible et qu’un retour à l’adresse initiale est bien prévu.
Point de vigilance: Une redirection temporaire ne décrit pas un retrait définitif. Ne rejouez pas un paiement ou une commande sans vérifier son état.

404 / 410Ressource introuvable ou retirée

Ce que cela signifie: 404 ne précise pas si l’absence est temporaire ou définitive. 410 indique un retrait vraisemblablement permanent.
Contrôle à effectuer: Cherchez une erreur dans le lien, un changement d’URL ou un retrait volontaire. Proposez un remplacement seulement s’il répond au même besoin.
Point de vigilance: Une page d’aide doit conserver le vrai statut 404 ou 410. Un message d’erreur avec 200 ne corrige pas l’absence.

429Trop de requêtes

Ce que cela signifie: 429 signale une limitation du nombre de requêtes. Un en-tête Retry-After peut indiquer quand réessayer.
Contrôle à effectuer: Examinez la portée de la limite et Retry-After. Ralentissez les appels et bornez les nouvelles tentatives.
Point de vigilance: Évitez les relances immédiates en boucle. Sans réponse HTTP reçue, une erreur réseau n’est pas un statut 429.

503Service temporairement indisponible

Ce que cela signifie: 503 convient à une indisponibilité temporaire, par exemple une maintenance ou une surcharge. Retry-After peut donner un délai ou une date.
Contrôle à effectuer: Vérifiez le vrai statut, le périmètre touché et le retour au fonctionnement normal. Retirez le message après la reprise.
Point de vigilance: Ne remplacez pas durablement toutes les pages par une erreur. Pour Google, des 5xx persistants peuvent finir par faire retirer des URL de l’index.

Matrice de recette à adapter au projet

Ces contrôles proposés utilisent des cas fictifs. Décidez du comportement attendu avec l’équipe, notez le résultat et attribuez les écarts non résolus avant publication.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Cas de test, résultats attendus et preuves utiles
Cas	Résultat attendu	Preuve à conserver
Une adresse inventée affiche l’accueil avec HTTP 200.	Elle retourne un statut 404 et une aide pertinente.	URL inexistante demandée, statut 404 reçu et liens d’aide utilisables dans la réponse.

Questions fréquentes

Une page introuvable doit-elle répondre avec un statut 200 ?

Un écran d’aide peut être utile tout en conservant un statut de page absente. Un faux succès masque l’erreur aux outils et aux moteurs. Si un remplacement réel existe, utilisez une redirection pertinente. Sinon, expliquez le problème et proposez navigation ou contact sans prétendre que la ressource existe.