Personnaliser les pages d'erreur 404 et autres réponses

Une page d'erreur utile explique ce qui s'est passé et propose une issue, comme revenir à l'accueil ou chercher un autre contenu. Vous pouvez personnaliser les réponses du serveur depuis cPanel > Pages d'erreur. Si vous utilisez WordPress, Joomla, PrestaShop, Magento ou similaire, cette option n'a aucun effet : l'application gère ses propres pages d'erreur depuis son thème ou son modèle.

Créer la page dans cPanel

1. Ouvrez Pages d'erreur et sélectionnez le bon domaine si un sélecteur apparaît.

2. Choisissez le code à personnaliser, par exemple 404, pour une adresse qui n'existe pas.

   

3. Rédigez le contenu dans l'éditeur. Il accepte le HTML : vous pouvez donc y mettre votre logo, un message et des liens vers l'accueil ou le moteur de recherche. Les boutons du haut insèrent des balises qui affichent des données de la requête : l'URL demandée, la page de provenance (referring URL), l'IP ou le navigateur du visiteur et le nom du serveur.

   

4. Enregistrez et visitez une URL inexistante de ce domaine.

cPanel enregistre la page sous 404.shtml dans le dossier racine du domaine ; vous pouvez aussi envoyer ce fichier directement par FTP. Si vous ajoutez des images ou des styles, vérifiez leurs chemins depuis une adresse inexistante située aussi dans un sous-dossier. Les ressources de la page d'erreur doivent rester disponibles au moment où l'erreur se produit.

Conserver le bon code HTTP

L'apparence de la page et son code HTTP sont deux choses distinctes. Une 404 doit continuer à répondre 404, même si elle affiche une mise en page complète. Renvoyer 200 avec un message « introuvable » peut amener les moteurs de recherche à l'interpréter comme une soft 404.

Vérifiez l'état dans l'onglet Réseau / Network des outils du navigateur, après avoir rechargé une URL inexistante. Si vous utilisez un outil en ligne de commande, consultez les en-têtes de la réponse réelle et vérifiez les éventuelles redirections.

Pour une maintenance temporaire, utilisez une réponse 503, avec une page légère et indépendante de l'application en maintenance. Consultez le guide de maintenance avec .htaccess.

Quand le changement n'apparaît pas

Si l'application intercepte la requête avant le serveur, personnalisez la page d'erreur dans l'application ou son thème. Vérifiez aussi les caches et proxys qui pourraient afficher leur propre réponse.

Évitez d'inclure dans la page publique des chemins internes, des traces, des identifiants ou des détails du serveur. Si vous utilisez des balises qui insèrent des données de la requête, vérifiez leur traitement et n'ajoutez pas de contenu reçu du visiteur sans l'échappement adéquat.

Une page personnalisée aide le visiteur, mais elle ne corrige pas l'origine d'une erreur 500 et ne récupère pas une URL qui devrait exister. Dans ces cas, consultez les journaux ou restaurez la ressource correspondante.