Je zit in je dashboard, klikt wat rond en plots is alles wit. Geen foutmelding, geen 500, niks. Dat is de white screen of death (WSOD), en het is de meest frustrerende fout die WordPress kent. Niet omdat hij zo complex is, maar omdat WordPress je gewoon niets vertelt.
Wat er echt gebeurt: PHP stopt halverwege met uitvoeren. Ergens botst een script op een fatal error — een ontbrekende functie, een verkeerd datatype, een geheugenlimiet — en omdat display_errors op productieservers standaard uit staat, zie je daar niets van. Alleen een lege pagina waar je site hoorde te staan.
Dat is meteen het belangrijkste inzicht: een wit scherm in WordPress is niet de fout, het is de verberging van de fout. Zodra je de melding zichtbaar maakt, is het probleem vaak binnen vijf minuten opgelost. Wie meteen in paniek de hele site opnieuw installeert, gooit gegevens weg die nergens voor nodig waren.
Zet eerst je foutmeldingen aan, anders blijf je gokken
Open wp-config.php via FTP of SFTP en zoek de regel define(‘WP_DEBUG’, false);. Zet die op true en voeg er deze twee regels onder: define(‘WP_DEBUG_LOG’, true); en define(‘WP_DEBUG_DISPLAY’, false);.
Door fouten naar een logbestand te schrijven in plaats van naar het scherm, voorkom je dat bezoekers ze zien. De melding verschijnt in /wp-content/debug.log. Staat dat bestand leeg? Kijk dan in het errorlog van je hosting. Veel PHP-fatal errors belanden daar en niet in het WordPress-log, zeker als de fout optreedt voordat WordPress volledig is geladen. Dat onderscheid scheelt je soms een uur zoeken.
Als je WP-CLI hebt, kun je ook wp config set WP_DEBUG true –raw gebruiken. Sneller dan handmatig prutsen in een editor.
Oorzaak 1: het PHP-geheugen is te krap
Dit is verreweg de nummer één oorzaak van een wit scherm in WordPress bij grotere sites met zware plugins. Elementor, WooCommerce, SEO-suites en page builders vreten geheugen. Loopt PHP tegen de limiet aan, dan kapt het script er per direct mee zonder nette melding.
Voeg in wp-config.php deze regel toe, vóór de regel die zegt dat je klaar bent met bewerken: define(‘WP_MEMORY_LIMIT’, ‘256M’); en voor het dashboard define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);.
Let op de nuance: WP_MEMORY_LIMIT werkt alleen als je hostingpartij de serverbrede limiet niet lager heeft vastgezet. Blijft je scherm wit, dan moet de memory_limit in php.ini omhoog via je provider. Een losse regel in wp-config.php kan een harde serverlimiet niet altijd overschrijven. Dat is geen kwestie van pech, dat is een kwestie van wie de baas is over de server — en dat is je host, niet jij.
Oorzaak 2: een plugin of thema met kapotte code
Een update die half is doorgekomen, een plugin die op een oude PHP-versie niet meer draait, of twee plugins die dezelfde functie herdefiniëren — allemaal bekende triggers voor een wit scherm in WordPress. Vooral plugins die in 2026 nog steeds niet compatibel zijn met PHP 8.2 of hoger zorgen voor problemen.
De snelste test: hernoem tijdelijk de map /wp-content/plugins naar plugins-uit. Is je site weer zichtbaar, dan zit de dader tussen je plugins. Zet ze één voor één terug en ververs na elke stap. Met WP-CLI gaat het sneller: wp plugin deactivate –all en daarna wp plugin activate pluginnaam om de dader te isoleren.
Heb je alleen een wit scherm in het dashboard en niet op de site zelf, dan sloopt een plugin waarschijnlijk de adminomgeving en niet de frontend. Dat is een ander spoor, vaak een database- of autoloadprobleem in plaats van een codefout. Kijk dan naar de wp_options tabel en of er een enorme autoloaded data is opgeslagen.
Oorzaak 3: PHP-versie en compatibiliteit
Hostingpartijen duwen je PHP-versie automatisch omhoog. Een thema uit 2019 draait prima op PHP 7.4 en klapt om op PHP 8.2. Deprecated-waarschuwingen zijn nog te overleven, maar verwijderde functies en oude constructies zoals create_function zijn fataal.
Zet je PHP-versie in het hostingpaneel tijdelijk terug en test opnieuw. Werkt alles weer, dan weet je dat de code van je thema of plugin verouderd is en dat migreren de enige echte oplossing is, niet eindeloos patchen. Ik heb te vaak gezien dat mensen maandenlang een oude PHP-versie blijven draaien omdat één plugin niet meewerkt. Dat is vragen om problemen, want op een dag zet je host die versie gewoon uit.
Dezelfde logica geldt voor je WordPress-kern. Een automatische major update gecombineerd met een thema dat niet is bijgewerkt, is een klassieke witte-schermcombinatie. Zet automatische updates voor plugins en thema’s liever uit en doe ze handmatig na een back-up. Automatische updates zijn handig, maar niet als je geen stagingomgeving hebt.
Oorzaak 4: een corrupte database
Een tabel die crasht tijdens het schrijven, een vastgelopen query, of een import die halverwege is afgebroken. Symptoom: de site geeft wit, het dashboard geeft wit, of je krijgt een melding over de databaseverbinding.
Repareren kan via de MySQL-console met het commando mysqlcheck -u gebruikersnaam -p databasenaam -r, of met wp db repair als je WP-CLI hebt. In phpMyAdmin selecteer je de tabellen en klik je gewoon op repareren. Krijg je de melding dat je geen toegang hebt, controleer dan je gegevens in wp-config.php. Een verkeerd gespelde DB_NAME of een wachtwoord met een aanhalingsteken dat niet goed is geëscaped geeft exact hetzelfde witte scherm.
Dit is ook waar veel mensen de fout maken door blindelings een back-up terug te zetten zonder te kijken wat er misging. Als je database corrupt is geraakt door een plugin die slechte queries schrijft, komt het probleem terug zodra je die plugin weer activeert.
Oorzaak 5: .htaccess, bestandsrechten en vastgelopen fixes
Een verkeerde regel in .htaccess kan een redirect-loop of een 500 veroorzaken die je browser als lege pagina toont. Hernoem het bestand naar .htaccess-oud en ververs. Werkt je site weer, ga dan naar Instellingen > Permalinks en sla opnieuw op: WordPress bouwt het bestand netjes op.
Bestandsrechten zijn de volgende verdachte. Mappen horen op 755 te staan, bestanden op 644, en wp-config.php mag 600 zijn. Alles op 777 zetten is geen oplossing maar een open deur voor kwaadwillenden. Ik heb sites gezien die jarenlang op 777 draaiden en verbaasd waren dat ze gehackt werden.
Het functions.php-bestand van je thema kan de boel ook slopen. Hernoem het tijdelijk via FTP — niet via de thema-editor, want die kun je daarna niet meer bereiken. Als je een syntaxfout in functions.php hebt gemaakt, krijg je namelijk precies hetzelfde witte scherm.
De noodroute: langs FTP naar een werkende site
Je kunt niets doen in het dashboard, dus je moet om WordPress heen werken. Verbind met een FTP-client en hernoem de map /wp-content/plugins. Zet daarna via wp-config.php de WP_DEBUG-regels goed, zodat je ziet wat er misgaat.
Met WP-CLI gaat het sneller: wp plugin deactivate –all en daarna wp plugin activate pluginnaam om de dader te isoleren. Heb je SSH-toegang, dan is dat de koninklijke weg. Lukt dat niet, dan is het hernoemen van de themamap de volgende stap: WordPress schakelt terug naar een standaardthema en je weet meteen of de fout daar zit.
Een tip die ik zelf vaak gebruik: als je geen FTP meer hebt maar wel toegang tot je hostingpaneel, kun je via de bestandsbeheerder van cPanel of Plesk meestal ook bestanden hernoemen. Dat is geen elegante oplossing, maar het werkt als je haast hebt.
Wanneer je hostingpartij moet bellen, en wanneer niet
Zit de fout in coderegels, in een plugin of in je database, dan kan je provider weinig voor je doen. Zie je echter niets in je debug.log, staat je PHP-versie niet waar je hem verwacht of heb je geen toegang tot de foutlogs, dan is dat juist wél hun terrein.
Vraag concreet om de laatste PHP-foutmelding rond het tijdstip dat je site wit werd. Elke serieuze host heeft die gegevens. Een vaag bericht als ‘mijn site is stuk’ levert een vaag antwoord op; een tijdstip plus een logbestand levert een oplossing op. Dat is het verschil tussen een dag wachten en een uur wachten.
Zo voorkom je dat een wit scherm in WordPress terugkomt
- Draai updates eerst op een stagingomgeving, niet direct op je live site.
- Maak een back-up van bestanden én database voordat je iets aanraakt.
- Verwijder plugins die je niet gebruikt in plaats van ze alleen te deactiveren.
- Test je site op de PHP-versie waar je host naartoe gaat voordat die overstapt.
- Laat WP_DEBUG_LOG aanstaan op staging, maar nooit op productie.
- Houd je thema en plugins actief bij, want verouderde code is de grootste voorspeller van een wit scherm in WordPress.
De kern blijft simpel: een wit scherm in WordPress is een foutmelding die je even niet mag zien. Maak hem zichtbaar, isoleer daarna de plugin, het thema of de database, en je hebt hem meestal binnen een half uur te pakken. Wie meteen in paniek de hele site opnieuw installeert, gooit gegevens weg die nergens voor nodig waren.
