Ecran blanc. Aucun message. Le back-office ne repond 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 amene 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-meme. Cet article vous montre exactement ou regarder, base sur un cas reel qu'on a traite sur un hebergement OVH mutualise avec Elementor.
Ce que vous allez apprendre
- Diagnostiquer l'erreur en 3 etapes sans toucher au code
- Identifier les 5 causes reelles (classees par frequence)
- Comprendre pourquoi Elementor, Divi et les page builders sont souvent impliques
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 repondre. C'est un message generique qui ne donne aucun indice sur la cause reelle.
WordPress est particulierement concerne parce qu'il empile des couches : le coeur WordPress, le theme, les plugins, le page builder. Chaque couche consomme de la memoire et du temps serveur. Quand la limite est atteinte, tout s'arrete.
Ce que vous voyez
- Page blanche ou message "500 Internal Server Error"
- Le site fonctionne en lecture mais plante en ecriture
- Elementor sauvegarde echoue sans explication
Ce qui se passe vraiment
- PHP depasse sa limite memoire (128M par defaut)
- Le .htaccess contient une directive incompatible
- Un plugin crashe silencieusement en arriere-plan
Ecran blanc = erreur 500
Le fameux "White Screen of Death" (WSOD) de WordPress est la meme chose qu'une erreur 500. PHP crashe avant de pouvoir generer la page, donc le navigateur affiche une page vide. Le diagnostic et les causes sont identiques.
Diagnostic en 3 etapes : trouver la cause reelle
Inutile de deviner. WordPress a un systeme de logs integre, mais il est desactive par defaut. C'est la premiere chose a activer.
1 Activer les logs d'erreur
Ouvrez le fichier wp-config.php a la racine de votre site (via FTP ou le gestionnaire de fichiers de votre hebergeur) et ajoutez ces 3 lignes avant le commentaire "C'est tout" :
WP_DEBUG_DISPLAY a false : les erreurs sont enregistrees dans un fichier, pas affichees aux visiteurs. Votre site reste propre.
2 Lire le fichier debug.log
Reproduisez l'erreur (rechargez la page, sauvegardez dans Elementor, etc.). Puis telechargez 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 memoire. C'est la cause numero 1.
3 Verifier le .htaccess
Si le debug.log ne montre rien, le probleme vient souvent du fichier .htaccess a la racine. Comparez-le avec la version par defaut de WordPress :
Toute ligne en dehors de ce bloc a ete ajoutee par un plugin (cache, SEO, securite) ou manuellement. C'est la qu'il faut chercher.
Les 5 causes reelles, classees par frequence
Apres des dizaines d'interventions sur des sites WordPress en production, voici les causes qu'on retrouve dans l'ordre. La premiere represente a elle seule plus de la moitie des cas.
#1 Memoire PHP insuffisante
C'est la cause la plus courante et la plus sournoise. Par defaut, PHP alloue 128 Mo de memoire a chaque requete. Ca peut sembler suffisant, mais faites le calcul :
- WordPress core : ~40 Mo
- Theme premium (Avada, OceanWP, Divi) : 20-50 Mo
- 20 plugins actifs : 30-80 Mo selon les plugins
- Elementor en mode edition : 60-120 Mo supplementaires
Total : 150 a 290 Mo pour une seule requete. Avec une limite a 128 Mo, PHP crashe. Le serveur renvoie une erreur 500. Rien dans WordPress ne vous previent.
Symptome revelateur : le site fonctionne en lecture (pages front-end) mais plante quand vous sauvegardez dans Elementor, modifiez une image ou accedez a certaines pages du back-office. C'est le signe classique d'un depassement memoire.
#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 instantanee.
Le piege classique : utiliser des directives php_value sur un hebergement qui tourne en PHP-FPM. Ces directives ne fonctionnent qu'avec mod_php, et la majorite des hebergeurs modernes (OVH, o2switch, Ionos) utilisent PHP-FPM.
#3 Conflit de plugins
Plus il y a de plugins actifs, plus le risque de conflit augmente. Sur le dernier site qu'on a audite, il y avait 3 plugins de consentement cookies actifs en meme temps. Chacun chargeait son propre code JavaScript et PHP. Resultat : conflit, crash, erreur 500.
Les cas les plus frequents :
- Plusieurs plugins qui font le meme travail (SEO, cache, cookies, securite)
- Un plugin d'optimisation d'images (EWWW, ShortPixel) qui consomme toute la memoire en traitant des lots
- Des plugins desactives qui laissent du bloat en base de donnees
Regle empirique : au-dela de 20 plugins actifs, faites un audit. Pas pour en supprimer aveuglément, mais pour eliminer les doublons fonctionnels et les plugins qui n'ont pas ete mis a jour depuis plus d'un an.
#4 Theme incompatible
Un theme mal code ou incompatible avec la version de PHP peut provoquer des erreurs 500. Les themes premium avec beaucoup d'options (OceanWP, Avada, Divi) chargent davantage de code et de dependances.
Test rapide : basculer temporairement sur le theme par defaut (Twenty Twenty-Four) via FTP en renommant le dossier du theme actif dans wp-content/themes/. Si l'erreur disparait, le theme est en cause.
#5 Version PHP obsolete
WordPress 6.x necessite PHP 7.4 minimum et recommande PHP 8.1 ou superieur. On voit encore des sites tourner sur PHP 7.2, voire PHP 7.0. Les fonctions depreciees provoquent des erreurs fatales que le serveur traduit en erreur 500.
Verifiez votre version PHP depuis le panel de votre hebergeur (OVH Manager, cPanel). Si vous etes en dessous de PHP 8.0, il est temps de migrer.
Cas reel : erreur 500 Elementor sur OVH mutualise
Site vitrine WordPress avec Elementor Pro. Hebergement OVH mutualise. 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 deja une limite de memoire elevee, et ca ne suffisait toujours pas. Pourquoi ?
- 58% des donnees Elementor etaient du bloat laisse par des plugins desactives (Happy Addons, Elementor Addon Elements)
- 3 plugins de cookies actifs pour le meme travail
- 7 extensions OceanWP activees mais inutilisees sur le site
- Des scripts PHP orphelins a la racine du serveur
Resultat apres intervention
6 890 parametres bloat supprimes sur 45 pages Elementor. Passage de 30 a 24 plugins actifs. Plus aucune erreur 500. Les sauvegardes Elementor fonctionnent instantanement.
Ce cas illustre bien le probleme : augmenter la memoire ne suffit pas si la cause profonde est un empilement de plugins inutiles et de donnees mortes qui saturent PHP a chaque requete. Il faut auditer, nettoyer, puis ajuster.
Les reflexes a prendre maintenant
Meme si votre site ne plante pas encore, ces points permettent d'eviter 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 a jour regulieres (WP, plugins, theme)
- PHP 8.1+ sur l'hebergeur
- Sauvegardes automatiques configurees
Questions frequentes
Pourquoi mon site affiche une erreur 500 uniquement dans Elementor ?
Elementor est gourmand en memoire PHP. En mode edition, il charge l'ensemble de la page, les widgets, les CSS dynamiques et les previews en temps reel. Si votre memory_limit est trop bas ou si trop de plugins sont actifs simultanement, PHP depasse sa limite et crashe. C'est la cause numero 1 des erreurs 500 liees a Elementor.
L'erreur 500 peut-elle venir de mon hebergement ?
Oui. Les hebergements mutualises imposent des limites strictes sur la memoire PHP, le temps d'execution et le nombre de requetes. Si vous avez optimise WordPress et que les erreurs 500 persistent, votre hebergement est probablement le facteur limitant. Un VPS ou un hebergement WordPress manage 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 probleme n'est pas la quantite mais la qualite : 3 plugins qui font le meme travail posent plus de problemes que 25 plugins bien choisis. Au-dela de 20 plugins actifs, un audit s'impose pour identifier les doublons et les plugins inutiles.
Mon site fonctionne en lecture mais plante en ecriture. Pourquoi ?
Les operations d'ecriture (sauvegarde Elementor, upload media, modification de contenu) consomment beaucoup plus de memoire que l'affichage d'une page. WordPress doit traiter les donnees, regenerer les caches, mettre a jour la base de donnees. C'est la que la limite memoire est atteinte.
L'ecran blanc WordPress et l'erreur 500, c'est la meme chose ?
Oui. Le White Screen of Death (WSOD) est la manifestation WordPress de l'erreur 500. PHP crashe avant de generer la page HTML, donc le navigateur recoit une reponse vide. Le diagnostic et les causes sont identiques dans les deux cas.
Votre WordPress affiche une erreur 500 ?
Chaque site est different : la combinaison theme + plugins + hebergement cree des situations uniques. Un diagnostic generique ne suffit pas.
Contactez-moi pour que je puisse auditer votre WordPress et identifier la cause exacte.
Demander un audit WordPress