Dépannage WordPress
Erreur 500 WordPress : méthode de diagnostic par couche
HTTP 500 est une réponse générique : le détail utile se trouve dans le journal de la couche qui a échoué. La page concernée, l’heure et le dernier changement permettent d’éviter une désactivation générale et non traçable.
Ce que ce symptôme signifie réellement
Une 500 sur une seule route pointe vers son code ou ses données ; sur tout le site, PHP, serveur ou configuration globale sont plus probables.
L’écran blanc peut être le rendu visible d’une erreur fatale, alors que 500 est le statut HTTP : les deux guides ont donc des angles complémentaires.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Reproduisez une fois, relevez le request ID si disponible et corrélez journaux web/PHP/WordPress.
- Confirmer le vrai statut et la couche émettrice.
- Lire les erreurs de la minute exacte.
- Comparer fichier, extension, thème ou règle récemment changé.
- Tester le rollback limité sur staging.
Correction : appliquer une action ciblée et réversible
Corrigez la cause enregistrée ou restaurez le composant responsable ; évitez les changements simultanés.
- Restaurer le dernier composant modifié.
- Corriger erreur PHP, permission ou règle serveur confirmée.
- Réduire la requête ou tâche qui dépasse une limite.
- Réactiver les composants un par un avec vérification.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Statut 200 seulement sur les routes attendues.
- Administration, REST, cron et formulaires concernés fonctionnent.
- Aucune nouvelle fatale ou 500.
Quand arrêter et demander une intervention
Une 500 sur données, paiement ou authentification impose de geler les écritures concernées et de vérifier l’intégrité avant reprise.