White Screen of Death in WordPress oplossen in 3 stappen

De WordPress White Screen of Death (WSoD) is een volledig witte pagina zonder foutmelding, meestal veroorzaakt door een PHP-fout in een plugin of thema of door een te lage geheugenlimiet. Je lost de White Screen of Death op in drie stappen: zet foutlogging aan met WP_DEBUG, schakel de boosdoener uit via SFTP en controleer de PHP-geheugenlimiet.

Stand van zaken november 2026: volgens WordPress.org is de nieuwste WordPress-versie 7.1.4, uitgebracht op 28 oktober 2026 als beveiligingsrelease. Een wit scherm betekent dat bezoekers niets zien, formulieren niet werken en een webshop geen bestellingen ontvangt. Deze gids is bedoeld voor iedereen met een WordPress-site die zelf wil ingrijpen. Wil je liever dat iemand meekijkt, dan kan Heijsen via remote support op afstand met je meekijken en het probleem samen met je oplossen.

1. Wat is de WordPress White Screen of Death precies?

De White Screen of Death is de bijnaam voor een WordPress-pagina die helemaal leeg blijft: geen tekst, geen menu, geen foutmelding. De officiële WordPress-documentatie over veelvoorkomende fouten beschrijft het als een leeg scherm zonder informatie en noemt zowel PHP-fouten als databasefouten als oorzaak.

Sinds WordPress 5.2 vangt WordPress veel fatale fouten zelf af. Volgens de ontwikkelaarsnotitie over Fatal Error Recovery Mode zien bezoekers dan een melding dat de site technische problemen heeft in plaats van een witte pagina. Tegelijk stuurt WordPress een e-mail naar het beheerdersadres met een geheime link naar de herstelmodus. Een volledig wit scherm kom je nog steeds tegen, bijvoorbeeld als de foutafhandeling is uitgezet met de constante `WP_DISABLE_FATAL_ERROR_HANDLER` in wp-config.php.

Voor de aanpak maakt het weinig uit of je een witte pagina of de melding over technische problemen ziet. In beide gevallen loopt PHP ergens vast en moet je uitzoeken in welke plugin, welk thema of welke instelling de fout zit.

Heb je de e-mail met de herstellink ontvangen? Gebruik die link dan eerst. In de herstelmodus pauzeert WordPress de plugin of het thema dat de fatale fout veroorzaakt, alleen voor jouw browser via een cookie. Je logt in, werkt de plugin bij of verwijdert hem, en sluit de herstelmodus af met de knop in de adminbalk. Is de plugin daarna nog steeds kapot, dan komt de fout gewoon terug.

2. Wat zijn de meest voorkomende oorzaken van een wit scherm in WordPress?

De meest voorkomende oorzaken van een wit scherm in WordPress zijn een plugin met een fout of conflict, een thema met een fout en een PHP-geheugenlimiet die te laag is. De WordPress-documentatie noemt een nieuw geactiveerd thema als extra verdacht wanneer het witte scherm direct daarna verschijnt.

Plugins zijn de grootste groep. Een plugin-update kan code bevatten die niet samenwerkt met je WordPress-versie, je PHP-versie of een andere plugin. Twee plugins die dezelfde functie of klasse proberen te laden, geven ook een fatale fout. Na een overstap naar een nieuwere PHP-versie kan verouderde code in een plugin of thema crashen, omdat functies uit oudere PHP-versies zijn verdwenen.

Geheugentekort herken je aan de melding 'Allowed memory size exhausted' in het foutlogboek. Zware page builders, grote imports en webshops met veel producten vragen meer werkgeheugen dan een eenvoudige blog. Een update die halverwege afbreekt, kan daarnaast onvolledige bestanden achterlaten die WordPress niet meer kan laden.

In de support zien we vaak dat een wit scherm direct na een update of na het installeren van een nieuwe plugin ontstaat. Wie dat moment terugweet, heeft de oorzaak meestal al te pakken. Soms blijkt een wit scherm het gevolg van een hack: aangepaste PHP-bestanden met schadelijke code breken de site. Uitschakelen is dan niet genoeg. Heijsen kan je gehackte WordPress-website herstellen met binnen 48 uur een schone installatie, een duidelijk herstelplan en een veilig systeem.

3. Stap 1: hoe vind je met WP_DEBUG de echte foutmelding?

Je vindt de echte foutmelding achter de White Screen of Death door in wp-config.php de debugmodus van WordPress aan te zetten en fouten naar een logbestand te laten schrijven. Volgens de WordPress-documentatie over debuggen staat WP_DEBUG standaard op false, dus zonder deze aanpassing zie je niets.

Stap 1: Maak verbinding met je hosting via SFTP of het bestandsbeheer van je hostingpaneel. Open wp-config.php in de hoofdmap van je WordPress-installatie en maak eerst een kopie van het bestand.

Stap 2: Zet boven de regel met 'That's all, stop editing!' deze drie regels: `define( 'WP_DEBUG', true );`, `define( 'WP_DEBUG_LOG', true );` en `define( 'WP_DEBUG_DISPLAY', false );`. Sla het bestand op.

Stap 3: Laad de witte pagina opnieuw en open daarna `wp-content/debug.log`. WP_DEBUG_LOG schrijft alle fouten naar dat bestand en werkt alleen als WP_DEBUG op true staat.

Stap 4: Zoek in debug.log naar 'PHP Fatal error'. Die regel noemt het bestandspad en het regelnummer, bijvoorbeeld een pad dat begint met `wp-content/plugins/` of `wp-content/themes/`. De mapnaam in dat pad vertelt je welke plugin of welk thema de fout veroorzaakt.

Zet WP_DEBUG_DISPLAY op false, want WP_DEBUG_DISPLAY staat standaard op true en toont fouten dan aan iedere bezoeker. De WordPress-documentatie raadt debugtools op een live site af en noemt ze bedoeld voor lokaal testen en staging. Zet WP_DEBUG daarom weer op false zodra het probleem is opgelost en verwijder debug.log, omdat dat bestand serverpaden en andere technische details kan bevatten.

4. Stap 2: hoe schakel je een kapotte plugin of thema uit zonder wp-admin?

Je schakelt een kapotte WordPress-plugin of een kapot thema zonder wp-admin uit door de map van die plugin of dat thema via SFTP een andere naam te geven. WordPress kan de code dan niet meer laden, waardoor de fatale fout verdwijnt en je weer kunt inloggen.

Stap 1: Ga via SFTP naar `wp-content/plugins` en hernoem de map van de plugin uit debug.log, bijvoorbeeld van `naam-plugin` naar `naam-plugin-uit`. Laad je site opnieuw en log in om te controleren of alles werkt.

Stap 2: Weet je niet welke plugin het is, hernoem dan de hele map `plugins` naar `plugins_old`. Volgens de WordPress-documentatie deactiveer je zo alle plugins tegelijk. Zet de mapnaam daarna terug en activeer de plugins in Plugins > Geïnstalleerde plugins een voor een, tot de site weer wit wordt. De laatst geactiveerde plugin is dan de boosdoener.

Stap 3: Ligt het aan het thema, hernoem dan in `wp-content/themes` de map van het actieve thema. WordPress valt dan terug op een standaardthema, zoals een Twenty Twenty-thema, mits er een geïnstalleerd staat.

Stap 4: Heb je SSH-toegang met WP-CLI, dan gaat het sneller met `wp plugin deactivate naam-plugin` of `wp plugin deactivate --all`. Een standaardthema activeer je met `wp theme activate` gevolgd door de naam uit `wp theme list`.

Een enkele plugin uitschakelen is beter als debug.log de boosdoener al noemt, omdat de rest van je site dan gewoon blijft werken. Alle plugins tegelijk uitschakelen past beter als je geen foutlogboek hebt, maar zet tijdelijk ook formulieren, caching en beveiligingsplugins uit. Houd die periode daarom zo kort mogelijk en controleer na afloop of formulieren en betalingen weer werken.

5. Stap 3: wanneer helpt het verhogen van de PHP-geheugenlimiet?

Het verhogen van de PHP-geheugenlimiet helpt alleen tegen de White Screen of Death als debug.log de melding 'Allowed memory size of ... bytes exhausted' toont. Bij een andere fatale fout, zoals een ontbrekende functie of een syntaxfout, verandert meer geheugen niets.

Volgens de WordPress-documentatie over wp-config.php probeert WordPress standaard 40 MB werkgeheugen te reserveren voor een enkele site en 64 MB voor een multisite. Je verhoogt die waarde met `define( 'WP_MEMORY_LIMIT', '256M' );` in wp-config.php. Voor de beheeromgeving stel je apart `WP_MAX_MEMORY_LIMIT` in. Of de verhoging echt werkt, hangt af van de PHP-instellingen van je server. Stelt je host een lagere maximale limiet in, dan heeft een hogere waarde in wp-config.php geen effect.

Een hogere limiet is geen oplossing voor een plugin die steeds meer geheugen opslokt. Dan schuif je het probleem alleen op. Kijk in dat geval welke plugin in het logbestand terugkomt en vervang hem als een update niet helpt.

Controleer in deze stap ook je PHP-versie. Volgens php.net krijgen PHP 8.4 en PHP 8.5 actieve ondersteuning, terwijl PHP 8.2 alleen nog beveiligingsupdates krijgt tot 31 december 2026 en PHP 8.3 tot 31 december 2027. Een actuele PHP-versie is beter voor veiligheid en ondersteuning; tijdelijk terugzetten naar een oudere versie past alleen als noodgreep wanneer een verouderde plugin crasht na een upgrade.

6. Hoe voorkom je dat je WordPress-site opnieuw een wit scherm geeft?

Je voorkomt een nieuwe White Screen of Death door updates eerst te testen, voor elke wijziging een back-up te hebben en je PHP-versie en plugins actueel te houden. De meeste witte schermen ontstaan op het moment van een wijziging, dus daar zit de grootste winst. Plan updates bovendien op een rustig moment, zodat een storing zo min mogelijk bezoekers raakt.

Test grote plugin- en thema-updates op een kopie van je site. Hoe je dat aanpakt, lees je in onze blog over nieuwe plugins testen op staging. Werk plugins daarna een voor een bij in plaats van alles tegelijk. Gaat er dan iets mis, dan weet je direct welke update de oorzaak is.

Zorg voor automatische back-ups die buiten je WordPress-installatie bewaard worden, zodat je bij een mislukte update terug kunt naar een werkende versie. Verwijder plugins die je niet meer gebruikt: elke extra plugin is code die kan botsen met een update. Kies bij nieuwe plugins voor actief onderhouden plugins met recente updates.

Twijfel je of je site technisch gezond is, laat dan een websiteanalyse van je WordPress-site uitvoeren. Heijsen scant je site op snelheid, veiligheid en techniek en levert een helder rapport met concrete verbeterpunten, zodat je zwakke plekken aanpakt voordat ze een storing veroorzaken.

Conclusie

De White Screen of Death in WordPress ziet er alarmerend uit, maar de oorzaak is bijna altijd te vinden. Zet WP_DEBUG met een logbestand aan, schakel de plugin of het thema uit dat in debug.log staat en verhoog de PHP-geheugenlimiet alleen als het logbestand om meer geheugen vraagt. Ruim daarna de debuginstellingen op.

Wil je dit soort storingen liever niet zelf oplossen? Met managed WordPress-hosting van Heijsen beheren we je updates, veiligheid, back-ups en snelheid voor je. WordPress, plugins en PHP-versies worden zorgvuldig getest en wekelijks bijgewerkt, en je krijgt 24/7 live monitoring en persoonlijke ondersteuning bij storingen. Neem contact op met Heijsen of stap over naar managed WordPress-hosting, dan houden wij je site online.