L’erreur 500 est un message du serveur, pas de WordPress : « j’ai demandé à PHP de produire cette page, ça s’est mal passé, je n’ai rien à afficher ». Le détail existe, mais il est volontairement masqué.
La démarche pour le retrouver est toujours la même, et elle est méthodique plutôt que technique. En pratique, la cause se trouve presque toujours parmi cinq suspects : une extension, le thème, le fichier .htaccess, une limite PHP, ou une mise à jour interrompue.
Réponse rapide
Activez la journalisation dans wp-config.php : define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true);, define('WP_DEBUG_DISPLAY', false);, puis lisez wp-content/debug.log et le journal d’erreurs de l’hébergeur. Pour reprendre l’accès à l’administration, renommez wp-content/plugins par FTP. Testez ensuite le .htaccess en le renommant, vérifiez la mémoire PHP et la version de PHP. Réactivez les extensions une par une jusqu’à retrouver l’erreur.
Rendre l’erreur visible
Sans message d’erreur, vous en êtes réduit aux suppositions. Trois sources, par ordre d’utilité.
Le journal WordPress
Dans wp-config.php, avant la ligne « That’s all, stop editing » :
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );
La dernière ligne évite d’afficher l’erreur aux visiteurs. Rechargez la page fautive, puis ouvrez wp-content/debug.log.
Supprimez ce fichier et remettez WP_DEBUG à false une fois terminé : il est accessible publiquement tant qu’il est là.
Le journal du serveur
Une erreur fatale qui survient avant que WordPress ne démarre n’apparaîtra jamais dans debug.log. Le journal d’erreurs de votre hébergeur, lui, l’enregistre. C’est la source à consulter quand le journal WordPress reste vide.
L’email de récupération
WordPress envoie automatiquement un message à l’adresse d’administration, contenant l’extension concernée, le fichier et la ligne — avec un lien de connexion en mode récupération. Vérifiez cette boîte, et les indésirables.
Les cinq suspects habituels
1. Une extension
De loin la cause la plus fréquente, en particulier après une mise à jour. Pour isoler : renommez wp-content/plugins en plugins-off par FTP. Toutes les extensions sont désactivées et l’administration redevient accessible. Renommez à l’identique, puis réactivez une par une en testant entre chaque.
Aucune donnée n’est perdue : les réglages vivent en base, pas dans les fichiers.
2. Le thème
Si l’erreur persiste sans aucune extension, renommez le dossier du thème actif : WordPress bascule sur un thème par défaut. Cela suppose qu’un thème par défaut soit présent — ne les supprimez jamais tous.
Cause classique : une modification directe de functions.php, avec une accolade manquante ou une fonction déclarée deux fois.
3. Le fichier .htaccess
Une directive non supportée, ou un fichier corrompu par une extension de cache ou de sécurité, provoque un 500 sur tout le site. Test : renommez .htaccess en .htaccess-off. Si le site revient, régénérez-le en enregistrant à nouveau les permaliens depuis l’administration.
4. La mémoire PHP
Message Allowed memory size exhausted. Ajoutez dans wp-config.php : define( 'WP_MEMORY_LIMIT', '256M' );. Si cela règle le problème, interrogez-vous : une consommation anormale révèle souvent une extension qui charge des données sans limite.
5. La version de PHP
Un changement de version côté hébergeur peut rendre un thème ou une extension ancienne inexécutable. Revenez temporairement à la version précédente pour confirmer, puis mettez à jour ce qui doit l’être. Rester sur une version de PHP obsolète n’est pas une option durable : elle ne reçoit plus de correctifs de sécurité.
La marche à suivre, dans l’ordre
- Sauvegardez fichiers et base avant toute manipulation.
- Identifiez ce qui a changé : mise à jour, nouvelle extension, modification du thème, intervention de l’hébergeur.
- Activez la journalisation et lisez les journaux.
- Testez le
.htaccess: trente secondes, et cela écarte ou confirme une cause entière. - Désactivez toutes les extensions par FTP si l’administration est inaccessible.
- Réactivez une par une, avec un test entre chaque.
- Testez le thème par défaut si le problème persiste.
- Vérifiez mémoire et version de PHP.
- Nettoyez :
WP_DEBUGàfalse, suppression dedebug.log, remise en place du.htaccess.
Un seul changement à la fois, toujours. Modifier trois choses puis constater que ça remarche ne vous apprend rien.
Sur une boutique, quelques précautions en plus
Si le site est une boutique WooCommerce, l’urgence est double : chaque minute coûte des commandes, et certaines manipulations peuvent affecter des paiements en cours.
Ne restaurez pas une sauvegarde à la légère. Vous écraseriez les commandes passées depuis. Sur une boutique active, c’est la manipulation la plus coûteuse de toutes.
Vérifiez ce qui se passe côté paiement. Un site en erreur peut continuer de recevoir des notifications de paiement sans pouvoir les traiter. Une fois rétabli, contrôlez les commandes restées en attente.
Testez une commande complète avant de considérer l’incident clos. Une page d’accueil qui s’affiche ne prouve rien.
Le message générique « une erreur critique est survenue » relève de la même famille de problèmes, avec quelques spécificités WooCommerce : je le détaille dans l’article dédié.
Prévenir la prochaine panne
Une erreur 500 est le symptôme d’un processus, pas d’un accident isolé. Les sites qui tombent sont ceux où l’on met à jour directement en production, sans sauvegarde vérifiée ni possibilité de retour arrière.
Quatre habitudes suppriment la majorité du risque : une préproduction pour tester les mises à jour, des sauvegardes dont on a vérifié la restauration, une adresse d’administration réellement consultée — c’est elle qui reçoit l’email de récupération — et des mises à jour espacées, jamais toutes en même temps un vendredi soir.
C’est le contenu même d’un accompagnement de maintenance : les mises à jour testées ailleurs, et quelqu’un qui connaît déjà le site le jour où il tombe.
Checklist
- Sauvegarder fichiers et base avant toute manipulation
- Noter ce qui a changé juste avant la panne
- Activer
WP_DEBUG_LOGavecWP_DEBUG_DISPLAYà false - Lire
debug.loget le journal d’erreurs de l’hébergeur - Tester en renommant
.htaccess - Désactiver les extensions par FTP puis les réactiver une par une
- Tester avec un thème par défaut
- Vérifier mémoire et version de PHP
- Remettre
WP_DEBUGà false et supprimerdebug.log
Questions fréquentes
Vais-je perdre du contenu en désactivant les extensions par FTP ?
Non. Contenus et réglages sont en base de données. Renommer le dossier plugins ne fait que les désactiver ; tout revient tel quel après réactivation.
Le site fonctionne mais l’administration est en 500.
Situation fréquente, et moins grave : vos visiteurs ne voient rien. L’origine est alors une extension ou un écran d’administration précis. Le mode récupération est ici particulièrement adapté.
L’erreur apparaît par intermittence.
Cela oriente vers une limite de ressources — mémoire, temps d’exécution, nombre de processus — plutôt que vers une erreur de code, qui serait constante. Regardez ce qui tourne en arrière-plan : tâches planifiées, imports, sauvegardes automatiques.
Mon hébergeur dit que le problème vient de mon site.
C’est souvent vrai, mais pas toujours : un changement de version de PHP ou une limite de ressources modifiée côté serveur produit exactement les mêmes symptômes. Demandez-lui simplement ce qui a changé récemment sur votre hébergement.
Mon site est en panne maintenant.
Écrivez-moi sur WhatsApp en précisant le message exact et ce qui a changé avant. Je vous dis rapidement si je peux intervenir. Voir la page dépannage e-commerce.