Écran blanc. Aucun message. Le back-office ne répond plus. Le client appelle en panique parce que son site "ne marche plus". C'est le quotidien de l'erreur 500 sur WordPress, et c'est probablement ce qui vous amène ici.
La bonne nouvelle : ce n'est presque jamais grave. La mauvaise : WordPress ne vous dit rien d'utile. Il faut aller chercher l'information vous-même. Cet article vous montre exactement ou regarder, base sur un cas réel qu'on a traite sur un hébergement OVH mutualisé avec Elementor.
Ce que vous allez apprendre
- Diagnostiquer l'erreur en 3 étapes sans toucher au code
- Identifier les 5 causes réelles (classées par fréquence)
- Comprendre pourquoi Elementor, Divi et les page builders sont souvent impliqués
Ce que l'erreur 500 vous dit (et ce qu'elle cache)
L'erreur 500 signifie "Internal Server Error". En clair : PHP a crashe et le serveur n'a pas su quoi répondre. C'est un message générique qui ne donne aucun indice sur la cause réelle.
WordPress est particulièrement concerné parce qu'il empile des couches : le coeur WordPress, le theme, les plugins, le page builder. Chaque couche consomme de la mémoire et du temps serveur. Quand la limite est atteinte, tout s'arrête.
Ce que vous voyez
- Page blanche ou message "500 Internal Server Error"
- Le site fonctionne en lecture mais plante en écriture
- Elementor sauvegarde échoue sans explication
Ce qui se passe vraiment
- PHP dépasse sa limite mémoire (128M par défaut)
- Le .htaccess contient une directive incompatible
- Un plugin crashe silencieusement en arrière-plan
Écran blanc = erreur 500
Le fameux "White Screen of Death" (WSOD) de WordPress est la même chose qu'une erreur 500. PHP crashe avant de pouvoir générer la page, donc le navigateur affiche une page vide. Le diagnostic et les causes sont identiques.
Diagnostic en 3 étapes : trouver la cause réelle
Inutile de deviner. WordPress a un système de logs intégré, mais il est désactivé par défaut. C'est la première chose à activer.
1 Activer les logs d'erreur
Ouvrez le fichier wp-config.php à la racine de votre site (via FTP ou le gestionnaire de fichiers de votre hébergeur) et ajoutez ces 3 lignes avant le commentaire "C'est tout" :
WP_DEBUG_DISPLAY a false : les erreurs sont enregistrées dans un fichier, pas affichées aux visiteurs. Votre site reste propre.
2 Lire le fichier debug.log
Reproduisez l'erreur (rechargez la page, sauvegardez dans Elementor, etc.). Puis téléchargéz le fichier wp-content/debug.log via FTP. Cherchez les lignes qui contiennent Fatal error.
134 217 728 bytes = 128 Mo. Cette ligne vous dit que PHP a atteint sa limite de mémoire. C'est la cause numéro 1.
3 Vérifier le .htaccess
Si le debug.log ne montre rien, le problème vient souvent du fichier .htaccess à la racine. Comparez-le avec la version par défaut de WordPress :
Toute ligne en dehors de ce bloc a été ajoutée par un plugin (cache, SEO, sécurité) ou manuellement. C'est la qu'il faut chercher.
Les 5 causes réelles, classées par fréquence
Après des dizaines d'interventions sur des sites WordPress en production, voici les causes qu'on retrouve dans l'ordre. La première représente a elle seule plus de la moitié des cas.
#1 Mémoire PHP insuffisante
C'est la cause la plus courante et la plus sournoise. Par défaut, PHP alloue 128 Mo de mémoire à chaque requête. Ça peut sembler suffisant, mais faites le calcul :
- WordPress core : ~40 Mo
- Thème premium (Avada, OceanWP, Divi) : 20-50 Mo
- 20 plugins actifs : 30-80 Mo selon les plugins
- Elementor en mode édition : 60-120 Mo supplémentaires
Total : 150 à 290 Mo pour une seule requête. Avec une limite à 128 Mo, PHP crashe. Le serveur renvoie une erreur 500. Rien dans WordPress ne vous prévient.
Symptôme révélateur : le site fonctionne en lecture (pages front-end) mais plante quand vous sauvegardez dans Elementor, modifiez une image ou accédez à certaines pages du back-office. C'est le signe classique d'un dépassement mémoire.
#2 Fichier .htaccess corrompu
Le .htaccess est un fichier de configuration Apache que WordPress, les plugins de cache et les plugins SEO modifient en permanence. Une mauvaise directive et c'est l'erreur 500 instantanée.
Le piège classique : utiliser des directives php_value sur un hébergement qui tourne en PHP-FPM. Ces directives ne fonctionnent qu'avec mod_php, et la majorité des hébergeurs modernes (OVH, o2switch, Ionos) utilisent PHP-FPM.
#3 Conflit de plugins
Plus il y a de plugins actifs, plus le risque de conflit augmenté. Sur le dernier site qu'on a audite, il y avait 3 plugins de consentement cookies actifs en même temps. Chacun chargeait son propre code JavaScript et PHP. Résultat : conflit, crash, erreur 500.
Les cas les plus fréquents :
- Plusieurs plugins qui font le même travail (SEO, cache, cookies, sécurité)
- Un plugin d'optimisation d'images (EWWW, ShortPixel) qui consomme toute la mémoire en traitant des lots
- Des plugins désactivés qui laissent du bloat en base de données
Règle empirique : au-delà de 20 plugins actifs, faites un audit. Pas pour en supprimer aveuglément, mais pour éliminer les doublons fonctionnels et les plugins qui n'ont pas été mis à jour depuis plus d'un an.
#4 Thème incompatible
Un thème mal codé ou incompatible avec la version de PHP peut provoquer des erreurs 500. Les thèmes premium avec beaucoup d'options (OceanWP, Avada, Divi) chargent davantage de code et de dépendances.
Test rapide : basculer temporairement sur le thème par défaut (Twenty Twenty-Four) via FTP en renommant le dossier du thème actif dans wp-content/themes/. Si l'erreur disparaît, le thème est en cause.
#5 Version PHP obsolète
WordPress 6.x nécessite PHP 7.4 minimum et recommande PHP 8.1 ou supérieur. On voit encore des sites tourner sur PHP 7.2, voire PHP 7.0. Les fonctions dépréciées provoquent des erreurs fatales que le serveur traduit en erreur 500.
Vérifiez votre version PHP depuis le panel de votre hébergeur (OVH Manager, cPanel). Si vous êtes en dessous de PHP 8.0, il est temps de migrer.
Cas réel : erreur 500 Elementor sur OVH mutualise
Site vitrine WordPress avec Elementor Pro. Hébergement OVH mutualisé. 30 plugins actifs. L'erreur 500 apparaissait uniquement lors de la modification d'images dans Elementor. Le front-end fonctionnait parfaitement.
Ce qu'on a trouve en activant WP_DEBUG_LOG :
536 870 912 bytes = 512 Mo. Le site avait déjà une limite de mémoire élevée, et ça ne suffisait toujours pas. Pourquoi ?
- 58% des données Elementor étaient du bloat laisse par des plugins désactivés (Happy Addons, Elementor Addon Elements)
- 3 plugins de cookies actifs pour le même travail
- 7 extensions OceanWP activées mais inutilisées sur le site
- Des scripts PHP orphelins à la racine du serveur
Résultat après intervention
6 890 paramètres bloat supprimés sur 45 pages Elementor. Passage de 30 à 24 plugins actifs. Plus aucune erreur 500. Les sauvegardes Elementor fonctionnent instantanément.
Ce cas illustre bien le problème : augmenter la mémoire ne suffit pas si la cause profonde est un empilement de plugins inutiles et de données mortes qui saturent PHP à chaque requête. Il faut auditer, nettoyer, puis ajuster.
Les réflexes a prendre maintenant
Même si votre site ne plante pas encore, ces points permettent d'éviter la plupart des erreurs 500 avant qu'elles n'arrivent :
- WP_DEBUG_LOG active en permanence
- memory_limit a 256M minimum
- max_input_vars a 5000 (Elementor/Divi)
- Moins de 20 plugins actifs
- Aucun doublon fonctionnel entre plugins
- Mises à jour régulières (WP, plugins, theme)
- PHP 8.1+ sur l'hébergeur
- Sauvegardes automatiques configurées
Questions fréquentes
Pourquoi mon site affiche une erreur 500 uniquement dans Elementor ?
Elementor est gourmand en mémoire PHP. En mode édition, il charge l'ensemble de la page, les widgets, les CSS dynamiques et les previews en temps réel. Si votre memory_limit est trop bas ou si trop de plugins sont actifs simultanément, PHP dépasse sa limite et crashe. C'est la cause numéro 1 des erreurs 500 liées à Elementor.
L'erreur 500 peut-elle venir de mon hébergement ?
Oui. Les hébergements mutualisés imposent des limites strictes sur la mémoire PHP, le temps d'exécution et le nombre de requêtes. Si vous avez optimisé WordPress et que les erreurs 500 persistent, votre hébergement est probablement le facteur limitant. Un VPS ou un hébergement WordPress managé offre davantage de marge.
Combien de plugins puis-je avoir avant de risquer une erreur 500 ?
Il n'y a pas de nombre magique. Le vrai problème n'est pas la quantité mais la qualité : 3 plugins qui font le même travail posent plus de problèmes que 25 plugins bien choisis. Au-delà de 20 plugins actifs, un audit s'impose pour identifier les doublons et les plugins inutiles.
Mon site fonctionne en lecture mais plante en écriture. Pourquoi ?
Les opérations d'écriture (sauvegarde Elementor, upload media, modification de contenu) consomment beaucoup plus de mémoire que l'affichage d'une page. WordPress doit traiter les données, régénérer les caches, mettre à jour la base de données. C'est là que la limite mémoire est atteinte.
L'écran blanc WordPress et l'erreur 500, c'est la même chose ?
Oui. Le White Screen of Death (WSOD) est la manifestation WordPress de l'erreur 500. PHP crashe avant de générer la page HTML, donc le navigateur reçoit une réponse vide. Le diagnostic et les causes sont identiques dans les deux cas.
Lire aussi
Votre WordPress affiche une erreur 500 ?
Chaque site est différent : la combinaison thème + plugins + hébergement crée des situations uniques. Un diagnostic générique ne suffit pas.
Contactez-moi pour que je puisse auditer votre WordPress et identifier la cause exacte.
Demander un audit WordPress