Zie je op je WordPress-site alleen nog de witte pagina met "Er is een kritieke fout opgetreden op deze website"? Dan is er een PHP-fout die WordPress laat vastlopen — bijna altijd veroorzaakt door een plugin, een thema of een PHP-versie die niet samengaan. Je site is niet kwijt: de echte foutmelding staat in de recovery-mail van WordPress of in de error_log op je hosting, en daarmee vind je de boosdoener meestal binnen een kwartier. Hieronder loop ik stap voor stap met je mee.
Wat betekent deze melding eigenlijk?
WordPress is gebouwd in PHP. Elke keer dat iemand een pagina opvraagt, voert de server honderden PHP-bestanden uit: de WordPress-core, je thema en al je plugins. Gaat er in één van die bestanden iets onherstelbaar mis — een zogeheten fatal error — dan stopt PHP er direct mee. Sinds WordPress 5.2 krijg je dan niet meer het beruchte witte scherm, maar deze nette melding.
Belangrijk om te weten: de melding zelf vertelt je bewust níét wat er misgaat. Dat is een veiligheidskeuze — de technische details kunnen aanvallers informatie geven over je site. De echte foutmelding staat op twee plekken:
- De recovery-mail. WordPress stuurt bij een kritieke fout automatisch een e-mail naar het beheerdersadres van de site, met daarin de exacte fout én een speciale link om in "herstelmodus" in te loggen.
- De error_log. Op de server houdt PHP een logbestand bij waarin elke fatale fout wordt weggeschreven, inclusief het bestand en het regelnummer waar het misging.
Zolang je die informatie niet hebt, ben je aan het gokken. Dus daar beginnen we.
Wat zijn de meest voorkomende oorzaken?
In mijn praktijk — ik beheer sinds 2006 servers voor zo'n duizend mkb-klanten — zie ik drie oorzaken telkens terugkomen:
1. Een plugin-update die een PHP-fout veroorzaakt
Verreweg de vaakst voorkomende oorzaak. Een plugin wordt bijgewerkt (vaak automatisch, midden in de nacht) en de nieuwe versie bevat een fout of botst met een andere plugin. 's Ochtends ligt de site eruit en heeft niemand iets aangeraakt. Kijk dus altijd eerst: is er recent iets bijgewerkt? In je dashboard zie je dat onder Dashboard → Updates of in het changelog van je plugins — als je nog kunt inloggen tenminste.
2. Een PHP-versie-upgrade waar oud thema of oude plugin niet tegen kan
Hosters werken de PHP-versie op de server regelmatig bij, en dat is terecht: oude PHP-versies krijgen geen beveiligingsupdates meer. Maar een thema uit 2016 dat nooit is bijgewerkt, gebruikt soms functies die in PHP 8 niet meer bestaan. De site draaide jaren probleemloos en gaat stuk op de dag dat de PHP-versie omhoog gaat. Herken je dat patroon — niets veranderd aan de site zelf, wel een mail van je hoster over PHP — dan weet je waar je moet zoeken.
3. Een kapotte functions.php na handmatig aanpassen
De derde klassieker: je hebt zelf (of iemand anders) via Weergave → Thema-bestandseditor een stukje code in functions.php geplakt — een snippet van internet, een tracking-code, een kleine aanpassing. Eén ontbrekende puntkomma of accolade is genoeg om de hele site plat te leggen. Laatst nog bij een klant: die had een snippet voor een aangepaste footer geplakt, per ongeluk inclusief de openings-tag <?php die er al stond. Site direct plat. Via FTP het bestand hersteld en binnen vijf minuten draaide alles weer.
Andere oorzaken die ik minder vaak zie: een vol geheugen (PHP memory limit), beschadigde core-bestanden na een mislukte update, en — vervelender — malware die bestanden heeft aangepast.
Stap voor stap: zo vind je de echte fout
Stap 1: Check je e-mail op de recovery-mail
Zoek in de mailbox van het beheerdersadres (check ook je spam) naar een mail met een onderwerp als "Je site ondervindt een technisch probleem". Daarin staat twee keer goud:
- De exacte fout, bijvoorbeeld: "Er is een fout van het type E_ERROR veroorzaakt op regel 214 van het bestand /wp-content/plugins/voorbeeld-plugin/init.php". Het pad vertelt je direct welke plugin of welk thema de schuldige is.
- Een herstelmodus-link. Klik je daarop, dan kun je inloggen terwijl WordPress de kapotte plugin tijdelijk uitschakelt. Je kunt de plugin dan gewoon vanuit je dashboard deactiveren.
Heb je die mail? Deactiveer de genoemde plugin (of schakel het genoemde thema om naar een standaardthema zoals Twenty Twenty-Four) en je site doet het weer. Klaar. Geen mail? Door naar stap 2.
Stap 2: Kijk in de error_log op je hosting
Log in op het controlepaneel van je hosting (DirectAdmin, Plesk, cPanel of het paneel van je hoster) en open de bestandsbeheerder, of verbind via FTP. Zoek naar een bestand met de naam error_log — meestal in de hoofdmap van je site (waar ook wp-config.php staat) of in wp-content/. Open het en scrol naar de onderste regels. Je zoekt een regel die begint met "PHP Fatal error", bijvoorbeeld:
[02-Aug-2026 03:14:07 UTC] PHP Fatal error: Uncaught Error: Call to undefined function ...
in /home/klant/public_html/wp-content/plugins/voorbeeld-plugin/includes/helper.php:87
Weer geldt: het pad achter wp-content/plugins/ of wp-content/themes/ wijst de schuldige aan. Kom je er niet uit of vind je het bestand niet? Een goede hoster duikt die error_log binnen een paar minuten voor je op — daar hoef je je niet voor te generen, het is letterlijk ons werk. Wordt je bij je huidige hoster van het kastje naar de muur gestuurd, dan zegt dat ook iets.
Stap 3: Geen log te vinden? Zet WP_DEBUG_LOG aan
Staat er niets bruikbaars in de error_log, dan kun je WordPress zelf laten loggen. Open via FTP of bestandsbeheer het bestand wp-config.php in de hoofdmap van je site en zet er, boven de regel /* That's all, stop editing! */, dit in:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Laad daarna de site één keer opnieuw. WordPress schrijft de fout nu weg naar wp-content/debug.log. Open dat bestand, lees de onderste "Fatal error"-regel, en je hebt je antwoord. Vergeet niet deze regels weer te verwijderen (of WP_DEBUG op false te zetten) zodra je klaar bent — een debug-log hoort niet permanent aan te staan op een live site.
Stap 4: Schakel de boosdoener uit via FTP
Weet je welke plugin het is, maar kun je niet meer inloggen? Dan schakel je hem uit door de map te hernoemen. Verbind via FTP of bestandsbeheer, ga naar wp-content/plugins/ en hernoem de map van de plugin, bijvoorbeeld van voorbeeld-plugin naar voorbeeld-plugin-uit. WordPress ziet de plugin dan niet meer en deactiveert hem automatisch. Je site doet het direct weer en je kunt gewoon inloggen.
Weet je niet wélke plugin het is en heb je geen log? Dan kun je de hele map plugins hernoemen naar bijvoorbeeld plugins-uit. Doet de site het dan weer, dan weet je zeker dat het een plugin is. Hernoem de map terug en hernoem daarna de plugin-mappen één voor één, telkens even de site verversend, tot je de schuldige te pakken hebt.
Voor een kapot thema geldt hetzelfde principe: hernoem de themamap in wp-content/themes/, en WordPress valt terug op een standaardthema (mits dat geïnstalleerd staat — dat is bijna altijd zo).
Stap 5: Los de oorzaak echt op
De site draait weer, maar je bent er nog niet — een uitgeschakelde plugin is een pleister, geen oplossing:
- Kapotte plugin-update? Kijk of er inmiddels een nieuwere versie is (fouten in populaire plugins worden vaak binnen een dag gerepareerd). Zo niet: zet tijdelijk de vorige versie terug (te downloaden via de "Ontwikkeling"-tab van de plugin op wordpress.org, onder "Vorige versies") en update pas weer als het gefixt is.
- PHP-versie-conflict? Vraag je hoster om de site tijdelijk op de vorige PHP-versie te zetten, zodat alles weer draait. Maar plan dan wél het echte werk in: het thema of de plugin vervangen of laten bijwerken. Op een oude PHP-versie blijven hangen is geen langetermijnoplossing.
- Zelf code kapotgemaakt? Herstel het bestand via FTP: haal je aanpassing eruit, of zet het originele bestand terug uit je back-up of uit het originele themapakket.
Hoe voorkom je deze fout in de toekomst?
Helemaal uitsluiten kan niet, maar met een paar gewoontes maak je de kans en de impact een stuk kleiner:
- Werk gecontroleerd bij. Automatische updates zijn prima voor kleine plugins, maar update grote of kritieke plugins (denk aan WooCommerce, page builders) liever handmatig op een moment dat je erbij bent — en check daarna even of alles nog werkt. Lees ook hoe je WordPress veilig up-to-date houdt met updates, staging en back-ups.
- Zorg voor dagelijkse back-ups. Niet als de site al plat ligt, maar nu. Met een goede back-up is elke kritieke fout hooguit een kwartier ongemak in plaats van een ramp.
- Gebruik de thema-editor niet voor maatwerk. Code-aanpassingen horen in een child-thema of een snippets-plugin, niet rechtstreeks in
functions.phpvia de editor. En test snippets nooit voor het eerst op je live site. - Ruim op. Elke plugin die je niet gebruikt is een extra kans op conflicten en beveiligingsproblemen. Verwijder wat uit staat.
- Houd je e-mailadres actueel. De recovery-mail is je snelste route naar de oplossing — maar alleen als hij aankomt. Controleer onder Instellingen → Algemeen of het beheerdersadres nog klopt.
- Kies een hoster die meekijkt. Een deel van deze fouten valt server-side te zien voordat jij er last van hebt. Bij ons draait op elke server monitoring die sites in de gaten houdt, en als er tóch iets stukgaat, pak ik de error_log er direct bij. Dat mag je van elke serieuze hoster verwachten.
Kom je er niet uit?
Dan is dat geen schande — soms zit de fout dieper, bijvoorbeeld in een geheugenlimiet, een databaseprobleem, lijkt de melding op een 500 Internal Server Error, of (zeldzamer) malware. Stuur je hoster de melding en vraag concreet: "Kun je in de error_log kijken welke fatal error mijn site geeft?" Met dat antwoord is elke WordPress-beheerder binnen no-time klaar.