Je WordPress-site gooit een witte pagina, een formulier werkt niet meer of je server reageert plotseling traag. Wat doe je? De meeste beheerders beginnen met googlen of plugins uit te schakelen. Maar de snelste route naar de oorzaak ligt in je WordPress logs. Logbestanden vertellen je precies wat er misgaat, wanneer het misgaat en welk onderdeel de schuldige is - als je weet waar je moet kijken.
In eerdere artikelen behandelden we al hoe je trage plugins debugt en hoe je performance bottlenecks herkent. Dit artikel gaat een laag dieper: je leert je logbestanden lezen, filteren en interpreteren als een doorgewinterde systeembeheerder.
De vier logbestanden die ertoe doen
WordPress en de onderliggende serverstack produceren meerdere typen logbestanden. Elk logbestand heeft een eigen functie en vertelt je iets anders over je site.
WordPress debug.log
Dit is het logbestand dat WordPress zelf schrijft. Het bevat PHP-fouten, waarschuwingen, notices en alles wat plugins of thema's loggen via error_log(). De standaard locatie is wp-content/debug.log.
PHP error log
Het error log van PHP-FPM of je PHP-handler vangt fatale fouten op die WordPress zelf niet meer kan loggen - denk aan geheugenlimieten of segfaults. Als je PHP-FPM hebt geconfigureerd, vind je dit log vaak onder /var/log/php-fpm/www-error.log.
Webserver access log
Elke request die je server ontvangt, wordt hier vastgelegd: de URL, het IP-adres, de statuscode en de responstijd. Voor NGINX staat dit standaard in /var/log/nginx/access.log.
Webserver error log
Hier belanden serverfouten: mislukte rewrites, time-outs, upstream-fouten van PHP-FPM en certificaatproblemen. Dit is het eerste bestand dat je opent bij 502- of 504-fouten.
WordPress debug logging inschakelen
Voordat je iets kunt analyseren, moet je zorgen dat WordPress zijn fouten ook daadwerkelijk opschrijft. Open je wp-config.php en voeg de volgende constanten toe:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
WP_DEBUG activeert de debugmodus. WP_DEBUG_LOG schrijft alle meldingen naar wp-content/debug.log. En cruciaal: WP_DEBUG_DISPLAY zet je op false zodat foutmeldingen niet aan bezoekers worden getoond. Dat is niet alleen lelijk, maar ook een beveiligingsrisico.
Optioneel: uitgebreide logging
Voor diepere analyse kun je twee extra constanten toevoegen:
define('SAVEQUERIES', true);
define('SCRIPT_DEBUG', true);
SAVEQUERIES slaat elke database-query op met de bijbehorende aanroepstack. Dat is goud waard als je trage queries opspoort, maar zet het nooit aan op productie - het vreet geheugen en vertraagt je site.
SCRIPT_DEBUG forceert WordPress om ongecomprimeerde CSS- en JavaScript-bestanden te laden, handig voor frontend-debugging maar niet voor loganalyse.
Logs lezen op de command line
Het WordPress-dashboard biedt geen ingebouwde logviewer. Je werkt het efficiëntst via SSH op de command line. Hier zijn de commando's die je dagelijks nodig hebt.
Realtime meekijken
tail -f wp-content/debug.log
Dit toont nieuwe logregels zodra ze worden geschreven. Ideaal om live mee te kijken terwijl je een probleem reproduceert. Druk op Ctrl+C om te stoppen.
Filteren op fouten
grep "Fatal error" wp-content/debug.log
grep "Warning" wp-content/debug.log | tail -50
Met grep filter je op specifieke fouttypen. Combineer het met tail om alleen de meest recente resultaten te zien.
Fouten tellen per type
grep -c "PHP Fatal error" wp-content/debug.log
grep -c "PHP Warning" wp-content/debug.log
grep -c "PHP Notice" wp-content/debug.log
Dit geeft je een snel overzicht van de ernst van je situatie. Tientallen fatal errors per dag wijzen op een structureel probleem. Duizenden notices zijn irritant maar meestal niet kritiek.
Unieke fouten vinden
grep "PHP Fatal error" wp-content/debug.log | sort -u
Eén fout die 500 keer voorkomt, is minder alarmerend dan 500 verschillende fouten. Met sort -u zie je alleen de unieke meldingen.
Access logs analyseren
Je access log is een goudmijn aan informatie. Elke regel bevat het IP-adres, de datum, de request-methode, de URL, de statuscode en de responstijd.
Trage requests opsporen
Als je NGINX hebt geconfigureerd met de $request_time variabele in je log format, kun je trage requests filteren:
awk '$NF > 2.0' /var/log/nginx/access.log
Dit toont alle requests die langer dan 2 seconden duurden. Zie je patronen? Dezelfde URL die steeds opduikt? Dan weet je waar je moet graven - bijvoorbeeld in je WP_Query-optimalisatie.
Statuscode-overzicht
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
Dit geeft een overzicht van alle HTTP-statuscodes. Een gezonde site heeft overwegend 200- en 304-responses. Veel 404's wijzen op gebroken links of botverkeer. Veel 500's betekenen dat er iets structureel fout gaat in PHP.
Verdacht verkeer herkennen
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
Dit toont de 20 IP-adressen met het meeste verkeer. Een IP dat duizenden requests per uur stuurt naar wp-login.php of xmlrpc.php is vrijwel zeker een brute force aanval. Blokkeer het via je firewall of overweeg fail2ban om dit automatisch te doen.
Visuele analyse met GoAccess
Command line tools zijn krachtig, maar voor een visueel overzicht is GoAccess onverslaanbaar. Het is een open-source log analyzer die je access logs omzet in een interactief dashboard - direct in je terminal of als HTML-rapport.
goaccess /var/log/nginx/access.log --log-format=COMBINED -o report.html
GoAccess toont je in één oogopslag:
- Bezoekers per dag en uur - wanneer is je piekverkeer?
- Meest bezochte pagina's - welke URL's genereren het meeste verkeer?
- Statuscodes - hoeveel 404's en 500's heb je?
- Browsers en bots - hoeveel verkeer komt van crawlers?
- Geografische verdeling - waar komen je bezoekers vandaan?
Dit is bijzonder nuttig als je vermoedt dat botverkeer je server belast. In combinatie met Cloudflare kun je verdachte patronen identificeren en op netwerkniveau blokkeren.
Veelgemaakte fouten en wat ze betekenen
Niet elke fout in je logbestand is een ramp. Hier is een overzicht van de meest voorkomende meldingen en hoe je ermee omgaat.
PHP Fatal error: Allowed memory size exhausted
WordPress heeft meer geheugen nodig dan beschikbaar is. Verhoog de limiet in wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
Maar let op: als dit herhaaldelijk optreedt, is het een symptoom. De echte oorzaak is vaak een plugin die te veel data in het geheugen laadt - denk aan autoloaded options die uit de hand lopen.
PHP Warning: file_get_contents failed to open stream
Een plugin probeert een extern bestand op te halen dat niet bereikbaar is. Dit kan door een API die offline is, een geblokkeerde uitgaande verbinding of een fout in de URL. Check welke plugin de aanroep doet (de stacktrace wijst je de weg) en onderzoek of het een essentiële functie betreft.
WordPress database error: Table doesn't exist
De database mist een tabel die WordPress of een plugin verwacht. Dit kan na een mislukte migratie of een verwijderde plugin die niet netjes is opgeruimd. Controleer of de plugin opnieuw geactiveerd kan worden om de tabel te herstellen, of voer de benodigde SQL handmatig uit.
502 Bad Gateway / 504 Gateway Timeout
Dit zijn geen WordPress-fouten maar serverfouten. NGINX kan PHP-FPM niet bereiken (502) of PHP-FPM reageert niet op tijd (504). Check het PHP-FPM error log en de pool-configuratie. Vaak zijn de workers uitgeput door te veel gelijktijdige requests.
Logs beheren met logrotate
Logbestanden groeien eindeloos als je ze niet beheert. Een debug.log van meerdere gigabytes is niet alleen onpraktisch om te doorzoeken, maar vreet ook schijfruimte.
Op Linux-servers gebruik je logrotate om logs automatisch te roteren:
/var/www/html/wp-content/debug.log {
weekly
rotate 4
compress
missingok
notifempty
create 0640 www-data www-data
}
Deze configuratie roteert het logbestand wekelijks, bewaart vier weken historie, comprimeert oude logs en maakt automatisch een nieuw leeg bestand aan. Voeg dit toe aan /etc/logrotate.d/wordpress.
Gecentraliseerd loggen
Als je WordPress op meerdere servers draait, wordt het onpraktisch om op elke server individueel logs te bekijken. Dan is gecentraliseerd loggen de volgende stap.
De populairste opties:
- ELK-stack (Elasticsearch, Logstash, Kibana) - krachtig maar resource-intensief. Geschikt voor grote omgevingen met meerdere applicaties.
- Grafana Loki - een lichtgewicht alternatief dat goed integreert met Grafana dashboards. Ideaal als je al Grafana gebruikt voor monitoring.
- Papertrail of Logtail - hosted oplossingen die je logs centraal verzamelen zonder eigen infrastructuur.
De kern is steeds hetzelfde: je stuurt alle logregels naar één plek, maakt ze doorzoekbaar en stelt alerts in voor patronen die aandacht vereisen. Denk aan een alert bij meer dan 10 fatal errors per minuut, of bij een plotselinge piek in 502-responses.
Een gestructureerde aanpak
Loganalyse is het effectiefst als je het systematisch aanpakt. Hier is een werkwijze die je bij elk incident kunt volgen:
- Bepaal het symptoom - witte pagina, trage respons, foutmelding voor de bezoeker?
- Kies het juiste log - PHP-fouten staan in debug.log, serverfouten in het error log, verkeerspatronen in het access log
- Filter op tijdstip - wanneer begon het probleem? Beperk je zoekactie tot dat tijdsvenster
- Zoek patronen - herhaalt dezelfde fout zich? Komt het van één IP, één plugin of één URL?
- Volg de stacktrace - een fatal error toont het bestandspad en regelnummer waar de fout optreedt. Dat wijst je naar de schuldige plugin of themacode
- Los op en verifieer - pas je fix toe en monitor het log om te bevestigen dat de fout verdwijnt
Veelgestelde vragen
Hoe schakel ik WordPress debug logging in?
Voeg WP_DEBUG, WP_DEBUG_LOG en WP_DEBUG_DISPLAY toe aan je wp-config.php. Zet WP_DEBUG en WP_DEBUG_LOG op true en WP_DEBUG_DISPLAY op false. WordPress schrijft dan alle fouten naar wp-content/debug.log zonder ze aan bezoekers te tonen.
Waar vind ik de WordPress error log?
De standaard locatie is wp-content/debug.log. PHP-fouten van de server vind je in het PHP error log, vaak onder /var/log/php-fpm/ of /var/log/apache2/error.log. NGINX access en error logs staan meestal in /var/log/nginx/.
Kan ik WordPress logs automatisch laten opruimen?
Ja. Gebruik logrotate op Linux om logbestanden automatisch te roteren en oude logs te verwijderen. Configureer een retentieperiode van bijvoorbeeld 14 dagen zodat je genoeg historie hebt zonder dat logs je schijfruimte opvreten.
Welke tools zijn handig voor het analyseren van WordPress logs?
Op de command line zijn tail, grep en awk onmisbaar. GoAccess biedt een visueel dashboard voor access logs. Voor geavanceerde analyse kun je de ELK-stack (Elasticsearch, Logstash, Kibana) of Grafana Loki gebruiken om logs centraal te verzamelen en doorzoekbaar te maken.
Hoe herken ik een brute force aanval in mijn logs?
Zoek naar herhaalde POST-requests naar wp-login.php of xmlrpc.php vanaf hetzelfde IP-adres in korte tijd. Honderden loginpogingen per minuut van één IP zijn een duidelijk signaal. Blokkeer het IP via je firewall of een tool als fail2ban.