Mis à jour le 12 octobre 2026

Pour lire les logs d’erreurs WordPress, j’active WP_DEBUG et WP_DEBUG_LOG dans wp-config.php, je désactive l’affichage à l’écran avec WP_DEBUG_DISPLAY, puis j’ouvre le fichier wp-content/debug.log. Si le fichier reste vide, je consulte les logs PHP de l’hébergeur. Voici la méthode que j’applique, avec les pièges à éviter sur un site en production.

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

Un log d’erreurs est un fichier texte qui enregistre les erreurs, avertissements et notices générés par PHP, WordPress, le thème et les extensions. Chaque ligne donne la date, le type de problème, le fichier fautif et le numéro de ligne. C’est la source la plus fiable pour comprendre un écran blanc ou une erreur critique.

Il existe deux familles de logs. Les logs applicatifs, produits par WordPress (debug.log), et les logs serveur, produits par PHP, Apache, Nginx ou LiteSpeed chez l’hébergeur. Sur les sites que je gère, je commence toujours par le premier, puis je descends au second si rien n’apparaît.

Comment activer les logs d’erreurs dans wp-config.php ?

On active le journal en définissant trois constantes dans wp-config.php, au-dessus de la ligne « That’s all, stop editing! Happy blogging ». La documentation officielle de WordPress précise que WP_DEBUG vaut false par défaut et que WP_DEBUG_LOG et WP_DEBUG_DISPLAY ne fonctionnent que si WP_DEBUG est à true.

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

Le rôle de chaque constante :

  • WP_DEBUG : active le mode débogage, y compris les alertes sur les fonctions obsolètes.
  • WP_DEBUG_LOG : écrit les messages dans wp-content/debug.log. Un chemin personnalisé est possible à la place de true.
  • WP_DEBUG_DISPLAY : à false, les erreurs ne s’affichent plus dans le HTML des pages. Je le mets toujours à false hors environnement local, sinon les visiteurs voient des chemins de fichiers.

Deux constantes complémentaires existent selon le besoin : SCRIPT_DEBUG charge les versions non minifiées des CSS et JS du cœur, et SAVEQUERIES conserve les requêtes SQL dans $wpdb->queries. La même documentation indique que SAVEQUERIES pèse sur les performances, donc je ne l’active que pour une session de diagnostic.

Où trouver le fichier debug.log ?

Par défaut, le fichier se trouve dans le dossier wp-content, à côté de vos thèmes et extensions. Il n’existe qu’après la première erreur enregistrée. Pour le lire, ouvrez-le en FTP/SFTP, depuis le gestionnaire de fichiers de l’hébergeur ou en SSH.

  1. Connectez-vous au serveur (SFTP, SSH ou gestionnaire de fichiers).
  2. Ouvrez wp-content/debug.log, ou le chemin que vous avez défini dans WP_DEBUG_LOG.
  3. En SSH, tail -n 50 wp-content/debug.log affiche les 50 dernières lignes, et tail -f suit le fichier en direct pendant que vous reproduisez le bug.
  4. Si rien n’est créé, vérifiez les droits d’écriture : la documentation de wp-config indique qu’il faut parfois créer le fichier soi-même et ajuster ses permissions.

Comment protéger le fichier debug.log ?

Un debug.log accessible par URL expose des chemins serveur, des noms de tables et parfois des données de requêtes. La documentation officielle classe les logs en zone publique comme un risque de sécurité et recommande de les stocker au-dessus de la racine web, ou de passer le fichier en permissions 600 en bloquant son accès côté serveur.

Ma pratique : un chemin hors du dossier public quand l’hébergeur le permet, et un test de l’URL du fichier dans le navigateur après activation. Si elle répond autrement que par une erreur 403 ou 404, je corrige avant de continuer. Je coupe aussi WP_DEBUG une fois le diagnostic terminé, car laisser le mode actif en permanence sur un site de production n’est pas recommandé par la documentation.

Quels outils pour lire les erreurs sans passer par le FTP ?

Query Monitor est l’extension que j’installe en premier quand je veux voir les erreurs PHP, les requêtes SQL lentes, les hooks et les appels HTTP depuis l’administration. La fiche officielle la présente comme un panneau d’outils de développement, avec plus de 200 000 installations actives et une version 4.0.7 publiée le 20 juin 2026.

Méthode Avantage Limite
debug.log Historique complet, aucune extension Lecture par FTP ou SSH, fichier à protéger
Query Monitor Erreurs, requêtes SQL et hooks dans l’admin Visible seulement pendant la requête analysée
Logs de l’hébergeur Capte les erreurs fatales avant le chargement de WordPress Accès variable selon l’offre

Je garde Query Monitor sur la préproduction et je le retire du site en production une fois l’analyse faite, pour limiter la surface d’attaque et la charge.

Quelles erreurs courantes apparaissent dans les logs ?

Trois messages reviennent le plus souvent : l’épuisement de mémoire, l’échec de connexion à la base de données et l’erreur de syntaxe PHP. Chacun a une cause précise, et le log donne le fichier et la ligne à examiner.

Message Cause probable Piste de correction
Allowed memory size exhausted Une extension ou un thème dépasse la mémoire PHP allouée Identifier le plugin gourmand, puis relever WP_MEMORY_LIMIT
Error establishing a database connection Identifiants erronés, base arrêtée ou saturée Vérifier DB_NAME, DB_USER, DB_PASSWORD et DB_HOST dans wp-config.php
Parse error: syntax error Code PHP invalide après une modification manuelle Annuler la dernière modification du fichier indiqué
Uncaught Error: Call to undefined function Extension ou thème incompatible avec la version de PHP ou de WordPress Désactiver l’extension concernée, puis la mettre à jour

Pour la mémoire, la documentation de wp-config indique que WordPress tente de monter PHP à 40 Mo en site simple et 64 Mo en multisite. Si le log le justifie, on peut relever la limite :

define( 'WP_MEMORY_LIMIT', '256M' );

Je ne traite cela que comme un contournement. Si une extension consomme des centaines de Mo, relever la limite masque le défaut au lieu de le résoudre.

Comment exploiter les logs pour corriger un problème ?

On reproduit le bug, on lit les dernières lignes du log, puis on isole le composant fautif grâce au chemin du fichier cité. Un chemin contenant wp-content/plugins/nom-extension désigne l’extension, wp-content/themes/ désigne le thème. C’est plus fiable que de désactiver les extensions au hasard.

  1. Videz ou renommez debug.log pour partir d’un fichier propre.
  2. Reproduisez l’erreur : chargez la page, soumettez le formulaire ou lancez la mise à jour.
  3. Repérez la ligne « Fatal error » ou « Warning » la plus récente et le chemin du fichier.
  4. Désactivez ou mettez à jour le composant désigné, de préférence sur une préproduction.
  5. Rechargez la page et vérifiez que l’erreur n’apparaît plus dans le log.
  6. Désactivez WP_DEBUG et supprimez le fichier de log.

Avant toute intervention sur un site en production, je fais une sauvegarde complète. Un guide existe sur la sauvegarde WordPress, et si le trafic a chuté après une erreur, le diagnostic est détaillé dans l’article sur la perte de trafic d’un site WordPress.

Quelles erreurs éviter avec les logs ?

  • Laisser WP_DEBUG_DISPLAY à true en production : les erreurs s’affichent aux visiteurs, avec des chemins serveur.
  • Oublier de désactiver le mode debug : le fichier grossit, ralentit les écritures disque et finit par être lu par n’importe qui s’il est public.
  • Placer les constantes après le require de wp-settings.php : elles sont ignorées. Elles doivent figurer avant la ligne « stop editing ».
  • Ignorer les notices et deprecated : ils annoncent souvent le futur plantage d’une extension après une montée de version de PHP.
  • Corriger sans sauvegarde : une modification de wp-config.php ou d’une extension peut aggraver la panne.

Sur mon parc de plus de 50 sites WordPress, je n’active le debug que ponctuellement, et je garde une habitude simple : lire les logs de l’hébergeur au moins une fois par mois, même quand tout fonctionne.

Questions fréquentes

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

C’est un fichier qui enregistre les erreurs, avertissements et notices produits par PHP, WordPress, le thème et les extensions. Il indique la date, le type de problème, le fichier concerné et la ligne. Il sert de journal de diagnostic quand le site n’affiche qu’un message générique.

Comment activer debug.log sur WordPress ?

Ajoutez WP_DEBUG et WP_DEBUG_LOG à true dans wp-config.php, avec WP_DEBUG_DISPLAY à false, avant la ligne « stop editing ». WordPress crée alors wp-content/debug.log dès la première erreur enregistrée.

Est-ce risqué de laisser WP_DEBUG actif en production ?

Oui. La documentation officielle déconseille ces outils sur un site en ligne. Le fichier peut devenir lisible publiquement et exposer des chemins serveur. Activez le mode le temps du diagnostic, protégez le fichier, puis désactivez-le.

Pourquoi mon fichier debug.log n’existe pas ?

Soit aucune erreur n’a encore été enregistrée, soit WordPress ne peut pas écrire dans wp-content. Vérifiez les permissions du dossier, créez le fichier à la main si besoin, et contrôlez que les constantes sont bien placées avant la ligne « stop editing ».

Que faire si les logs WordPress restent vides alors que le site plante ?

L’erreur survient probablement avant le chargement de WordPress, ou PHP écrit ailleurs. Consultez les logs d’erreurs PHP et du serveur web dans l’espace de votre hébergeur, où figurent les erreurs fatales, de configuration et de mémoire.

Source :

Url :

wppourlesnuls