Erreur 500 WordPress : méthode de diagnostic par couche

Une erreur 500 ne dit pas quel fichier réparer. Elle indique qu’une requête n’a pas pu aboutir côté serveur. Le bon point de départ est donc une adresse, une heure et un contexte précis, avant de modifier WordPress. Ce repère permet de suivre la requête dans les journaux et de corriger une cause identifiée, sans accumuler les changements.

Confirmer la requête qui reçoit le code 500

Relevez l’URL complète, la méthode de la requête et le statut dans les outils réseau du navigateur. Notez si l’erreur touche une page publique, une connexion, un appel REST ou une action d’administration. La définition HTTP du statut 500 reste générale : elle ne désigne ni une extension, ni la base de données, ni un problème de mémoire.

Gardez aussi l’heure avec son fuseau et, s’il existe, l’identifiant de requête fourni par l’hébergement. Une page d’erreur peut provenir de WordPress, du serveur web ou d’un intermédiaire. Son logo et son apparence donnent une piste, pas une preuve. Les codes 502, 503 et 504 ont d’autres significations : conservez le statut réellement reçu plutôt que de regrouper tous les échecs sous « erreur 500 ».

Comparez avec une autre route et une visite déconnectée, sans multiplier les soumissions. Une commande ou un paiement peut avoir été enregistré avant l’échec de la réponse. Vérifiez son état avant tout nouvel essai. Si la réponse est 200 mais que rien ne s’affiche, le diagnostic de l’écran blanc WordPress traite cette différence entre statut et affichage.

Relier les journaux serveur à l’erreur PHP

Commencez par les journaux accessibles dans l’hébergement : accès web, erreurs serveur et PHP-FPM lorsque ce moteur est utilisé. Cherchez la requête à l’heure notée, en tenant compte du fuseau propre à chaque journal. La configuration error_log de Nginx illustre pourquoi le chemin et le niveau de journalisation dépendent de l’installation. N’utilisez pas un emplacement trouvé ailleurs comme s’il était forcément celui du site.

Relevez le message utile, le fichier, la ligne et la version du composant concerné. Un chemin d’extension dans une trace peut correspondre à un appel intermédiaire : il faut lire le contexte avant d’accuser ce composant. La configuration des erreurs PHP distingue la journalisation de leur affichage. Le détail doit rester dans un emplacement privé, sans mots de passe, jetons ni données de formulaire recopiés dans un compte rendu public.

Si WordPress démarre suffisamment, sa journalisation de débogage peut compléter les traces. Elle ne remplace pas le journal du serveur si l’arrêt survient avant son initialisation. Gardez l’affichage public désactivé et limitez la durée du diagnostic. Un journal WordPress vide ne prouve donc pas que PHP fonctionne correctement ; vérifiez d’abord que le bon journal est activé et consultable.

Comparer le dernier changement sans tout désactiver

Rapprochez l’heure de début des erreurs des opérations réellement effectuées : mise à jour, déploiement, changement de version PHP, import ou règle de sécurité. Conservez les versions et les fichiers avant et après. Une proximité dans le temps oriente l’essai, mais ne suffit pas à établir la cause. Sur une copie de test, reproduisez d’abord l’erreur avec les mêmes conditions utiles.

Testez ensuite une seule hypothèse : corriger la ligne signalée ou revenir au dernier composant modifié, avec une préimage disponible. Évitez la désactivation générale des extensions et le remplacement simultané du thème, de PHP et des règles serveur. Ces gestes peuvent masquer le défaut tout en cassant une autre fonction. Si un accès de récupération est proposé, le guide de l’erreur critique WordPress précise son usage et ses limites.

La documentation des erreurs courantes de WordPress présente plusieurs pistes possibles. Choisissez celle que vos traces permettent de tester. Si elles désignent une connexion à la base, poursuivez avec le diagnostic de connexion à la base de données, au lieu de lancer une réparation ou de changer les identifiants à l’aveugle.

Vérifier les règles et le moteur PHP utilisés

Une règle de réécriture ou une directive refusée peut provoquer une erreur avant le chargement de WordPress. Pour Apache, le fonctionnement des fichiers .htaccess dépend notamment des directives autorisées dans leur contexte. Comparez le fichier réellement chargé à sa dernière version valide. Ne remplacez pas tout son contenu par un modèle : il peut contenir des protections, des redirections et des règles propres au site.

Pour Nginx ou une architecture avec proxy, faites vérifier la configuration effective et la couche qui renvoie l’erreur. Les recettes Apache ne se transposent pas automatiquement. Une validation de syntaxe doit précéder un rechargement de configuration, selon la procédure de l’hébergeur. Conservez un retour possible et vérifiez les autres sites concernés si le réglage est partagé ; une correction locale ne justifie pas une modification globale du serveur.

Vérifiez enfin la version PHP et les limites appliquées à la requête web. Elles peuvent différer de celles d’une commande en terminal. Une erreur de mémoire ou de durée appelle un contrôle de l’opération qui consomme la ressource, puis un réglage adapté si nécessaire. Augmenter toutes les limites ou ouvrir les permissions sans diagnostic ne constitue pas une correction de la cause.

Choisir un retour arrière qui respecte les données

Avant une écriture en production, vérifiez une sauvegarde récente et restaurable. La procédure de sauvegarde WordPress distingue les fichiers et la base : il faut savoir ce qui est protégé et comment le remettre en place. Pour une correction limitée, préparez aussi le retour du fichier ou du composant concerné, afin de ne pas restaurer tout le site inutilement.

Un retour de version mérite une vérification particulière si la mise à jour a modifié la structure des données. Remettre les anciens fichiers ne garantit pas leur compatibilité avec la base courante. À l’inverse, réimporter une ancienne base peut effacer les commandes, comptes ou contenus reçus depuis. Suspendez les écritures affectées si leur intégrité est incertaine, puis faites établir un retour cohérent avec leur état réel.

Appliquez le plus petit changement qui répond au diagnostic. Notez son périmètre, la version livrée et le contrôle qui permettra de le conserver ou de revenir en arrière. Si l’hébergement refuse une directive ou si l’erreur touche une configuration inaccessible, transmettez au support l’heure, la requête et un extrait de journal expurgé. Ces éléments lui permettent d’intervenir sur la bonne couche.

Valider les routes et surveiller le retour de l’incident

Rejouez d’abord la consultation qui échouait et vérifiez le statut attendu ainsi que son contenu réel. Contrôlez ensuite les parcours concernés : administration, formulaire, appel REST ou tâche planifiée, selon l’origine du défaut. Pour une écriture sensible, utilisez un environnement de test ou un cas autorisé ; ne créez pas une vraie commande simplement pour vérifier que le bouton répond.

Comparez les journaux avant et après, puis vérifiez en visite déconnectée, sur mobile et sans JavaScript lorsque le contenu doit rester accessible. Une réponse en cache peut cacher un défaut toujours présent à l’origine. Ne purgez que les éléments concernés, avec la procédure prévue, et vérifiez le résultat après leur renouvellement. Un code 200 ne suffit pas si le contenu servi est une page d’erreur.

Conservez enfin le diagnostic confirmé, la correction et le moyen de revenir en arrière. Surveillez le parcours qui déclenchait l’incident pendant une période adaptée à sa fréquence habituelle. Une réapparition demande de reprendre les traces, sans ajouter une seconde correction au hasard. Pour une panne qui reste bloquante, le service Urgence WordPress permet de cadrer l’intervention à partir de ces éléments.