Logs d’erreurs WordPress : où les trouver et comment les lire

Un matin, votre site vous accueille avec une belle page blanche. Rien. Le vide. Ou alors c’est votre formulaire de contact qui fait semblant d’envoyer les messages, sauf que personne ne reçoit rien. Panique à bord ?

Bonne nouvelle : dans l’immense majorité des cas, l’incident a laissé une trace quelque part. Un fichier discret, prévu exactement pour ça : un log d’erreurs, ou journal d’erreurs. C’est un peu la boîte noire de votre site. Encore faut-il savoir qu’elle existe, où elle se cache, et comment traduire ce qu’elle raconte.

C’est tout l’objet de ce tuto. On va voir ensemble ce qu’est vraiment un log, quels journaux existent et lequel ouvrir selon la panne, où les débusquer concrètement (on prend l’exemple d’un hébergement o2switch), et surtout comment décoder une ligne pour remonter du symptôme jusqu’à la vraie cause. On va à l’essentiel, pas de détour inutile.

C’est quoi, un log d’erreurs ?

Un log d’erreurs, c’est un fichier dans lequel le serveur ou le site note tout ce qui part de travers : ce qui a planté, à quelle heure, et le plus souvent pourquoi. La différence avec le message qui s’affiche à l’écran ? Le message disparaît dès que vous quittez la page. Le log, lui, garde tout en mémoire, tranquillement, pour que vous puissiez le relire à tête reposée.

Et c’est là que se joue toute la partie. L’erreur que voit votre visiteur — la fameuse page blanche, ou l’erreur 500 — n’est que le symptôme. Le log, c’est l’indice qui mène au coupable. Un peu comme un médecin : la fièvre se voit tout de suite, mais c’est l’analyse qui dit ce qui la provoque.

Pourquoi il n’y a pas UN log, mais plusieurs

Voici le piège qui fait perdre le plus de temps. On imagine souvent un grand cahier unique où tout serait noté. En réalité, il existe plusieurs journaux, et chacun ne consigne que ce qui le concerne.

Pourquoi ? Parce que quand un visiteur arrive sur votre site, sa demande traverse plusieurs étages, comme un colis qui passe de main en main. Le serveur web, puis le code PHP, puis WordPress. Une erreur ne s’inscrit que dans le journal de l’étage où elle s’est produite. Chercher une panne PHP dans le journal du serveur web, c’est fouiller la mauvaise pièce.

Petite nuance à garder en tête : les lignes PHP et WordPress se chevauchent un peu. WordPress étant lui-même écrit en PHP, une même erreur — disons une extension qui provoque une erreur fatale — peut apparaître à la fois dans le error_log et dans le debug.log. Ce dernier se distingue surtout par les avertissements maison de WordPress, comme les fonctions dépréciées, que le error_log ne signale pas toujours.

Ce que les logs ne vous diront jamais

Avant de partir à la chasse, un réflexe qui évite des heures de recherche dans le vide. Certains problèmes ne laissent aucune trace, tout simplement parce que, techniquement, rien n’a échoué.

Le cas le plus déroutant : le site répond, le code tourne sans broncher, mais le résultat est faux. Une redirection mal réglée, un cache qui sert une vieille version de vos pages, une règle CSS qui casse l’affichage. Le visiteur voit bien un souci, mais aucun journal ne bronche, puisque rien n’a planté. Inutile d’éplucher des logs vides : ces cas-là se diagnostiquent autrement, par exemple avec les outils d’inspection de votre navigateur.

Même logique pour un site lent mais fonctionnel. La lenteur n’est pas une erreur, elle ne laisse pas de trace dans les journaux d’erreurs. Elle s’analyse avec des outils dédiés à la performance (chez o2switch, X-Ray ou Application Profiler).

Où trouver vos logs, concrètement

Passons à la pratique. Pour une erreur visible ou une page qui refuse de se charger, deux réflexes couvrent la grande majorité des situations. On les prend dans l’ordre.

1. L’outil Erreurs du cPanel : votre tout premier réflexe

Depuis votre cPanel, ouvrez la rubrique Mesures, puis l’outil Erreurs. Aucune activation, aucune configuration : il est là, tout de suite. Vous y trouvez les 300 dernières erreurs remontées par le serveur web Apache.

C’est l’outil qui tranche le plus vite, parce qu’en quelques secondes il vous dit si la panne vient du serveur, oui ou non. Pour une vraie erreur 500, le message affiché est en général assez parlant pour vous mettre sur la piste.

2. Le fichier error_log : quand l’outil Erreurs reste muet

Il arrive souvent que l’outil Erreurs soit vide, ou qu’il n’affiche que des 404 sans rapport avec votre souci. C’est normal : les vraies erreurs serveur sont assez rares. Et c’est justement là que le second réflexe entre en jeu.

Si votre site affiche une page blanche ou une erreur 500 alors que l’outil Erreurs reste silencieux, la cause est très probablement du côté de PHP, c’est-à-dire dans le code exécuté par le site, pas dans la configuration du serveur. Le navigateur montre bien une 500, mais l’origine est ailleurs.

Bonne nouvelle : chez o2switch, rien à activer. Les erreurs PHP sont enregistrées par défaut dans un fichier nommé error_log, posé à la racine de votre site, au même niveau que le fichier wp-config.php. C’est donc le premier endroit à regarder.

Pour l’ouvrir, deux chemins tout simples. Depuis le cPanel, le gestionnaire de fichiers vous le fait lire directement dans le navigateur. En FTP, vous le téléchargez comme n’importe quel fichier. Dans les deux cas, c’est du texte brut : pas besoin d’outil spécial.

3. Le debug.log : le journal maison de WordPress

Sur un site WordPress, vous croiserez peut-être un second fichier : wp-content/debug.log. Celui-là n’existe que si vous l’allumez. Pour l’activer, on ajoute deux lignes dans le fichier wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

À partir de là, les erreurs et avertissements de WordPress s’accumulent dans wp-content/debug.log. Comme il faut l’activer puis reproduire l’incident pour qu’il s’y inscrive, ce journal sert surtout au diagnostic ciblé : vous l’allumez le temps de comprendre un problème précis, puis vous l’éteignez. Un journal ne note que ce qui se passe après son activation : inutile d’espérer y retrouver une erreur d’hier.

4. L’outil Accès brut : à ne pas confondre

Toujours dans la rubrique Mesures, vous verrez un outil nommé Accès brut. Attention au piège : ce n’est pas un journal d’erreurs. Il enregistre les accès à votre site, autrement dit chaque requête reçue, et non ce qui a échoué.

Son intérêt est ailleurs : repérer un pic de trafic inhabituel, une rafale de requêtes vers la même adresse, une activité suspecte. Pour comprendre pourquoi une ressource est sollicitée en boucle, c’est le bon endroit. Pour comprendre pourquoi votre site affiche une erreur, non. Contrairement à l’outil Erreurs qui s’affiche à l’écran, l’Accès brut se télécharge sous forme de fichier compressé.

Comment lire une ligne de log (sans être développeur)

Ouvrir un journal pour la première fois, ça peut intimider : des lignes serrées, des codes, des chemins à rallonge. Rassurez-vous : chaque ligne suit une structure fixe. Une fois que vous savez où regarder, elle se lit en quelques secondes.

Une ligne d’erreur PHP

C’est la plus utile pour le diagnostic. Voici une erreur fatale typique, telle qu’elle apparaît dans un error_log :

[10-Jun-2026 15:09:32 Europe/Paris] PHP Fatal error: Uncaught Error:
Call to undefined function ma_fonction() in
/home/xxxxx/public_html/wp-content/themes/mon-theme/functions.php:42

Cette ligne contient cinq informations :

• La date et l’heure : [10-Jun-2026 15:09:32 Europe/Paris], le moment exact de l’incident.
• Le niveau : PHP Fatal error, ici une erreur grave qui stoppe tout.
• Le message : Call to undefined function ma_fonction(), ce qui a échoué.
• Le fichier : le chemin vers functions.php, là où ça a coincé.
• La ligne : :42, l’endroit précis dans ce fichier.

Les deux dernières sont de l’or en barre : le fichier et le numéro de ligne vous disent exactement où regarder. Ici, le chemin pointe vers un dossier de thème : l’erreur vient donc du thème, pas du cœur de WordPress. Vous venez de diviser votre zone de recherche par cent.

Une ligne d’accès

Les journaux d’accès suivent une autre logique. Une ligne ressemble à ça :

203.0.113.42 - - [10/Jun/2026:15:09:32 +0200] "GET /contact/ HTTP/1.1"
200 5120 "https://exemple.fr/" "Mozilla/5.0 ..."

On y lit, dans l’ordre : l’adresse IP du visiteur, la date et l’heure, la requête (la méthode GET et l’URL demandée), puis le code de statut HTTP, la taille de la réponse, la page de provenance, et enfin le navigateur utilisé.

Le code de statut, c’est le pont avec les erreurs. Un 200 signale une page servie normalement. Un 404 ou un 500 qui revient sans cesse au même endroit, lui, pointe un problème à creuser dans les journaux d’erreurs.

Et maintenant, qu’est-ce qu’on en fait ?

Lire, c’est bien. Agir, c’est mieux. Une fois la ligne décodée, le chemin du fichier vous oriente déjà. S’il pointe vers le dossier d’une extension, suspectez cette extension. S’il pointe vers un thème, regardez de ce côté. Pour confirmer, désactivez l’élément en cause et vérifiez si l’erreur disparaît.

C’est toute la différence avec la méthode « je désactive mes extensions une par une au hasard en priant ». Cette fois, le journal vous dit précisément laquelle. Vous ne tâtonnez plus, vous visez.

Certaines causes ne dépendent pas de vous : une limite serveur, un comportement impossible à reproduire. Dans ce cas, transmettez au support l’extrait de journal concerné plutôt qu’une description floue. Une ligne précise, avec sa date et son message, fait gagner un temps fou. « Mon site bugue » ouvre une enquête ; une ligne d’error_log ouvre une solution.

Questions fréquentes

Où se trouve le fichier error_log d’un site WordPress ?

Par défaut sur un hébergement o2switch, le fichier error_log se trouve à la racine du site, au même niveau que wp-config.php. Vous l’ouvrez via le gestionnaire de fichiers du cPanel ou en FTP. C’est un simple fichier texte.

Comment activer le debug.log de WordPress ?

Ajoutez define( 'WP_DEBUG', true ); et define( 'WP_DEBUG_LOG', true ); dans votre fichier wp-config.php. Les erreurs s’enregistrent alors dans wp-content/debug.log. Pensez à désactiver ces deux lignes une fois le diagnostic terminé.

Mon site affiche une erreur 500 mais l’outil Erreurs est vide, pourquoi ?

Parce que la panne ne vient pas du serveur web mais du code PHP. Le navigateur affiche une 500, mais l’origine réelle se trouve dans le error_log à la racine du site, pas dans la configuration Apache.

Une page blanche laisse-t-elle toujours une trace dans les logs ?

Le plus souvent oui, dans le error_log PHP. Mais si le site répond sans planter (redirection, cache, CSS cassé), aucun journal ne signalera quoi que ce soit : le diagnostic passe alors par les outils d’inspection du navigateur.

À retenir

• Commencez par l’outil Erreurs du cPanel : il repère les problèmes du serveur web, comme les vraies erreurs 500.
• S’il reste vide, direction PHP : le fichier error_log, à la racine du site, est présent par défaut.
• Pour les avertissements propres à WordPress, activez le debug.log le temps du diagnostic, puis éteignez-le.
• Dans une ligne d’erreur, le fichier et le numéro de ligne vous disent où regarder.
• Le chemin désigne souvent l’extension ou le thème coupable ; si la cause vous échappe, envoyez l’extrait au support.

Avec ces repères en poche, un site qui casse cesse d’être une énigme angoissante. Il vous parle, en fait. Il vous reste juste à lire ce qu’il vous raconte.

Et si vous préférez déléguer ?

Lire un log, désactiver la bonne extension, remonter à la cause : c’est faisable, mais ça demande du temps et un peu de sang-froid quand le site est à l’arrêt. Si vous préférez confier votre WordPress à des gens dont c’est le métier, c’est exactement ce que fait Poulpe Média. Maintenance, dépannage, sécurité : on garde un œil sur votre site pendant que vous gardez le vôtre sur votre activité. Parlons de votre projet.

Ça pourrait vous plaire

• Installer WordPress : le guide pas à pas pour démarrer sans se perdre
• Votre admin WordPress : comment y accéder et (surtout) le sécuriser
• WP-Cron : le petit robot silencieux qui fait tourner votre WordPress