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

Un jour, votre site affiche une page blanche. Une autre fois, c’est un for­mu­laire de contact qui ne répond plus. Que faire ?

Dans beau­coup de cas, un inci­dent tech­nique laisse une trace dans un fichier pré­vu pour cela : un log, ou jour­nal d’erreurs. Encore faut-il savoir qu’il existe, où le trou­ver, et com­ment lire ce qu’il raconte.

C’est tout l’ob­jet de cet article. Nous ver­rons ce qu’est réel­le­ment un log d’er­reurs, quels jour­naux existent et lequel consul­ter selon le type de pro­blème, où les trou­ver concrè­te­ment dans votre espace o2switch, et com­ment déco­der une ligne pour remon­ter à la véri­table ori­gine d’un incident.

Qu’est-ce qu’un log d’erreurs ?

Un log d’er­reurs, ou jour­nal d’er­reurs, est un fichier dans lequel le ser­veur ou le site enre­gistre les évé­ne­ments anor­maux : ce qui a échoué, quand, et le plus sou­vent pour­quoi. Là où un mes­sage affi­ché à l’é­cran dis­pa­raît dès que vous quit­tez la page, le log conserve une trace que vous pour­rez consul­ter ensuite.

C’est cette dis­tinc­tion qui compte. L’er­reur que voit votre visi­teur, une page blanche ou une erreur 500, n’est que le symp­tôme. Le log, lui, donne sou­vent la piste qui per­met de remon­ter à la cause.

À quel niveau se situe le problème ?

Voi­ci ce qui fait perdre le plus de temps : il n’existe pas un seul jour­nal, mais plu­sieurs, et cha­cun n’en­re­gistre que ce qui le concerne. Quand un visi­teur arrive sur votre site, sa requête tra­verse plu­sieurs couches suc­ces­sives. Une erreur n’ap­pa­raît que dans le jour­nal de la couche où elle se produit.

Une pré­ci­sion sur ce tableau : les lignes PHP et Word­Press se recoupent en par­tie. Word­Press étant écrit en PHP, une même erreur, par exemple une exten­sion qui pro­voque une erreur fatale, peut figu­rer à la fois dans le error_log de PHP et dans le debug.log de Word­Press. Ce der­nier se dis­tingue sur­tout par les aver­tis­se­ments propres à Word­Press, comme les fonc­tions dépré­ciées de son inter­face, que le error_log ne signale pas toujours.

Ce que les logs ne montrent pas

Der­nier cas, le plus dérou­tant : le site répond nor­ma­le­ment, le code s’exé­cute sans plan­ter, mais le résul­tat est faux. Une redi­rec­tion mal réglée, un cache qui sert une ancienne ver­sion des fichiers, un réglage qui casse l’affichage ou une règle CSS incor­recte peuvent pro­duire un pro­blème visible sans géné­rer d’erreur. Ici, aucun jour­nal ne signale quoi que ce soit, puisque tech­ni­que­ment rien n’a échoué. Inutile alors de cher­cher dans des logs vides : ces situa­tions se diag­nos­tiquent autre­ment, par exemple avec les outils d’ins­pec­tion du navigateur.

Même logique pour un site lent mais qui fonc­tionne : la len­teur n’est pas une erreur, elle ne laisse aucune trace dans les jour­naux d’er­reurs. Elle s’a­na­lyse avec des outils dédiés à la per­for­mance, comme X‑Ray ou Appli­ca­tion Pro­fi­ler chez o2switch.

Où consulter vos logs

En pra­tique, pour les erreurs visibles ou les pages qui ne se chargent plus, deux réflexes suf­fisent sou­vent. Pre­mier réflexe, et c’est par là qu’il faut tou­jours com­men­cer : l’ou­til Erreurs de votre cPa­nel.

L’outil Erreurs du cPanel o2switch, votre premier réflexe

Depuis votre cPa­nel, ouvrez la rubrique Mesures, puis l’ou­til Erreurs. Aucune acti­va­tion, aucune confi­gu­ra­tion : il est dis­po­nible immé­dia­te­ment. Vous y trou­vez les 300 der­nières erreurs remon­tées par le ser­veur web Apache pour vos sites.

C’est l’ou­til qui tranche le plus vite, parce qu’il vous dit en quelques secondes si votre pro­blème vient du ser­veur ou non. Pour les vraies erreurs 500, le mes­sage affi­ché est géné­ra­le­ment assez clair pour vous mettre sur la voie.

Quand l’outil Erreurs reste vide

Voi­ci l’in­for­ma­tion qui vous fera gagner le plus de temps. Il arrive sou­vent que cet outil soit vide, ou qu’il ne contienne que des erreurs sans rap­port direct avec le pro­blème ren­con­tré, comme des 404. C’est nor­mal : les erreurs au niveau du ser­veur web sont rela­ti­ve­ment rares.

Et c’est pré­ci­sé­ment là que se joue le second réflexe. Un outil Erreurs vide n’est pas une impasse, c’est une infor­ma­tion : si rien n’y appa­raît alors que votre site affiche une page blanche ou une erreur 500, la cause se situe sou­vent ailleurs, au niveau du code exé­cu­té par le site, donc côté PHP. La docu­men­ta­tion o2switch le for­mule clai­re­ment : si l’ou­til Erreurs ne contient rien en rap­port avec la page concer­née, il s’agit très pro­ba­ble­ment d’une erreur PHP. Le navi­ga­teur affiche bien une erreur 500, mais l’origine du pro­blème se situe dans le code exé­cu­té par le site, pas dans la confi­gu­ra­tion Apache.

Autre­ment dit, l’ou­til Erreurs vous répond par oui ou par non. S’il pointe une erreur ser­veur, vous tenez votre piste. S’il reste muet, vous savez désor­mais qu’il faut regar­der du côté de PHP, ce que nous voyons juste après.

Les erreurs PHP et le fichier error_log

Quand l’ou­til Erreurs reste muet, la piste est donc du côté de PHP. Bonne nou­velle : chez o2switch, vous n’a­vez rien à acti­ver. Les erreurs PHP sont enre­gis­trées par défaut dans un fichier nom­mé error_log.

Par défaut chez o2switch, ce fichier se trouve à la racine de votre site, au même niveau que le fichier wp-config.php. C’est donc là qu’il faut regar­der en premier.

Selon la confi­gu­ra­tion PHP de l’hébergement, son empla­ce­ment peut aus­si être per­son­na­li­sé, voire géré direc­te­ment côté ser­veur. Dans cet article, nous res­tons sur le cas le plus cou­rant : le fichier error_log géné­ré à la racine du site.

Pour ouvrir un error_log, deux che­mins simples. Depuis le cPa­nel, le ges­tion­naire de fichiers vous per­met de le consul­ter direc­te­ment dans le navi­ga­teur. En FTP, vous le télé­char­gez comme n’im­porte quel autre fichier. Dans les deux cas, c’est un simple fichier texte : vous pou­vez l’ou­vrir et le lire sans outil particulier.

Sur un site Word­Press, vous croi­se­rez peut-être un second fichier, wp-content/debug.log. Celui-là est géné­ré par Word­Press lorsque le mode débo­gage est acti­vé. C’est l’ob­jet du point suivant.

Le journal de WordPress, le debug.log

Pour l’ac­ti­ver, on ajoute deux constantes dans le fichier wp-config.php : WP_DEBUG et WP_DEBUG_LOG. Les erreurs et aver­tis­se­ments de Word­Press s’ac­cu­mulent alors dans le fichier wp-content/debug.log.

Comme il faut l’ac­ti­ver, puis repro­duire l’in­ci­dent pour qu’il s’y ins­crive, ce jour­nal sert sur­tout au diag­nos­tic ciblé : vous l’al­lu­mez le temps de com­prendre un pro­blème pré­cis, puis vous l’é­tei­gnez. Un jour­nal n’en­re­gistre que ce qui se pro­duit après son acti­va­tion ; inutile donc d’es­pé­rer y retrou­ver une erreur sur­ve­nue la veille.

L’ac­ti­va­tion pas à pas, les réglages asso­ciés et les pré­cau­tions à prendre, notam­ment ne pas le lais­ser actif en per­ma­nence sur un site en pro­duc­tion, sont détaillés dans l’ar­ticle Com­ment acti­ver WP_DEBUG pour diag­nos­ti­quer une erreur Word­Press.

L’outil Accès brut : un journal d’accès, pas d’erreurs

Tou­jours dans la rubrique Mesures, vous croi­se­rez un outil nom­mé Accès brut. Il a sa place ici, mais avec une réserve essen­tielle : ce n’est pas un jour­nal d’er­reurs. Il enre­gistre les accès à votre site, c’est-à-dire chaque requête reçue par le ser­veur, et non ce qui a échoué.

Son inté­rêt est donc ailleurs : repé­rer un pic de tra­fic inha­bi­tuel, une série de requêtes vers une même adresse, ou une acti­vi­té sus­pecte. Pour com­prendre pour­quoi une res­source est sol­li­ci­tée en boucle, c’est le bon endroit. Pour com­prendre pour­quoi votre site affiche une erreur, non.

Contrai­re­ment à l’ou­til Erreurs, qui s’af­fiche à l’é­cran, l’Ac­cès brut se télé­charge : vous récu­pé­rez un fichier com­pres­sé que vous ouvrez ensuite. Par défaut, une option archive ces jour­naux et sup­prime ceux du mois pré­cé­dent ; vous pou­vez la déco­cher pour conser­ver un his­to­rique plus long.

Lire une ligne de log

Ouvrir un jour­nal pour la pre­mière fois peut inti­mi­der : des lignes denses, des codes, des che­mins de fichiers. En réa­li­té, chaque ligne suit une struc­ture fixe. Une fois que vous savez quoi y cher­cher, elle se lit en quelques secondes.

Une ligne d’erreur PHP

C’est la plus utile au diag­nos­tic. Voi­ci une erreur fatale typique, telle qu’elle appa­raît dans un fichier 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

[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’erreur.
• Le niveau : PHP Fatal error, ici une erreur grave qui inter­rompt l’exécution.
• Le mes­sage : Call to undefined function ma_fonction(), ce qui a échoué.
• Le fichier : le che­min vers functions.php, où l’er­reur s’est produite.
• La ligne : :42, l’en­droit pré­cis dans ce fichier.

Les deux der­nières sont les plus pré­cieuses : le fichier et le numé­ro de ligne vous disent où regar­der. Ici, le che­min pointe vers un thème, l’er­reur vient donc de là, et non du cœur de WordPress.

Une ligne d’accès

Les jour­naux d’ac­cès suivent une autre struc­ture. Une ligne res­semble à ceci :

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

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’a­dresse IP du visi­teur, la date et l’heure, la requête (la méthode GET et l’URL deman­dée), puis le code de sta­tut HTTP, la taille de la réponse, la page de pro­ve­nance, et enfin le navi­ga­teur utilisé.

Le code de sta­tut est ce qui fait le pont avec les erreurs : un 200 signale une requête ser­vie nor­ma­le­ment, tan­dis qu’un 404 ou un 500 répé­té au même endroit pointe un pro­blème à creu­ser dans les jour­naux d’erreurs.

Que faire de l’information

Une fois la ligne lue, le che­min du fichier vous oriente déjà. S’il pointe vers le dos­sier d’une exten­sion, c’est elle qu’il faut sus­pec­ter ; s’il pointe vers un thème, regar­dez de ce côté. Pour confir­mer, désac­ti­vez l’élé­ment en cause, puis véri­fiez si l’er­reur dis­pa­raît. C’est toute la dif­fé­rence avec le fait de désac­ti­ver une exten­sion au hasard : cette fois, le jour­nal vous dit laquelle.

Cer­taines causes ne sont pas de votre res­sort, par exemple une limite ser­veur ou un com­por­te­ment que vous ne par­ve­nez pas à repro­duire. Dans ce cas, trans­met­tez au sup­port l’ex­trait de jour­nal concer­né plu­tôt qu’une des­crip­tion vague. Une ligne pré­cise, avec sa date et son mes­sage, fait gagner un temps consi­dé­rable. L’ar­ticle Com­ment faire une demande de sup­port effi­cace détaille ce qu’il est utile de joindre.

Der­nier point, une fois le pro­blème réglé. Le error_log de PHP et les jour­naux du ser­veur peuvent se rem­plir en conti­nu : c’est leur rôle, et vous n’a­vez pas à les sup­pri­mer sys­té­ma­ti­que­ment. Sur­veillez sim­ple­ment qu’un fichier ne gonfle pas de façon anor­male, signe d’une erreur qui se répète et qu’il vaut mieux cor­ri­ger à la source. Avec le para­mé­trage par défaut chez o2switch, le fichier error_log pla­cé à la racine du site n’est pas consul­table direc­te­ment depuis le navi­ga­teur : une ten­ta­tive d’accès ren­voie une erreur 403. Cela ne dis­pense pas de res­ter pru­dent avec les infor­ma­tions qu’il contient, mais ce com­por­te­ment le dis­tingue du fichier debug.log de Word­Press, pla­cé par défaut dans wp-content.

Le debug.log de Word­Press, en revanche, n’a pas voca­tion à res­ter actif sans rai­son sur un site en pro­duc­tion. Acti­vé pour un diag­nos­tic, il doit être désac­ti­vé ensuite : il conti­nue d’écrire des infor­ma­tions qui ne sont plus utiles, peut finir par gros­sir rapi­de­ment, et à son empla­ce­ment par défaut dans wp-content, il ne béné­fi­cie pas de la même pro­tec­tion que le error_log. Ne par­tez jamais du prin­cipe qu’un jour­nal est pri­vé : au moindre doute, véri­fiez s’il est acces­sible depuis l’ex­té­rieur, et pro­té­gez ou sup­pri­mez celui qui contient des infor­ma­tions sensibles.

À retenir

La démarche en bref

• Com­men­cez par l’ou­til Erreurs du cPa­nel : il signale les pro­blèmes du ser­veur web, comme les vraies erreurs 500.
• S’il reste vide, regar­dez du côté de PHP : le fichier error_log, à la racine du site, est pré­sent par défaut.
• Pour les aver­tis­se­ments propres à Word­Press, acti­vez le debug.log le temps du diag­nos­tic, puis désactivez-le.
• Dans une ligne d’er­reur, le fichier et le numé­ro de ligne vous disent où regarder.
• Le che­min du fichier désigne sou­vent l’ex­ten­sion ou le thème en cause ; si la cause vous échappe, trans­met­tez l’ex­trait au support.

Avec ces repères, un site qui casse cesse d’être une énigme. Il vous reste à lire ce qu’il vous dit.