Le plugin qui revient en tête de tous les comparatifs « meilleurs plugins 404 WordPress » s’appelle aujourd’hui Smart Custom 404 Error Page. Son créateur, Peter Raschendorfer, a arrêté de le maintenir en octobre 2023, un détail que ces listes omettent systématiquement alors qu’il détermine si l’extension mérite encore sa place sur un parc de sites clients. Pour définir une page 404 personnalisée : créez une page normale via Pages > Ajouter, activez le plugin, puis sélectionnez cette page dans Apparence > Page d’erreur 404. Le code retourné reste un vrai 404, sans redirection déguisée. Le reste, la partie que les listicles sautent, se joue avant l’installation.
Vérifier que le plugin est toujours maintenu
NerdPress a repris la maintenance du plugin en septembre 2024, un an après le retrait de Raschendorfer.
« Peter Raschendorfer a décidé de se consacrer à d’autres projets et a mis le plugin en retraite en octobre 2023 » (NerdPress, annonce de reprise, 17 septembre 2024).
La version 11.4.8, publiée le 2 octobre 2024, corrige une vulnérabilité XSS potentielle signalée via une divulgation responsable. Sur un site isolé, ce genre de flottement passe inaperçu. Sur un parc de 15 ou 20 sites clients, un plugin WordPress gratuit resté sans mise à jour pendant un an est une porte ouverte : les CVE non corrigées s’accumulent et Patchstack, qui suit les divulgations de vulnérabilités via son programme Zero Day, référence régulièrement des extensions à l’arrêt comme point d’entrée. Avant d’installer, vérifiez trois choses : la date de la dernière mise à jour sur la fiche WordPress.org, le nombre d’installations actives (le plugin en comptait plus de 100 000 au moment du retrait de son créateur) et l’intégrité des fichiers eux-mêmes avec wp plugin verify-checksums 404page depuis WP-CLI. La commande compare chaque fichier installé aux checksums publiés par WordPress.org et signale toute modification suspecte. Le même outil vérifie aussi les fichiers du cœur WordPress via wp core verify-checksums, utile après une migration ou une mise à jour groupée sur plusieurs sites. Deux minutes de vérification avant un déploiement en masse.
Installer Smart Custom 404 Error Page
Une fois la vérification faite, l’installation ne prend effectivement que quelques secondes. Depuis le tableau de bord, ouvrez Extensions > Ajouter, cherchez « Smart Custom 404 Error Page », cliquez sur Installer puis Activer. C’est tout. Aucun réglage supplémentaire à ce stade : le plugin ajoute simplement une nouvelle option dans le menu Apparence, sans surcharger l’interface d’administration ni ajouter de widget superflu.
Créer la page et la définir comme page 404
Créez une page comme n’importe quelle autre, avec le titre et le contenu de votre choix : un message clair et un lien vers l’accueil suffisent. Rendez-vous ensuite dans Apparence > Page d’erreur 404 et sélectionnez cette page dans la liste déroulante. Sauvegardez. Un prérequis passe souvent inaperçu : la structure des permaliens doit être réglée sur autre chose que « Simple » dans Réglages > Permaliens, sinon WordPress ne déclenche jamais le mécanisme de détection 404 que le plugin exploite. Sans ce réglage, la page personnalisée ne s’affiche jamais, même correctement configurée dans l’écran du plugin. Le plugin ajoute aussi un shortcode, [pp_404_url page], qui affiche l’URL exacte ayant provoqué l’erreur directement dans le contenu de la page.
Vérifier le code HTTP réel malgré le cache
Une page 404 qui s’affiche correctement à l’écran ne garantit pas que le serveur renvoie le bon code. La documentation Search Console distingue une erreur « Introuvable (404) » réelle d’un soft 404, qui renvoie un code 200 alors que le contenu affiché dit « page introuvable ». La recommandation officielle est explicite sur ce point : ne jamais rediriger ces URL vers la page d’accueil ni servir un faux contenu avec un statut 200. Pour vérifier concrètement, lancez curl -I https://votredomaine.fr/url-inexistante depuis un terminal et contrôlez la première ligne de la réponse. Elle doit afficher HTTP/1.1 404. Sur un hébergement managé avec cache full-page actif, ce test doit se faire après une purge complète : le plugin s’intègre nativement avec WP Super Cache et W3 Total Cache, qui excluent du cache les URL en erreur pour éviter de resservir une ancienne version. Un serveur qui tourne sous Nginx FastCGI Cache plutôt que sous un plugin de cache classique n’hérite pas de cette exclusion automatique : elle se configure manuellement dans le bloc location de la conf Nginx. Un cache géré en amont au niveau du CDN edge peut aussi continuer de servir une réponse mise en cache avant même l’installation du plugin. WebPageTest affiche la ligne de statut HTTP complète dans son onglet Détails et reste le moyen le plus rapide de trancher.
Le piège des thèmes de blocs et du template 404.html
Un thème FSE (Full Site Editing) embarque son propre template 404.html dans le dossier templates du thème. WordPress applique une hiérarchie de templates stricte et ce fichier peut passer devant la page choisie dans les réglages du plugin selon la version du thème installée. Le symptôme revient sur les sites migrés vers un thème de blocs récent : la page 404 est bien configurée dans le plugin. WordPress affiche pourtant encore l’ancien template par défaut, celui que WP 6.x charge en priorité tant que le fichier reste présent dans le thème. La solution consiste à ouvrir l’éditeur de site, chercher le template nommé 404 dans la liste des templates disponibles, puis soit le supprimer soit vérifier qu’il pointe bien vers le contenu défini par le plugin. Un thème classique bâti en PHP, sans architecture de blocs, ne rencontre pas ce conflit.
Le plugin est en place, la page personnalisée répond en 404 réel, le cache ne la contourne plus. Le tri des erreurs listées dans le rapport d’indexation de Search Console, entre celles qui viennent d’un lien interne cassé et celles qui n’ont jamais eu vocation à exister, est un chantier distinct qui se traite dans la durée.
