White Screen of Death in WordPress: een leeg scherm diagnosticeren als het kritieke foutscherm niet verschijnt

Je opent je WordPress-site en ziet helemaal niks. Geen header, geen footer, geen foutmelding, geen tekst. Het browser-tabblad laadt, de pagina is klaar en wat je overhoudt is puur wit. In de broncode staat gewoon een lege pagina. Dat is de klassieke White Screen of Death, en in 2026 kom je hem minder vaak tegen dan vroeger. Maar als hij toeslaat, dan is hij wel vervelender dan vroeger.

Wat dit in 2026 eigenlijk betekent

Sinds WordPress 5.2 in april 2019 de fatal error recovery mode introduceerde, leveren de meeste PHP fatals geen leeg scherm meer op. WordPress vangt ze op in WP_Fatal_Error_Handler, geeft HTTP 500 terug, toont het scherm "Er heeft zich een kritieke fout voorgedaan op deze site" en stuurt de beheerder een e-mail met een recovery link. Zie je die melding in plaats van een leeg scherm, dan wil je het gerichte diagnose-pad in er heeft zich een kritieke fout voorgedaan op deze site hebben, niet dit artikel.

Een volledig leeg scherm in 2026 betekent één specifiek ding: een PHP fatal sloeg zo vroeg in de request toe, of in een context die de handler niet meer kan bereiken, dat WordPress nooit de kans kreeg om het fallback-scherm te tonen. Daar komt bij dat PHP's display_errors directive op vrijwel elke productiehost uit staat, en dat hoort ook zo. Dus de fatal wordt ook niet op het scherm getoond. Wat je overhoudt is stilte.

Typische oorzaken van een leeg scherm, geordend naar waarschijnlijkheid

Na jaren van deze fouten op managed sites is de volgorde consistent:

1. Een fatal in wp-config.php of een vroeg geladen bestand. Een parse error in wp-config.php, in wp-settings.php of in een must-use plugin onder wp-content/mu-plugins/ slaat toe voordat WP_Fatal_Error_Handler überhaupt is geregistreerd. De handler wordt via register_shutdown_function() opgezet tijdens het booten van WordPress, dus alles wat crasht voordat dat gebeurt, geeft gewoon een leeg scherm.
2. Een parse error in een gewone plugin of thema. Een ontbrekende puntkomma of accolade in functions.php of in een pluginbestand is een compile-time error (E_PARSE). PHP weigert dan het bestand überhaupt uit te voeren. Zit de fout in een bestand dat heel vroeg wordt geladen, of in een bestand dat verhindert dat de handler initialiseert, dan krijg je een leeg scherm in plaats van het kritieke foutscherm.
3. Het kritieke foutscherm verschijnt wel in wp-admin, maar de voorkant blijft leeg. Dit is de meest misleidende variant. De fatal error handler deed het prima op de admin-request en heeft zelfs een recovery email gestuurd, maar een cachinglaag of page cache plugin serveert een verouderd leeg HTML-document aan bezoekers. De back-end is gezond, de voorkant is een spook.
4. Output buffering of caching at de foutpagina op. Een plugin die ob_start() aanroept zonder een bijpassende ob_end_flush(), of een page cache die zich misdraagt, kan het kritieke foutscherm strippen en een lege response in de cache zetten. Daaropvolgende bezoekers krijgen dan die lege response.
5. Een fatal tijdens WordPress maintenance mode. De handler slaat de afhandeling expliciet over wanneer wp_is_maintenance_mode() true is. Als een update halverwege is gesneuveld en een .maintenance bestand in de root heeft achtergelaten, krijg je voor de duur daarvan gewoon een leeg scherm te zien.

Het diagnose-pad maakt van dat lege scherm weer een leesbare foutmelding, nog voordat je één regel code aanraakt.

Diagnose: maak van het lege scherm een leesbare foutmelding

Je moet gewoon kunnen zien waar PHP over zeurt. De canonieke aanpak staat in de WordPress debug documentatie. Verbind via SFTP of het bestandsbeheer van je hosting, open wp-config.php in de WordPress-root en zoek deze regel:

define('WP_DEBUG', false);

Vervang hem door de veilige logging-configuratie, plaats die VOOR de regel /* That's all, stop editing! Happy blogging. */:

// Debug mode aan
define('WP_DEBUG', true);
// Fouten wegschrijven naar wp-content/debug.log
define('WP_DEBUG_LOG', true);
// Fouten niet tonen aan bezoekers
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Opslaan, de kapotte pagina één keer herladen en dan wp-content/debug.log openen. De laatste entry is de fatal die dat lege scherm heeft geproduceerd. Een typische regel ziet er zo uit:

[07-Apr-2026 09:14:22 UTC] PHP Parse error: syntax error, unexpected token ";" in /var/www/html/wp-content/plugins/some-plugin/init.php on line 42

Je weet dat debug logging werkt zodra wp-content/debug.log bestaat en er een PHP Fatal error of PHP Parse error regel in staat met de timestamp van de gefaalde page load. Noteer het bestandspad en het regelnummer. Dat is je hele antwoord.

Er wordt geen debug.log aangemaakt? Dan is er één van drie dingen aan de hand. De host heeft het log-pad overschreven (check je hosting control panel), het PHP-proces heeft geen schrijfrechten in wp-content/, of de fatal zit in wp-config.php zelf en slaat toe voordat WP_DEBUG_LOG überhaupt is gedefinieerd. Voor dat laatste geval kun je tijdelijk fouten direct in de browser renderen door helemaal bovenaan wp-config.php ini_set('display_errors', 1); en error_reporting(E_ALL); toe te voegen, de pagina één keer te laden en de fout te lezen. Haal die regels meteen daarna weer weg. Laat ze nooit op een live site staan, display_errors hoort nooit aan te staan in productie.

Fix per oorzaak

De debug log vertelt je welk bestand en welk type fout het betreft. De fix volgt daaruit:

Parse error in een plugin of thema

Staat er PHP Parse error: syntax error, unexpected ... in de log, dan is een PHP-bestand kapot, bijna altijd door een handmatige edit. Het volledige diagnose-pad staat in syntax error, unexpected: hoe je een PHP parse error in WordPress oplost. Kort samengevat: open het genoemde bestand op de genoemde regel, corrigeer de typo, opslaan.

Je weet dat het werkt als de site weer laadt en debug.log niet verder aangroeit.

Fatal in een must-use plugin

Staat in het log-pad /wp-content/mu-plugins/, dan crasht een must-use plugin. Die laden voor de gewone plugins en komen vooral voor in managed hosting omgevingen. Hernoem het bestand via SFTP (jouw-mu-plugin.php naar jouw-mu-plugin.php.off) om hem uit te zetten. Herlaad de site. Herstelt hij, dan is de mu-plugin de oorzaak en moet die gerepareerd of verwijderd worden door wie hem heeft geïnstalleerd. Op managed hosts is dat vaak de host zelf.

Fatal in wp-config.php

Open wp-config.php en zoek naar recente wijzigingen. Eén verdwaald teken breekt het hele bestand. Weet je niet meer dat je iets hebt aangepast, kijk dan of er constants worden gezet die naar niet-bestaande bestanden verwijzen, of constants die twee keer worden gedefinieerd. Herstel gewoon een backup als je er eentje hebt.

Geheugen op voordat de handler kon draaien

Staat er PHP Fatal error: Allowed memory size of N bytes exhausted, dan is het script door zijn geheugen heen voordat WordPress het kon opvangen. De gerichte fix leeft in allowed memory size exhausted in WordPress. Je weet dat het werkt als dezelfde pagina weer tot het einde laadt en de geheugenregel niet meer terugkomt in debug.log.

Lege voorkant, werkende admin

Laadt wp-admin gewoon normaal en kun je daar ook bij, maar blijft de voorkant voor bezoekers leeg, dan is het probleem helemaal geen fatal — en als je ook onverwachte admin-accounts of bezoekersredirects ziet, kan de oorzaak geïnjecteerde code zijn, beschreven in WordPress gehackt / malware-redirect opruimen. Anders is het. Een page cache serveert een leeg HTML-document. Leeg de page cache van je caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache), leeg de server-side cache van je host als die er is en herlaad de voorkant in een incognito-venster. Je weet dat het werkt als bezoekers de echte pagina zien en de admin nog steeds werkt. Blijft de cache de lege response opnieuw opbouwen, dan schrijft één van je plugins bij normale requests een lege buffer weg. Dat is een diepere bug en vraagt om een aanpak zoals in php workers uitgeput in WordPress staat beschreven voor een verwant symptoom.

HTTP 500 met lege body

Toont het Network-tabblad van je browser een 500 response met nul bytes body, dan is de fatal wel degelijk opgetreden, heeft PHP hem gepakt en geeft de webserver 500 terug zonder enige inhoud. Dat is hetzelfde faalscenario als een generieke 500 Internal Server Error, en de webserver error log van je host is de snelste weg naar de oorzaak.

Wanneer schakel je hulp in

Verschijnt er geen debug log, of blijft het lege scherm ondanks alle fixes, dan geef je het probleem door aan je host of een WordPress-specialist, mét onderstaande bundel al verzameld. Elke minuut die zij besparen op het verzamelen van context, is een minuut dichter bij een werkende site.

Verzamel vooraf:

• De exacte HTTP status code en response size in het Network-tabblad van je browser op de falende request.
• Of wp-admin wel laadt, los van de voorkant.
• Je PHP-versie (uit je hosting panel) en je WordPress-versie (uit wp-includes/version.php).
• De laatste 30 regels van wp-content/debug.log als dat bestand er is, of de melding dat het er niet is.
• Je webserver error log als je erbij kunt (de meeste control panels hebben een "Error logs" sectie).
• Een lijstje van wat je al hebt geprobeerd, in volgorde, en wat er telkens veranderde.
• Elke wijziging van de afgelopen 24 uur voordat de pagina leeg werd: een plugin-update, een PHP-versiewissel, een edit in wp-config.php of functions.php, een theme-switch.

Hoe voorkom je de volgende lege pagina

Elke fatal voorkomen lukt niet, maar je kunt er wel voor zorgen dat de volgende wél netjes het recovery-scherm laat zien in plaats van een leeg scherm:

• Edit wp-config.php of functions.php nooit rechtstreeks op een live site. Gebruik staging, of houd op zijn minst een lokale kopie van het bestand open zodat je het letterlijk terug kunt plakken.
• Houd WP_DEBUG_LOG in wp-config.php gericht op een schrijfbaar pad, zodat toekomstige fatals in een log terechtkomen dat je kunt lezen. Zet WP_DEBUG_DISPLAY nooit aan op een live site.
• Zorg dat de admin-e-mail werkt. De recovery-flow van de kritieke foutafhandelaar is waardeloos als dat adres bounced. Test het eens per paar maanden met een simpele password reset.
• Maak een backup voor elke update. Terugzetten uit een werkende backup is een fix van 60 seconden; een leeg scherm zonder backup diagnosticeren kost je een middag.
• Draai niet meer plugins dan je nodig hebt. Elke actieve plugin is een mogelijke bron voor de volgende fatal, en de gemiddelde WordPress-site draait meer plugins dan hij daadwerkelijk gebruikt. Gaan twee plugins onderling slecht samenwerken zonder een echte fatal, dan verandert het lege scherm in een subtieler "functie is stuk"-symptoom dat een eigen diagnose-pad heeft in zo vind je welke plugin je site stukmaakt.