Erreur HTTP 500 sur WordPress : identifier la panne et rétablir le site

Choisissez le parcours adapté à votre panne

Une erreur HTTP 500 signifie que le serveur n’a pas terminé la demande. Elle peut venir d’une extension, d’une faute dans un fichier PHP, des règles Apache ou d’une ressource épuisée. Le numéro ne permet pas de choisir la réparation à lui seul. En revanche, votre dernier changement, les accès qui fonctionnent et une ligne de journal permettent souvent d’avancer rapidement.

Ce guide propose trois parcours. Commencez par celui qui correspond à votre situation ; vous n’avez pas à effectuer toutes les manipulations. Après chaque essai, contrôlez la même page en lecture seule et notez le résultat, sans renvoyer un formulaire ou un paiement. Une seule modification à la fois permet de comprendre ce qui a rétabli le site. Les parcours fichiers concernent WordPress autohébergé avec les accès nécessaires. Sur WordPress.com, utilisez seulement les outils accessibles dans votre offre ; en multisite, faites valider les changements partagés par l’administrateur réseau.

L’administration s’ouvre encore : commencez par l’approche 1. Vous pourrez désactiver l’extension suspecte ou isoler un conflit avec le plugin Troubleshooting.
Le site et l’administration sont inaccessibles : passez à l’approche 2. Le gestionnaire de fichiers de l’hébergement ou SFTP permet de neutraliser une extension ciblée et de lire les erreurs PHP.
Le journal cite .htaccess, Invalid command ou une règle de réécriture : utilisez l’approche 3, réservée à la configuration Apache décrite plus bas.
Le message contient Allowed memory size ... exhausted : consultez ensuite la section sur la mémoire. Augmenter une limite sans ce constat n’est pas une méthode de diagnostic.

Préparez une sauvegarde et un test reproductible

Avant une modification de fichier, téléchargez son original sur votre ordinateur. Pour les manipulations d’extensions ou de thème, vérifiez qu’une sauvegarde récente des fichiers et de la base est disponible. Une copie de wp-config.php contient des informations sensibles : gardez-la dans un dossier privé, jamais sous un nom comme wp-config.php.bak dans le répertoire public du site.

Si votre hébergement propose une préproduction, utilisez-la pour les essais qui affecteraient les visiteurs. Il s’agit d’une copie avec sa propre base. Neutralisez les paiements réels, les courriels et les automatismes externes dès sa création, avant sa première visite. Si vous intervenez directement sur une boutique, évitez de reproduire un paiement : une commande peut avoir été enregistrée avant que sa réponse se termine en erreur.

Le résultat de référence doit être simple : une adresse précise, une heure et ce que vous obtenez. Une image qui s’affiche encore ne prouve pas que WordPress fonctionne ; elle peut être servie sans PHP ou provenir d’un cache.

Ouvrez l’accueil, un article connu et votre adresse habituelle d’administration. Relevez les pages qui échouent et celles qui répondent.
Dans le navigateur, ouvrez F12, puis Réseau. Rechargez une page publique et sélectionnez la requête de type Document correspondant à son adresse. Vérifiez que son statut est bien 500. Si la panne apparaît après un clic ou un enregistrement, examinez la requête Fetch/XHR déjà enregistrée, sans rejouer l’action : le document principal peut répondre 200.
Notez le dernier changement : extension mise à jour, extrait ajouté, version PHP modifiée ou règle de redirection enregistrée.
Dans l’hébergement, repérez les sauvegardes et le gestionnaire de fichiers. Téléchargez l’original du fichier que vous allez modifier, ou notez l’état de l’extension concernée.
Conservez le même navigateur et la même adresse pour le premier contrôle. Comparez ensuite avec une fenêtre privée pour détecter une différence de session ou de cache.

Approche 1 : désactiver une extension depuis l’administration

Cette méthode convient si /wp-admin/ fonctionne et si la panne suit l’activation ou la mise à jour d’une extension. Elle ne nécessite aucun code. Commencez par l’extension désignée par le journal ou par le dernier changement, plutôt que par une désactivation générale.

Une désactivation agit sur le site réel et peut retirer une fonctionnalité visible. Pour une extension de paiement, de connexion ou de protection d’accès, faites l’essai sur la préproduction ou pendant un créneau prévu. Le bouton Désactiver ne correspond pas au bouton Supprimer : vous cherchez à arrêter temporairement le chargement du code, pas à désinstaller ses données.

Si la page revient, vous avez identifié une dépendance probable. Il reste à vérifier s’il s’agit d’un défaut de cette extension ou d’un conflit avec un autre composant. Gardez son nom et sa version pour chercher une correction. Une réactivation immédiate, sans modification, peut simplement faire revenir l’erreur.

Ouvrez Extensions → Extensions installées.
Retrouvez l’extension suspecte et notez sa version ainsi que son état actuel.
Cliquez sur Désactiver uniquement pour cette extension. Ne lancez pas une mise à jour simultanément.
Rechargez l’adresse qui produisait le 500, puis ouvrez un article et l’administration.
Si rien ne change, réactivez l’extension pour revenir à l’état initial de cet essai, puis consultez le journal avant de tester une autre piste.
Si le site revient, laissez l’extension désactivée le temps de tester une version corrigée sur une copie. Vérifiez les fonctions qu’elle assurait avant de considérer la réparation comme terminée.

Isoler un conflit avec le plugin Troubleshooting

Quand l’administration fonctionne mais qu’aucun composant ne se détache, je recommande Troubleshooting pour mener un essai dans votre session. Ce plugin gratuit reprend le mode de dépannage auparavant présent dans Health Check. Il permet de tester un ensemble réduit d’extensions et un thème par défaut sans chercher à modifier la configuration vue par les visiteurs ordinaires.

Ce n’est ni une copie de votre base ni un bouton de réparation automatique. N’y créez pas de commande et n’y modifiez pas du contenu pour tester : les écritures restent réelles. Les extensions indispensables et certaines couches de cache ne sont pas isolées comme les extensions ordinaires. Une préproduction reste préférable pour un site marchand ; contrôlez aussi le rendu déconnecté si vous utilisez ce mode.

Au moment de cette révision, l’ancien Health Check est annoncé comme déprécié dans son dépôt officiel. Utilisez la fiche du nouveau plugin indiquée dans l’encadré, puis vérifiez les versions WordPress et PHP demandées avant l’installation. Si WordPress ne démarre plus du tout, passez directement à SFTP : un plugin ne pourra pas vous rendre un écran qui ne se charge pas.

Dans Extensions → Ajouter une extension, recherchez exactement Troubleshooting. Vérifiez l’auteur Marius L. J. et le lien vers sa fiche officielle, puis installez et activez le plugin.
Ouvrez Outils → Santé du site, puis l’onglet Troubleshooting, parfois traduit par Dépannage. Activez le mode de dépannage proposé.
Dans cette session, ouvrez la page qui échouait. Si elle fonctionne avec la configuration minimale, le conflit devient une piste exploitable.
Réactivez votre thème habituel depuis les commandes du mode de dépannage, puis testez à nouveau. Vous distinguez ainsi l’effet du thème de celui des extensions.
Activez ensuite les extensions une par une dans ce même mode, en rechargeant la page après chacune. Notez celle dont le retour fait réapparaître le 500.
Quittez le mode avec Disable Troubleshooting Mode dans le tableau de bord ou la barre d’administration. Si l’écran est inaccessible, supprimez uniquement les cookies de ce domaine dans le navigateur, puis reconnectez-vous : cela retire aussi la session de dépannage.
Comparez avec une fenêtre privée. Si le cache conserve le rendu de dépannage, purgez le cache concerné, puis vérifiez de nouveau. Appliquez ensuite la correction ciblée sur le site normal ou sa préproduction.

Approche 2 : neutraliser l’extension suspecte par SFTP

Si WordPress ne permet plus de vous connecter, utilisez le gestionnaire de fichiers de votre hébergement ou SFTP avec vos accès habituels. Ouvrez le dossier du bon domaine : vous devez y retrouver wp-admin, wp-includes et wp-content. Ne supposez pas que tous les comptes utilisent un dossier nommé public_html.

Le principe est de renommer temporairement le dossier d’une seule extension. WordPress ne retrouve plus son fichier principal et cesse de le charger. Cela affecte également les visiteurs. Sur un réseau multisite, faites intervenir l’administrateur réseau : le dossier peut être partagé par plusieurs sites. Choisissez une extension identifiée par le journal, ou celle qui vient d’être modifiée ; ne renommez pas tout wp-content pour tenter votre chance.

Le chemin wp-content/plugins/extension-exemple ci-dessous est un modèle : remplacez extension-exemple par le nom réellement présent dans le journal et dans vos fichiers. Cette procédure ne s’applique pas telle quelle aux extensions indispensables dans mu-plugins, ni aux fichiers spéciaux de cache comme object-cache.php. Si le journal désigne ces éléments, utilisez les instructions propres à leur fournisseur.

Entrez dans wp-content/plugins/ et repérez le dossier exact de l’extension impliquée. Notez son nom avant de le modifier.
Renommez, par exemple, extension-exemple en extension-exemple.pause. Conservez tous ses fichiers ; ne les supprimez pas.
Rechargez l’adresse défaillante et essayez d’ouvrir l’administration.
Si le site revient, connectez-vous et ouvrez Extensions → Extensions installées pendant que le dossier porte encore son nom temporaire. WordPress peut alors constater l’absence du fichier et enregistrer la désactivation.
Remettez ensuite le nom original du dossier. Vérifiez dans Extensions installées que l’extension reste désactivée ; ne cliquez pas encore sur Activer.
Si l’essai n’a rien changé, restaurez le nom original avant de passer à une autre piste. Si WordPress a déjà enregistré la désactivation, réactivez aussi l’extension depuis l’administration lorsqu’elle redevient disponible.
Pour une extension confirmée en cause, recherchez une version corrigée et testez-la sur une copie. Rétablir le nom du dossier avant que la désactivation soit enregistrée peut la remettre immédiatement en service et faire revenir la panne.

Activer un journal PHP sans exposer les erreurs

Commencez par le journal PHP ou le journal d’erreurs proposé dans le panneau d’hébergement. Rechargez une page publique qui produit le 500 et cherchez l’événement à la même heure. Pour une opération sensible, utilisez l’erreur déjà enregistrée. Si ce journal ne contient pas le détail utile et que vous avez accès à wp-config.php, la journalisation WordPress peut aider à identifier une erreur survenant pendant son chargement.

Le code utilise un chemin privé à adapter. Le dossier doit exister, être accessible en écriture au processus PHP et se trouver hors de toutes les racines publiques du compte. Demandez à l’hébergeur ce chemin si vous ne pouvez pas le déterminer ; ne copiez pas littéralement COMPTE. Sur un hébergement qui ne permet pas ce stockage privé, utilisez son journal intégré au lieu de créer un fichier exposé aux visiteurs.

Placez les constantes avant la ligne de fin d’édition de wp-config.php, et avant l’instruction require_once ABSPATH . 'wp-settings.php'; lorsqu’elle est présente : elle démarre WordPress. Les valeurs true et false n’ont pas de guillemets. Si les constantes existent déjà, modifiez-les sur place : deux définitions du même nom ne constituent pas une configuration valide de dépannage.

Téléchargez une copie privée de wp-config.php et notez les valeurs actuelles de WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY.
Faites créer ou choisissez le dossier privé approprié, puis remplacez le chemin d’exemple dans le code.
Remplacez les définitions existantes ou ajoutez les lignes manquantes avant le démarrage de WordPress. N’ajoutez pas une nouvelle balise <?php dans le fichier.
Enregistrez, rechargez une seule fois la page en erreur et consultez le fichier journal par SFTP ou depuis le panneau.
Relevez le message fatal, le chemin et la ligne concernés. Un avertissement plus ancien n’est pas nécessairement la cause du 500.
Si aucun événement n’apparaît, vérifiez le chemin, les droits d’écriture et le journal serveur. Une panne avant l’initialisation de WordPress ne sera pas capturée par ce réglage. Retirez ensuite le diagnostic temporaire comme indiqué à la fin du guide.

// Remplacer ce chemin par un emplacement privé réel, accessible à PHP.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/COMPTE/private-logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Traduire la ligne du journal en action concrète

Les trois lignes suivantes sont des exemples fictifs de messages, pas un relevé de votre serveur. Leur intérêt est de montrer ce qu’il faut repérer : le type d’erreur, le composant désigné et parfois la quantité de mémoire. Ne recopiez pas ces lignes dans WordPress ; elles servent à lire un résultat.

Un chemin vers une extension indique où l’échec est remonté, mais pas toujours l’auteur du défaut initial. Par exemple, une extension peut appeler une fonction qui dépend d’une autre extension désactivée. Après isolement, comparez donc aussi les dépendances annoncées et les dernières mises à jour. Conservez quelques lignes de contexte, sans transmettre les cookies, jetons ou données de visiteurs que le journal pourrait contenir.

Uncaught Error avec un chemin wp-content/plugins/... : testez la désactivation ciblée de l’extension concernée, puis recherchez la correction ou la dépendance manquante.
Parse error après une modification de fichier : restaurez ce fichier depuis sa copie précédente, ou corrigez la syntaxe comme expliqué dans la section dédiée.
Allowed memory size ... exhausted : vérifiez la limite effective et le traitement concerné avant de passer à la section mémoire.
Une ligne Apache contenant .htaccess et une directive refusée : passez au parcours suivant. Si elle vise une ligne extérieure au bloc WordPress, corrigez cette ligne précise ; remplacer les permaliens ne la supprimera pas.

PHP Fatal error: Uncaught Error: Call to undefined function exemple() in /site/wp-content/plugins/extension-exemple/plugin.php:42
PHP Parse error: syntax error, unexpected token "}" in /site/wp-content/themes/theme-exemple/functions.php on line 120
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

Approche 3 : réparer le bloc WordPress de .htaccess

Utilisez cette méthode si l’hébergement emploie Apache avec les règles .htaccess et si le journal ou votre dernière modification désigne ces règles. Le code ci-dessous convient à un site WordPress simple installé à la racine du domaine. Il ne convient pas à Nginx, à un réseau multisite, ni à une installation dont WordPress ou ses adresses publiques nécessitent des chemins particuliers.

L’objectif est de réparer le bloc de réécriture WordPress, pas d’effacer la configuration du serveur. Un même fichier peut contenir des protections d’accès, des règles de cache, des redirections et le choix du moteur PHP. Conservez ces directives extérieures. Si une copie du fichier juste avant la panne existe, comparez d’abord la ligne récemment modifiée : un retour ciblé sera souvent plus simple.

L’exemple doit remplacer le bloc compris entre # BEGIN WordPress et # END WordPress, marqueurs inclus. N’empilez pas deux blocs. Si le fichier contient une structure personnalisée ou aucun bloc identifiable, utilisez la configuration de votre installation au lieu de l’écraser. Le résultat attendu est le retour de l’accueil et des adresses internes ; si seule l’erreur change, poursuivez le diagnostic à partir de ce nouveau message.

Dans le gestionnaire de fichiers, activez l’affichage des fichiers cachés et ouvrez la racine documentaire du domaine.
Téléchargez .htaccess sur votre ordinateur et conservez cette copie privée pour le retour arrière.
Vérifiez qu’il s’agit bien d’un site simple à la racine sur Apache. Identifiez les deux marqueurs du bloc WordPress.
Remplacez uniquement ce bloc par l’exemple ci-dessous. Gardez toutes les directives extérieures et enregistrez le fichier sous son nom exact .htaccess.
Ouvrez l’accueil, un article avec une adresse lisible et /wp-admin/. Le contrôle doit porter sur ces trois chemins.
Si le 500 reste présent ou s’aggrave, remettez l’ancien bloc depuis la copie. Ne restaurez le fichier complet que si aucune autre modification n’est intervenue depuis. Consultez la nouvelle ligne du journal pour savoir si Apache refuse une autre directive ou si PHP échoue ensuite.
Si le site revient, passez à la vérification des permaliens. Ne réintroduisez pas une règle récemment ajoutée avant d’avoir corrigé sa syntaxe ou confirmé qu’elle est autorisée.

# 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

Régénérer les permaliens lorsque l’administration fonctionne

Si l’accueil est revenu mais que les articles affichent une erreur 404, WordPress peut avoir besoin de réécrire ses règles de permaliens. Cette action sert à rétablir la correspondance entre les adresses publiques et WordPress ; elle ne réparera pas une extension qui provoque encore une erreur fatale PHP.

La structure d’adresse doit rester identique. Changer toutes les adresses d’articles pour tester créerait un second problème, notamment pour les liens déjà partagés. Sur Nginx, la partie serveur est gérée dans une autre configuration : enregistrer l’écran WordPress ne crée pas magiquement des règles Apache utilisables.

Ouvrez Réglages → Permaliens et notez la structure sélectionnée.
Sans choisir une autre structure, cliquez sur Enregistrer les modifications.
Si WordPress indique que le fichier n’est pas accessible en écriture, utilisez les règles qu’il fournit pour cette installation. Ne forcez pas des permissions 777.
Vérifiez deux articles existants, une catégorie et les éventuelles pages de boutique. Confirmez que leur adresse n’a pas changé.
Si une fonction disparaît, comparez le fichier avec sa sauvegarde et restaurez les règles personnalisées nécessaires. Un accueil accessible ne valide pas toutes les routes du site.

Augmenter la mémoire seulement si le journal le justifie

Le message Allowed memory size ... exhausted signifie que le script a atteint sa limite mémoire. Par exemple, 134217728 octets correspondent à 128 Mio. Vous pouvez envisager une hausse à 256 Mo si la limite effective est inférieure et si votre hébergement l’autorise. Cette modification ne crée pas de mémoire physique supplémentaire et ne contourne pas un plafond imposé au compte.

Dans WordPress, WP_MEMORY_LIMIT vise le fonctionnement habituel. L’administration utilise aussi WP_MAX_MEMORY_LIMIT, dont la valeur par défaut est généralement déjà au moins 256 Mo. Le code proposé ne promet donc pas de réparer un traitement d’administration qui épuise déjà 256 Mo. Vérifiez la valeur appliquée aux demandes web dans le panneau PHP ou les informations de Santé du site ; la valeur d’un terminal peut être différente.

Une hausse qui permet un import légitime peut suffire. Une consommation qui augmente à chaque essai signale plutôt une boucle, un volume excessif ou un défaut de composant. Dans ce cas, corrigez le traitement au lieu de supprimer les limites.

Notez la limite actuelle et l’opération qui l’épuise. Vérifiez dans l’offre d’hébergement si 256 Mo sont disponibles pour ce site.
Sauvegardez wp-config.php, puis cherchez une définition existante de WP_MEMORY_LIMIT.
Remplacez-la par la valeur ci-dessous, ou ajoutez-la avant le chargement de wp-settings.php si elle est absente. Ne créez pas de doublon.
Reproduisez une seule fois l’opération non sensible qui échouait et vérifiez le nouveau journal. Si la limite n’a pas changé, contrôlez le réglage PHP de l’hébergement.
Si la panne persiste ou si la consommation continue de croître, restaurez l’ancienne valeur et examinez le composant ou le volume de données. N’utilisez pas -1 comme réparation universelle.

// Exemple : uniquement si 256 Mo sont autorisés et utiles pour ce site.
define( 'WP_MEMORY_LIMIT', '256M' );

Corriger une erreur de syntaxe après un ajout de code

Si le 500 apparaît juste après une modification de functions.php, de wp-config.php ou d’un fichier d’extension, commencez par le fichier nommé dans le journal. Une accolade en trop, un point-virgule manquant ou une seconde balise PHP peuvent empêcher son analyse. La ligne indiquée est parfois celle où PHP découvre le problème ; l’erreur peut se trouver juste avant.

Le retour le plus rapide consiste à retirer votre ajout à l’aide de la copie précédente. Restaurez le fichier entier seulement si aucune autre modification utile n’est intervenue depuis. Vous retirez ainsi seulement l’extrait ajouté, sans restaurer une base de données entière ni supprimer des commandes récentes. Si l’extrait a été enregistré dans une extension de snippets, utilisez son mécanisme de récupération documenté ; ne supprimez pas un fichier du thème qui n’a pas été modifié.

La commande ci-dessous est une vérification facultative pour les personnes disposant déjà de SSH. Elle analyse la syntaxe du fichier et ne l’exécute pas. Remplacez le chemin par le fichier réel et utilisez un binaire PHP en ligne de commande de même version que le PHP du site. Un succès de syntaxe ne teste ni les dépendances WordPress ni le comportement du code.

Téléchargez le fichier défaillant pour conserver la modification et ouvrez votre sauvegarde précédente.
Comparez uniquement l’extrait ajouté et les lignes qui l’entourent. N’éditez pas des fichiers du cœur WordPress pour masquer le message.
Par SFTP, annulez l’ajout fautif en préservant les autres modifications récentes. Rechargez ensuite la page en lecture seule qui échouait.
Si vous souhaitez conserver le nouvel extrait, corrigez-le et vérifiez sa syntaxe sur une copie avant de le remettre sur le site.
Avec SSH, exécutez la commande adaptée ci-dessous. Le résultat attendu commence par No syntax errors detected. Sinon, corrigez le fichier indiqué et relancez seulement cette vérification.
Testez enfin la fonction attendue sur la préproduction : l’absence d’erreur de syntaxe ne garantit pas l’absence d’erreur à l’exécution.

# Remplacer le chemin par celui du fichier à vérifier.
php -l "/chemin/du/site/wp-content/themes/theme-exemple/functions.php"

Vérifier un changement de thème ou de version PHP

Quand le journal désigne le thème et que vous retrouvez l’administration, un changement temporaire de thème permet de distinguer sa responsabilité. Utilisez de préférence la préproduction, car menus, emplacements de widgets et présentation peuvent changer pendant l’essai. Gardez le thème initial installé pour revenir en arrière ; changer de thème n’exige pas sa suppression.

Un changement de version PHP peut également révéler une incompatibilité dans un composant ancien. La bonne correction dépend de la fonction citée par l’erreur. Revenez à la version précédente seulement si elle reste prise en charge par l’hébergement et compatible avec le site ; ne choisissez pas une version abandonnée simplement parce qu’elle fait disparaître le message.

Dans Apparence → Thèmes, notez le thème actif et, s’il existe, son thème parent.
Sur la copie de test, activez un thème WordPress par défaut déjà installé et compatible avec votre version.
Rechargez la page en erreur. Si elle revient, cherchez une correction du thème, de son thème enfant ou de ses dépendances avant de réactiver l’ensemble.
Si la panne a suivi un changement PHP, ouvrez le réglage PHP du domaine dans l’hébergement et notez la version actuelle ainsi que l’ancienne.
Testez la version maintenue compatible sur la copie, puis vérifiez le site et le journal. Certains panneaux appliquent ce réglage à plusieurs domaines : confirmez sa portée avant de l’enregistrer.
Si aucun de ces essais ne change le résultat, rétablissez le thème et la version de départ de l’essai, puis poursuivez à partir du journal plutôt que de multiplier les combinaisons.

Utiliser Query Monitor pour une panne partielle

Query Monitor est utile lorsque WordPress arrive encore à charger la page ou l’administration. Il aide à consulter les erreurs PHP collectées, les requêtes à la base et les appels HTTP sortants, avec des informations permettant de retrouver le composant concerné. Je le recommande pour approfondir une panne partielle ou reproduite sur une préproduction, pas comme remplacement du journal serveur quand tout le site est bloqué.

Il ne répare pas automatiquement une erreur 500 et montre les données du chargement courant, pas l’historique de la panne. Sa collecte consomme aussi des ressources. Un appel HTTP sortant qui échoue peut expliquer une fonction défaillante sans être la cause de la réponse principale. Examinez donc les éléments correspondant à l’action et à l’heure du problème. Les panneaux affichent des informations techniques : ne publiez pas des captures contenant des données de requêtes ou des chemins privés.

Depuis Extensions → Ajouter une extension, installez puis activez Query Monitor de John Blackbourn après vérification de sa compatibilité avec votre environnement.
Avec votre compte administrateur, ou super administrateur en multisite, ouvrez la page en lecture seule qui déclenche le problème, puis le menu Query Monitor dans la barre d’administration.
Consultez les panneaux PHP Errors et HTTP API Calls lorsqu’ils sont disponibles. Repérez le composant et le message correspondant à votre action.
Si une extension se détache, confirmez par une désactivation ciblée ou un essai dans le mode de dépannage décrit plus haut.
Si la page s’interrompt avant que vous puissiez lire les panneaux, revenez au journal PHP. L’absence de panneau exploitable ne signifie pas qu’il n’y a pas d’erreur.
Désactivez Query Monitor après l’investigation si vous n’en avez plus besoin, puis vérifiez la page dans une session ordinaire.

Quand agir dans l’hébergement plutôt que dans WordPress

Si les journaux signalent un disque plein, un processus PHP indisponible ou une limite de processus atteinte, l’intervention se situe dans l’hébergement. Vous pouvez déjà relever les quotas et les événements depuis le panneau. Une moyenne correcte sur la journée ne suffit pas à exclure un pic au moment précis de l’erreur.

Le support devient nécessaire pour ce que votre offre ne vous permet pas d’administrer : relancer un service PHP défaillant, corriger un propriétaire de fichiers ou ajuster une règle serveur gérée. Fournissez les éléments que vous avez réunis, plutôt qu’une demande générale « mon site ne marche plus ». Demandez la cause observée et le réglage modifié afin de pouvoir contrôler la réparation.

Ouvrez les indicateurs d’espace disque, de nombre de fichiers et de ressources du domaine. Relevez l’heure des dépassements éventuels.
En cas de stockage saturé, identifiez les fichiers volumineux avant toute suppression. Si une ancienne archive de sauvegarde est la cause, copiez-la vers un stockage privé hors du quota saturé. Vérifiez la copie avant de retirer uniquement cette archive du compte, sans toucher aux médias ni à la base.
Si le journal indique un accès refusé, relevez le fichier et le processus concernés. N’appliquez pas des permissions 777 à toute l’installation.
Si un proxy comme Cloudflare se trouve devant le site, relevez l’identifiant de la réponse et demandez si le 500 vient de l’origine ou de l’intermédiaire. Gardez les protections réseau et HTTPS en place.
Transmettez le domaine, l’URL, l’heure avec fuseau, le message exact et la liste des essais avec leur résultat. Demandez le journal du domaine à cet instant et la valeur effective des limites concernées.
Après l’intervention, reprenez vous-même les contrôles ci-dessous. Un redémarrage peut rétablir l’accueil sans expliquer une panne qui reviendra au prochain traitement.

Valider la réparation et fermer le diagnostic temporaire

Une réparation est concluante lorsque la page fonctionne, que le statut 500 a disparu et que les fonctions utiles restent disponibles. Quittez d’abord le mode Troubleshooting et revenez à la configuration normale retenue pour le site, puis effectuez les contrôles ci-dessous. Ne vous contentez pas d’un message de succès dans le panneau d’hébergement. Reprenez le scénario qui échouait, avec une opération de lecture ou un brouillon sans conséquence commerciale.

Restaurez les réglages de diagnostic précédents. Si le site utilisait normalement WP_DEBUG à false, remettez cette valeur ; retirez le chemin privé et les autres lignes que vous avez ajoutées uniquement pour l’essai, tout en conservant l’affichage public des erreurs désactivé. Ne supprimez pas une configuration de journalisation durable mise en place par votre prestataire. Archivez l’extrait utile du journal dans un espace privé, puis retirez le fichier temporaire lorsqu’il n’est plus nécessaire.

La dernière vérification porte sur ce que l’essai a pu changer : une extension encore désactivée, un thème provisoire ou une règle d’accès retirée peuvent laisser le site utilisable mais incomplet. Notez la cause retenue, la correction et la version du composant réparé pour éviter de recommencer tout le diagnostic au prochain incident.

Vérifiez l’accueil, deux articles, l’administration et le statut de la requête principale dans le navigateur.
Comparez avec une fenêtre privée et contrôlez les fonctions auparavant assurées par l’extension désactivée.
Enregistrez un brouillon de contrôle et rouvrez-le. Les paiements ou envois réels demandent leur propre procédure de test ; ne les déclenchez pas pour cette vérification générale.
Vérifiez qu’aucune nouvelle erreur correspondante n’apparaît dans le journal pendant votre essai.
Après la dernière consultation du journal, désactivez les outils devenus inutiles et remettez la configuration de débogage à son état normal.
Si une réponse d’erreur reste conservée après correction, purgez uniquement le cache concerné et contrôlez à nouveau la page.
Si la panne revient, conservez le nouveau message et l’heure. Le résultat du premier essai doit guider la suite : ne recommencez pas tous les changements en même temps.

Notre méthode éditoriale