404 Not Found

Utilisation

Lorsqu’une erreur 404 Not Found arrive, le statut ne précise pas si la ressource est indisponible de façon permanente, indisponible temporairement, ou n’a jamais existé. Cette erreur résulte le plus souvent d’URL mal saisies et elle est fréquemment rencontrée par les développeurs qui travaillent sur un ensemble de ressources encore en cours de réalisation.

Les liens vers des adresses renvoyant 404 Not Found sont communément appelés liens morts ou liens brisés. Ce statut est également utilisé lorsqu’un serveur ne souhaite pas reconnaître l’existence d’une ressource.

Lorsque le serveur sait que la ressource a existé à l’adresse indiquée mais qu’elle a été supprimée définitivement, un statut 410 Gone est plus informatif.

Comme cette erreur est très souvent vue par les utilisateurs finaux, de nombreux serveurs utilisent une page d’erreur personnalisée, descriptive et pertinente pour leur site.

Remarque

Un 404 ne signifie pas que le client est bloqué. Un blocage produit un 403 Forbidden. Certains serveurs renvoient 404 au lieu de 403 pour masquer l’existence d’une ressource. Le 404 n’indique aucun caractère définitif. La ressource peut apparaître plus tard. Pour une suppression permanente, le serveur renvoie 410 Gone.

Impact SEO

Les moteurs de recherche comme Google n’indexent pas une URL renvoyant un statut 404. Les URL précédemment indexées qui renvoient ce code de statut sont retirées des résultats de recherche. Les pages renvoyant ce code ne gaspillent pas de budget d’exploration. Google traite 404 et 410 de façon identique. Tous deux retirent le contenu de l’index à la même vitesse. Bingbot considère le 404 comme un signal de suppression de contenu et désindexe l’URL après avoir confirmé le statut lors d’une réexploration ultérieure. Renvoyer un 200 accompagné d’un contenu d’erreur au lieu d’un véritable 404 crée un soft 404, ce qui gaspille du budget d’exploration et érode la confiance accordée aux signaux du serveur du site.

Exemple

Le client demande une ressource et le serveur répond 404 Not Found parce que la ressource n’existe pas à l’adresse indiquée.

Requête

GET /documents/secret-formula.pdf HTTP/1.1
Host: example.com

Réponse

HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 216

<html>
  <head>
    <title>Resource Not Found</title>
  </head>
  <body>
    <p>The requested resource was not found.
    Check the spelling of the address.</p>
  </body>
</html>

Comment corriger

Un 404 Not Found signifie qu’aucune ressource n’existe à l’adresse demandée.

Vérifiez l’orthographe et le chemin de l’URL. Les fautes de frappe dans le chemin, le nom de fichier ou la chaîne de requête sont la cause la plus fréquente. Contrôlez chaque segment de l’adresse. Copiez le chemin directement depuis le lien source plutôt que de le saisir à la main.

Vérifiez la sensibilité à la casse. Les serveurs sous Linux traitent /Page et /page comme deux chemins différents. Respectez exactement la casse de l’URL d’origine. Les serveurs IIS sous Windows sont insensibles à la casse par défaut : un 404 sur IIS désigne donc une ressource réellement absente.

Surveillez l’absence de barre oblique finale. Certains serveurs distinguent /path et /path/. Ajoutez ou retirez la barre oblique finale puis réessayez. nginx et Apache gèrent les barres obliques finales différemment selon la configuration de try_files et de DirectorySlash.

Confirmez que la ressource existe sur le serveur. Vérifiez que le fichier ou la route est déployé et accessible. Connectez-vous en SSH au serveur et confirmez que le fichier se trouve au chemin attendu dans la racine documentaire. Sous nginx, vérifiez la directive root ou alias du bloc location correspondant. Sous Apache, vérifiez DocumentRoot dans l’hôte virtuel.

Mettez en place des redirections 301 ou 308 pour le contenu déplacé. Lorsqu’une ressource change d’adresse, redirigez l’ancienne URL afin d’éviter les liens brisés. Sous nginx :

location = /old-path {
    return 301 /new-path;
}

Dans le .htaccess d’Apache :

Redirect 301 /old-path /new-path

Vérifiez les règles de réécriture du serveur. Passez en revue les règles mod_rewrite sous Apache ou les blocs try_files et location sous nginx. Une réécriture mal configurée abandonne silencieusement les requêtes vers des chemins valides. Activez la journalisation des réécritures pour suivre l’évaluation des règles. Sous Apache, définissez temporairement LogLevel alert rewrite:trace3.

Vérifiez les types MIME et les mappages de gestionnaires sur IIS. IIS renvoie 404.3 lorsqu’une extension de fichier n’a pas de type MIME ni de mappage de gestionnaire enregistré. Ajoutez le type MIME manquant dans le Gestionnaire IIS ou via web.config :

<staticContent>
  <mimeMap fileExtension=".json"
    mimeType="application/json" />
</staticContent>

Vérifiez la configuration DNS et celle des hôtes virtuels. Un domaine pointant vers le mauvais serveur, ou une entrée d’hôte virtuel manquante, provoque un 404 sur tous les chemins. Vérifiez que les enregistrements DNS A/CNAME résolvent vers la bonne IP de serveur et que le serveur dispose d’une directive server_name (nginx) ou ServerName (Apache) correspondante.

Auditez les liens brisés avec un crawler. Lancez un crawler de site pour détecter toutes les réponses 404 sur l’ensemble du site. Corrigez les liens internes brisés et soumettez un sitemap XML à jour aux moteurs de recherche afin d’accélérer la réindexation du contenu déplacé. Parmi les outils permettant de trouver les liens brisés : Google Search Console (rapport de couverture), Screaming Frog, Ahrefs Site Audit, ou wget —spider pour une vérification en ligne de commande.

Références de code

.NET

HttpStatusCode.NotFound

Rust

http::StatusCode::NOT_FOUND

Rails

:not_found

http.StatusNotFound

Symfony

Response::HTTP_NOT_FOUND

Python3.5+

http.HTTPStatus.NOT_FOUND

Java

java.net.HttpURLConnection.HTTP_NOT_FOUND

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_NOT_FOUND

Angular

@angular/common/http/HttpStatusCode.NotFound