There has been a critical error on this website: zo los je de WordPress kritieke fout op

Je site toont bijna een lege pagina met één korte zin: "Er heeft zich een kritieke fout voorgedaan op deze site. Controleer de inbox van je sitebeheerder voor instructies." De HTTP-response is 500. Bezoekers zien hetzelfde scherm als jij. Soms helpt een refresh voor één request, maar meestal ligt de site eruit tot je ingrijpt.

Wat deze fout eigenlijk betekent

De exacte tekst komt uit WP_Fatal_Error_Handler, een class die WordPress sinds versie 5.2 meelevert. Die vangt vijf categorieën PHP-fatale fouten af tijdens een request: E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR en E_RECOVERABLE_ERROR. Zodra er eentje wordt opgevangen, stopt de response, geeft WordPress HTTP 500 terug en toont het kritieke-foutscherm in plaats van de pagina die de bezoeker had moeten zien.

In gewone taal: een PHP-bestand in WordPress core, in een plugin of in je thema probeerde code uit te voeren die PHP weigerde te draaien. Het script overleed halverwege het request. WordPress kon geen HTML produceren, en gaf dus de fallback-melding met het verzoek om je mail te checken.

Dit scherm verving het oudere "witte scherm". Vóór WordPress 5.2 zou dezelfde fatale fout gewoon helemaal niets renderen, en mocht je raden wat er gebeurd was. Zie je nog steeds een volledig leeg scherm (geen melding, geen headers, alleen wit)? Dan heeft de fatal error handler niet kunnen draaien en moet je het diagnose-pad volgen uit White Screen of Death in WordPress. De fixes overlappen, maar de diagnose loopt anders.

Veelvoorkomende oorzaken, op volgorde van waarschijnlijkheid

Na tientallen van deze gevallen op managed sites is de volgorde elke keer hetzelfde:

1. Een PHP fatal in een plugin. Verreweg de meest voorkomende. Een plugin-update introduceerde een bug, twee plugins claimen dezelfde functienaam, of een plugin gebruikt een PHP-feature die je server niet heeft. De fatale fout treedt op tijdens het laden van plugins (plugins_loaded), dus je hele site valt om en niet alleen de pagina van die plugin.
2. Een PHP-versiemismatch. Een plugin of thema vereist PHP 8.1 of hoger, maar de server draait nog op PHP 7.4. Of andersom: een oude plugin gebruikt een PHP 5-constructie die in PHP 8.2 is geschrapt. WordPress zelf raadt PHP 8.3 of hoger aan volgens de officiële vereisten, en veel plugins eisen tegenwoordig minimaal PHP 8.0.
3. Een PHP fatal in het actieve thema. Minder vaak dan plugins, maar veel waarschijnlijker net na een thema-update of na handmatige aanpassingen in functions.php. Vaak een parse error door een ontbrekende puntkomma of haakje.
4. De PHP memory limit is geraakt. WordPress slaat een fatale fout op als een script meer geheugen probeert toe te wijzen dan de server toestaat. In de debug log zie je dan Allowed memory size of N bytes exhausted.
5. De database-verbinding viel halverwege weg. Als MySQL of MariaDB de verbinding midden in een page load verbreekt, gooien sommige WordPress-operaties een recoverable fatal die de handler omzet in het kritieke-foutscherm. Dit komt minder vaak voor en is meestal een symptoom van trouble bij de host, niet iets in je site zelf.

De diagnose-stappen hieronder vertellen je welke oorzaak van toepassing is voordat je bestanden gaat aanpassen.

Stap 1: Check eerst de recovery-mail

WordPress stuurt een mail naar het admin-mailadres van de site zodra de fatal error handler een fatale fout vangt tijdens een normale page load. In die mail zit een eenmalige link die de site laadt in recovery mode. Dat is een speciale sessie waarin de problematische plugin of het problematische thema voor jou (de admin) tijdelijk is gepauzeerd. Bezoekers zien nog steeds het kritieke-foutscherm, maar jij kunt inloggen op wp-admin en het probleem oplossen vanuit een werkend dashboard.

Wat je moet doen:

1. Open de inbox van het mailadres dat aan je WordPress-admin-user hangt. Check ook spam. Heeft de site een aparte admin-mailconstante gezet (RECOVERY_MODE_EMAIL in wp-config.php)? Check dan die inbox.
2. Zoek naar het onderwerp "[je sitenaam] Your Site is Experiencing a Technical Issue". Die string komt rechtstreeks uit de WP_Recovery_Mode_Email_Service class. In de body staat welke plugin of welk thema de fatal veroorzaakte, plus een recovery-link.
3. Klik op de recovery-link. Die logt je in op wp-admin in recovery mode. WordPress heeft de kapotte extensie voor jouw sessie even gepauzeerd. Ga naar Plugins (of Weergave > Thema's als het een thema betreft) en deactiveer de boosdoener, update naar een versie die de bug fixt, of vervang de plugin.
4. Log uit. Daarmee eindigt recovery mode. WordPress activeert de gepauzeerde extensie niet automatisch opnieuw. Jij bepaalt wanneer hij weer aangaat.

De recovery-link is rate-limited. Standaard staat recovery_mode_email_rate_limit op één dag, wat betekent dat er hooguit eens per 24 uur een nieuwe mail wordt gestuurd. Heb je die mail gemist? Dan moet je wachten of de fatal vanuit een schone staat opnieuw triggeren. De link blijft minimaal hetzelfde venster geldig.

Je weet dat het werkte als de site weer normaal laadt voor bezoekers en het kritieke-foutscherm verdwenen is. Bevestig dat door de site in een privévenster te openen.

Geen mail ontvangen? Drie redenen komen het vaakst voor:

• De uitgaande mail van je hosting is stuk en WordPress-mails worden nooit afgeleverd. Dat is een eigen probleem en het is sowieso de moeite om dat los op te lossen. Zie waarom WordPress geen e-mail verstuurt.
• Het admin-mailadres in Instellingen > Algemeen wijst naar een inbox die je niet meer leest.
• De fatal treedt zo vroeg in de request lifecycle op (vóórdat plugins überhaupt laden) dat de handler nooit kan draaien. In dat geval ga je direct door naar stap 2.

Stap 2: Lees de debug log

Als de recovery-mail niets oplevert, zet je debug logging aan en laat je WordPress je gewoon zelf vertellen wat er stuk is en waar.

Verbind via SFTP of de file manager van je hosting en bewerk wp-config.php in de root van WordPress. Zoek dit blok:

define('WP_DEBUG', false);

Vervang het door de canonieke veilige debug-configuratie uit de WordPress debug-documentatie:

// Debug mode aan
define('WP_DEBUG', true);
// Schrijf fouten naar wp-content/debug.log in plaats van het scherm
define('WP_DEBUG_LOG', true);
// Verberg fouten voor bezoekers
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Sla op en laad de kapotte pagina één keer opnieuw. Open daarna wp-content/debug.log (dat bestand wordt aangemaakt bij de eerste fout). De laatste regels beschrijven de fatale fout die het kritieke-foutscherm triggerde. Een typische regel ziet er zo uit:

[07-Apr-2026 09:14:22 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/plugins/some-plugin/render.php on line 87

Drie dingen in die regel vertellen je bijna alles:

• PHP Fatal error: Uncaught Error: Call to undefined function get_field() betekent dat een plugin een functie aanroept die niet bestaat. Meestal omdat Advanced Custom Fields (of een andere helper-plugin) gedeactiveerd is.
• /wp-content/plugins/some-plugin/render.php is het bronbestand. De mapnaam (some-plugin) is de plugin die je als verdachte moet pakken.
• line 87 is de exacte plek om naar te kijken als je het bestand wil inspecteren.

Een parse error ziet er net iets anders uit. Alles dat begint met Parse error: syntax error, unexpected ... is een kapot PHP-bestand, bijna altijd het gevolg van een handmatige aanpassing. Zie syntax error, unexpected: zo verhelp je een PHP parse error in WordPress voor de gerichte fix.

Je weet dat debug logging werkte als wp-content/debug.log bestaat en een PHP Fatal error-regel bevat met een datumstempel van je laatst mislukte page load. Zet WP_DEBUG weer op false zodra je je antwoord hebt. Live sites horen nooit met debug aan te draaien.

Stap 3: Pas de gerichte fix toe

Nu je weet welk bestand en welke extensie de fatale fout veroorzaakte, lijnt de fix zich direct uit met de oorzaak:

Fatale fout in een plugin

Wijst de log naar /wp-content/plugins/some-plugin/? Deactiveer die plugin. Vanuit wp-admin ga je naar Plugins en klik je op Deactiveren. Kun je niet bij wp-admin? Deactiveer dan via SFTP: hernoem de map van de plugin, bijvoorbeeld van some-plugin naar some-plugin.off. WordPress kan hem niet meer vinden en behandelt hem als gedeactiveerd.

Laad de site opnieuw. Je weet dat het werkte als de site normaal rendert en de debug log niet meer groeit. Kies daarna één van drie vervolgstappen:

• Update de plugin als er een nieuwere versie is die de bug fixt.
• Vervang hem door een alternatief dat niet afhankelijk is van een ontbrekende helper.
• Neem contact op met de pluginmaker met de exacte regel uit de debug log, zeker bij betaalde plugins waar je gewoon support op hebt.

Fatale fout in het thema

Wijst de log naar /wp-content/themes/jouwtheme/? Forceer WordPress dan terug te vallen op een standaardthema. Hernoem via SFTP de map van het actieve thema (jouwtheme naar jouwtheme.off). Staat er nog een standaardthema zoals Twenty Twenty-Four in wp-content/themes/? Dan schakelt WordPress automatisch over. Geen ander thema geïnstalleerd? Download Twenty Twenty-Four van wordpress.org/themes en upload het voordat je het kapotte thema hernoemt.

Je weet dat het werkte als de site laadt met het ontwerp van het standaardthema. Daarna kun je het oorspronkelijke thema repareren (vaak één foute aanpassing in functions.php) of overstappen op een thema dat actief wordt onderhouden.

PHP-versiemismatch

Vermeldt de log dingen als Cannot use ... as ..., Unsupported declare, of een PHP-fout die met een taalfeature te maken heeft? Dan past de PHP-versie op de server niet bij wat de plugin of het thema verwacht. Check je hosting control panel voor Select PHP Version of een vergelijkbare instelling. WordPress raadt PHP 8.3 of hoger aan, en de meeste moderne plugins eisen minimaal PHP 8.0. Heb je net PHP geüpgraded en brak de site? Schakel dan tijdelijk terug om dat te bevestigen. Zit je nog op PHP 7.x? Upgrade dan.

Je weet dat het werkte als de site laadt na de versiewissel en dezelfde fatale fout niet opnieuw verschijnt in de debug log. Houd er rekening mee dat een PHP-versiewissel andere compatibiliteitsproblemen aan het licht kan brengen, dus doe het bij voorkeur eerst op een staging-kopie als je die hebt.

Geheugen op

Zegt de debug log Allowed memory size of N bytes exhausted? Dan is het script niet logisch gecrasht maar gewoon door zijn geheugen heen. De gerichte fix staat in detail in Allowed memory size exhausted in WordPress. Kort gezegd: verhoog WP_MEMORY_LIMIT in wp-config.php, of verhoog de onderliggende PHP memory_limit als je host de WordPress-override blokkeert.

Je weet dat het werkte als dezelfde pagina volledig laadt en de geheugen-regel niet meer in de debug log opduikt.

Database-verbinding viel weg

Zegt de log iets als MySQL server has gone away? Dan brak de verbinding tussen PHP en de database midden in het request. Soms is dat eenmalig. Als het structureel is, ligt het probleem aan de host-kant en niet aan de site, en zit de fix in je hostingaccount. Zie Error establishing a database connection in WordPress voor het diagnostische pad.

Wanneer je hulp inschakelt

Lukt het hierboven niet, of wil je gewoon liever niet zelf in bestanden wroeten? Geef het probleem dan door aan je host of een WordPress-specialist, met deze checklist al klaar. Elke minuut die zij besparen aan context verzamelen, is een minuut dichterbij een werkende site.

Verzamel voordat je hulp vraagt:

• De exacte foutmelding die je in de browser ziet, woord voor woord.
• De HTTP-statuscode (open de Network tab in je browser en herlaad; het kapotte request laat 500 zien).
• De PHP-versie waarop je site draait (zichtbaar in je hostingpanel onder PHP-instellingen).
• De WordPress-versie (uit de recovery-mail als je die kreeg, of uit wp-includes/version.php).
• De volledige laatste 30 regels van wp-content/debug.log na het één keer triggeren van de fatal.
• Een lijstje met wat je hebt geprobeerd, in welke volgorde, en wat er telkens veranderde.
• Elke wijziging die je in de 24 uur vóór de crash hebt gedaan: een plugin-update, een PHP-upgrade, een aanpassing in custom code, een thema-wissel.

Een goede host of specialist tackelt zo'n kritieke fout meestal in minder dan een uur met dat pakket. Zonder dat duurt dezelfde klus drie keer zo lang.

Hoe je de volgende kritieke fout voorkomt

Helemaal voorkomen kun je fatale fouten niet, maar je kunt ze wel zeldzaam en overleefbaar houden:

• Test plugin- en thema-updates eerst op een staging-kopie. De meeste managed hosts hebben staging meegeleverd. Heeft jouw host dat niet? Dan vangt zelfs een eenvoudige lokale kopie de meest voor de hand liggende fatals al af voor ze productie raken.
• Maak een backup vóór elke update. Restoren duurt dan 60 seconden. Zonder backup duurt het uren. Heb je nog geen backupstrategie, zie dan WordPress-backupstrategie.
• Houd het admin-mailadres op een inbox die je daadwerkelijk leest. De recovery-mail is je snelste route terug, en hij is niets waard als hij ergens land waar jij nooit kijkt.
• Blijf binnen één major PHP-versie van wat je plugins eisen. Een plugin geschreven voor PHP 7.4 breekt op PHP 8.3 op manieren die op willekeurige fatals lijken.
• Draai niet meer plugins dan nodig. Elke plugin is een potentiële bron van de volgende fatal, en de gemiddelde WordPress-site heeft er een hoop die niet actief gebruikt worden.

Voor een bredere preventieaanpak met bestandsrechten, DISALLOW_FILE_EDIT en update-automatisering, zie de WordPress-beveiligingschecklist.