Erreur 500 sur WordPress : trouver la cause et réparer.« Internal Server Error », « HTTP ERROR 500 » : la marche à suivre.

1. Faites une copie et notez ce qui a changé juste avant.
2. Lisez le journal des erreurs du serveur : la ligne la plus récente désigne la cause.
3. Renommez .htaccess ; si le site revient, régénérez-le par Réglages, puis Permaliens.
4. Désactivez les extensions, puis le thème, en renommant leur dossier par FTP.
5. Vérifiez la version de PHP, la mémoire et le temps d'exécution.
6. Remettez des droits normaux (755 et 644), ou remplacez les fichiers de WordPress.
7. Journal vide et erreur partout ? Le problème est chez l'hébergeur : appelez-le.

Dans ce guide

• Les formes de l'erreur 500
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• Ce que nous ferions à votre place
• Questions fréquentes

• « Internal Server Error », suivi de « The server encountered an internal error or misconfiguration and was unable to complete your request » : la page d'erreur d'Apache, le serveur de la plupart des hébergements mutualisés.
• « Cette page ne fonctionne pas » avec HTTP ERROR 500 : la façon dont Chrome et Edge l'affichent quand le serveur n'envoie aucune page.
• « 500 Internal Server Error » sur une page sobre : un serveur nginx.
• « Il y a eu une erreur critique sur ce site » : c'est aussi une erreur 500, interceptée par WordPress. Notre guide de l'erreur critique WordPress la traite en détail.

Dans tous les cas, le serveur dit seulement qu'il a échoué. La raison, elle, n'est écrite qu'à un endroit : son journal des erreurs.

1. Un fichier .htaccess abîmé : une règle ajoutée par une extension de cache, de sécurité ou de redirection, que le serveur refuse. Le journal parle d'Invalid command, de bad flag delimiters, ou de Request exceeded the limit of 10 internal redirects pour une boucle de réécriture.
2. Une extension ou le thème, quand l'erreur de PHP survient trop tôt pour que WordPress l'intercepte : PHP Fatal error, avec le chemin du fichier en cause.
3. Une version de PHP incompatible, après un changement fait par l'hébergeur ou par vous : du code ancien qui ne passe plus sous PHP 8, ou du code récent qui exige PHP 8.2 ou plus.
4. La mémoire ou le temps de PHP dépassés : Allowed memory size exhausted ou Maximum execution time exceeded, souvent sur une importation, une sauvegarde ou une page de boutique très lourde.
5. Des droits de fichiers refusés : certains serveurs refusent d'exécuter un fichier PHP modifiable par tous (droits 777), avec un message du type is writeable by group. Ou une directive non acceptée dans un fichier php.ini ou .user.ini.
6. Une panne chez l'hébergeur, ou des fichiers de WordPress incomplets après une mise à jour coupée.
7. Plus rarement, une intrusion : un .htaccess qui contient des redirections vers des sites inconnus ou de longues lignes illisibles a été modifié par un intrus. C'est une intrusion repérée : suivez notre guide du site WordPress piraté.

1. Une copie, et ce qui a changé

Sauvegardez l'état actuel depuis l'espace de l'hébergeur, ou téléchargez par FTP wp-content, wp-config.php et .htaccess. Notez ce qui a changé juste avant l'erreur : une extension installée, une mise à jour, un réglage de cache ou de redirection, une nouvelle version de PHP.

2. Lisez le journal des erreurs du serveur

C'est l'étape qui fait gagner le plus de temps. Sous cPanel, ouvrez Métriques, puis Erreurs : les dernières erreurs du site s'y affichent, la plus récente en haut. Cherchez aussi un fichier error_log à la racine du site ou dans wp-admin. Sous Plesk, ouvrez Journaux. Rechargez la page en erreur juste avant, pour que la bonne ligne soit en tête, et rapprochez-la des causes ci-dessus. Le journal de WordPress complète celui du serveur : dans wp-config.php, define('WP_DEBUG', true); et define('WP_DEBUG_LOG', true);, avec define('WP_DEBUG_DISPLAY', false);, écrivent les erreurs de PHP dans wp-content/debug.log.

3. Mettez le fichier .htaccess de côté

À la racine du site, renommez .htaccess en .htaccess.off. C'est un fichier caché : dans FileZilla, affichez-le par le menu Serveur, puis « Forcer l'affichage des fichiers cachés » ; dans le gestionnaire de fichiers de cPanel, par Paramètres, puis « Afficher les fichiers cachés ». Si l'accueil revient, le coupable est trouvé. Dans l'administration, ouvrez Réglages, puis Permaliens, et cliquez sur « Enregistrer les modifications » sans rien changer : WordPress récrit son propre bloc. Le voici, s'il faut le recréer à la main :

# 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 WordPress

Reprenez ensuite, une à une, les règles utiles de l'ancien fichier (redirections, cache, sécurité), en rechargeant le site après chacune. Celle qui ramène l'erreur 500 est à corriger, ou à confier à l'extension qui l'a écrite.

4. Désactivez les extensions, puis le thème, par FTP

Si le journal désigne wp-content/plugins/un-dossier, renommez ce dossier en ajoutant .off : WordPress désactive l'extension. Sans indice, renommez le dossier plugins entier, ouvrez la page Extensions pour que WordPress les désactive toutes, redonnez au dossier son nom, puis réactivez-les une à une. Même méthode pour le thème, dans wp-content/themes : WordPress passe sur un thème par défaut s'il en reste un.

5. Vérifiez la version de PHP

Dans l'espace de l'hébergeur (sous cPanel : « Sélectionner une version de PHP » ou « MultiPHP Manager »), regardez si la version a changé récemment. Revenir à la précédente remet souvent le site en ligne, le temps de mettre à jour l'extension ou le thème trop ancien. Puis visez une version suivie : WordPress recommande PHP 8.3 ou plus, et PHP 8.1 ne reçoit plus de correctif de sécurité.

6. Relevez la mémoire ou le temps, si le journal le dit

Dans wp-config.php, define('WP_MEMORY_LIMIT', '256M');. Dans les réglages de PHP de votre espace, quand l'offre le permet, memory_limit (256M) et max_execution_time (120, par exemple). Si une seule opération dépasse, une importation ou une sauvegarde, découpez-la plutôt que de tout relever.

7. Remettez des droits normaux

Les droits recommandés par WordPress : 755 pour les dossiers, 644 pour les fichiers, 440 ou 400 pour wp-config.php (certains hébergeurs demandent 640). Un clic droit, puis « Droits d'accès au fichier » dans FileZilla, ou « Modifier les autorisations » dans le gestionnaire de fichiers. Retirez aussi toute ligne ajoutée récemment dans un php.ini ou un .user.ini.

8. Remplacez les fichiers de WordPress, ou appelez l'hébergeur

Si le journal désigne wp-admin ou wp-includes, remplacez ces deux dossiers et les fichiers de la racine (sauf wp-config.php) par ceux de la même version, téléchargée sur fr.wordpress.org. Si le journal est vide et que même un simple fichier test.html déposé à la racine renvoie une erreur 500, le problème est chez l'hébergeur : contactez-le avec l'heure de l'erreur et l'adresse de la page.

9. Une fois le site revenu

Remettez WP_DEBUG à false, supprimez wp-content/debug.log et le fichier .htaccess.off s'il ne sert plus, puis vérifiez les pages qui comptent : accueil, formulaire de contact, panier et paiement si vous vendez en ligne.

• Erreur critique WordPress : « Il y a eu une erreur critique sur ce site » : trouver l'extension ou le thème fautif, et le désactiver.
• Page blanche WordPress : Rien ne s'affiche, sur tout le site, dans l'administration ou sur une seule page.
• Erreur de connexion à la base de données : WordPress ne joint plus la base où sont rangés vos contenus : identifiants, serveur, tables.
• Erreurs Cloudflare 520, 521 et 522 : Cloudflare répond, mais le serveur qui héberge le site, non.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 20 octobre 2026. Manipulations vérifiées le 20 octobre 2026 sur WordPress 7.1 ; elles valent aussi pour WordPress 6, et pour PHP 8.1 à 8.5.

• WordPress, le fichier .htaccess de WordPress (bloc de réécriture par défaut).
• WordPress, déboguer WordPress (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY).
• WordPress, les erreurs courantes de WordPress.
• WordPress, historique des versions (7.1.3 et 7.0.7 publiées le 6 octobre 2026) et configuration recommandée (PHP 8.3 ou plus).
• PHP, versions encore suivies, consulté le 20 octobre 2026.

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.