Erreur 500 WordPress : trouver la cause et remettre le site en ligne

Votre site renvoie une erreur 500. Il ne s'affiche plus, ou bien c'est le tableau de bord qui refuse de s'ouvrir. Le serveur a rencontré un problème qu'il ne sait pas expliquer et il vous renvoie un code d'erreur générique à la place de vos pages.

Ce guide donne la procédure complète, celle qu'on applique en intervention : lire l'écran, lire le log, identifier la cause, corriger, vérifier. Les chemins de fichiers exacts sont donnés, et la manière de revenir en arrière si une manipulation ne donne rien.

Ce que vous voyez, et pourquoi ça change tout

Il existe deux écrans d'erreur 500 complètement différents. La quasi-totalité des guides les traite comme un seul problème. C'est la première raison pour laquelle les gens perdent des heures.

Écran numéro un : la page brute du serveur

Fond blanc, police par défaut, un titre Internal Server Error et une phrase du type The server encountered an internal error or misconfiguration and was unable to complete your request. Parfois s'ajoute Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. Chrome affiche sa propre version : This page isn't working suivi de HTTP ERROR 500.

Cet écran vient d'Apache. Il signifie une chose précise : WordPress n'a jamais démarré. Le serveur web a refusé la requête avant de passer la main à PHP. Les causes possibles se limitent à la configuration : .htaccess, php.ini, .user.ini, permissions, propriétaire des fichiers, ou une panne côté hébergeur.

Conséquence directe, et personne ne le dit : votre wp-content/debug.log restera désespérément vide. Ce n'est pas que le journal ne marche pas, c'est que WordPress n'a pas eu l'occasion d'y écrire une seule ligne.

Écran numéro deux : la page WordPress

Une page sobre mais mise en forme, avec la phrase « Il y a eu une erreur critique sur ce site. » et souvent un lien vers la documentation WordPress. Si vous êtes connecté en administrateur, le message est plus long et mentionne un e-mail envoyé à l'adresse de l'administrateur.

Là, WordPress a démarré normalement, puis PHP est mort en cours de route. Le fautif est dans le code exécuté : une extension, le thème, un fichier functions.php, une limite mémoire atteinte, une incompatibilité avec la version de PHP. Le debug.log a de bonnes chances de contenir la ligne exacte, avec le nom du fichier et le numéro de ligne.

Petit piège à connaître : les pannes 2 et 3 de nos essais en laboratoire, une erreur fatale dans une extension et un épuisement mémoire, produisent exactement le même écran. Visuellement, rien ne les distingue.

C'est le log qui tranche, jamais l'écran.

En trente secondes

Trois gestes, dans cet ordre, avant de toucher à quoi que ce soit.

1. Notez lequel des deux écrans vous avez. Page brute du serveur, ou page WordPress « erreur critique ». Cette seule observation élimine la moitié des causes.

2. Faites le test du fichier statique. Créez un fichier test.txt contenant n'importe quel mot, déposez-le à la racine du site (le dossier qui contient wp-config.php, souvent public_html, www ou htdocs), puis appelez https://votre-domaine.fr/test.txt dans le navigateur.

• Le texte s'affiche : le serveur fonctionne, le problème est dans WordPress ou dans PHP.
• Vous obtenez encore une erreur 500 : ni WordPress, ni vos extensions, ni PHP ne sont en cause. C'est la configuration du serveur ou l'hébergement lui-même. Inutile de renommer quoi que ce soit dans wp-content.

Ce test prend dix secondes et il oriente tout le reste. Pensez à supprimer le fichier ensuite.

3. Regardez votre boîte mail. Depuis WordPress 5.2, quand une extension provoque une erreur fatale, WordPress envoie automatiquement à l'adresse de l'administrateur un message intitulé « Votre site rencontre un problème technique ». Ce message contient le nom du fichier fautif et un lien de connexion en mode de récupération. Si vous avez cet e-mail, vous avez déjà votre coupable et votre porte d'entrée.

Les causes, par fréquence réelle

Les pourcentages qui circulent dans les articles sur l'erreur 500 sont des opinions présentées comme des statistiques. Nous n'en inventerons pas.

Ce qui suit vient d'un dépouillement de 40 fils de discussion publics où quelqu'un décrivait une erreur 500 sur WordPress, lus en entier, réponses comprises. Premier constat : 19 fils sur 40 seulement se concluent par une cause identifiée. Plus d'une panne sur deux ne trouve jamais son explication en public, soit parce que la personne abandonne, soit parce qu'elle restaure une sauvegarde sans savoir ce qui s'était passé.

Sur les 19 cas résolus, la répartition est la suivante.

Le déclencheur, lui, est bien plus prévisible que la cause. Une mise à jour dans 8 cas, une migration ou un changement d'environnement dans 6 à 7 cas, un changement de version PHP dans 6 cas, l'installation d'une extension dans 5 cas. Et dans 6 fils, la personne affirme n'avoir strictement rien touché. Deux fois au moins, c'était vrai.

Retenez la première question à vous poser : qu'est-ce qui a changé, et quand ?

L'arbre de diagnostic

Suivez-le dans l'ordre. Chaque branche renvoie à la section de réparation correspondante.

Le fichier test.txt s'affiche-t-il ?

• Non → le serveur refuse tout. Allez voir le .htaccess de la racine, puis la section sur les directives php_value. Si le fichier .htaccess est absent ou déjà mis de côté, c'est l'hébergement : sautez à « Si rien n'a marché ».
• Oui → PHP tourne, WordPress est en cause. Continuez.

Quel écran s'affiche sur la page d'accueil ?

• La page brute du serveur → la panne se produit avant le démarrage de WordPress. Cherchez du côté de .htaccess, php.ini, .user.ini, wp-config.php et des permissions.
• « Il y a eu une erreur critique sur ce site. » → WordPress démarre puis meurt. Activez le journal et lisez-le.

Avez-vous reçu l'e-mail « Votre site rencontre un problème technique » ?

• Oui → vous avez le nom du fichier fautif. Utilisez le lien de récupération, désactivez l'extension nommée, terminé dans la plupart des cas.
• Non → activez WP_DEBUG_LOG et lisez wp-content/debug.log.

Le fichier wp-content/debug.log contient-il quelque chose ?

• Une ligne PHP Fatal error → vous avez le fichier et le numéro de ligne. Allez directement à la cause correspondante.
• Rien du tout, ou le fichier ne se crée pas → la panne est antérieure au démarrage de WordPress, ou bien elle est dans wp-config.php lui-même. Ce vide est une information, pas un échec. Passez au log du serveur.

Le front s'affiche mais seul /wp-admin renvoie 500 ? → section dédiée plus bas, le diagnostic n'est pas le même.

La réparation, cause par cause

Avant toute manipulation

Deux précautions valables pour tout ce qui suit.

Téléchargez une copie de wp-config.php et de .htaccess sur votre ordinateur avant de les modifier. Deux fichiers de quelques kilo-octets qui vous éviteront la panique si une modification aggrave les choses.

Ne changez qu'une chose à la fois, et testez entre chaque. Le vrai coût du bricolage n'est pas le temps perdu, c'est l'état inconnu dans lequel il laisse le site : après quinze modifications successives, plus personne ne sait ce qui a été touché.

Cause 1 : une directive php_value dans le .htaccess

Voilà l'avertissement le plus important de ce guide, et il vise un conseil que vous allez lire partout.

Des tutoriels très répandus, y compris ceux de gros hébergeurs, recommandent d'augmenter la mémoire PHP en ajoutant ce genre de lignes dans le .htaccess :

php_value memory_limit 512M
php_value max_execution_time 300
php_value upload_max_filesize 128M

Sur un serveur où PHP tourne en module Apache, ça fonctionne. Sur un serveur en PHP-FPM ou en CGI, qui est le mode par défaut chez OVH, o2switch, Infomaniak et Hostinger, Apache ne connaît pas la directive php_value et refuse la requête immédiatement. Résultat : une erreur 500 sur la totalité du site, y compris sur les fichiers statiques.

Nous l'avons reproduit sur une installation propre. Une seule ligne ajoutée, et voici ce qu'écrit le journal d'Apache :

[core:alert] [client x.x.x.x] /chemin/du/site/.htaccess: Invalid command 'php_value',
perhaps misspelled or defined by a module not included in the server configuration

C'est la capture montrée en tête de ce guide. Le conseil censé réparer fabrique la panne.

Comment corriger. Ouvrez le .htaccess à la racine du site. Supprimez toutes les lignes commençant par php_value ou php_flag. Enregistrez, rechargez la page. Si le site remonte, vous avez votre réponse.

Où mettre ces réglages à la place. Dans un fichier php.ini ou .user.ini à la racine selon ce qu'accepte votre hébergeur, ou depuis son panneau de gestion, qui propose presque toujours un éditeur de configuration PHP. Pour la mémoire allouée à WordPress, la constante dans wp-config.php fait le travail sans toucher au serveur :

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

La seconde constante concerne l'administration, plus gourmande que le front.

Attention, le .htaccess fautif n'est pas toujours celui de la racine. Les extensions déposent parfois le leur dans leur propre dossier. Un cas documenté : l'extension Cloudflare écrit un wp-content/plugins/cloudflare/.htaccess contenant une directive Require que certaines configurations Apache refusent, avec pour message Require not allowed here. Renommer le .htaccess de la racine ne le trouve jamais. Si vous avez accès au serveur en ligne de commande :

find . -name ".htaccess"

Autre cas réel : une extension de cache a écrit dans le .htaccess la ligne BEGIN W3TC Page Cache core en oubliant le # qui en fait un commentaire. Apache a répondu Invalid command 'BEGIN'. Le fichier n'était pas corrompu au sens habituel du terme, il lui manquait un caractère.

Le .htaccess par défaut de WordPress, si vous devez le reconstruire :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Revenir en arrière : remettez votre copie de sauvegarde. Si vous n'en avez pas et que le site est reparti, laissez le fichier tel quel, puis allez dans Réglages, Permaliens et cliquez sur « Enregistrer les modifications » : WordPress régénère le bloc proprement.

Un cas particulier à connaître : sous Nginx, LiteSpeed ou OpenLiteSpeed, le fichier .htaccess n'est pas lu du tout, ou seulement partiellement. Tous les conseils de cette section sont alors sans objet. o2switch tourne en LiteSpeed, beaucoup de serveurs privés en Nginx. Vérifiez auprès de votre hébergeur avant de passer une heure sur un fichier qui n'est pas exécuté.

Cause 2 : une erreur fatale dans une extension ou dans le thème

C'est l'écran « Il y a eu une erreur critique sur ce site. » Deux raccourcis avant de sortir le client FTP.

Le mode de récupération de WordPress. Introduit en version 5.2, il est absent de tous les guides que nous avons lus. Quand une extension provoque une erreur fatale, WordPress la met en pause et envoie à l'adresse de l'administrateur un e-mail intitulé « Votre site rencontre un problème technique ». Ce message contient :

• le nom exact du fichier qui a planté et le numéro de ligne,
• le message d'erreur PHP,
• un lien du type https://votre-domaine.fr/wp-login.php?action=enter_recovery_mode&rm_token=...

Ce lien vous connecte au tableau de bord avec l'extension fautive désactivée. Vous la supprimez ou vous la remplacez, vous quittez le mode de récupération, c'est fini. Le lien expire au bout d'un moment, et un nouvel e-mail part si l'erreur se reproduit. Si l'adresse de l'administrateur est une boîte que vous ne relevez plus, corrigez-la dans la table wp_options, ligne admin_email, via phpMyAdmin.

Si vous préférez voir l'erreur PHP brute plutôt que la page polie de WordPress, ajoutez temporairement dans wp-config.php :

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

WP-CLI, si votre hébergeur le propose. Disponible chez o2switch, Infomaniak, Kinsta, WP Engine et sur tout serveur privé, il règle en une commande ce qui prend un quart d'heure en FTP :

wp plugin list --status=active
wp plugin deactivate --all
wp theme activate twentytwentyfive
wp core verify-checksums
wp config set WP_DEBUG true --raw

La méthode manuelle, si vous n'avez ni l'e-mail ni WP-CLI. Activez d'abord le journal, en ajoutant dans wp-config.php juste avant la ligne /* C'est tout, ne touchez pas à ce qui suit ! */ :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Rechargez la page en panne, puis ouvrez wp-content/debug.log. Voici ce qu'on y trouve, tel que notre installation de test l'a écrit :

PHP Fatal error: Uncaught Error: Class "Reservation_Creneaux" not found in
/wp-content/plugins/reservation-fournee/reservation-fournee.php:9

Le chemin donne l'extension, le nombre après les deux-points donne la ligne. Vous n'avez pas besoin de désactiver les autres.

Ignorez les lignes PHP Warning et PHP Notice, elles sont presque toujours du bruit sans rapport. Cherchez PHP Fatal error et, dans le log Apache, [core:alert].

Désactiver l'extension par FTP : renommez son dossier, par exemple wp-content/plugins/reservation-fournee en reservation-fournee-off. WordPress ne la trouve plus et la désactive proprement. Pour revenir en arrière, remettez le nom d'origine et réactivez-la depuis le tableau de bord.

Si vous devez toutes les désactiver d'un coup, renommez le dossier wp-content/plugins en wp-content/plugins-off. Attention : WordPress les marque alors toutes comme désactivées, et il faudra les réactiver une par une même après avoir remis le nom. Profitez-en pour réactiver par moitiés plutôt qu'une par une : avec quarante extensions, la dichotomie demande six essais au lieu de quarante.

Pour le thème, renommez le dossier du thème actif dans wp-content/themes/. WordPress bascule sur un thème par défaut s'il en trouve un, twentytwentyfour ou twentytwentyfive. S'il n'y en a aucun, installez-en un par FTP avant de renommer.

Cause 3 : la mémoire PHP épuisée

Le message est explicite dans le journal :

PHP Fatal error: Allowed memory size of 50331648 bytes exhausted
(tried to allocate 4096 bytes) in /wp-content/...

Le premier nombre est votre limite actuelle en octets : 50331648 correspond à 48 Mo, 134217728 à 128 Mo. Divisez par 1048576 pour obtenir la valeur en mégaoctets.

Deux signes distinctifs. Le site devient lent avant de tomber, et la panne frappe par écran plutôt que partout : les pages qui listent beaucoup d'éléments cèdent en premier, l'onglet Produits d'une boutique ou la médiathèque, tandis que le reste continue de répondre.

Le piège, et il a coûté plusieurs jours à des gens dont nous avons lu les récits : augmenter WP_MEMORY_LIMIT dans wp-config.php ne sert à rien si la limite bloquante est celle du serveur. La constante WordPress ne peut jamais dépasser le memory_limit de PHP. Si votre hébergeur vous alloue 64 Mo, écrire 512M dans wp-config.php ne produit aucun effet.

L'ordre à suivre :

1. Ajoutez define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php, testez.
2. Si rien ne change, montez memory_limit côté serveur : éditeur PHP du panneau d'hébergement, fichier php.ini ou .user.ini à la racine selon ce qu'accepte l'hébergeur. Ne le faites pas dans le .htaccess, revoyez la cause 1.
3. Si la limite est déjà haute et que la mémoire se remplit quand même, ce n'est plus un problème de plafond mais de consommation : une extension qui boucle, une requête qui charge dix mille objets d'un coup. Le nom du fichier dans le log vous indique où regarder.

Pour vérifier la limite réellement appliquée, la page Outils, Santé du site, onglet Informations, section Serveur, affiche la valeur vue par PHP. C'est plus fiable que ce qu'affiche le panneau de l'hébergeur.

Cause 4 : le fichier wp-content/db.php, et les autres drop-ins

Ce cas mérite sa place parce qu'il résiste à toute la procédure habituelle.

wp-content/db.php, wp-content/object-cache.php et wp-content/advanced-cache.php ne sont pas des extensions. Ce sont des drop-ins : WordPress les charge très tôt, directement depuis wp-content/, avant même de regarder le dossier plugins. Renommer wp-content/plugins ne les désactive donc pas.

Le scénario type : quelqu'un fait le ménage dans ses extensions inactives, en supprime une vingtaine, et le site tombe. Le db.php déposé par l'une d'elles pointait encore vers un fichier qui n'existe plus. Le journal affiche :

PHP Fatal error: require_once(): Failed opening required
'/chemin/du/site/wp-content/plugins/<extension supprimée>/<fichier>.php'

Le signe décisif : le chemin cité dans l'erreur est celui d'une extension supprimée, et renommer le dossier plugins ne corrige rien.

Correction : renommez wp-content/db.php en wp-content/db.php.off. Si le site remonte, supprimez-le. Faites de même avec object-cache.php et advanced-cache.php s'ils sont présents et orphelins. Ces fichiers sont recréés automatiquement par l'extension concernée si vous la réinstallez.

Cause 5 : l'adresse du site modifiée dans les réglages

Chronologie sans ambiguïté : la panne apparaît juste après avoir cliqué sur « Enregistrer » dans Réglages, Général, et vous êtes déconnecté dans la foulée. Les deux champs « Adresse web de WordPress » et « Adresse web du site » ont reçu une valeur incorrecte, ou identique alors qu'elles devaient différer.

Trois façons de corriger, selon les accès dont vous disposez.

En base de données, avec phpMyAdmin : table wp_options (le préfixe wp_ peut être différent chez vous), lignes siteurl et home, corrigez la colonne option_value. Pas de barre oblique à la fin, et respectez le https:// si le site est en HTTPS.

Dans wp-config.php, en forçant les valeurs :

define( 'WP_HOME', 'https://votre-domaine.fr' );
define( 'WP_SITEURL', 'https://votre-domaine.fr' );

Ces deux constantes prennent le pas sur la base et grisent les champs correspondants dans l'administration, ce qui évite de recommencer l'erreur. Vous pouvez les retirer une fois la base corrigée.

Depuis le panneau de l'hébergeur, s'il propose un outil de gestion WordPress avec un champ « URL du site ».

Cause 6 : une version de PHP incompatible

La panne apparaît exactement au moment où vous changez la version de PHP depuis le panneau de l'hébergeur, ou quand l'hébergeur la change pour vous.

Le test qui tranche : si d'autres sites du même compte d'hébergement tournent correctement sur la nouvelle version, le problème est dans ce site-là, pas sur le serveur.

Revenir à la version précédente remet le site en ligne. C'est une rustine, pas une réparation : une version de PHP abandonnée par ses mainteneurs ne reçoit plus de correctif de sécurité. Cherchez ensuite ce qui n'a pas supporté la montée de version, en commençant par les extensions non mises à jour depuis longtemps, puis le thème, puis le code ajouté dans functions.php.

Un cas plus retors existe et il échappe à toute la procédure classique. Un wp-config.php ancien, écrit il y a dix ans et jamais retouché, peut à lui seul provoquer le 500 sous PHP 8, notamment par sa manière de définir ABSPATH. Désactiver les extensions, changer de thème, vider le .htaccess : rien ne le révèle, et l'erreur n'apparaît ni dans debug.log ni dans le log serveur. La solution consiste à reconstruire le fichier à partir de wp-config-sample.php, en y recopiant uniquement vos identifiants de base de données, votre préfixe de table et vos clés de sécurité.

Erreur 500 uniquement sur /wp-admin

Le site public s'affiche parfaitement, mais /wp-admin ou /wp-login.php renvoie une erreur 500. Ce cas a sa propre logique et aucun des articles de référence ne le traite, ce qui explique que Google fasse remonter des fils de forum à sa place.

La dissymétrie vous apprend déjà l'essentiel : le serveur fonctionne, PHP fonctionne, WordPress démarre. Ce qui casse est propre à l'administration. Passez en revue les pistes suivantes, dans cet ordre.

Une extension active uniquement dans l'administration. Beaucoup d'outils de sécurité, de SEO ou de sauvegarde ne chargent leur code lourd que sur les écrans d'admin. Renommez wp-content/plugins pour vérifier, puis réactivez par moitiés.

Un .htaccess propre à /wp-admin. Le fichier wp-admin/.htaccess existe parfois, déposé par une extension de sécurité ou par une protection par mot de passe mal configurée. Renommez-le.

La limite max_input_vars. L'administration envoie des formulaires bien plus volumineux que le front, en particulier les réglages de thème et les constructeurs de page. Si max_input_vars est trop bas, le traitement s'interrompt. Montez-le à 3000 côté serveur, jamais via php_value dans le .htaccess.

La mémoire allouée à l'administration. C'est WP_MAX_MEMORY_LIMIT qui s'applique ici, pas WP_MEMORY_LIMIT. Passez-la à 512M.

Une règle de pare-feu applicatif, type ModSecurity. Signature reconnaissable entre toutes : le 500 est reproductible à la demande sur une action précise, publier un contenu contenant certains mots ou certains caractères, enregistrer un formulaire particulier. Rien n'apparaît dans le log PHP, parce que l'entrée est dans le journal ModSecurity, auquel les hébergements mutualisés ne donnent pas accès. C'est un des rares cas où il faut passer par le support de l'hébergeur, en lui demandant explicitement de vérifier les règles déclenchées à l'heure précise de votre test.

Variante du même problème : le 500 n'apparaît qu'au moment d'enregistrer, jamais en lecture. Regardez max_input_vars, post_max_size, et là encore le pare-feu applicatif.

Autre variante : seuls certains écrans de l'administration tombent, les listes de produits ou de clients par exemple. C'est presque toujours la mémoire, voir la cause 3.

Un outil qui aide beaucoup ici : l'onglet Réseau des outils de développement du navigateur. Quand un écran d'admin envoie une requête en arrière-plan, la réponse du serveur contient parfois un message d'erreur détaillé que ni les logs de l'hébergeur ni WP_DEBUG n'affichent.

Si rien n'a marché

Certaines situations ne se règlent pas depuis le FTP, et il vaut mieux les reconnaître tôt que d'y perdre une journée.

Le fichier test.txt ne s'affiche toujours pas. C'est le serveur. Vérifiez que les permissions du dossier racine sont à 755, que le propriétaire des fichiers est bien celui attendu par le serveur web, et que l'espace disque du compte n'est pas saturé, cause bête et fréquente. Si tout est correct, la balle est chez l'hébergeur.

Vous ne trouvez aucun log. Certains panneaux n'en exposent pas, d'autres imposent un délai avant de les rendre consultables. Demandez alors au support les lignes correspondant à l'horaire exact d'un test que vous venez de faire, et formulez la demande en « aidez-moi à comprendre ce qui se passe » plutôt qu'en « réparez mon site ». La première obtient beaucoup plus souvent une réponse utile. Si l'hébergeur renvoie la balle, insistez ou rappelez : un cas documenté a été résolu en une heure en tombant sur un autre technicien, un autre a duré quatre jours et cinq interlocuteurs avant qu'on ne mentionne une sauvegarde disponible depuis le premier jour.

Le site est intermittent. Il remarche seul par périodes de quelques minutes. Ce n'est généralement pas WordPress mais l'infrastructure : serveurs de noms mal configurés, proxy ou CDN, ressources saturées aux heures de pointe. Vérifiez vos enregistrements DNS avec un outil externe avant de toucher au site.

Plusieurs personnes signalent la même chose le même jour. Cherchez sur core.trac.wordpress.org avant de modifier quoi que ce soit. Une régression du cœur de WordPress est rare, mais elle se corrige côté WordPress et pas chez vous.

Le site a été piraté. Contenu remplacé, redirections vers des pages inconnues, fichiers PHP au nom bizarre à la racine. Une erreur 500 peut être le symptôme d'une injection maladroite. Prudence dans l'autre sens : la présence d'un maliciel ne prouve pas qu'il soit la cause. Un cas de notre corpus a coûté à son auteur le nettoyage complet du site et l'idée de perdre trois ans de publications, alors que le journal affichait une limite mémoire à 8 Mo dès le premier jour.

Ce que nous ne faisons pas. Notre forfait couvre la panne : remettre le site en ligne et documenter la cause. Il ne couvre pas la reconstruction d'une mise en page abîmée dans un constructeur, ni la refonte d'un thème, ni le développement de fonctionnalités.

Comment éviter que ça recommence

Un site qui tombe pour une cause identifiée retombe rarement pour la même. Encore faut-il l'avoir identifiée, ce que la restauration de sauvegarde à l'aveugle ne fait pas.

Sachez où sont vos logs avant d'en avoir besoin. Repérez maintenant, à froid, où votre hébergeur expose l'error_log du serveur. Le jour de la panne, cette information vaut une heure.

Ne mettez pas tout à jour d'un coup. Le scénario qui revient le plus souvent : deux mois d'absence, quarante extensions mises à jour dans la même minute, et plus aucun moyen de savoir laquelle a cassé le site. La plupart des hébergeurs français proposent une copie de préproduction en un clic, autant s'en servir.

Gardez WP_DEBUG_LOG activé, avec WP_DEBUG_DISPLAY à false. Le journal se remplit en silence, les visiteurs ne voient rien, et le jour où ça tombe vous avez déjà l'historique. Surveillez juste la taille du fichier, un debug.log peut atteindre plusieurs gigaoctets s'il enregistre une erreur à chaque chargement de page.

Vérifiez que l'adresse e-mail de l'administrateur est relevée. C'est là qu'arrive le message du mode de récupération, celui qui vous donne le nom du fichier fautif sans aucun effort.

Testez vos sauvegardes. Une sauvegarde jamais restaurée est une hypothèse. Dans les cas que nous avons dépouillés, la restauration a échoué ou s'est révélée incomplète plus d'une fois sur trois.

Vérifiez après correction, et pas seulement la page d'accueil. Chargez une page interne, l'administration, et faites un enregistrement de contenu. Une erreur 500 peut être masquée par un cache et revenir deux heures plus tard.

Questions fréquentes

Comment corriger l'erreur 500 ?

Dans l'ordre : identifiez lequel des deux écrans s'affiche, page brute du serveur ou page WordPress « erreur critique ». Déposez un test.txt à la racine pour savoir si le serveur répond. Lisez le log, wp-content/debug.log du côté WordPress et l'error_log du côté serveur. Le log donne le fichier et la ligne. Corrigez ce point précis. Désactiver toutes les extensions à l'aveugle avant d'avoir lu le log fait perdre du temps et ne marche pas du tout dans quatre familles de causes sur dix.

C'est quoi l'erreur 500 ?

Un code de réponse HTTP qui signifie « le serveur a rencontré un problème et ne peut pas répondre ». Il ne dit rien de plus, volontairement : détailler l'erreur au visiteur reviendrait à exposer le fonctionnement interne du site. La véritable explication est écrite dans le journal du serveur, jamais dans le navigateur.

C'est quoi une erreur de serveur ?

C'est la famille des codes 5xx, ceux où la responsabilité est du côté du serveur et non du visiteur. Le 500 est le cas générique. Le 502 et le 504 apparaissent quand un service intermédiaire ne répond pas ou met trop de temps, le 503 quand le serveur est indisponible ou en maintenance, le 508 quand une limite de ressources est atteinte, ce qui est fréquent en mutualisé. Vérifiez le code réellement renvoyé avant de chercher : curl -I https://votre-domaine.fr affiche la première ligne de la réponse. Beaucoup de « 500 » sont en fait des 502 ou des 504, et le diagnostic n'a rien à voir.

Comment debugger WordPress ?

Ajoutez dans wp-config.php, avant la ligne /* C'est tout, ne touchez pas à ce qui suit ! */ :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Rechargez la page en panne, puis lisez wp-content/debug.log. Cherchez PHP Fatal error, ignorez les Warning et les Notice. Si le fichier reste vide ou ne se crée pas, ce n'est pas un échec : cela signifie que la panne se produit avant le démarrage de WordPress, et la réponse est alors dans le log du serveur, pas dans celui de WordPress.

Comment provoquer une erreur 500 ?

Sur un site de test uniquement, jamais en production. Une ligne php_value memory_limit 512M dans le .htaccess d'un serveur en PHP-FPM suffit, et c'est d'ailleurs la panne que nous avons reproduite pour illustrer ce guide. Une accolade non fermée dans le functions.php du thème actif donne le même résultat côté PHP. Ce genre de manipulation sert à vérifier que vos journaux fonctionnent et que vous savez les lire, avant d'en avoir réellement besoin.