Wat betekent een wit scherm in WordPress?

Een wit scherm betekent meestal dat het PHP-verzoek is gestopt zonder dat de fout aan bezoekers wordt getoond. Een plugin, thema, maatwerkcode, geheugenfout of serverprobleem kan de oorzaak zijn, dus gebruik herstelmodus en logs om de juiste laag te vinden.

Waarom is maar één WordPress-pagina wit?

Dan is routegebonden code waarschijnlijker, zoals een template, blok, shortcode of pluginfunctie die alleen op die pagina draait. Noteer de exacte URL en vergelijk het log van die pagina met een pagina die wel werkt.

Waar vind ik de e-mail voor WordPress-herstelmodus?

WordPress stuurt die naar het beheeradres van de site wanneer het tijdens een gewone paginalaadactie een geschikte fatale PHP-fout opvangt. Controleer spam en mailbezorging, maar gebruik logging of SFTP als de mail niet aankomt.

Mag ik WP_DEBUG aanzetten op een live WordPress-site?

Alleen kort en gecontroleerd als dat nodig is. Schrijf fouten naar een beschermd log, houd WP_DEBUG_DISPLAY op false, deel geen gevoelige logregels en verwijder de tijdelijke instellingen en het log na de diagnose.

Hoe schakel ik een plugin uit als wp-admin wit blijft?

Hernoem via SFTP of het hostingbeheer eerst alleen de map van de plugin die het log aanwijst. Is er geen kandidaat, hernoem dan tijdelijk de hele map wp-content/plugins, test één keer en herstel de oorspronkelijke naam als het scherm wit blijft.

Lost een hogere WordPress-geheugenlimiet een wit scherm op?

Alleen wanneer een logregel letterlijk meldt dat de toegestane geheugengrootte is uitgeput. Verhoog nooit onbeperkt en onderzoek welke plugin, afbeelding, import of query het geheugen verbruikt.

Wanneer moet ik de hostingprovider inschakelen?

Doe dat als je geen herstelbare back-up of logs hebt, ook statische bestanden niet laden, PHP-instellingen onduidelijk zijn of de fout blijft nadat je de genoemde plugin, het thema en een recente wijziging veilig hebt uitgesloten.

Wit scherm in WordPress oplossen: veilige diagnose (2026)

Een wit scherm in WordPress betekent meestal dat PHP is gestopt zonder een foutmelding aan bezoekers te tonen. Maak eerst een herstelbare back-up, controleer de WordPress-herstelmail of een beschermd foutlog en schakel daarna alleen het onderdeel uit dat het bewijs aanwijst.

Bepaal welk deel van de site wit blijft

Test zonder iets te wijzigen een vaste set adressen:

de startpagina;
één bericht of pagina;
/wp-admin/;
/wp-login.php;
een bestaand statisch bestand, zoals een afbeelding.

Noteer per adres het exacte tijdstip en wat je ziet. Werkt het beheer maar de voorkant niet, dan zijn het actieve thema, pagina-cache of routegebonden pluginlogica aannemelijker. Is alleen één pagina wit, kijk dan naar de template, blokken, shortcodes en gegevens die juist die pagina gebruikt. Zijn zowel voorkant als beheer leeg, dan kan een vroeg geladen plugin, thema, PHP-configuratie of serverlaag falen.

Controleer ook de echte HTTP-status in de browsernetwerkinformatie of het hostingpaneel. Een lege respons met status 200 vraagt een andere analyse dan een 500 Internal Server Error. Zie je de tekst over een kritieke fout of heb je een herstelmail, gebruik dan ook de beslisroute voor een kritieke WordPress-fout.

De officiële WordPress-uitleg over veelvoorkomende fouten noemt zowel PHP- als databasefouten als mogelijke bron van een wit scherm. Trek daarom nog geen conclusie uit het uiterlijk alleen.

Maak eerst back-up en rollback concreet

Maak vóór wijzigingen een database-export en een kopie van de WordPress-bestanden. Neem in elk geval wp-config.php, .htaccess en de hele map wp-content mee. De officiële WordPress-back-uphandleiding legt uit dat bestanden en database samen één herstelset vormen.

Controleer of je het herstelpunt kunt terugvinden en hoe je het terugzet. Download van elk bestand dat je wilt aanpassen eerst een ongewijzigde kopie met datum. Noteer bij iedere test:

welke ene laag je verandert;
welke URL en handeling je daarna test;
wat het resultaat is;
hoe je de vorige staat direct herstelt.

Werk bij een winkel, boekingssysteem of druk bezocht formulier bij voorkeur eerst in staging. Het terugzetten van een oude database kan nieuwe bestellingen of inzendingen overschrijven.

Stap voor stap het witte scherm herstellen

1. Controleer cache en een onafhankelijke sessie

Open de pagina in een privésessie en op een tweede apparaat. Werkt de pagina daar wel, verwijder dan alleen cookies en sitegegevens voor het getroffen domein. Leeg daarna gericht de pagina-, server- of CDN-cache die jouw site gebruikt.

Een cache kan een eerder opgeslagen lege respons blijven tonen, maar herhaald wissen is geen diagnose. Blijft het scherm wit voor onafhankelijke bezoekers, ga dan verder en leg opnieuw het tijdstip vast.

2. Gebruik de WordPress-herstelmodus

Controleer de inbox en spammap van het beheeradres op een bericht over technische problemen. De officiële documentatie voor Recovery Mode legt uit dat WordPress bij bepaalde fatale PHP-fouten een speciale inloglink stuurt. Die modus pauzeert het foute onderdeel alleen voor jouw beheersessie en toont aanwijzingen in het dashboard.

Log via die unieke link in, noteer welke plugin of welk thema wordt genoemd en deactiveer alleen dat onderdeel. Verwijder het niet. Controleer eerst of er een compatibele update of veilige vorige versie is. Verlaat de herstelmodus pas nadat de voorkant, het beheer en de oorspronkelijke foutactie opnieuw zijn getest.

Geen e-mail betekent niet dat er geen fatale fout is. Herstelmodus start bijvoorbeeld niet voor iedere achtergrondtaak, en mailbezorging kan zelf stuk zijn. Ga dan verder met de logs.

3. Lees het server- of PHP-log op het juiste tijdstip

Open eerst het PHP- en serverfoutlog in het hostingpaneel. Herhaal één verzoek naar de witte pagina en zoek direct rond dat tijdstip. Noteer fouttype, bestand en regelnummer, maar deel geen cookies, tokens, formulierinhoud, volledige serverpaden of persoonsgegevens.

Als WordPress ver genoeg opstart, kun je tijdelijk loggen volgens de officiële WordPress-debughandleiding:

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

Plaats de regels vóór de afsluitende opmerking in wp-config.php en voorkom dubbele definities. Op productie blijft WP_DEBUG_DISPLAY op false, zodat bezoekers geen technische details zien. Bescherm debug.log tegen publieke toegang en verwijder of archiveer het veilig zodra de diagnose klaar is.

Een leeg WordPress-log sluit een fout niet uit. PHP of de webserver kan stoppen voordat WordPress zijn eigen logging initialiseert. De hostinglog is dan leidend.

4. Draai de laatste aantoonbare wijziging terug

Begon het witte scherm direct na een plugin-, thema-, PHP- of code-update, draai dan alleen die wijziging terug vanuit een geverifieerde back-up. Test exact dezelfde route en actie. Blijft het scherm wit, herstel dan de uitgangssituatie voordat je een andere laag onderzoekt.

Upload geen willekeurige oudere plugin van een downloadsite. Gebruik de officiële leverancier of je eigen werkende back-up. Pas geen WordPress-corebestanden aan om een foutmelding te onderdrukken.

5. Isoleer plugins zonder instellingen te verwijderen

Noemt het log een pluginbestand, hernoem dan via SFTP of het hostingbeheer alleen die pluginmap. Voeg bijvoorbeeld .test-uit aan de naam toe, test één keer en herstel de oorspronkelijke naam als de fout blijft. Verwijderen is niet nodig en maakt rollback moeilijker.

Is er geen duidelijke kandidaat en is het beheer onbereikbaar, hernoem dan tijdelijk wp-content/plugins naar plugins.test-uit. Dit is ook de aanpak uit de officiële WordPress-handleiding voor het uitschakelen van plugins zonder beheerscherm.

Werkt de site daarna, zet de mapnaam exact terug en activeer plugins één voor één totdat de fout terugkomt. Controleer na iedere activatie dezelfde route. Normale plugins uitschakelen raakt must-use plugins en drop-ins zoals object-cache.php niet. Onderzoek die alleen wanneer het log of de hostingconfiguratie ernaar verwijst.

6. Test het actieve thema met een veilige terugval

Wijst het log naar het actieve thema of begon de fout direct na een themawijziging, schakel dan in herstelmodus of staging tijdelijk naar een geïnstalleerd standaardthema. Werkt de site daarmee, herstel dan eerst de presentatie en onderzoek het genoemde template, functions.php of recente maatwerk.

Kun je niet inloggen, hernoem de actieve themamap alleen wanneer je vooraf hebt gecontroleerd dat een geschikt standaardthema is geïnstalleerd. Bewaar de originele mapnaam en zet die direct terug als de test niets verandert. Een wit scherm na het hernoemen zonder terugvalthema levert geen bruikbaar bewijs.

Maak structurele aanpassingen in een child-thema of de broncode met versiebeheer. Een snelle wijziging in het actieve productiethema kan bij een volgende update verdwijnen.

7. Verhoog geheugen alleen bij een passende foutregel

Zoek naar Allowed memory size exhausted in het log. Alleen dan is een geheugentest onderbouwd. De bestandsnaam op die regel is het punt waar de laatste allocatie mislukte en niet automatisch de werkelijke verbruiker.

Meet eerst de effectieve PHP-limiet via Gereedschap > Sitediagnose > Informatie > Server of het hostingpaneel. WordPress kan een limiet aanvragen, maar de server bepaalt of die verhoging is toegestaan. De officiële WordPress-uitleg over PHP-geheugen waarschuwt bovendien dat een verhoging de echte oorzaak kan verbergen.

Gebruik nooit een onbeperkte limiet. Verhoog alleen tijdelijk en begrensd volgens de hostingcapaciteit, herhaal dezelfde handeling en onderzoek welke plugin, query, import of afbeelding het geheugen gebruikt. Volg daarvoor de volledige handleiding voor een WordPress memory limit-fout.

8. Controleer PHP, server en database met bewijs

Controleer of de actieve PHP-versie en extensies passen bij WordPress, het thema en de plugins. Een versie in de opdrachtregel kan afwijken van de versie die webverzoeken gebruikt. Bevestig daarom de actieve webomgeving in het hostingpaneel.

Wijst het log naar een ontbrekende PHP-functie, onleesbaar bestand, verkeerd eigenaarschap of serverconfiguratie, laat de host de betreffende laag controleren. Zet bestandsrechten niet breed op 777. Dat vergroot het risico en herstelt verkeerd eigenaarschap niet betrouwbaar.

Toont WordPress expliciet Error establishing a database connection, gebruik dan de aparte databaseverbindingshandleiding. Repareer of importeer geen tabellen alleen omdat de pagina wit is.

9. Valideer herstel en ruim diagnose op

Test na de oplossing:

de oorspronkelijke witte URL;
startpagina en een andere inhoudspagina;
/wp-login.php en /wp-admin/;
de actie die de fout veroorzaakte;
geplande taken of formulieren die bij het onderdeel horen;
het PHP- en serverlog op nieuwe fouten.

Heractiveer tijdelijk uitgeschakelde cache- en beveiligingslagen één voor één. Zet debug terug naar de productie-instelling, houd foutweergave uit en ruim gevoelige logbestanden op. Noteer de oorzaak, de werkende wijziging en de rollback. Eén geslaagde paginalaadactie is geen garantie dat een import, cronjob of formulier ook gezond is.

Veelgemaakte fouten

Foutmeldingen op de live pagina tonen. Gebruik een beschermd log en houd WP_DEBUG_DISPLAY op productie uit.
Een volledig debuglog delen. Logs kunnen persoonsgegevens, serverpaden, tokens en andere gevoelige informatie bevatten.
Alle plugins, het thema en PHP tegelijk wijzigen. Dan weet je niet welke laag de oorzaak was.
De laatst genoemde bestandsnaam automatisch als schuldige zien. Een ander onderdeel kan eerder al het geheugen of de foutstatus hebben veroorzaakt.
Plugins of thema's direct verwijderen. Hernoemen of deactiveren bewaart een duidelijke rollback.
De geheugenlimiet blijven verhogen. Zonder passende logregel maskeer je mogelijk een lus, zware query of foutieve import.
Een themamap hernoemen zonder terugvalthema. Dan kan WordPress nog steeds geen pagina renderen.
Bestandsrechten op 777 zetten. Dit is geen veilige algemene reparatie.
Stoppen zodra de startpagina werkt. Controleer ook beheer, foutactie, formulieren en logs.

Hulp bij een blijvend wit scherm

Stop met wijzigen als je geen herstelbare back-up hebt, geen logs kunt openen, de serverlaag faalt of de site actuele transacties verwerkt. Verzamel de getroffen URL, het exacte tijdstip, de laatste wijziging en enkele opgeschoonde foutregels. Bekijk andere beslisroutes op de WordPress-hub.

Blijft de oorzaak onduidelijk of wil je dat de reparatie en controle veilig worden uitgevoerd, beschrijf dan wat er gebeurde en stel je vraag via het contactblok hieronder.