Contact
← Terug naar kennisbank WORDPRESS

"There has been a critical error on this website" — WordPress fout oplossen

Je opent je site en ziet een witte pagina met één regel: "There has been a critical error on this website." Geen detail, geen regelnummer, geen plugin-naam — alleen die ene zin. Dit is sinds WordPress 5.2 hoe fatal errors worden afgehandeld, en het is bedoeld om bezoekers geen technische details te tonen. Voor jou betekent het: de echte oorzaak ligt elders. Deze gids laat zien waar je 'm vindt en hoe je 'm oplost.

15 min lezen · Laatst gecheckt:

De volledige melding is meestal:

There has been a critical error on this website.
Please check your site admin email inbox for instructions.

Learn more about troubleshooting WordPress.

Op Nederlandse installaties zie je de vertaalde versie:

Er is een kritieke fout op deze website opgetreden.
Controleer je beheer-e-mailinbox voor instructies.

Soms zonder de tweede zin (oudere installaties of als de site geen admin email kan versturen). Soms aangevuld met een link naar de WordPress-support docs. De inhoud van de fatal error zelf wordt nooit aan bezoekers getoond.

Wat WordPress hier doet — en waarom

Sinds WordPress 5.2 (mei 2019) heeft WP een ingebouwde fatal error handler en recovery mode. Het idee:

  • Een fatal error op een plugin of theme zou anders een witte pagina opleveren waar je geen toegang meer kreeg tot wp-admin
  • WordPress vangt de fatal nu af, toont bezoekers de generieke melding, en stuurt jou (admin) een e-mail met een speciale recovery-link
  • Via die link log je in op een speciale modus waar je het probleemplugin/-theme kunt uitschakelen — zónder FTP-toegang nodig

Dit is een net systeem als alles werkt. In de praktijk werkt het in drie van de vier scenario's:

  1. Admin-email is verkeerd of komt niet aan → geen recovery link
  2. De error blokkeert ook het versturen van mail → e-mail verschijnt nooit
  3. De fatal zit zo diep dat zelfs de error handler crasht → niets wordt gemaild
  4. Het werkt zoals bedoeld → je doet recovery via de mail

Onderstaande aanpak werkt in alle vier de scenario's, ongeacht de mailstatus.

Stap 1: kijk eerst in je admin-mailbox

Voor je iets aanpast, controleer de inbox van het e-mailadres dat in WordPress als admin email staat ingesteld (Settings → General → Administration Email Address). Kijk ook in spam — deze mails landen daar regelmatig.

Onderwerp van de mail: meestal "Your Site is Experiencing a Technical Issue" of in het Nederlands "Je site ondervindt een technisch probleem". De inhoud bevat:

  • De exacte foutmelding (PHP fatal: bestand, regel, error-tekst)
  • De plugin of theme die de fout veroorzaakt
  • Een recovery-link die geldig is voor 24 uur

Als je deze mail hebt: klik de link, log in, deactiveer de boosdoener. Klaar in 30 seconden. Als je 'm niet hebt: door naar stap 2.

Stap 2: zet WP_DEBUG_LOG aan via wp-config.php

Geen e-mail? Dan moet je zelf bij de fout. Voeg aan wp-config.php toe (boven de regel "That's all, stop editing!"):

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

Wat dit doet:

  • WP_DEBUG: zet WordPress in debug-modus
  • WP_DEBUG_LOG: stuurt fouten naar wp-content/debug.log
  • WP_DEBUG_DISPLAY = false: voorkomt dat fouten op de site verschijnen voor bezoekers
  • display_errors = 0: extra zekerheid

Sla op, refresh de site die crasht, en open daarna wp-content/debug.log via FTP, je hosting file manager of SSH. Daar staat de volledige fatal error met bestandspad en regelnummer.

Voorbeeldoutput:

[03-May-2026 14:23:11 UTC] PHP Fatal error: Uncaught Error:
Call to undefined function wp_get_current_user_id() in
/home/site/wp-content/plugins/oude-plugin/includes/auth.php:42

Hier zie je: oude-plugin is de boosdoener. Stap 3 is uitschakelen.

Belangrijk: haal deze debug-instellingen weer weg na het oplossen, of zet WP_DEBUG_LOG op een aangepast pad buiten wp-content. Het bestand is wereldwijd toegankelijk via jouwsite.nl/wp-content/debug.log als je 't laat staan.

Stap 3: server error_log — de tweede plek om te kijken

Soms crasht WordPress te vroeg om WP_DEBUG_LOG aan te roepen. Dan staat de fout alleen in het server-niveau error_log:

  • cPanel: Metrics → Errors
  • Plesk: Logs → klik domein → Error Log
  • DirectAdmin: Domain Setup → klik domein → Error Log
  • SSH: tail -100 ~/logs/error_log (pad varieert per hoster)

Lees de laatste 50-100 regels. De fatal staat er bijna altijd in, met meer context dan WordPress' eigen logging — bijvoorbeeld het exacte memory-gebruik bij een memory-fout, of de stack trace die laat zien hoe de code in de fout terechtkwam.

Stap 4: tijdelijk alle plugins uitschakelen — als je geen wp-admin meer in komt

Soms kom je niet eens meer in /wp-admin/ omdat ook die crasht. Drie methodes om plugins zonder admin-toegang uit te zetten:

Via FTP/SFTP/file manager

Hernoem de map wp-content/plugins naar wp-content/plugins-uit. WordPress kan z'n plugins niet meer vinden en deactiveert ze automatisch op de eerstvolgende load. Site komt terug, je kunt inloggen.

Daarna hernoem je de map terug naar plugins en activeer je in wp-admin de plugins één voor één tot je vindt welke crasht.

Via WP-CLI (SSH)

# Alles deactiveren
wp plugin deactivate --all --skip-plugins

# Een voor een activeren
wp plugin activate plugin-naam

# Of: lijst van actieve plugins
wp plugin list --status=active

WP-CLI is veruit de snelste route als je SSH hebt. Werkt ook bij memory-issues omdat je de --skip-plugins flag kunt gebruiken.

Via database (laatste redmiddel)

In phpMyAdmin → tabel wp_options → zoek de rij active_plugins → wijzig option_value naar a:0:{}. Alle plugins zijn dan gedeactiveerd. Wel even backuppen voor je dit doet — verkeerde syntax breekt WordPress harder.

Stap 5: theme uitschakelen of switchen

Als plugins uit zijn maar de fout blijft, ligt 't waarschijnlijk aan je theme. Switch tijdelijk naar een default theme (Twenty Twenty-Four of vergelijkbaar):

Via FTP

Hernoem wp-content/themes/jouw-theme naar iets anders. WordPress valt dan terug op een default theme. Als die niet meer bestaat, upload twentytwentyfour-map naar wp-content/themes/.

Via WP-CLI

wp theme list
wp theme activate twentytwentyfour

Via database

In wp_options → wijzig template en stylesheet naar bijvoorbeeld twentytwentyfour.

Veelvoorkomende oorzaken — en hoe je ze herkent

Aan de inhoud van de fatal error herken je vaak welk type probleem 't is:

Plugin- of theme-incompatibiliteit met PHP-versie

Foutteksten als Call to undefined function, syntax error, unexpected '?', required parameter follows optional parameter: dat is PHP-versie-incompatibiliteit. De plugin of theme is geschreven voor een oudere PHP-versie en werkt niet meer op de huidige.

Komt vooral voor na een hosting-side PHP-upgrade. Zie ook PHP-versie veilig upgraden.

Memory exhausted

Foutteksten met Allowed memory size of X bytes exhausted: geen echte plugin-crash maar een geheugen-overschrijding. Soms door één probleemplugin, soms door cumulatieve overhead. Zie Allowed memory size exhausted oplossen voor de complete aanpak.

Database-fouten

Foutteksten met mysqli_* of Error establishing a database connection: geen WordPress-bug, maar database-issue. Zie Warning: mysqli foutmeldingen oplossen.

Conflict tussen twee plugins

Symptoom: één plugin werkt prima alleen, de andere ook — maar samen crashen ze. Vaak omdat beide een functie of class met dezelfde naam definiëren. Foutteksten als Cannot redeclare function ... of Cannot redeclare class ... verraden dit. Eén van de twee plugins moet weg.

Beschadigde core-bestanden

Foutteksten met paden in /wp-includes/ of /wp-admin/ kunnen wijzen op beschadigde core-files (mislukte update, truncated upload, of een hack die core gemodificeerd heeft). Snelle fix: vervang core via wp-admin (Updates → Re-install Now) of via WP-CLI: wp core download --force.

Plugin-update-corruptie

De crash begon direct na een plugin-update. Aanpak: de update is incompleet (bestanden ontbreken of zijn corrupt). Fix: deactiveer de plugin, verwijder 'm volledig, herinstalleer schoon vanaf wp-admin. Belangrijk: backup data eerst als de plugin custom data opslaat.

WooCommerce na update

WooCommerce updates breken regelmatig sites die op verouderde extensies of theme's draaien. Foutteksten verwijzen naar woocommerce/includes/. Fix: rollback WC naar de vorige versie (er bestaat een gratis "WP Rollback" plugin), update bijhorende extensies, dan opnieuw upgraden.

Recovery mode handmatig aanroepen — als je geen mail kreeg

Sinds WP 5.2 kun je recovery mode ook handmatig benaderen. Voeg in wp-config.php tijdelijk toe:

define('WP_DISABLE_FATAL_ERROR_HANDLER', true);
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

Dit schakelt de error handler uit en toont de échte fatal error op je scherm — inclusief stack trace. Doe dit alleen tijdelijk en verwijder weer zodra je gediagnosticeerd hebt; bezoekers krijgen anders je server-paden en code-internals te zien.

Stappenplan in volgorde — wat te doen als je site nu down is

  1. Check admin-mailbox voor recovery-mail (incl. spam-folder)
  2. Geen mail? Open wp-config.php, zet WP_DEBUG_LOG aan, refresh site, lees wp-content/debug.log
  3. Geen debug.log? Check server error_log via control panel
  4. Foutmelding gevonden? Identificeer plugin/theme/oorzaak, ga naar de bijbehorende fix
  5. Geen toegang tot wp-admin meer? Hernoem wp-content/plugins-map of gebruik WP-CLI om alles te deactiveren
  6. Werkt site na plugins uit, theme nog steeds default? Activeer plugins één voor één om de echte boosdoener te isoleren
  7. Werkt site weer normaal? Verwijder debug-instellingen uit wp-config.php en eventuele test-bestanden

Hoe voorkom je dat dit weer gebeurt?

  • Test updates eerst op staging. Zie WordPress staging site opzetten. Dit is de #1 preventieve maatregel
  • Check admin-email werkt. Zonder werkende mail kom je nooit aan je recovery-link. Test door je eigen wachtwoord te resetten — als die mail aankomt werkt 't
  • Beperk plugin-stack. Elke plugin is een potentieel breekpunt. 30 plugins draaien = 30 sources van fatal errors. Streef naar 12-15 essentiële plugins
  • Auto-updates op major-plugins uit tijdens drukke periodes (kerst, sales) — zo komt een breaking-change niet in het weekend
  • Backup voor elke update. Klassieke 3-2-1 backup-strategie. Zie ook WordPress beveiligen — 10 essentiële stappen
  • Houd WordPress core, plugins, theme's, en PHP up-to-date. Verouderde versies breken vaker dan up-to-date stacks
  • Monitoring. Tools als UptimeRobot of een simpel cronjob die je homepage checkt — krijg alert binnen minuten in plaats van uren
Tip: sla het exacte plugin-en theme-overzicht (versies + welke actief zijn) ergens op. Bij een crash kun je dan checken: was er net een update? Welke plugin is recent gewijzigd? WP-CLI: wp plugin list > ~/plugins-snapshot.txt als wekelijkse cron-job geeft je een changelog van wat er door de tijd gewijzigd is.

Wanneer schakel je hulp in?

  • Site is down en je krijgt geen recovery-mail én geen toegang tot wp-admin
  • Je vindt de fatal error in debug.log maar weet niet hoe je een PHP-stack-trace moet lezen
  • Plugin uitschakelen lost het op, maar je moet die plugin gebruiken (custom code, betaalde, geen alternatief)
  • Crash herhaalt zich na elke fix — vaak teken van een dieperliggend probleem (memory, database, hosting)
  • Theme/plugin uit de marketplace die uit support is en breekt op nieuwe PHP/WP-versie
  • WooCommerce-shop met live klanten die geen orders meer kunnen plaatsen — elke minuut downtime kost geld
  • De crash is verdacht plotseling en je vermoedt een hack — zie Chinese spam in WordPress verwijderen en Pharma hack — Viagra-spam in je WordPress verwijderen

"There has been a critical error on this website" is in 80% van de gevallen een plugin- of theme-conflict dat binnen 30 minuten op te lossen is — als je weet waar je moet kijken. De stappen hierboven brengen je daar in 9 van de 10 gevallen. Voor de tiende: blijft het bij elke fix terugkomen, ligt de oorzaak dieper en is professionele diagnose efficiënter.