Erreur 500 sur WordPress : la page d’erreur vous dit où chercher

Chaque page envoyée par un serveur porte un code : 200 veut dire que tout va bien, 500 que le serveur a échoué, sans dire pourquoi. Faute d’indice, on essaie alors les remèdes un à un : désactiver les extensions, changer de thème, renommer le fichier .htaccess (un fichier de réglages lu par le serveur), augmenter la mémoire.

Pourtant, l’aspect de la page d’erreur donne déjà une bonne idée de qui l’a produite : WordPress, PHP (le langage qu’exécute le serveur pour faire tourner WordPress), le serveur web (le logiciel qui envoie les pages) ou votre hébergeur. Chaque cas se règle à un endroit différent.

Ce que la page vous dit

Deux conséquences en découlent. Si vous voyez le message d’erreur critique de WordPress, laissez le .htaccess de côté, car ce message ne s’affiche que pour les erreurs PHP. À l’inverse, face à une page « Internal Server Error » en texte brut, regardez le .htaccess et les limites de l’hébergement avant de toucher aux extensions.

Les causes, selon la page

Le fichier .htaccess

Dans ce fichier, une seule ligne que le serveur ne comprend pas suffit à mettre tout le site en erreur 500. Les lignes php_value ou php_flag, parfois conseillées pour « augmenter la mémoire », ne sont comprises que par certains serveurs ; sur les autres, elles provoquent une erreur 500 (documentation LiteSpeed, en anglais). Un .htaccess qui fonctionnait chez un hébergeur peut aussi casser un site après un déménagement chez un autre, dont le serveur est plus strict.

Pour vérifier, renommez le fichier, par exemple en .htaccess.old, par FTP (un logiciel de transfert de fichiers vers le serveur) ou dans le gestionnaire de fichiers de votre hébergeur. Comme son nom commence par un point, il peut être masqué : activez l’affichage des fichiers cachés. Si le site revient, demandez à WordPress de recréer un fichier propre : Réglages, puis Permaliens, bouton « Enregistrer les modifications ». Recopiez ensuite, une à une, les autres règles de l’ancien fichier, en vérifiant le site après chacune.

Une extension, un thème, la version de PHP

C’est la piste à suivre quand WordPress affiche son message d’erreur critique ou que la page reste blanche, sauf si WordPress lui-même vient d’être mis à jour (voir la section suivante). Notre article sur l’erreur critique explique comment lire le journal d’erreurs, désactiver les extensions sans passer par l’administration, tester le thème, et que faire quand l’hébergeur change de version de PHP.

Une mise à jour de WordPress interrompue

Une mise à jour de WordPress interrompue en cours de route, par exemple parce qu’un hébergement lent a dépassé son délai, laisse un mélange d’anciens et de nouveaux fichiers. Désactiver les extensions ou changer de thème n’y changera rien, puisque la panne vient des fichiers de WordPress eux-mêmes, restés incomplets.

Pour réparer, téléchargez sur wordpress.org la version visée par la mise à jour (si WordPress vous a écrit à ce sujet, son e-mail l’indique). Envoyez ensuite par FTP ses dossiers wp-admin et wp-includes à la place des vôtres, puis les fichiers placés directement dans le dossier principal du site, sauf wp-config.php. Ne touchez pas au dossier wp-content, qui contient vos extensions, votre thème et vos images. Une mise à jour ratée peut d’ailleurs passer inaperçue longtemps : nous racontons, dans notre article sur WordPress 7, le cas d’un site resté douze jours en panne.

Les limites de l’hébergement

Certaines erreurs de la famille 500 ne viennent pas de votre site. Sur un hébergement mutualisé, c’est-à-dire un serveur partagé entre de nombreux clients, chaque compte a des plafonds : nombre de demandes traitées en même temps, mémoire, nombre de tâches. Avec CloudLinux, un système qui fixe la part de ressources de chaque client, le plafond par défaut est de 20 demandes traitées en même temps par PHP. Au-delà, le serveur répond par une erreur 508 ; quand la limite de mémoire ou de tâches est atteinte, par une erreur 500 ou 503 (documentation CloudLinux, en anglais).

Le signe typique est une erreur qui va et vient : aux heures de pointe, pendant une sauvegarde, ou quand un robot parcourt le site trop vite. Avant de désactiver dix extensions, regardez les statistiques de ressources de votre hébergeur. Chez OVHcloud, c’est le graphique de dépassement du plafond de ressources ; chez o2switch, la rubrique « Entry Process ». Certaines protections d’hébergeurs répondent aussi par une erreur 503 aux visites qu’elles prennent pour des robots, si bien qu’un outil de test peut signaler une panne que vos visiteurs ne voient pas.

Les droits des fichiers

Les droits d’un fichier fixent qui peut le lire ou le modifier. Trop larges ou incohérents, ils peuvent provoquer une erreur 500 sur certains serveurs. Les valeurs habituelles sont 755 pour les dossiers et 644 pour les fichiers ; certains hébergeurs en demandent d’autres (OVHcloud indique 705 et 604). N’utilisez jamais 777, même pour tester, car ce réglage permet à n’importe quel programme du serveur de modifier le fichier.

Une page cassée peut passer pour normale

Si l’erreur survient alors que la page a déjà commencé à s’afficher, WordPress ne peut plus montrer son message. Le visiteur reçoit une page coupée, et le serveur annonce pourtant une page normale (code 200). Un contrôle qui ne regarde que ce code ne remarque donc rien. Pour s’en apercevoir, il faut regarder la page elle-même.

Ce que fait Google pendant la panne

Face à une erreur serveur, Google passe moins souvent sur le site et n’enregistre pas la page d’erreur à la place de la vôtre. Mais si l’erreur dure, il finit par retirer vos pages de ses résultats (documentation de Google).

Un autre effet tient à WordPress lui-même. Le fichier robots.txt, qui indique aux moteurs de recherche ce qu’ils peuvent explorer, est fabriqué par WordPress à chaque demande, sauf si vous en avez déposé un vous-même à la racine du site. Quand tout le site est en erreur 500, ce fichier l’est aussi. Or, dans ce cas, Google cesse d’explorer tout le site pendant les douze premières heures de la panne, puis se fie, pendant trente jours, à la dernière version du fichier qu’il a pu lire (documentation de Google sur robots.txt). Une panne de quelques heures n’a donc pas de conséquence durable.

À l’inverse, sur le forum wpfr.net, fin 2020, un message demandait encore de l’aide pour un site en erreur depuis quatre mois. Sans surveillance, vous risquez d’apprendre la panne de votre site par un client, ou par un e-mail de la Search Console, l’outil que Google met gratuitement à la disposition des propriétaires de sites, si le vôtre y est inscrit.

Questions fréquentes

Une erreur 500 veut-elle dire que mon site est piraté ?

Pas forcément. Mais un piratage peut en provoquer une, quand le code ajouté est mal écrit ou entre en conflit avec une mise à jour. Si le journal d’erreurs cite des fichiers que vous ne reconnaissez pas, pensez à un piratage et commencez par notre guide du site piraté.

Mon hébergeur dit que le problème vient de mon site. A-t-il raison ?

Pas toujours, comme on l’a vu avec les limites de l’hébergement. Demandez-lui le journal d’erreurs de l’heure de la panne et l’état de vos ressources, puis lisez-le vous-même ou faites-le lire par un prestataire. OVHcloud, par exemple, précise dans sa documentation qu’il n’aide pas ses clients à interpréter leurs journaux.

Puis-je restaurer la sauvegarde de mon hébergeur ?

Oui, une fois la cause trouvée, et en connaissant ses limites. Chez OVHcloud, par exemple, la restauration remet en arrière tout l’espace d’hébergement, donc tous les sites qui s’y trouvent, et les points de restauration ne remontent qu’à deux semaines. Et si la panne vient d’un changement de version de PHP, le site restauré retombera dans la même erreur.