Une erreur 500 WordPress signifie que le serveur n’a pas pu terminer une requête. Le code ne donne pas la cause. Repérez d’abord l’action qui échoue, puis rapprochez son heure des journaux du serveur : vous pourrez choisir une vérification ciblée plutôt que modifier le site au hasard.
Une réponse, plusieurs origines possibles
Ce guide concerne le diagnostic d’une requête HTTP 500, sur une page ou pendant une action. Si WordPress affiche déjà « Une erreur critique est survenue » et cite une erreur fatale, le guide sur l’erreur critique WordPress et le mode de récupération détaille cette autre entrée.
Où apparaît réellement l’erreur 500 ?
L’accueil peut s’ouvrir alors que l’enregistrement d’une page échoue. Ce n’est pas forcément toute l’installation qui est indisponible. Notez l’URL, le message exact et l’action effectuée avant de conclure à une panne générale.
| Situation observée | Premier repère utile |
|---|---|
| Une page publique affiche une erreur | Sa réponse HTTP, puis celle d’une autre page connue. |
| L’administration ne s’ouvre plus | L’URL d’administration en échec et l’état du site public. |
| Le constructeur refuse d’enregistrer | La requête d’enregistrement, pas seulement la page de l’éditeur. |
| Un formulaire ou une action échoue | La réponse à cette action et son éventuel enregistrement côté serveur. |
Une page portant le texte « erreur 500 » peut avoir une réponse différente. À l’inverse, une requête secondaire peut recevoir un vrai code 500 sans remplacer la page affichée. Le message visible et le statut HTTP sont deux informations à relever.
Comment voir la requête qui échoue ?
Une requête est un échange entre le navigateur et le serveur : charger une page ou enregistrer un contenu, par exemple. Pour repérer celle qui échoue dans Chrome :
- Ouvrez le panneau : clic droit sur la page → Inspecter → onglet Réseau / Network.
- Reproduisez une action sans risque en gardant le panneau ouvert.
- Repérez le statut 500 : relevez l’adresse, la méthode et l’heure de la requête. Pour un enregistrement, cherchez l’échange déclenché par le bouton.
Exemple pédagogique, pas une capture client
Le guide du panneau Réseau de Chrome explique ces colonnes. Si vous ne savez pas les interpréter, transmettez une capture expurgée au prestataire plutôt que multiplier les tests.
- Ne répétez pas un paiement ou une commande pour reproduire la panne : l’opération peut avoir été traitée avant l’erreur d’affichage.
- Ne partagez pas un export réseau brut. Il peut contenir des cookies, jetons, adresses ou données de formulaire.
- Ne créez pas de fichier public de diagnostic PHP simplement pour suivre un tutoriel ; demandez les contrôles appropriés à l’hébergeur.
Serveur ou WordPress : où chercher ?
Une erreur peut survenir avant le chargement de WordPress. L’absence de journal WordPress ne prouve donc pas l’absence de panne. Commencez par les traces que l’hébergement fournit déjà, sans activer immédiatement de nouveaux réglages.
Trois sources complémentaires
- Journal d’accès : retrouver l’URL, l’heure et le code renvoyé lorsqu’ils sont enregistrés.
- Journal d’erreur du serveur : chercher un refus de directive, un problème de traitement ou un échec de connexion au service PHP.
- Journal PHP / application : examiner les erreurs d’exécution correspondant à la même action, si celle-ci a atteint PHP.
Les noms, emplacements et durées de conservation dépendent de l’offre. Si un CDN ou un proxy est présent, demandez quelle couche a produit la réponse et s’il existe un identifiant de requête. Une page de marque de l’hébergeur est un indice, pas une preuve que WordPress est hors de cause.
Les outils WP_DEBUG et WP_DEBUG_LOG peuvent compléter certaines investigations. La documentation de débogage WordPress les destine au test et au développement. Ne les activez pas à l’aveugle sur le site public et n’exposez pas les erreurs aux visiteurs.
Comment relier une trace à la bonne requête ?
Un journal peut contenir de nombreux avertissements anciens ou sans rapport. Pour éviter une fausse piste, rapprochez l’heure avec son fuseau, l’URL ou l’action et le message correspondant. Un simple avertissement ne démontre pas qu’il a provoqué le code 500.
Extrait fictif et simplifié, sans données client.
- Requête
- 09:18:42 UTC
POST /action-exemple
Statut 500 - Journal PHP
[09:18:42 UTC] PHP Fatal error: Uncaught Error: Call to undefined function fonction_exemple() in …/plugins/extension-exemple/action.php:42- Comment le lire
- undefined function : une fonction appelée est introuvable.
action.php:42 : fichier et ligne où l’erreur est signalée, pas forcément sa cause initiale.
Dans cet exemple, l’erreur PHP correspondante oriente vers le code exécuté. Pour savoir comment lire le fichier et la ligne sans accuser trop vite une extension, poursuivez avec le diagnostic d’une erreur fatale WordPress. Si le serveur rejette une directive avant PHP, la piste est différente.
Gardez les traces originales dans un espace protégé. Pour échanger, masquez les secrets, données personnelles et chemins internes inutiles. Notez aussi les actions déjà tentées : elles peuvent expliquer pourquoi les traces suivantes diffèrent des premières.
Quelle correction tester selon les indices ?
Le code 500 seul ne justifie ni une désactivation générale, ni un changement de version PHP. Choisissez un test relié à une trace et prévoyez son retour arrière. Le tableau aide à orienter le travail, pas à poser automatiquement un diagnostic.
| Indice observé | Vérification ciblée |
|---|---|
| Directive refusée dans un fichier .htaccess | Sur un serveur qui le lit, comparer la directive citée, les règles autorisées et la dernière modification. Préserver les règles spécifiques. |
| Erreur fatale PHP avec composant cité | Vérifier sa version, ses dépendances et sa compatibilité ; préparer un test sur copie. |
| Limite mémoire ou ressources explicitement atteinte | Examiner l’opération et la consommation avec l’hébergeur avant d’ajuster une limite. |
| Erreur au passage vers le service PHP | Faire vérifier sa disponibilité et sa configuration par l’hébergeur, sans remplacer les fichiers WordPress au hasard. |
Le cas du fichier .htaccess
La documentation Apache précise que les directives autorisées dépendent de la configuration du serveur. Un tutoriel prévu pour Apache ne se transpose pas tel quel à Nginx, qui n’utilise pas ce fichier.
- Identifier le serveur : demandez confirmation à l’hébergeur si l’architecture n’est pas claire.
- Conserver le fichier actuel : il peut porter des redirections, restrictions ou réglages propres au site.
- Tester la piste précise : une régénération des permaliens ne recrée pas toutes les règles personnalisées.
Avant une modification, vérifiez la sauvegarde et la possibilité de restauration. La configuration externe de l’hébergement doit aussi être conservée. Si la panne suit une mise à jour WordPress, comparez les versions et changements réels ; ne lancez pas une nouvelle série de mises à jour pour essayer.
Quand contacter l’hébergeur ou un prestataire ?
Contactez l’hébergeur lorsque les traces serveur manquent, qu’un incident d’infrastructure est suspecté ou que le traitement PHP échoue. Si les traces concernent le thème, une extension ou du code personnalisé, un dépannage de site internet peut prendre le relais. Les deux intervenants peuvent devoir travailler ensemble.
Une demande exploitable, sans partager les secrets
- Contexte : domaine, URL ou action concernée, heure exacte et fuseau.
- Constat : code HTTP observé, pages encore accessibles et caractère intermittent éventuel.
- Indices : extrait de journal expurgé ou identifiant de requête, lorsqu’il existe.
- Historique : dernière modification connue et manipulations déjà tentées.
- Question : quelle couche renvoie le 500 et quelles traces permettent de vérifier la piste ?
Les accès se transmettent par le canal sécurisé convenu, avec un compte dédié lorsque c’est possible. N’envoyez pas le mot de passe principal dans un formulaire public. Si vous n’avez ni reprise fiable ni accès aux journaux, mieux vaut cadrer l’intervention que suivre une suite de commandes trouvées en ligne.
Comment vérifier que l’erreur 500 est corrigée ?
Rejouez le parcours qui échouait, dans un scénario maîtrisé. Le retour de l’accueil ne valide pas un enregistrement, une soumission ou un espace client. Examinez la réponse attendue et le résultat réel dans l’application.
La validation suit le parcours
Code 500 constaté
Trace correspondante conservée
Résultat attendu confirmé
Nouvelles traces examinées
Pour un formulaire, contrôlez aussi la réception de la notification : une soumission qui ne renvoie plus d’erreur ne prouve pas que le mail arrive. Le guide WordPress n’envoie pas de mail détaille ce second contrôle.
Conservez un compte rendu court : cause établie ou encore incertaine, modification appliquée, tests et suite prévue. Une maintenance WordPress peut organiser les contrôles convenus après l’incident, sans garantir l’absence de panne. Présentez-moi votre problème →
Questions fréquentes sur l’erreur 500 WordPress
Vider le cache suffit-il à réparer une erreur 500 ?
Pas nécessairement. Le cache peut masquer un état récent ou conserver une réponse selon sa configuration. Comparez les réponses et les traces avant de conclure. Une purge peut aider à vérifier l’état réel, mais elle ne corrige pas à elle seule un problème de code ou de configuration serveur.
Pourquoi l’erreur apparaît-elle seulement de temps en temps ?
La panne peut dépendre de l’action, des données, d’une ressource disponible ou d’un service appelé. Relevez plusieurs occurrences avec leurs heures et leur contexte, sans provoquer de charge supplémentaire. Une période sans erreur ne prouve pas que la cause a disparu.
Une erreur 500 signifie-t-elle que le site a été piraté ?
Non. Ce code ne démontre pas une compromission. Des comptes inconnus, redirections suspectes ou fichiers modifiés sans explication demandent une investigation distincte. Préservez les traces et ne restaurez pas à l’aveugle une copie dont l’intégrité n’est pas établie.
Faut-il changer d’hébergement pour résoudre le problème ?
Pas sur le seul constat d’un code 500. Une erreur de configuration ou de code peut être déplacée avec le site et réapparaître. Identifiez les limites ou défaillances démontrées, puis comparez les solutions avec leurs contraintes de migration.
Sources et documentation
Ces références expliquent les mécanismes utilisés dans le diagnostic. Les réglages exacts restent ceux de votre hébergement et de l’application concernée.
