Wat is precies een white screen of death?

Een lege, witte pagina zonder content, header of footer. WordPress stopt halverwege het laden zonder dat er een foutmelding wordt getoond. Meestal veroorzaakt door PHP-fouten die niet doorkomen omdat error-uitvoer uitstaat.

Waarom zie ik geen foutmelding?

Op live sites staat de PHP-foutweergave standaard uit, om gevoelige informatie niet aan bezoekers te tonen. Door WP_DEBUG en WP_DEBUG_LOG aan te zetten, schrijf je de fouten naar een logbestand zonder ze op de site te tonen.

Werkt mijn admin nog wel als de frontend wit is?

Soms wel, soms niet. Bij plugin-conflicten is vaak alleen de frontend wit, terwijl wp-admin nog werkt. Bij thema-fouten kan ook de admin uitvallen, omdat ze deels dezelfde code laden.

Kan ik dit zelf oplossen?

Stap 1 en 2 (debug aanzetten, memory limit verhogen) zijn voor de meeste mensen met FTP-toegang doenlijk. Stap 3 en verder vraagt om wat handigheid met FTP, code-editors en het lezen van foutlogs. Vanaf daar wordt het technischer.

Wat als ik geen FTP-toegang heb?

De meeste hosters hebben een ingebouwde file manager in het paneel. Daarmee kun je hetzelfde doen als met FTP. Zoek in het hostingpaneel naar "Bestandsbeheer" of "File Manager". Bij een gehackte site of als je echt niet zelf de bestanden in wil, is hulp inroepen de snellere route.

Kan een WSOD een teken zijn van een hack?

In zeldzame gevallen wel. Een malware-injectie kan PHP-fouten veroorzaken die de site doen crashen. Dat zie je terug in het debug-log als verwijzingen naar onbekende bestanden of vreemde functies. Bij twijfel is een malware-scan via Wordfence of via een handmatige check de volgende stap.

WordPress wit scherm oplossen: stap voor stap

Je opent je site en ziet niets. Geen header, geen footer, geen foutmelding. Een lege witte pagina. Geen melding wat er mis is. Dit is het white screen of death (WSOD), en het is een van de vervelendste foutmeldingen in WordPress, omdat het geen foutmelding is.

De oorzaak ligt bijna altijd in een van drie hoeken: een plugin-conflict, een te krap PHP-geheugen, of een fout in het thema. Soms zit het dieper, in PHP-versies of bestandsrechten, maar dat is uitzondering.

Ik werk dit artikel door alsof je net hebt opgemerkt dat je site wit is. Eerst de snelle checks, daarna de stappen die meer tijd kosten. Geen theorie vooraf.

WordPress wit scherm wordt onderzocht met handboeken en debug-tools voor stap-voor-stap troubleshooting

Eerst: is het echt een WSOD?

Voor je gaat sleutelen, controleer dat het écht een wit scherm is en niet iets anders. Een paar snelle checks:

Open je site in een incognito-venster. Soms zie je een wit scherm omdat je browser een corrupte cache toont. In een incognito-venster wordt er geen cache geladen. Werkt de site daar wel, dan is het geen WSOD maar een cache-probleem.

Probeer een andere pagina. Is alleen de homepage wit, of alles? Werkt /wp-admin/ wel? Dat informatie verkleint het probleem.

Kijk in de browser-console. Druk op F12 in Chrome of Firefox, ga naar het tabblad “Console” of “Network”. Soms staat daar een 500-fout, een 504-timeout, of een ander signaal dat helpt.

Test vanuit een andere internetverbinding. Mobiel datanetwerk werkt prima om te bevestigen dat het niet jouw lokale internet is.

Is de site overal wit, ook in incognito, ook op mobiel data? Dan is het waarschijnlijk WSOD. Door naar stap 1.

Stap 1: zet WP_DEBUG aan

Een wit scherm is feitelijk PHP dat halverwege stopt zonder bericht. Standaard staat in WordPress de debug-uitvoer uit, omdat fouten zichtbaar maken op een live site een veiligheidsrisico is. Maar tijdelijk aanzetten om de oorzaak te zien, is precies wat je nu nodig hebt.

Open wp-config.php via FTP, SFTP of de file manager van je hoster. Zoek de regel:

define( 'WP_DEBUG', false );

Verander false naar true. Voeg daarnaast deze regels toe:

define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Met deze combinatie schrijft WordPress de foutmeldingen naar een logbestand in wp-content/debug.log, zonder ze zichtbaar te maken op de live site. Veiliger dan ze direct in beeld zetten.

Bezoek de site, vernieuw de pagina, en open daarna het bestand wp-content/debug.log via FTP. Daar staan de fouten die de WSOD veroorzaken. Vaak zie je iets als:

“Fatal error: Uncaught Error: Call to undefined function…”
“Allowed memory size of X bytes exhausted”
“Maximum execution time of 30 seconds exceeded”

De volgende stap hangt af van wat er in dat log staat.

WP_DEBUG aanzetten in wp-config.php toont de PHP-foutmelding achter een WordPress wit scherm

Stap 2: PHP-geheugen verhogen (memory limit)

Als de foutmelding “Allowed memory size of X bytes exhausted” bevat, zit je PHP-geheugenlimiet vol. WordPress vraagt meer RAM dan de server bereid is te geven. Vooral op shared hosting met een lage standaardlimiet (32M of 64M) komt dit voor.

In wp-config.php, ergens boven de regel /* That's all, stop editing! */, voeg toe:

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

Werkt dat niet, dan zit de limiet op PHP-niveau en moet je via php.ini, .htaccess of je hosting-paneel verhogen. In php.ini:

memory_limit = 256M

In .htaccess (Apache-hosters):

php_value memory_limit 256M

Bij veel moderne hosters (Hostinger, TransIP, Combell) zit de PHP-limiet in het hosting-paneel onder “PHP-instellingen”. Verhoog daar naar 256M of 512M, sla op, vernieuw de site.

Werkt het na de aanpassing nog steeds niet en blijft het log dezelfde foutmelding gooien? Dan vraagt een plugin of thema gewoon te veel geheugen. Door naar plugin-isolatie.

Stap 3: plugin-conflict isoleren

De meest voorkomende oorzaak van een WSOD na een update is een plugin-conflict. Eén plugin botst met een andere, of met een recente WordPress-versie, of met een PHP-versie. De truc is om de boosdoener te vinden zonder alle plugins permanent uit te schakelen.

Via FTP. Ga naar wp-content/plugins. Hernoem de map plugins naar plugins-uit. Daarmee schakelt WordPress alle plugins in één klap uit. Bezoek je site. Werkt hij weer? Dan zit het probleem in een van die plugins.

Hernoem de map terug naar plugins. Ga dan plugin per plugin de individuele mappen hernoemen (bijvoorbeeld wpforms naar wpforms-uit). Vernieuw de site na elke wijziging. Wanneer de site weer faalt, heb je de boosdoener.

Via wp-admin (als de admin nog werkt). Soms is alleen de frontend wit en doet wp-admin het wel. Dan kun je via Plugins → Geïnstalleerde plugins de plugins één voor één deactiveren. Zelfde principe, maar dan veiliger zichtbaar.

Veelvoorkomende oorzaken bij plugin-conflicten:

een caching-plugin met agressieve instellingen
een security-plugin die per ongeluk een legitieme functie blokkeert
een verouderde plugin die nooit is bijgewerkt voor de huidige PHP-versie
een nieuwe plugin die net is geïnstalleerd en niet samenwerkt met een bestaande

Plugin isolatie via FTP door plug-in folder te hernoemen om de oorzaak van een WordPress wit scherm te vinden

Stap 4: thema-fallback

Geen van de plugins veroorzaakt het probleem? Dan is het waarschijnlijk je thema. Vooral na een thema-update, of na een PHP-upgrade van de hoster, kan een thema-functie breken.

Test door tijdelijk over te schakelen naar een standaard WordPress-thema (Twenty Twenty-Four of Twenty Twenty-Five). Werkt de site dan wel? Dan zit het probleem in je eigen thema.

Via FTP. Hernoem de map van je actieve thema in wp-content/themes. WordPress valt dan automatisch terug op een standaardthema (als dat geïnstalleerd is). Werkt de site weer? Bevestiging dat het thema de oorzaak is.

Bij een eigen of aangepast thema is de volgende stap kijken in functions.php of in recent gewijzigde template-bestanden. Een tikfout, een verkeerd geplaatste ;, een PHP-functie die in de nieuwe PHP-versie niet meer bestaat: het zijn de klassiekers.

Bij een gekocht thema is het vaak een kwestie van de nieuwste versie installeren via de marketplace waar je hem hebt gekocht (ThemeForest, MyThemeShop, of de officiële WordPress-themarepository).

Stap 5: bestanden of permissies kapot

Komt zelden voor, maar wel: corrupte bestanden in de WordPress core, of verkeerde bestandsrechten op de server.

Een corrupte core herstel je door een schone kopie van WordPress te downloaden van wordpress.org en de mappen wp-admin en wp-includes te overschrijven via FTP. De map wp-content laat je staan, want daar staan je eigen plugins, thema’s en uploads.

Verkeerde bestandsrechten (permissions) geven soms een wit scherm bij toegang tot specifieke pagina’s. De standaardrechten op een WordPress-installatie zijn:

mappen: 755
bestanden: 644
wp-config.php: 600 of 640 (strenger, omdat dit gevoelige info bevat)

Bij twijfel: vraag bij je hoster of hij dit kan resetten. De meeste hosters hebben een functie “permissies herstellen” in het paneel.

Stap 6: PHP-versie controleren

Soms is de oorzaak structureel: je site draait op een te oude (of in zeldzame gevallen te nieuwe) PHP-versie. WordPress vraagt op dit moment minimaal PHP 7.4, maar aanbeveling is PHP 8.1 of hoger.

Een plugin of thema dat alleen werkt met PHP 7.x kan crashen op PHP 8.x. Andersom kan ook: een verouderd thema crasht omdat een functie uit PHP 5.x is verwijderd.

In het hosting-paneel kun je vaak de PHP-versie wisselen. Doe dit op een kopie of staging-omgeving als die er is. Test plugin voor plugin of alles werkt. Als veel plugins falen, is de site toe aan een grondige update-ronde, niet aan een snelle PHP-switch.

Wat ik nooit zou doen

Een aantal “snelle” oplossingen die meer kapot maken dan ze repareren.

Niet alle plugins tegelijk verwijderen. Hernoemen is omkeerbaar, verwijderen niet. Hernoemen behoudt alle plugin-instellingen in de database.

Niet de hele wp-content map vervangen. Dat wist alle uploads, eigen plugin-configuraties en je actieve thema. Wel wp-admin en wp-includes mogen vervangen worden, want die zijn standaard core-code.

Niet WP_DEBUG aan laten staan na de reparatie. Het foutlog blijft groeien en op een live site is dit een lichte info-leak. Zet het terug op false zodra je site werkt.

Niet eerst een tweede plugin installeren om de eerste te repareren. Dat is het tegenovergestelde van isolatie. Eerst opruimen, dan pas toevoegen.

Wat het kost om door iemand anders te laten doen

Een WSOD-reparatie valt voor mij meestal binnen één tot drie uur werk, afhankelijk van waar het zit. Plugin-isolatie en debug-mode aanzetten is in een half uur klaar als de toegangen op orde zijn. Een dieper PHP- of thema-probleem kan een halve dag kosten.

Tarief: 70 euro per uur voor standaardwerk, 95 euro per uur voor migratie, serverwerk en database. Spoed buiten kantooruren 105 euro per uur. Tijdregistratie afgerond per 15 minuten. Minimum per factuur 50 euro. Alle bedragen exclusief btw.

Wat ik graag vooraf weet als je me belt of mailt: de URL, je hoster, wat je als laatste hebt aangeraakt (plugin-update, themewijziging, migratie, PHP-versie). Met die info schat ik snel of het 30 minuten werk is of een halve dag.

Verbeteren boven herbouwen. Een WSOD is geen reden om de hele site opnieuw op te zetten. In bijna alle gevallen is herstel goedkoper en sneller dan herbouw. Meer over onderhoud lees je in de categorie website onderhoud. De officiële WordPress-documentatie over debugging is een goede technische referentie.