Journal serveur

Quand un site WordPress affiche une page blanche ou renvoie une erreur 500, la première réaction utile n’est pas de deviner mais de consulter les journaux serveur : ces fichiers texte enregistrent, ligne après ligne, ce que le serveur a réellement fait — quelle requête est arrivée, quelle erreur PHP s’est produite, quel processus a échoué.

Les journaux qui comptent sur un site WordPress

On distingue plusieurs fichiers selon la couche concernée : le journal d’accès Nginx ou Apache liste chaque requête HTTP reçue, le journal d’erreur du serveur web signale les problèmes bas niveau, et le journal PHP (error_log) consigne les avertissements et erreurs fatales du code, y compris ceux provenant du thème ou des extensions. WordPress peut aussi écrire son propre journal applicatif via la constante WP_DEBUG_LOG.

Activer le journal de débogage WordPress

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

Les erreurs s’accumulent alors dans wp-content/debug.log sans jamais s’afficher aux visiteurs du site.

Pièges fréquents

• Laisser WP_DEBUG_DISPLAY activé en production expose des chemins de fichiers et des détails techniques exploitables par un attaquant.
• Les journaux non purgés peuvent grossir jusqu’à saturer l’espace disque d’un VPS ; une rotation automatique (via logrotate par exemple) est indispensable.
• Une multiplication soudaine de lignes suspectes dans le journal d’accès (tentatives répétées sur wp-login.php) signale souvent une tentative de force brute plutôt qu’un simple pic de trafic.