Pages 404 personnalisées et soft 404 : servir la page d'erreur avec le statut d'erreur

Ce que c'est

La documentation de dépannage de Google définit un soft 404 comme une URL qui renvoie une page indiquant à l'utilisateur que la page n'existe pas tout en renvoyant également un statut 200, et liste des causes telles qu'un fichier inclus manquant, une connexion de base de données rompue, une page de résultats de recherche vide ou un fichier JavaScript manquant ; de telles pages sont exclues de la recherche. La même documentation recommande de renvoyer 404 ou 410 pour un contenu disparu, et décrit une bonne page 404 personnalisée comme une page qui indique clairement que la page est introuvable, conserve l'apparence et la navigation du site, renvoie vers des pages populaires et vers la page d'accueil, et propose un moyen de signaler un lien cassé. Sa documentation sur les codes de statut ajoute que le contenu des réponses 4xx n'est pas utilisé et qu'une URL auparavant utilisée qui renvoie désormais du 4xx est retirée au fil du temps, avec une fréquence d'exploration décroissante.

Côté serveur, la directive error_page de nginx définit l'URI affichée pour des erreurs données via une redirection interne, la méthode étant changée en GET pour les requêtes non-GET. La même directive peut changer le statut avec =response ; l'exemple de la documentation elle-même, error_page 404 =200 /empty.gif;, montre comment un 404 devient un 200. Les applications monopages qui servent index.html pour chaque chemin produisent le même effet par construction.

Pourquoi c'est important

Un soft 404 gaspille des requêtes d'exploration, garde des URL mortes dans les index, cache les liens cassés à la surveillance (tout est 200), et perturbe les outils qui traitent les codes de statut comme une vérité. Un 404 franc avec une page serveur nue perd le visiteur à la place.

Comment l'appliquer

• Configurer la page d'erreur (error_page 404 /404.html;) sans =200, et confirmer avec curl -I https://example.com/no-such-page que la ligne de statut indique 404 et que le corps est bien votre page.
• Pour les applications monopages, renvoyer 404 depuis le serveur pour les chemins que le routeur ne connaît pas, ou faire en sorte que l'application affiche un état d'erreur et, quand le framework le permet, fixer le statut sur la réponse rendue côté serveur.
• Rendre la page autonome : intégrer les styles critiques en ligne ou référencer des ressources à empreinte (fingerprint) par chemin absolu, car l'URL en échec peut se trouver dans un répertoire profond.
• Journaliser les 404 avec leur référent et les examiner ; les plus fréquents méritent une redirection, les autres un correctif sur la page qui pointe vers eux.
• Utiliser 410 pour les suppressions délibérées si l'on veut affirmer un caractère définitif ; la question ouverte associée traite de la manière dont les clients le traitent.

Pièges

Rediriger toutes les URL inconnues vers la page d'accueil (un soft 404 avec un 302). Des pages d'erreur qui chargent des ressources par chemin relatif et se cassent dans les sous-répertoires. Des pages d'erreur qui renvoient elles-mêmes du 404 pour leurs propres ressources, ou du 500 parce qu'un template a besoin de données qu'une requête « introuvable » n'a pas.

Applications monopages sans table de routes côté serveur

La plupart des applications monopages ne peuvent pas renvoyer 404 depuis le serveur pour des routes inconnues, car le serveur ne détient pas la table de routes et les routes paramétrées nécessitent une recherche de données. La documentation JavaScript SEO de Google donne deux alternatives que son robot d'indexation respecte : rediriger depuis JavaScript vers une URL à laquelle le serveur répond par 404 (par exemple /not-found), ou ajouter <meta name="robots" content="noindex"> au document depuis JavaScript lorsque l'application détermine que la page n'existe pas. Les deux méthodes maintiennent la page hors de l'index ; ni l'une ni l'autre ne donne de code de statut à la surveillance, donc préférer le prérendu ou le rendu côté serveur de l'état « introuvable » avec un vrai 404 là où le framework le permet, et utiliser les méthodes JavaScript pour le reste.