Faire ses propres pages d'erreur 404 et 500 sans fausser le code HTTP

Sur un site internet, les pages d'erreur 404 et 500 se règlent dans la configuration du serveur web (ErrorDocument chez Apache, error_page chez Nginx) ou dans un fichier PHP, et renvoient le vrai code : 404 si l'URL n'existe pas, 500 ou 503 si le service tombe, jamais 200.

Pourquoi le code de statut compte plus que le décor de la page

Le code de statut HTTP est le nombre de trois chiffres que le serveur envoie avant le contenu, dans la première ligne de la réponse. Le protocole HTTP (Hypertext Transfer Protocol, décrit aujourd'hui par la RFC 9110 de l'IETF, publiée en juin 2022) range ces codes par familles : 2xx pour une réponse réussie, 3xx pour une redirection, 4xx pour une erreur côté client, 5xx pour une erreur serveur. Le navigateur de l'utilisateur affiche le document reçu, mais les moteurs de recherche lisent d'abord ce nombre, et le référencement du site en dépend.

Une page « introuvable » soignée, servie avec un code 200, devient ce que Google appelle une soft 404 : le moteur doit deviner qu'il s'agit d'une erreur, et il peut garder l'adresse dans son index comme un vrai document presque vide. Le rapport d'indexation de Google Search Console signale ces adresses à part, sous l'étiquette « Soft 404 ». Rediriger toutes les erreurs vers l'accueil produit un problème voisin : le visiteur perd l'information qu'il a suivi un lien mort, et Google traite souvent ces redirections massives comme des soft 404.

Le bon statut dépend donc de la situation réelle, pas du message affiché. Un gabarit personnalisé n'a de sens que s'il accompagne la vraie erreur ; le décor vient ensuite.

Déclarer les pages d'erreur avec Apache et un fichier .htaccess

Sur un site hébergé sous Apache, la directive ErrorDocument associe une erreur au fichier à afficher. Elle accepte trois formes de valeur : un chemin local, une adresse complète ou un simple texte entre guillemets. Seul le chemin local, qui commence par une barre oblique, conserve le statut d'origine. La documentation officielle de la version 2.4 le précise : avec une adresse en http://, le serveur envoie une redirection, et l'utilisateur reçoit un code 302 au lieu de l'erreur attendue.

ErrorDocument 404 /erreurs/introuvable.html
ErrorDocument 410 /erreurs/supprimee.html
ErrorDocument 500 /erreurs/panne.html
ErrorDocument 503 /erreurs/maintenance.html

Dans un fichier .htaccess, ces lignes ne s'appliquent que si l'hébergement autorise AllowOverride FileInfo (ou All) pour le dossier, ce que font la plupart des offres mutualisées. Sur un serveur dédié, mieux vaut les placer dans la configuration du serveur ou du virtual host, lue une seule fois au démarrage plutôt qu'à chaque requête. Le fichier htaccess sert aussi à d'autres réglages, comme la forme avec ou sans www de l'adresse ; les directives d'erreur cohabitent sans difficulté avec ces règles de réécriture.

Avant toute modification, une sauvegarde du fichier s'impose. Une faute de syntaxe dans un .htaccess déclenche justement une erreur 500 sur tout le site, et le message d'erreur générique remplace alors chaque URL du site ; la sauvegarde permet de résoudre la panne en quelques secondes.

Le cas des erreurs renvoyées par PHP-FPM

Une erreur 500 produite par un script PHP ne passe pas toujours par le fichier déclaré dans ErrorDocument. Quand PHP tourne en PHP-FPM derrière mod_proxy_fcgi, le serveur transmet tel quel ce que renvoie le script, corps compris. La directive ProxyErrorOverride On, dans la configuration du serveur, demande à Apache de remplacer ces réponses d'erreur par ses propres pages. Sans elle, le gabarit personnalisé ne sert qu'aux erreurs constatées par le serveur lui-même.

Configurer error_page avec Nginx

Avec Nginx, la directive error_page joue le même rôle et accepte plusieurs codes sur une ligne. Le bloc location suivant, marqué internal, empêche d'ouvrir ces fichiers directement depuis le navigateur : elles ne servent qu'en réponse à une erreur réelle.

error_page 404 /erreurs/introuvable.html;
error_page 500 502 503 504 /erreurs/panne.html;

location ^~ /erreurs/ {
    internal;
}

Nginx garde le statut d'erreur tant que la ligne ne contient pas de signe égal. Une forme comme error_page 404 =200 /autre.html remplace le status code par 200, ce qui recrée une soft 404 : c'est une option à réserver à des cas très particuliers. Pour les erreurs qui viennent de PHP-FPM, la directive fastcgi_intercept_errors on (ou proxy_intercept_errors on derrière un proxy) fait appliquer error_page aux réponses du backend, comme ProxyErrorOverride de l'autre côté.

Chaque modification se teste avec nginx -t avant le rechargement. Cette commande vérifie la syntaxe de toute la configuration du serveur et signale la ligne fautive, ce qui évite de couper le service pour une accolade oubliée. Une sauvegarde du fichier de configuration avant l'édition garantit un retour arrière immédiat.

Poser le code d'erreur depuis un script PHP

Un script PHP doit poser lui-même le code 404 quand c'est l'application, et non le serveur web, qui constate l'absence d'un article. C'est le cas typique d'un article supprimé de la base de données alors que son adresse reste valide pour le routeur : le fichier index.php existe, le serveur web répond donc 200, et seul le script sait que rien ne correspond. La fonction http_response_code(), disponible depuis PHP 5.4, fixe le code avant tout affichage :

<?php
$article = trouver_article($slug);
if (!$article) {
    http_response_code(404);
    include __DIR__ . '/erreurs/introuvable.html';
    exit;
}

L'appel doit précéder le moindre octet envoyé au navigateur, espace ou ligne vide compris, sinon PHP signale que les en-têtes sont déjà partis et la réponse reste en 200. Pour une panne détectée par l'application, http_response_code(500) ou (503) suit cette logique. Une erreur fatale non interceptée renvoie déjà un code 500 lorsque display_errors est désactivé, ce qui doit toujours être le cas en production : le message d'erreur technique va dans le journal, jamais à l'écran. Pour remonter à la ligne fautive, la marche à suivre est détaillée dans trouver l'origine d'une panne PHP en dix minutes.

Personnaliser la page 404 d'un site WordPress

Un site WordPress gère déjà le code 404 tout seul : quand aucune publication ne correspond à l'adresse, le cœur du CMS pose le bon code et charge le fichier 404.php du thème, prévu par la hiérarchie des modèles. Personnaliser cette page revient à modifier ce fichier dans un thème enfant, pour que le changement survive aux mises à jour du thème parent. Avec un thème à blocs, le modèle « 404 » se modifie directement dans l'éditeur de site, sans toucher au code source.

La page 500 échappe en revanche à WordPress, puisqu'elle s'affiche justement quand PHP ou la base de données ne répondent plus. WordPress prévoit pour ce cas deux fichiers placés dans wp-content : db-error.php, affiché quand la connexion à la base échoue, et php-error.php, utilisé par le mode de récupération introduit avec WordPress 5.2. Les autres CMS (Joomla, Drupal, PrestaShop) ont un gabarit d'erreur équivalent. Si le choix de l'outil reste ouvert, le CMS à retenir quand on débute se compare sur ce genre de détail.

Une extension (plugin) de redirection installée sur le site garde souvent un journal des adresses en 404, utile pour repérer les anciens liens à rediriger, surtout juste après une refonte de site.

Que mettre sur la page 404, et sur la page 500 ?

La page 404 peut reprendre l'en-tête, le menu et le pied de page du site, puisque le serveur fonctionne. Elle dit clairement que l'adresse n'existe pas ou plus, sans jargon technique, puis propose une sortie : un champ de recherche, les rubriques principales, les articles les plus lus. Le titre de la page (balise title) indique aussi l'erreur, pour que l'onglet du navigateur et l'historique de l'utilisateur ne la confondent pas avec un vrai article.

• un message court qui nomme le problème (« cette adresse ne correspond à aucune page du site ») ;
• une zone de saisie pour chercher et trois à cinq liens vers les grandes rubriques ;
• aucune redirection automatique au bout de quelques secondes, qui désoriente le visiteur ;
• un poids léger : la page est servie à chaque lien mort, robots compris.

La page 500 obéit à une règle inverse : un fichier HTML statique, sans PHP, sans appel à la base de données et sans feuille de style externe hébergée sur le même serveur. Si la panne vient de là, une page d'erreur dynamique tomberait elle aussi, et l'utilisateur verrait le message brut du serveur web. Une phrase d'excuse, l'invitation à réessayer plus tard et, éventuellement, un moyen de contact suffisent. Pour une maintenance, le code 503 accompagné d'un en-tête Retry-After indique aux robots quand repasser.

Comment détecter les erreurs 404 et 500 d'un site ?

Les erreurs 404 d'un site se repèrent par quatre outils complémentaires, du plus simple au plus complet. Le premier est la ligne de commande : curl -I suivi d'une adresse inventée affiche la réponse du serveur à la requête, et la première ligne doit montrer 404, pas 200 ni 302. La même commande sur une page qui provoque une panne doit afficher 500 ou 503.

curl -I https://exemple.fr/adresse-qui-nexiste-pas
HTTP/2 404

Google Search Console liste ensuite, dans le rapport d'indexation des pages, les adresses classées « Introuvable (404) », « Soft 404 » et « Erreur de serveur (5xx) », avec la date de dernière exploration. Un link checker, comme le W3C Link Checker ou un robot d'exploration installé en local, parcourt les liens internes et signale ceux qui pointent vers une page absente. Après chaque refonte, vérifier les URL les plus visitées du site évite de perdre leur référencement. Le journal d'accès du serveur reste la source la plus exhaustive : un filtre sur « 404 » dans access.log montre les adresses demandées, les liens d'origine et les robots qui insistent.

Un pic d'erreurs 500 se lit plutôt dans le journal d'erreurs (error.log ou le journal PHP de l'hébergement), qui donne le fichier et la ligne en cause. Un refus d'accès se traite à part : il renvoie un code 403, dont les causes côté serveur sont décrites dans l'erreur 403 Forbidden et ses permissions de fichiers.

Un cas souvent oublié : le CDN et le cache devant le site

Un service placé devant le site, comme un CDN ou un proxy de cache, peut afficher sa propre page d'erreur et masquer celle du serveur. Quand l'hébergement ne répond plus du tout, c'est la page du CDN qui apparaît, avec un code 5xx qui lui est propre (Cloudflare utilise par exemple 521 ou 522 pour un serveur d'origine injoignable). La plupart de ces services permettent de remplacer leur page par un modèle personnalisé, à héberger chez eux puisque le serveur d'origine est justement indisponible.

Le cache pose un autre piège : une page 404 mise en cache avec une durée longue continue d'être servie quelque temps alors que l'article est revenu. Limiter la durée de cache des réponses d'erreur, ou purger l'adresse dès sa remise en ligne, évite qu'un article republié reste invisible. Ce raisonnement vaut aussi pour un changement de nom de domaine, où l'ancien domaine doit rediriger en 301 plutôt que renvoyer des 404 en série.

Codes 404, 410 et 500 : trois situations à trancher

Faut-il une 404 ou une redirection pour une page déplacée ?

Une page déplacée appelle une redirection 301 vers sa nouvelle adresse, pas une 404. Le visiteur et les moteurs de recherche arrivent directement au bon contenu, et les liens reçus par l'ancienne adresse continuent de servir. La 404 reste la réponse correcte quand rien ne remplace la page.

Quelle différence entre une erreur 404 et une erreur 500 ?

Une erreur 404 signale que la ressource demandée n'existe pas, alors que le serveur fonctionne normalement. Une erreur 500 indique au contraire que le serveur a rencontré un problème interne et n'a pas pu produire la réponse, même pour une adresse valide.

Une page d'erreur doit-elle être indexée par Google ?

Une page d'erreur ne doit pas être indexée, et le code 404 ou 410 suffit à l'exclure de l'index sans balise noindex supplémentaire. Seule une page d'erreur servie en 200 risque d'y entrer, sous forme de soft 404.

Les autres réglages d'hébergement (DNS, certificats, messagerie) sont rassemblés dans la rubrique des services internet.

Sources : documentation Apache HTTP Server 2.4 (réponses personnalisées aux erreurs, directives ErrorDocument et ProxyErrorOverride), documentation Nginx (error_page, internal, fastcgi_intercept_errors), manuel PHP (http_response_code), RFC 9110 de l'IETF pour la sémantique des codes 404, 410, 500 et 503, documentation WordPress (hiérarchie des modèles, mode de récupération), aide Google Search Central sur les soft 404.