Écran blanc. Cinq caractères: 500 Internal Server Error. Le site est hors ligne, le client vous envoie des messages, et vous ne savez pas par où commencer.

L'erreur 500 est le code de statut HTTP le plus frustrant. Contrairement à une 404 («page introuvable») ou une 403 («accès refusé»), elle ne désigne pas de coupable. Elle se contente de dire «quelque chose s'est mal passé sur le serveur». Ensuite, vous êtes livré à vous-même: un plugin, un thème, du mauvais PHP, l'hébergement, un fichier .htaccess corrompu. Il existe des dizaines de possibilités, et chacune exige une correction différente.

La bonne nouvelle: une erreur 500 peut toujours être corrigée. Sans panique, sans réinstaller WordPress de zéro, et dans la plupart des cas, sans développeur. En 7 étapes (du diagnostic en 30 secondes au remplacement chirurgical des fichiers système), vous trouverez la cause et remettrez votre site en ligne. Chaque méthode inclut les fichiers, les lignes de code et les captures d'écran précis.

💡 Aperçu rapide:

• Étape 1: activez WP_DEBUG et lisez les journaux pour voir immédiatement quel fichier est en cause
• Étape 2: écartez les problèmes d'hébergement pendant que vous explorez le code
• Étape 3: corrigez .htaccess, la cause numéro un selon les statistiques de support
• Étape 4: augmentez la limite de mémoire PHP, un coupable fréquent lors du téléchargement de médias ou de la connexion à l'administration
• Étape 5: retéléversez le cœur de WordPress lorsque les fichiers sont corrompus par un échec de mise à jour automatique
• Étape 6: désactivez les plugins via FTP, une méthode qui résout plus de la moitié des cas
• Étape 7: réinitialisez le thème par défaut, une étape souvent négligée

Qu'est-ce que l'erreur 500 et d'où vient-elle

HTTP 500 est une réponse du serveur qui signifie «erreur interne». La requête du navigateur est bien arrivée, Apache ou Nginx l'a acceptée, PHP a commencé à s'exécuter, puis il a trébuché. Contrairement à une 404 ou une 403 (où le serveur répond consciemment «non»), un cinq au début du code signifie que quelque chose s'est cassé dans le script, et le serveur ne sait pas quoi.

Dans WordPress, l'erreur 500 se produit dans quatre scénarios typiques:

• Vous avez installé ou mis à jour un plugin, et il entre en conflit avec un autre code du système.
• Vous avez modifié .htaccess, et une erreur de syntaxe a fait planter Apache.
• Un script PHP a épuisé sa mémoire allouée (écran blanc avec Allowed memory size of X bytes exhausted dans les journaux).
• Les fichiers du cœur sont corrompus: échec de mise à jour automatique, transfert FTP interrompu, plugin défaillant qui a altéré les dossiers système.

Moins fréquemment: un thème avec une erreur fatale dans functions.php, des problèmes côté hébergement (surcharge, module PHP désactivé), ou un shortcode cassé provenant d'un plugin supprimé dans le contenu d'une page.

Avant de commencer: faites une sauvegarde complète de votre site. Sans sauvegarde, toute action sur les fichiers du serveur est un risque. La plupart des hébergeurs proposent un bouton de sauvegarde dans le panneau de contrôle (cPanel, ISPmanager, aaPanel) en seulement deux clics.

1. Activez WP_DEBUG et lisez les journaux

Le moyen le plus rapide de trouver la cause est de forcer WordPress à la révéler. Par défaut, le cœur masque les erreurs PHP derrière un écran blanc (c'est le mode «ne pas effrayer les visiteurs»). Mais WordPress dispose d'un mécanisme de débogage intégré: les constantes WP_DEBUG.

Activer le mode débogage

Ouvrez wp-config.php à la racine de votre site via FTP ou le gestionnaire de fichiers de votre hébergeur. Trouvez cette ligne:

1
/* That's all, stop editing! Happy blogging. */

Avant celle-ci, insérez ce bloc:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Voici ce qui se passe:

• WP_DEBUG est l'interrupteur principal; sans true, les autres constantes ne fonctionnent pas.
• WP_DEBUG_LOG dirige toutes les erreurs vers wp-content/debug.log au lieu de l'écran. Les visiteurs ne voient pas de messages inquiétants.
• WP_DEBUG_DISPLAY + @ini_set masque de force les erreurs de l'affichage des pages.

Enregistrez le fichier, rafraîchissez la page problématique sur votre site, et téléchargez wp-content/debug.log via FTP. Dans le journal, vous verrez le fichier et la ligne précis: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Désactivez le débogage après le diagnostic. Commentez ou supprimez les lignes que vous avez ajoutées. WP_DEBUG sur un site en production ralentit les performances, et debug.log peut atteindre des gigaoctets avec le temps.

2. Contactez votre hébergeur

Si les journaux sont vides ou n'ont pas été créés, l'erreur se situe peut-être côté serveur plutôt que dans le code WordPress. C'est particulièrement fréquent sur les hébergements mutualisés bon marché avec des limites de processus strictes.

Ouvrez un ticket de support et joignez trois éléments:

• L'heure exacte à laquelle l'erreur est apparue, avec le fuseau horaire du serveur.
• L'URL de la page où l'erreur se reproduit.
• Une capture d'écran de l'erreur, si disponible.

Le support vérifiera les journaux du serveur Apache ou Nginx, la charge CPU et mémoire, et les modules PHP disponibles. Les problèmes se résolvent souvent à cette étape: un administrateur d'hébergement redémarre PHP-FPM ou ajuste la limite de processus.

Comment savoir de quel côté se situe le problème

Créez un fichier appelé info.php avec une seule ligne:

1
<?php phpinfo(); ?>

Téléversez-le à la racine de votre site via FTP et ouvrez your-site.com/info.php. Si vous voyez un tableau avec les paramètres PHP, le serveur fonctionne et l'erreur est dans le code WordPress. Si vous voyez une 500, l'erreur est au niveau du serveur; communiquez cette URL au support.

Après le test, **supprimez **info.php. phpinfo() expose les versions du serveur, les chemins et les modules, créant une faille de sécurité.

3. Corrigez le fichier.htaccess

.htaccess est un fichier de configuration Apache situé à la racine de votre site. WordPress l'utilise pour les URL lisibles, les redirections et les règles de sécurité de base. Une parenthèse en trop, un conflit entre les règles de deux plugins, et tout le site tombe avec une erreur 500. Selon les statistiques des tickets de support, .htaccess s'avère être la cause numéro un.

Vérification rapide: renommez .htaccess en .htaccess_old via FTP et rafraîchissez le site. S'il fonctionne, le problème vient assurément de ce fichier.

Restaurez maintenant le fichier .htaccess: allez dans l’administration WordPress, Réglages → Permaliens et cliquez sur «Enregistrer les modifications» sans changer la structure. WordPress va générer un nouveau fichier .htaccess propre avec les règles standard:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Si vous aviez des règles personnalisées dans le .htaccess (redirections, cache, sécurité), rajoutez-les une par une et vérifiez le site après chaque ajout. Vous identifierez ainsi la ligne qui pose problème.

4. Augmenter la limite mémoire PHP

Les scripts PHP de WordPress ont besoin de RAM. Quand un plugin ou un thème demande plus que ce qui est alloué, le script s’arrête brutalement. Résultat: une erreur 500 ou une page blanche avec le message Allowed memory size of X bytes exhausted.

La limite standard sur de nombreux hébergements est encore de 64 Mo. Pour un site WordPress moderne avec une dizaine de plugins, c’est dramatiquement bas. Le minimum recommandé est de 256 Mo.

Méthode 1: via wp-config.php (recommandée)

Ajoutez ceci dans wp-config.php avant /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Cette constante écrase la limite PHP pour la partie publique du site. Pour l’administration, WordPress relève automatiquement le plafond à WP_MAX_MEMORY_LIMIT (256 Mo par défaut).

Méthode 2: via php.ini (si votre hébergeur ne vous permet pas de modifier wp-config)

Créez un fichier php.ini avec ce contenu:

1
memory_limit = 256M

Déposez-le à la racine du site ainsi que dans le dossier wp-admin/. Si cela ne suffit pas, créez ou modifiez le fichier .user.ini à la racine du site avec la même ligne.

Si aucune de ces méthodes ne fonctionne, votre offre d’hébergement limite physiquement la mémoire. Il est temps de passer à l’offre supérieure ou de changer d’hébergeur.

5. Retéléverser les fichiers cœur de WordPress

Un fichier cœur corrompu est une cause rare mais insidieuse. Un échec de mise à jour automatique, un transfert FTP interrompu, un plugin qui a modifié des fichiers système, et wp-admin ou wp-includes contient du code erroné.

Procédure:

• Téléchargez une archive ZIP WordPress vierge depuis wordpress.org.
• Décompressez l'archive sur votre ordinateur.
• Via FTP, allez à la racine de votre site et supprimez les dossiers wp-admin et wp-includes (uniquement ces deux-là; ne touchez pas à wp-content!).
• Téléversez les dossiers wp-admin et wp-includes de l'archive vierge.
• N'écrasez pas wp-content; c'est là que se trouvent vos thèmes, plugins et médias.

Les fichiers racine (wp-settings.php, index.php et autres) peuvent aussi être remplacés par ceux de l'archive vierge. Sauf wp-config.php; n'y touchez pas, car il contient vos identifiants de base de données. Après le remplacement, rafraîchissez le site; l'erreur disparaîtra si la cause était des fichiers système corrompus.

6. Désactiver les plugins

Un plugin tueur est la cause la plus probable d'une erreur 500. Vous avez mis à jour plusieurs plugins en même temps, et l'un est entré en conflit avec un autre: bonjour l'écran blanc.

Si l'administration fonctionne

Allez dans Extensions → sélectionnez tout → action groupée «Désactiver» → «Appliquer». Si l'erreur disparaît, réactivez les plugins un par un, en rafraîchissant le site après chacun. Quand vous trouvez le coupable, supprimez-le ou signalez le problème au développeur.

Si l'administration est inaccessible

Connectez-vous au serveur via FTP et renommez le dossier wp-content/plugins en plugins_off. WordPress cessera de charger tous les plugins et le site reviendra à la vie. Redonnez au dossier son nom d'origine et renommez les sous-dossiers de plugins un par un; vous trouverez ainsi le problématique sans entrer dans l'administration.

Ce qu'il faut surveiller: les plugins de cache (W3 Total Cache, WP Rocket) écrivent parfois leurs propres règles dans .htaccess et wp-config.php. Après avoir désactivé un tel plugin, l'erreur peut persister; vérifiez ces fichiers et supprimez les lignes entre les marqueurs comme # BEGIN W3TC et # END W3TC ou similaires.

7. Basculer vers le thème par défaut

Le thème actif est une source sous-estimée mais réelle d'erreurs 500. Surtout si vous avez ajouté un extrait de code avec une erreur fatale dans functions.php.

La vérification est simple: via FTP, renommez le dossier du thème actif dans wp-content/themes/ (par exemple, mytheme → _mytheme). WordPress détectera que le thème actif est manquant et basculera automatiquement vers un thème standard: Twenty Twenty-Five ou un autre thème par défaut installé sur le système.

Si le site fonctionne avec le thème par défaut, le problème vient du vôtre. Redonnez au thème son nom d'origine, ouvrez functions.php et cherchez les erreurs dans le code personnalisé. Si vous n'avez pas ajouté le code vous-même, contactez le développeur du thème.

⁉️🤔 Foire aux questions

Que faire si l'erreur 500 apparaît uniquement lors de la connexion à l'administration?

Très probablement, la limite de mémoire PHP est insuffisante spécifiquement pour l'administration, qui charge tous les plugins en même temps et est plus lourde que la partie publique. Ajoutez la ligne define( 'WP_MAX_MEMORY_LIMIT', '512M' ); dans wp-config.php; c'est une limite distincte pour l'administration, plus élevée que WP_MEMORY_LIMIT pour le front-end. Vérifiez aussi votre dossier de plugins: d'après notre expérience, les coupables les plus fréquents sont les plugins de sécurité comme Wordfence ou les plugins de sauvegarde qui consomment de la mémoire lors du chargement de la barre d'administration. Désactivez-les via FTP (le dossier plugins_off de l'étape 6) et vérifiez.

Puis-je corriger une erreur 500 sans accès FTP?

Oui. La plupart des hébergeurs proposent un gestionnaire de fichiers dans le panneau de contrôle: cPanel → Gestionnaire de fichiers, ISPmanager → Fichiers. Vous pouvez y renommer .htaccess, les dossiers de plugins et de thèmes, et modifier wp-config.php; toutes les étapes sont les mêmes. Sans aucun accès aux fichiers, votre seule option est l'équipe support de l'hébergeur. Astuce de pro: si vous avez un plugin d'extraits de code installé (Code Snippets, WPCode) et que votre dernière action a été d'ajouter un extrait, essayez d'ouvrir your-site.com/?code_snippets_safe_mode=1 ou une URL de mode sans échec similaire pour votre plugin. Cela désactive tous les extraits sans FTP.

L'erreur 500 apparaît seulement sur une page. Quelle est la cause?

Une fonction ou un shortcode cassé dans le contenu de cette page spécifique. Ouvrez la page dans l'éditeur WordPress (si l'administration fonctionne) et supprimez temporairement tous les shortcodes, blocs Gutenberg et intégrations de code. Si l'administration est inaccessible, trouvez l'article dans la base de données via phpMyAdmin (la table wp_posts), copiez le contenu dans un éditeur de texte et supprimez les shortcodes suspects. Les coupables les plus courants: les shortcodes de plugins supprimés ([dead_plugin] reste mais le plugin a disparu), du PHP cassé dans des blocs de contenu, ou des blocs Gutenberg incorrectement imbriqués.

Après la récupération, l'erreur 500 revient après quelques heures. Comment trouver la cause?

Une erreur cyclique avec un intervalle est presque toujours l'un de ces trois scénarios: une tâche cron WordPress exécute un processus défaillant de façon planifiée, un plugin de cache génère un cache corrompu, ou l'hébergeur atteint périodiquement les limites de processus (surtout sur les hébergements mutualisés économiques). Installez WP Crontrol et vérifiez la liste des tâches cron; trouvez celle qui coïncide avec l'heure du plantage. Videz le cache de votre plugin de cache. Demandez à votre hébergeur quelles sont les limites d'Entry Processes ou de PHP Workers; sur les offres mutualisées, elles sont souvent limitées à 5-10, et un pic de trafic fait tomber le site.

Dois-je passer par les 7 étapes, ou puis-je en sauter certaines?

Les deux premières étapes (WP_DEBUG et hébergement) sont diagnostiques: elles ne cassent rien et fournissent des informations. D'après notre expérience de support de sites WordPress, l'étape 3 (.htaccess) et l'étape 6 (plugins) résolvent la grande majorité des cas. Le reste concerne la mémoire PHP, le cœur corrompu et le thème. Dans une situation typique, vous résoudrez le problème à l'étape 3 ou 6 sans parcourir toute la chaîne.

Par où commencer maintenant

Ne répétez pas le scénario typique: panique → tout supprimer au hasard → aggraver la situation. Suivez l'ordre, du diagnostic à la correction:

La règle principale pour les réparations WordPress: une action, une vérification. Ne faites jamais deux corrections en même temps; vous ne saurez pas laquelle a fonctionné. Et notez exactement quel plugin ou quelle modification a causé l'erreur. La prochaine fois, vous réglerez tout en 30 secondes.