Le code 500 signifie une seule chose : le serveur a rencontré une situation qu’il ne sait pas expliquer. Il ne dit ni où, ni pourquoi. Trois couches peuvent le produire — WordPress, PHP, ou le serveur web lui-même — et chacune appelle une enquête différente. Commencez donc par déterminer laquelle a répondu.

Le réflexe qui fait gagner une heure

Affichez le code source de la page d’erreur (Ctrl+U). Une page d’erreur écrite par WordPress, par Apache ou par nginx ne se ressemblent pas du tout. Vous saurez en dix secondes si PHP a seulement été atteint.

Trois signatures, trois enquêtes

La page vient de WordPress

Vous lisez « Il y a eu une erreur critique sur ce site », dans une page sobre et en français. WordPress a démarré, chargé ses extensions, puis rattrapé une erreur fatale de PHP. C’est de très loin le cas le plus fréquent, et il a sa propre marche à suivre : débloquer une erreur critique.

La page vient du serveur web

Vous lisez « Internal Server Error » en anglais, dans une page nue, sans rien de votre thème : ni votre police, ni vos couleurs, ni le moindre menu. Regardez le bas du code source. Nginx laisse presque toujours un discret <hr><center>nginx</center> ; Apache ajoute une ligne d’adresse et de version quand sa directive ServerSignature est active — beaucoup d’hébergeurs la coupent, et l’absence de signature ne prouve donc rien à elle seule.

Le signe qui ne trompe pas est ailleurs : la page du serveur est en anglais et son <html> ne porte aucun attribut de langue. Une page d’erreur produite par WordPress, elle, est traduite et s’ouvre sur <html lang="fr-FR"> — même dépouillée de votre thème.

Cette signature est une information majeure : elle prouve que la requête n’est jamais arrivée jusqu’à votre code, ou que l’interpréteur PHP a été coupé net. Inutile de désactiver des extensions, elles n’ont pas été chargées.

La page est vide

Aucun texte, aucune balise. Le diagnostic est différent encore et se conduit à part : page blanche WordPress.

Quand le serveur web répond : les trois suspects

1. Le fichier .htaccess

Premier suspect sur un hébergement Apache. Une directive inconnue, un module absent, une règle collée depuis un forum : Apache refuse de servir le répertoire entier. Le test est immédiat et réversible.

cd /chemin/vers/le/site
mv .htaccess .htaccess-desactive

Si le site revient, la cause est là. Ne remettez pas l’ancien fichier : laissez WordPress en régénérer un propre en ouvrant Réglages → Permaliens et en enregistrant sans rien changer. Reportez ensuite vos ajouts un par un.

Le fichier est masqué par un point en début de nom : pensez à activer l’affichage des fichiers cachés dans votre client FTP, faute de quoi vous conclurez à tort qu’il n’existe pas. Une règle de ce fichier qui ne fait pas planter Apache mais renvoie sans fin vers une autre adresse produit une autre erreur, la boucle de redirection.

2. Les permissions des fichiers

Sur beaucoup d’hébergements, un fichier trop permissif est refusé par sécurité — et le refus se traduit par un 500. La règle est stable : 644 pour les fichiers, 755 pour les dossiers. Un wp-config.php en 777, souvent laissé après une manipulation pressée, suffit à faire tomber le site entier.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

3. Le processus PHP lui-même

Si PHP-FPM plante ou refuse la connexion, le serveur web n’a plus d’interlocuteur. Le journal parle alors de Premature end of script headers ou d’une erreur upstream. Notez au passage la nuance de code, elle oriente : un 502 désigne un interpréteur injoignable, un 504 une requête qui a dépassé le temps imparti, un 500 une erreur interne pendant l’exécution.

Le journal du serveur, seule source de vérité

Tout le reste est de la déduction. Le journal, lui, donne le fichier et la ligne. Selon l’hébergement, il se trouve dans un fichier error_log à la racine du site, dans un dossier logs/, ou dans une rubrique dédiée du panneau d’administration.

tail -n 50 error_log

Vous cherchez la dernière ligne PHP Fatal error ou [core:error]. Son horodatage doit correspondre à votre dernier rechargement : c’est ce détail qui évite de partir sur une erreur ancienne et sans rapport.

Si rien n’est journalisé côté serveur, faites parler WordPress en ajoutant ceci dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Le journal apparaît dans wp-content/debug.log. À retirer une fois le problème réglé.

Le cas particulier de l’administration

Une erreur 500 qui ne frappe que /wp-admin/, alors que le site public fonctionne, a presque toujours la même origine : la mémoire. Les écrans d’administration en consomment davantage, en particulier la liste des extensions et l’éditeur.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Ces valeurs restent plafonnées par le memory_limit du serveur. Et rappelez-vous qu’augmenter la mémoire ne résout rien : cela achète du temps pour trouver ce qui la consomme.

Autre cas propre à l’administration : le site s’affiche, mais l’éditeur refuse d’enregistrer avec « La réponse n’est pas une réponse JSON valide ». Ce n’est pas une erreur 500, c’est l’API REST qui répond une page au lieu de JSON, et le diagnostic est celui-ci.

Ce qu’il ne faut pas faire

  • Réinstaller WordPress au hasard. Le cœur est rarement en cause, et une réinstallation menée dans l’urgence emporte parfois wp-config.php.
  • Tout modifier en même temps. Un changement, un rechargement. Sinon vous saurez que le site est réparé sans savoir par quoi — et la panne reviendra.
  • Se fier à ce que montre le navigateur. Il affiche parfois une version en cache. Testez en navigation privée, ou en lisant directement les en-têtes.

Vérifier, puis surveiller

Une fois la cause traitée, contrôlez la réponse réelle plutôt que l’apparence de la page :

curl -I https://votre-site.fr/
curl -I https://votre-site.fr/robots.txt

Les deux doivent répondre 200. Le second contrôle n’est pas anecdotique : une erreur prolongée sur robots.txt fait cesser l’exploration du site entier, bien au-delà de la page qui plantait. Le testeur d’en-têtes fait la même lecture sans terminal.

Un 500 qui dure envoie le mauvais signal

Aux yeux d’un moteur, un 500 est une panne. Répété pendant plusieurs jours, il fait reculer l’exploration puis disparaître des pages. Si la réparation demande du temps, ne laissez pas le site en erreur : passez-le explicitement en maintenance avec un statut 503. Le message aux moteurs devient « je reviens » au lieu de « je suis cassé », et la différence est réelle.