Écran blanc. Cinq chiffres: 500. Pas de panneau d’administration, pas de site, aucun indice sur la cause. Cela vous dit quelque chose?

L’erreur interne de serveur 500 de WordPress est la plus silencieuse de toutes les erreurs. Elle ne vous dit pas ce qui a cassé, ce qui ne fait qu’aggraver la panique. Mais la réalité est banale: dans 9 cas sur 10, le coupable est une extension, un thème ou une simple ligne mal formée dans .htaccess. Le serveur n’est pas devenu fou; il a simplement rencontré du code qu’il ne peut pas exécuter.

Passons en revue les trois principaux scénarios et corrigeons-les étape par étape. Pas de panique, pas d’appel à votre hébergeur à trois heures du matin. De vos propres mains, en 15 minutes.

💡 Aperçu rapide:

• Désactivez toutes les extensions d’un coup en renommant le dossier plugins via FTP; si l’erreur disparaît, le coupable est parmi elles
• Réinitialisez .htaccess avec le modèle standard de WordPress: une directive de cache ou de redirection cassée peut instantanément mettre votre site hors service
• Activez WP_DEBUG dans wp-config.php pour voir le fichier et la ligne exacts de l’erreur fatale
• Si votre site vient d’être migré vers un nouvel hébergeur, vérifiez la version de PHP: WordPress depuis 2026 nécessite PHP 8.3 ou plus récent, et les anciennes extensions sont souvent incompatibles

Codes de réponse HTTP: ce que le serveur essaie de vous dire

Avant de plonger dans le débogage, il est utile de comprendre les bases des réponses HTTP. Le serveur répond toujours au navigateur avec un code à trois chiffres, et le premier chiffre vous indique déjà où chercher le problème.

• 1xx, informationnel: «la connexion est en cours d’établissement, veuillez patienter». Ceux-ci n’ont rien à voir avec des erreurs.
• 2xx, succès. Le fameux 200 OK signifie que le serveur a délivré la page sans problème.
• 3xx, redirections. Par exemple, 301 (redirection permanente) ou 307 (temporaire). Le navigateur se rend à la nouvelle adresse silencieusement; c’est une commande, pas une erreur.
• 4xx, erreur côté client. 404 Not Found signifie que la page a été supprimée ou l’URL mal saisie. Le serveur est en vie; le contenu n’existe tout simplement pas.
• 5xx, erreur côté serveur. C’est ici que notre territoire commence.

Parmi les codes 5xx, il y a trois «patients» principaux: 503 Service Unavailable (le serveur est surchargé; corrigez avec de la mise en cache ou en passant à un plan plus puissant), 502 Bad Gateway (PHP-FPM a planté ou perdu la connexion avec le serveur web; un problème de configuration), et enfin **500 **Internal Server Error, le plus générique et donc le plus traître. C’est de cela que nous allons parler.

Trois causes principales de l’erreur 500 et corrections étape par étape

L’erreur 500 n’est pas mystérieuse; elle est juste générique. Le serveur dit: «Je n’ai pas pu exécuter le code, mais je ne vous dirai pas lequel». Le diagnostic consiste à passer méthodiquement en revue trois suspects habituels.

1. Incompatibilité de version PHP lors de la migration d’un site

Un scénario classique: vous avez migré votre site d’un ancien hébergeur utilisant PHP 7.4 vers un nouveau avec PHP 8.3 ou 8.4. Et vous avez immédiatement obtenu un écran blanc.

La raison est simple: une ancienne extension ou un ancien thème utilise des fonctions qui ont été dépréciées ou entièrement supprimées dans les versions plus récentes de PHP. L’interpréteur refuse de les exécuter, et le site plante.

Comment corriger. Faites une sauvegarde complète des dossiers wp-content/plugins/ et wp-content/themes/. Renommez ensuite le dossier plugins en plugins_old via FTP ou le gestionnaire de fichiers de votre hébergement; cela désactive instantanément toutes les extensions d’un coup. L’erreur a-t-elle disparu? Le coupable est parmi les extensions. Restaurez-les une par une, en vérifiant le site à chaque fois. Celle après laquelle l’erreur 500 revient est le problème.

La même logique s’applique aux thèmes: passez à un thème WordPress standard (Twenty Twenty-Five ou plus récent). Le site est-il revenu à la vie? Le problème vient de votre thème; mettez-le à jour ou remplacez-le.

Ce scénario apparaît le plus souvent lors de la migration d’un site entre des hébergeurs avec des versions PHP différentes. La plupart des hébergeurs ne proposent plus PHP 7.x dans leurs panneaux de contrôle, et les exigences minimales de WordPress depuis 2026 commencent à PHP 8.3. Le vieux code sans mises à jour est condamné dans cet environnement.

2. .Htaccess corrompu, le tueur invisible

Vous avez configuré une extension de cache, activé des redirections ou ajouté vos propres règles dans .htaccess, et le site est tombé. Instantanément et sans avertissement.

Le fichier .htaccess (Apache) contrôle le serveur web à la volée: une directive est écrite, une directive est exécutée. Une erreur de syntaxe, un drapeau incorrect ou un conflit de règles, et tout le site répond par une 500.

Comment corriger. Connectez-vous à votre site via FTP ou via le gestionnaire de fichiers de votre hébergement. Trouvez .htaccess dans le dossier racine (public_html, www ou htdocs). Copiez son contenu dans un fichier texte comme sauvegarde. Remplacez ensuite tout par le modèle standard de WordPress:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

Ce code restaure les règles de réécriture d’URL standard (permaliens propres) et supprime tout le superflu. Le site devrait revenir à la vie immédiatement. Vous pourrez reconfigurer votre extension par la suite, mais vous savez maintenant où chercher si quelque chose ne va pas.

Cela n’a pas aidé? Restaurez l’ancien .htaccess depuis votre sauvegarde et passez à l’étape suivante. Sur Nginx, .htaccess ne fonctionne pas; vérifiez les logs dans /var/log/nginx/error.log, le problème se situe dans la configuration du bloc serveur.

3. Erreur fatale dans le code PHP

Une extension ou un thème appelle une fonction qui n’existe pas, passe un type d’argument incorrect ou fait référence à une classe inexistante. PHP arrête l’exécution, et vous vous retrouvez face à cette même 500.

Sans information de débogage, vous devinez à l’aveugle. Heureusement, WordPress peut afficher les erreurs; vous devez juste activer le mode débogage.

Activer WP_DEBUG

Ouvrez le fichier wp-config.php à la racine de votre site. Trouvez la ligne:

1
define( 'WP_DEBUG', false );

Remplacez false par true. Si cette ligne n’existe pas, ajoutez-la avant /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Après avoir sauvegardé, rafraîchissez la page. Au lieu d’un écran blanc, vous verrez un message comme:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

L’erreur montre: le type de problème (undefined function), le fichier fautif (wp-cache.php) et la ligne (342). C’est un pointeur direct vers l’extension qui a causé le plantage. Désactivez-la en renommant le dossier de l’extension, et le site fonctionnera à nouveau. Ensuite, mettez à jour l’extension, trouvez un remplacement ou contactez le développeur.

Assurez-vous de remettre WP_DEBUG à false après le diagnostic. Sur un site en production, afficher les erreurs aux visiteurs est inutile et peut révéler des chemins internes du serveur. Si vous voulez collecter des logs sans les afficher à l’écran, ajoutez ces lignes à wp-config.php: define( 'WP_DEBUG_LOG', true ); et define( 'WP_DEBUG_DISPLAY', false );. Les erreurs seront écrites dans wp-content/debug.log.

⁉️🤔 Foire aux questions

Puis-je simplement redémarrer le serveur pour effacer l’erreur 500?

Non. Contrairement à 503, qui disparaît souvent après un redémarrage (lorsque le pic de charge est soulagé), l’erreur 500 est causée par un problème dans le code. Redémarrer le serveur ne le corrigera pas: après le démarrage, le site rencontrera le même code cassé et plantera à nouveau.

Comment déterminer si une extension ou un thème est en cause si le panneau d’administration est inaccessible?

Connectez-vous via FTP ou via le gestionnaire de fichiers de votre hébergement. Renommez le dossier wp-content/plugins; cela désactive instantanément toutes les extensions. Le site est-il revenu à la vie? Le problème vient des extensions. Si ce n’est pas le cas, renommez le dossier du thème actif dans wp-content/themes. WordPress basculera automatiquement vers le thème par défaut. Est-il revenu à la vie? Le problème vient du thème.

Dois-je activer WP_DEBUG sur un site en production?

Non, sur un site en fonctionnement, WP_DEBUG doit être désactivé (false). Activez-le uniquement pendant le diagnostic et désactivez-le immédiatement après. Pour une collecte continue des erreurs sans les montrer aux visiteurs, utilisez la combinaison de WP_DEBUG_LOG (écrit dans wp-content/debug.log) et WP_DEBUG_DISPLAY (désactive l’affichage à l’écran).

Que faire si aucune des trois méthodes n’a aidé?

Vérifiez la limite de mémoire PHP (memory_limit dans php.ini). Parfois, les scripts n’ont pas assez de mégaoctets alloués et plantent avec une 500. Augmentez-la à 256M ou 512M. Si cela n’aide pas, contactez le support de votre hébergement: demandez-leur de vérifier les logs d’erreur du serveur (error_log pour Apache/Nginx). La cause exacte s’y trouvera, ce que vous ne pouvez pas voir depuis le côté WordPress.

Mon site est sur Nginx; que dois-je faire avec .htaccess?

Nginx n’utilise pas .htaccess. Les règles de réécriture sont spécifiées dans la configuration du bloc serveur (nginx.conf ou sites-available/your-site). Si vous êtes sur Nginx et avez obtenu une 500, vérifiez les logs dans /var/log/nginx/error.log. Un .htaccess incorrect sur un serveur Nginx ne cause pas de problèmes; il est simplement ignoré.

Comment prévenir l’erreur 500 à l’avenir?

Trois règles de prévention. Premièrement: mettez à jour régulièrement les extensions, les thèmes et le cœur de WordPress (chaque mois, pas une fois par an). Deuxièmement: ne vous accrochez pas aux extensions abandonnées; si une extension n’a pas été mise à jour depuis plus d’un an, cherchez une alternative vivante. Troisièmement: avant d’installer une extension, vérifiez la date de la dernière mise à jour et la compatibilité avec votre version de PHP sur la page de l’extension dans le répertoire WordPress. Dix minutes de maintenance par mois vous épargnent des heures de débogage d’urgence.

Que faire tout de suite si votre site est hors service avec une 500

L’erreur 500 est un puzzle avec une solution prévisible. Dans la grande majorité des cas, vous réparerez le site en quinze minutes en suivant trois étapes dans le bon ordre: désactiver les extensions, réinitialiser .htaccess, activer WP_DEBUG. L’ordre a son importance: du plus probable et le plus rapide au plus détaillé.

Si vous avez migré le site vers un nouvel hébergeur, commencez par vérifier PHP. Si vous avez configuré la mise en cache ou des redirections, commencez par .htaccess. Si vous avez mis à jour des extensions et que le site a planté, commencez par WP_DEBUG. Et si vous n’avez encore rien fait et qu’une 500 est apparue d’elle-même, passez en revue les trois étapes dans l’ordre; l’une d’elles fonctionnera presque certainement.

Ne tardez pas à diagnostiquer: chaque minute d’indisponibilité du site signifie des visiteurs et des positions dans les moteurs de recherche perdus. Ouvrez FTP, faites une sauvegarde et lancez-vous.