Le serveur qui héberge votre site a rencontré un problème qu’il ne sait pas décrire, alors il renvoie ce code générique à la place de la page. Sur un site WordPress, la cause se trouve en général dans le site lui-même : une extension, le thème, le fichier .htaccess ou une limite de PHP. Le détail exact n’apparaît pas à l’écran, il est noté dans les journaux d’erreurs.
Pourquoi cette erreur apparaît
- Une extension ou le thème provoque une erreur PHP fatale, souvent juste après une installation ou une mise à jour.
- Le fichier .htaccess contient une règle invalide, ou une directive que le serveur ne comprend pas, comme php_value sur un hébergement en PHP-FPM.
- La mémoire ou le temps d’exécution accordés à PHP sont dépassés pendant une tâche lourde.
- La version de PHP choisie dans l’espace d’hébergement ne convient pas au code du site.
- Des droits d’accès incorrects sur des fichiers ou des dossiers, après un transfert ou une restauration.
Comment corriger le problème
Relier l’erreur à votre dernière action
Demandez-vous ce qui a changé juste avant l’apparition de l’erreur : une mise à jour, une nouvelle extension, une retouche du fichier .htaccess, un changement de version de PHP. Si l’administration répond encore, annulez ce dernier changement et rechargez une page du site.
Tester le fichier .htaccess
Une règle mal écrite dans .htaccess suffit à provoquer une erreur 500 sur toutes les pages. Donnez à ce fichier, situé à la racine du site, le nom .htaccess-old. Si le site revient, un simple enregistrement de la page Réglages > Permaliens fait réécrire à WordPress un fichier propre. Le bloc standard est celui-ci ; vos règles personnelles se réintègrent ensuite une à une.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressDésactiver les extensions sans l’administration
Renommez le dossier wp-content/plugins en plugins-off : toutes les extensions sont coupées d’un coup. Si l’erreur disparaît, rendez au dossier son nom d’origine, puis renommez les sous-dossiers un par un pour isoler la fautive. Le thème se teste de la même façon dans wp-content/themes, à condition qu’un thème par défaut soit installé.
Lire le journal d’erreurs
Le message affiché ne dit rien de la cause, le journal de débogage si : c’est un fichier où WordPress note chaque erreur PHP. Dans wp-config.php, remplacez la ligne define( ‘WP_DEBUG’, false ); par ces trois lignes (une constante déjà définie ne peut pas l’être une seconde fois), provoquez de nouveau l’erreur puis ouvrez wp-content/debug.log. Si ce fichier reste vide, consultez le journal des erreurs du serveur dans l’espace client de l’hébergeur. Remettez WP_DEBUG à false une fois la cause trouvée : debug.log peut être lu depuis le web.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Vérifier PHP et les droits des fichiers
Contrôlez la version de PHP et la valeur de memory_limit dans l’espace d’hébergement. Après un transfert, vérifiez aussi les droits : 755 pour les dossiers et 644 pour les fichiers conviennent à la plupart des hébergements. Une directive php_value placée dans .htaccess déclenche une erreur 500 sur les serveurs Apache qui exécutent PHP en PHP-FPM ou en CGI : déplacez ce réglage dans un fichier .user.ini.
Avant de renommer ou de modifier quoi que ce soit, téléchargez une copie de .htaccess et de wp-config.php, et assurez-vous d’avoir une sauvegarde complète du site (fichiers et base de données).
Un autre message d'erreur ? Collez-le dans le décodeur : il le reconnaît et vous oriente vers la bonne fiche.
Ouvrir le décodeur