White Screen of Death in WordPress – oorzaken en oplossingen

De “white screen of death” (WSoD) is een veelvoorkomende WordPress-fout waarbij je website alleen een blanco wit scherm toont in plaats van je content. Deze fout kan zowel voor beheerders als bezoekers optreden en geeft meestal geen directe foutmelding. In dit artikel lees je wat de WSoD is, waarom het gebeurt, en vooral hoe je dit probleem stap voor stap kunt oplossen. Ik bespreek ook wanneer je hulp van een expert moet inschakelen en hoe je kunt voorkomen dat dit in de toekomst opnieuw gebeurt.

Niets is zo schrikken als ineens een leeg wit scherm op je website. Je krijgt geen aanwijzing wat er mis is en zowel de voorkant als de back-end van je site kan onbereikbaar lijken. Gelukkig is deze White Screen of Death meestal niet zo fataal als het klinkt – het is zelfs een van de meest voorkomende WordPress-fouten en in de meeste gevallen goed op te lossen. Hieronder leg ik uit wat er aan de hand is en hoe je je site zo snel mogelijk weer online krijgt.

Wat is de WordPress White Screen of Death (WSoD)?

De White Screen of Death (WSoD) houdt in dat je WordPress-site niets anders laat zien dan een volledig wit scherm – geen inhoud, geen menu’s, mogelijk enkel een algemene HTTP 500 foutmelding. Het is alsof de website “dood” is, vandaar de dramatische naam. In sommige browsers zie je daarbij een melding dat de pagina niet werkt, bijvoorbeeld “This page isn’t working – HTTP ERROR 500” in Google Chrome.

Belangrijk om te weten: in recente WordPress-versies wordt in plaats van een leeg scherm vaak een boodschap getoond in de trant van “Er heeft zich een kritieke fout voorgedaan op deze site. Controleer je sitebeheerder e-mail voor instructies.” Dit is dezelfde fout – de WSoD – maar WordPress probeert je nu te helpen door een e-mail te sturen met meer informatie en een speciale herstelmodus. Vroeger kreeg je bij zo’n crash geen enkele melding te zien (alleen dat witte scherm). Als je deze “kritieke fout” melding ziet, kun je dus de instructies in de e-mail volgen om het probleem op te lossen. Zie je echter helemaal niets verschijnen (geen e-mail, geen melding), dan ervaar je de klassieke WSoD en moet je handmatig op zoek naar de oorzaak en oplossing.

Waarom gebeurt dit? – Typische oorzaken van een wit scherm

Een wit scherm in WordPress betekent vrijwel altijd dat er iets fundamenteel misgaat in de code of het geheugen van je site. Hier zijn de meest voorkomende oorzaken op een rij:

• Fout in een plugin (pluginconflict of slechte update): verreweg de meest voorkomende oorzaak is een probleem met een plugin. Bijvoorbeeld een bug of een conflict tussen twee plugins kan een fatale PHP-fout veroorzaken. Vaak gaat een site offline direct na het bijwerken of installeren van een nieuwe plugin. Slecht geschreven of verouderde plugins kunnen dit gedrag vertonen.
• Probleem met het thema: ook een defect of incompatibel thema kan de WSoD geven. Bijvoorbeeld als je een nieuw (of verouderd) thema activeert dat niet compatibel is met jouw WordPress-versie, kan de site crashen.
• PHP-codefouten of syntaxfouten: de white screen treedt bijna altijd op door fouten in PHP-code. Eén verkeerd teken of foutieve code in een bestand (bijvoorbeeld in functions.php van je thema, een pluginbestand, of zelfs WordPress-corebestanden als wp-config.php of .htaccess) kan het laden van de site volledig doen stoppen. Vooral als je kort ervoor handmatig code hebt toegevoegd of aangepast, is dit verdacht.
• Uitgeputte PHP-geheugenlimiet: WordPress heeft een bepaalde hoeveelheid geheugen tot zijn beschikking op de server. Als een script die limiet overschrijdt (bijvoorbeeld door een proces in een oneindige lus of een plugin die blijft hangen), dan breekt WordPress de uitvoer af. Er wordt geen foutmelding getoond omdat de server de uitvoering gewoon stopt – resultaat: een wit scherm. Onvoldoende geheugen of een te strenge max_execution_time instelling kan dus ook de boosdoener zijn.
• Mislukte update: soms gaat er iets mis tijdens het updaten van WordPress, een plugin of thema. Bijvoorbeeld een time-out tijdens een updateproces kan de site in onderhoudsmodus zetten en daar laten “hangen”. Als een update niet volledig is afgerond (of een bestand niet is verwijderd), kan dit leiden tot een blanco pagina tot het probleem is verholpen.
• Server- of bestandsrechten issues: minder vaak ligt de oorzaak buiten WordPress zelf – bijvoorbeeld foutieve bestandsrechten op de server of serverinstellingen die nodig zijn voor WordPress. Dit komt niet vaak voor, maar als alle andere oorzaken zijn uitgesloten, kan het probleem bij de serverconfiguratie liggen (in zo’n geval is hulp van de host nodig, zie verderop).

Zoals je ziet, komt het meestal neer op problemen met code (plugins/themes) of geheugen. Met deze kennis kan ik je stap voor stap laten troubleshooten om het witte scherm op te lossen.

Hoe los je de White Screen of Death op? (stapsgewijze oplossingen)

Wanneer je site onbruikbaar is door de WSoD, wil je dit natuurlijk zo snel mogelijk verhelpen. Hieronder bespreek ik stap voor stap meerdere oplossingen. Probeer ze in logische volgorde – na elke stap kun je je site vernieuwen om te zien of het probleem is opgelost. Maak bij voorkeur eerst een backup van je site voordat je dingen gaat aanpassen, zodat je altijd kunt terugvallen als er iets misgaat. (Heb je al een backup van voordat het probleem begon, dan kun je die ook overwegen terug te zetten.)

1. Deactiveer alle plugins (mogelijk conflict)

De eerste en meest simpele stap is om al je WordPress-plugins uit te schakelen. In veel gevallen is een plugin de schuldige – bijvoorbeeld een plugin-update die slecht is verlopen, of twee plugins die elkaar in de weg zitten. Door alle plugins te deactiveren kun je snel testen of de site dan weer laadt.

Als je nog toegang hebt tot je WordPress-dashboard: ga in het admin-menu naar Plugins → Geïnstalleerde plugins. Vink alle plugins aan, kies Deactiveren in het bulkacties-menu en bevestig. Hiermee zet je in één keer alle plugins uit. Controleer vervolgens de voorkant van je website. Doet de site het nu wel? Dan lag het probleem aan (een van) de plugins.

Zo ja – vind de boosdoener: activeer de plugins nu één voor één opnieuw en laad telkens je site opnieuw. Zodra de site weer wit wordt na het inschakelen van een specifieke plugin, heb je de veroorzaker te pakken. Verwijder of vervang die plugin, of neem contact op met de maker ervan voor een oplossing. De overige plugins kun je daarna weer activeren.

Als je niet in het wp-admin kunt komen: geen nood, je kunt plugins ook via FTP of het bestandsbeheer van je hosting uitschakelen. Log in op de serverbestanden en navigeer naar de wp-content map. Hernoem de map plugins bijvoorbeeld naar plugins_oud. Hiermee herkent WordPress de plugins niet meer en worden alle plugins gedeactiveerd (maak er dus niet gewoon weer plugins van totdat je klaar bent met testen). Probeer nu je site te laden. Werkt de site weer? Dan weet je dat een plugin de oorzaak was.

Vervolg in dat geval zoals hierboven: hernoem plugins_oud terug naar plugins en heractiveer één voor één je plugins (eventueel opnieuw via FTP hernoemen of via het dashboard als dat weer toegankelijk is) om uit te vinden welke plugin de fout triggerde. De plugin die bij activering opnieuw het witte scherm geeft, moet je verwijderen of updaten/vervangen.

(Als het uitschakelen van alle plugins niets verandert aan het probleem, hernoem dan de plugin-map weer terug naar plugins zodat je site de plugins weer herkent – je kunt dan tenminste je plugins behouden, zij het dat ze inactief blijven.)

2. Schakel over naar een standaard WordPress-thema

Is het probleem niet door een plugin veroorzaakt, dan kan een conflict in je actieve thema de WSoD veroorzaken. Vooral custom of verouderde thema’s willen nog wel eens problemen geven na een WordPress-update. De oplossing is om (tijdelijk) over te schakelen naar een standaardthema van WordPress.

Via wp-admin (als toegankelijk): ga naar Weergave → Thema’s in het dashboard. Activeer een recent WordPress default thema, bijvoorbeeld Twenty Twenty-One/Two/Three. Daarna bezoek je je site opnieuw. Laadt de site nu wel? Dan ligt het probleem aan je vorige thema.

Geen toegang tot wp-admin: gebruik weer FTP of het hosting-bestandsbeheer. Ga naar de folder wp-content/themes en hernoem de map van je actieve thema (bijv. mijnthema) naar iets als mijnthema_oud. Als er andere thema’s in de map staan, zal WordPress automatisch proberen te revert’en naar een standaardthema (zoals Twenty Twenty). Als je geen ander thema had geïnstalleerd, kun je vooraf via wordpress.org even een default thema downloaden en in de themes map plaatsen.

Controleer daarna je site. Werkt deze nu? Dan was het thema inderdaad de oorzaak. In dat geval kun je het beste contact opnemen met de theme-developer of kijken of er een update/patch is voor het thema. Blijft het probleem bestaan, overweeg dan een ander thema te gebruiken dat beter wordt onderhouden.

3. Wis cache (indien van toepassing)

In sommige gevallen lijkt de WSoD alleen voort te duren door caching, terwijl de onderliggende oorzaak al is verholpen. Dit kan gebeuren als je wel bij de WordPress-backend kunt, maar de voorkant blijft wit. Oplossing: leeg zowel de browsercache als de WordPress cache (als je een caching-plugin gebruikt).

• Browsercache legen: forceer je browser om de pagina opnieuw te laden zonder cache. Dit doe je door op Windows Ctrl + F5 te drukken (op Mac Cmd + Shift + R). Je kunt ook in de instellingen van je browser de cache/geschiedenis wissen.
• Caching-plugin legen: gebruik je plugins als WP Rocket, W3 Total Cache, WP Super Cache, etc., dan hebben deze een knop of instelling om de cache te legen. Ga in je WP-dashboard naar de instellingenpagina van de betreffende caching-plugin en kies Delete/Empty Cache.

Nadat je dit gedaan hebt, bezoek je je site opnieuw. Als het goed is, zie je nu (als de oorspronkelijke fout al verholpen was) weer een normale pagina. Blijft het witte scherm ondanks het legen van de caches, dan ligt de oorzaak elders en kun je naar de volgende stap gaan.

4. Schakel de debug-modus in voor meer info

Wanneer de bovenstaande stappen het probleem nog niet hebben opgelost, of als je nog steeds niet kunt achterhalen wat de WSoD veroorzaakt, is het tijd om de debug mode van WordPress aan te zetten. In debug-modus laat WordPress wél foutmeldingen zien in plaats van een stil wit scherm, zodat je de oorzaak kunt opsporen.

Om debugging in te schakelen moet je het bestand wp-config.php aanpassen (dit bevindt zich in de hoofdmap van je WordPress-installatie). Open dit bestand via FTP of het hostingcontrolepaneel en zoek naar de regel:

define('WP_DEBUG', false);

Wijzig false naar true (staat deze regel er niet, voeg hem dan toe). Sla het bestand op en laad je website opnieuw.

In plaats van een lege pagina zou je nu wel tekst moeten zien – namelijk één of meerdere PHP-foutmeldingen bovenop een (gedeeltelijk) wit scherm. Zo’n foutmelding ziet er bijvoorbeeld zo uit:

Fatal error: Uncaught Error: Call to undefined function get_posts() in /var/www/html/wordpress/wp-content/plugins/mijn-plugin/plugin.php on line 38

In bovenstaand voorbeeld zie je dat de fout veroorzaakt wordt in een pluginbestand (.../wp-content/plugins/mijn-plugin/...). Dat is een duidelijke hint: de plugin “mijn-plugin” veroorzaakt waarschijnlijk het probleem en moet gedeactiveerd of gefixt worden. Kortom: de debug-output vertelt je meestal waar de fout zit (welk bestand/regel).

Ga op basis van deze info terug naar stap 1 of 2: schakel de betreffende plugin uit of vervang/patch de code op de genoemde plek. Je kunt ook de precieze foutmelding kopiëren en googelen – vaak kom je dan andere gebruikers tegen met dezelfde fout en mogelijk oplossingen (of updates van de plugin/theme).

Tip: zie je geen foutmelding verschijnen na het inschakelen van WP_DEBUG? Het kan dat de server het tonen van fouten blokkeert. WordPress maakt in debug-modus dan ook een logbestand aan. Kijk via FTP in de wp-content folder of er een debug.log is en open die om de fouten in te zien. Als ook die leeg is, vraag dan je host of zij serverfouten kunnen doorgeven – sommige hosts hebben error logging uitgeschakeld waardoor je zelf niets ziet.

Heb je gevonden wat er mis is? Vergeet dan niet de debug-modus weer uit te schakelen als je klaar bent (zet in wp-config.php de WP_DEBUG terug op false). Laat je dit namelijk aan staan, dan blijven foutmeldingen voor iedereen zichtbaar en dat wil je niet op een live-site.

5. Verhoog de PHP-geheugenlimiet

Krijg je in de foutmeldingen specifiek iets te zien als “Allowed memory size exhausted” of blijft na de voorgaande stappen het witte scherm hardnekkig, dan kan het helpen om meer geheugen toe te kennen aan WordPress. Hiermee voorkom je dat een zwaar proces de hele boel laat vastlopen omdat het geheugen op is.

Je kunt de PHP-memory limit op meerdere manieren verhogen. Probeer eerst de WordPress-manier via wp-config.php:

Open het wp-config.php bestand (zie vorige stap) en voeg ergens bovenin (bijvoorbeeld net voor de regel “That's all, stop editing”) de volgende code toe:

define('WP_MEMORY_LIMIT', '64M');

Sla op en test de site opnieuw. Hiermee vraag je WordPress om 64 MB geheugen te gebruiken in plaats van de standaard (meestal 40 MB voor een single site). Merk je geen verschil of blijft de foutmelding aangeven dat het geheugen op is, dan kun je een hoger getal proberen (bijv. 128M). Sommige hosts laten de WP_MEMORY_LIMIT echter niet overschrijven. In dat geval kun je ook via de server proberen de limiet te verhogen:

• Via .htaccess: voeg deze regel toe in het .htaccess bestand in de root van je site:

php_value memory_limit 128M

• Via php.ini: op veel servers kun je een php.ini (of php.ini.user) bestand in de site-root plaatsen of bewerken. Voeg daar memory_limit = 128M in toe.

Lukt het verhogen van de limiet niet of blijft de site onbereikbaar terwijl je zeker weet dat geheugen het probleem was, dan is er mogelijk een onderliggend probleem dat veel resources vreet (bijvoorbeeld een plugin met een geheugenlek). In dat geval is het raadzaam om een ontwikkelaar of hosting-support mee te laten kijken (zie ook de sectie over expert inschakelen).

Let op: zet de geheugenlimiet niet té hoog (256M is doorgaans ruim voldoende). Blijft een site zelfs dan geheugenproblemen geven, dan is er iets anders mis dat opgelost moet worden – het onbeperkt opvoeren van geheugen is geen duurzame oplossing en kan andere serverprocessen beïnvloeden.

6. Controleer op een mislukte update (.maintenance)

Is de WSoD opgetreden vlak na een update van WordPress core, een plugin of thema? Dan kan het zijn dat de update niet goed is voltooid. WordPress zet tijdens een update namelijk kort een .maintenance bestand in de hoofdmap, en verwijdert dat normaal weer. Als de update echter halverwege faalt, blijft dit achter en “bevriest” je site als het ware in onderhoudsmodus.

Oplossing: ga via FTP of File Manager naar de root (hoofdmapp) van je WordPress-site en zoek naar een bestand genaamd .maintenance (of een variant daarvan, soms met een tilde of iets ervoor/ernaar). Verwijder dit bestand en laad je site opnieuw.

Als de update eigenlijk al gelukt was maar alleen dat bestand nog roet in het eten gooide, zal nu alles weer normaal moeten werken.

Was de update daadwerkelijk niet afgerond, dan zal WordPress bij het herladen mogelijk opnieuw proberen up te daten of de update terugdraaien. Geef het even de tijd.

Lost dit het probleem nog niet op? Probeer dan de update handmatig uit te voeren volgens de officiële instructies van WordPress. Vooral bij core-updates kun je via FTP de nieuwste WordPress-versie uploaden (behalve de wp-content map) om ontbrekende of corrupte bestanden te herstellen.

7. Herstel recente codewijzigingen of zet een backup terug

Heb je kort voor het optreden van de WSoD handmatig code toegevoegd of aangepast (bijvoorbeeld in het thema, een plugin of via de functie-editor in wp-admin)? Dan is de kans groot dat daar ergens een foutje in geslopen is. Één enkele typefout of verkeerd geplaatst haakje kan de hele site laten crashen. Dit is precies de reden dat WordPress adviseert om nooit op een live-website in de code te editten.

Gelukkig is het op te lossen: maak via FTP verbinding en draai de recente wijziging terug. Verwijder de code die je toegevoegd had of vervang het bestand met een origineel exemplaar. Weet je niet precies welke wijziging de problemen veroorzaakt? Dan ben je nu extra blij als je regelmatig backups maakt van je site. Je kunt dan simpelweg een backup van vóór de crash terugplaatsen om weer een werkende situatie te hebben. Daarna kun je in een testomgeving uitzoeken wat er misging in de code.

Debug-tip: als je eerder de debug-modus had aangezet, kan de foutmelding ook direct wijzen op een “parse error” of syntaxfout in een bepaald bestand/regel. Je weet dan precies waar de fout zit in de code, zodat je die kunt herstellen.

8. (Zeldzaam) Lange pagina of bericht veroorzaakt WSoD

In uitzonderlijke gevallen kan een extreem lange pagina of blogbericht het witte scherm veroorzaken. Dit komt doordat PHP in de achtergrond teksten moet verwerken (bijvoorbeeld voor bepaalde regex-functies) en bij héél lange input kan vastlopen. Je merkt dit bijvoorbeeld als één specifieke pagina steeds niet laadt, terwijl de rest van de site het wel doet.

Oplossing voor gevorderden: je kunt de capaciteit van PHP om tekst te verwerken vergroten. Dit doe je door twee instellingen (de backtrack en recursion limits) te verhogen in je wp-config.php. Voeg deze regels toe in het bestand:

ini_set('pcre.recursion_limit', 20000000);
ini_set('pcre.backtrack_limit', 10000000);

Sla op en refresh de betreffende pagina. In veel gevallen zal de lange pagina nu wel laden. Mocht dit niet helpen, dan is de pagina mogelijk te zwaar – overweeg de content op te splitsen in meerdere pagina’s of secties.

Met bovenstaande methoden zou je de meeste WSoD-situaties moeten kunnen oplossen. Een simpele controle van plugins en thema’s verhelpt het probleem in de meeste gevallen. En door de debugmodus te gebruiken kun je beter inzicht krijgen in waar het misgaat, zodat je gericht een oplossing kunt toepassen.

Wanneer schakel je hulp van een expert in?

Niet iedereen voelt zich prettig bij het modificeren van websitebestanden of het uitpluizen van foutmeldingen – en dat hoeft ook niet. Schakel een expert in als je ondanks de bovenstaande stappen de website niet aan de praat krijgt, óf als je het simpelweg te technisch vindt worden. Er is geen schaamte in het vragen om hulp; een ervaren WordPress-specialist of ontwikkelaar kan vaak in korte tijd de oorzaak vinden en oplossen.

Zeker wanneer het probleem dieper ligt (bijvoorbeeld in de serverinstellingen, database of bestandsrechten) is professionele hulp verstandig. Zo kunnen problemen met file permissions (bestandsrechten) ook WSoD veroorzaken, maar het is af te raden hier zelf mee te experimenteren als je niet precies weet wat je doet – je kunt per ongeluk beveiligingsrisico’s creëren. Een expert of je hostingprovider kan dit veilig voor je nakijken en herstellen.

Kortom, aarzel niet om contact op te nemen met je host of een WordPress-deskundige als het probleem blijft. Als na alle oplossingen de site nog steeds onbereikbaar is, ligt de oorzaak mogelijk buiten WordPress (op serverniveau) – je hostingpartij kan dit dan verder onderzoeken. Het inschakelen van hulp kan je veel tijd en frustratie besparen, zodat jij je kunt richten op je eigen werk.

Tips om de WSoD in de toekomst te voorkomen

Helemaal voorkómen dat je ooit een white screen tegenkomt is lastig, maar je kunt het risico sterk verminderen door goed onderhoud en voorzorgsmaatregelen:

• Houd WordPress up-to-date: zorg dat je altijd de nieuwste versie van WordPress core, je thema’s en plugins draait. Veel wit-scherm-problemen ontstaan na updates wanneer verouderde thema’s of plugins niet meer compatibel zijn. Door regelmatig te updaten (en incompatibele software tijdig te vervangen) verklein je de kans op fouten.
• Gebruik betrouwbare plugins en thema’s: kies plugins en thema’s van goede kwaliteit, met een hoge beoordeling en recente updates. Vermijd overbodige of dubieuze plugins – hoe minder plugins, hoe minder kans op conflicten. Slecht geschreven of niet onderhouden extensies zijn een recept voor problemen.
• Maak altijd back-ups: regelmatige backups zijn je redding als er toch iets misgaat. Stel automatische dagelijkse back-ups in (veel hosts bieden dit, of gebruik een plugin) en maak extra een handmatige backup vóór je grote updates uitvoert. Zo kun je bij een calamiteit snel terug naar een werkende versie van je site.
• Test updates op een veilige plek: als je website kritiek is voor je bedrijf, overweeg dan een staging-omgeving of testsite. Daar kun je updates eerst uitproberen zonder dat je live-site risico loopt. Pas als alles werkt, voer je de updates op de live-site door. Dit voorkomt dat een foutieve update je productie-website onderuit haalt.
• Pas op met custom code: voeg je maatwerk code toe (bijv. in het functions.php-bestand of via code-snippets), doe dat dan zeer voorzichtig. Één typo kan de site laten crashen, zoals je hebt gezien. Test custom code bij voorkeur eerst lokaal of op een staging-site. Gebruik een child-theme voor aanpassingen aan thema’s, zodat je hoofdthema intact blijft.
• Monitor je website: gebruik een monitoringdienst of plugin die je waarschuwt als je site offline gaat of fouten geeft. Zo weet je meteen wanneer er iets mis is en kun je sneller ingrijpen. Ook error-logging plugins kunnen helpen om problemen vroegtijdig te signaleren voordat ze een WSoD veroorzaken.
• Onderhoud en veiligheidsmaatregelen: houd ook de PHP-versie van je hosting up-to-date (in overleg met je host) en zorg voor voldoende serverresources voor je site. Regelmatig onderhoud plegen – zoals database optimalisatie en het opschonen van ongebruikte plugins/themes – kan voorkomen dat kleine issues zich opstapelen tot grote problemen.

Conclusie

Een white screen of death in WordPress is in eerste instantie schrikken, maar meestal is de situatie niet zo ernstig als hij lijkt. Het witte scherm is vaak simpelweg WordPress’ manier om te zeggen dat er iets misging, zonder meteen prijs te geven wat. Met een gestructureerde aanpak – zoals in dit artikel beschreven – kun je in de meeste gevallen de oorzaak vinden en je site weer online krijgen.

Samengevat: begin bij de usual suspects (plugins en thema’s), gebruik de debug-modus om technische details te zien, en voer waar nodig oplossingen door zoals het verhogen van het geheugen of terugdraaien van een fout. Houd je WordPress-omgeving gezond door updates, backups en kwalitatieve plugins/themes, dan voorkom je veel ellende.