Kritieke fout in WordPress oplossen: “Er heeft zich een kritieke fout voorgedaan op deze site”

Laatst bijgewerkt: 21 oktober 2026

Je opent je website en in plaats van je homepage staat er één zin: “Er heeft zich een kritieke fout voorgedaan op deze site.” Of: “Er is een kritieke fout op deze site opgetreden. Controleer je beheer e-mail inbox voor instructies.” Schrik niet: je teksten, foto’s en bestellingen zijn vrijwel altijd nog gewoon aanwezig. WordPress laat alleen zien dát er iets misgaat, niet wát. Hieronder lees je per stap hoe je de oorzaak vindt en je site weer online krijgt, ook als je niet meer kunt inloggen.

Welke melding zie je precies?

De tekst verschilt per WordPress-versie, per taal en per situatie. Deze varianten komen letterlijk uit WordPress (Nederlandse vertaling van versie 7.1 en de Engelse brontekst):

Onder de melding staat meestal de link “Lees verder over het oplossen van problemen met WordPress.” Veel mensen zoeken ook op de oudere of vrij vertaalde vorm “Er is een kritieke fout opgetreden op deze website”. Het gaat om dezelfde fout en dezelfde aanpak.

Wat betekent een kritieke fout?

Achter de melding zit een fatale PHP-fout: een stuk code dat niet verder kan, waardoor WordPress de pagina niet kan opbouwen. Vóór versie 5.2 kreeg je dan een leeg wit scherm. Sinds 5.2 vangt WordPress die fout op, toont een nette melding en probeert de beheerder te waarschuwen.

Belangrijk om te weten:

• Je site is niet weg. De bestanden en de database staan nog op de server. Alleen het opbouwen van de pagina mislukt.
• De melding noemt geen oorzaak. Die staat in de herstelmodus-mail of in de foutlog.
• Het kan ook op één pagina zitten. Soms werkt de homepage wel en geeft alleen de afrekenpagina, het beheer of de pagina-editor de fout.

Zie je helemaal niets, ook geen melding? Lees dan wit scherm in WordPress. Krijg je “500 Internal Server Error”, kijk dan bij 500-fout in WordPress.

De meest voorkomende oorzaken

• Een plugin die botst met een andere plugin, met je thema of met de PHP-versie. Vaak direct na een (automatische) update.
• Je thema, bijvoorbeeld na een update of na een aanpassing in functions.php van een child-thema.
• Een nieuwere PHP-versie op de server waar oude code niet mee overweg kan (functies die in PHP 8 zijn verdwenen).
• Te weinig geheugen (PHP memory limit), bijvoorbeeld bij een paginabouwer, een grote import of een back-up.
• Een half gelukte update, waarbij bestanden ontbreken of maar voor een deel zijn overgezet.
• Een zelf geplakt codefragment met een typfout, bijvoorbeeld via een snippets-plugin of in functions.php.
• Een volle schijf of verkeerde bestandsrechten op de hosting.

Snel: wat heb je net gedaan?

De oorzaak zit bijna altijd in de laatste wijziging. Kijk eerst in dit overzicht:

Stap 1: maak eerst een back-up

Klinkt saai, maar het voorkomt dat je het erger maakt. Download via je hostingpaneel of FTP de map wp-content en het bestand wp-config.php, en maak een export van de database (bijvoorbeeld via phpMyAdmin of de back-upfunctie van je hosting). Heb je een webshop, noteer dan het tijdstip: bestellingen die daarna binnenkomen, zitten niet in die back-up.

Stap 2: gebruik de herstelmodus-mail

Kon WordPress vaststellen welke plugin of welk thema de fout veroorzaakt, dan krijgt het e-mailadres van de sitebeheerder (Instellingen → Algemeen) een mail met als onderwerp:

[Naam van je site] je site ervaart een technisch probleem
Engels: “[Site] Your Site is Experiencing a Technical Issue”

In de mail staat letterlijk onder andere:

“WordPress heeft een ingebouwde functie die detecteert wanneer een plugin of thema een fatale fout op je site veroorzaakt en je op de hoogte stelt met deze geautomatiseerde e-mail. In dit geval heeft WordPress een fout gevonden met één van je plugins, [naam].”

Daaronder staat een link om in te loggen in de herstelmodus. Zo gebruik je die:

1. Klik op de link en log in met je gewone beheerdersaccount.
2. Bovenaan staat nu een melding dat de site in herstelmodus is. Het onderdeel uit de mail is alleen voor jou gepauzeerd; bezoekers zien de fout nog steeds.
3. Ga naar Plugins (of Weergave → Thema’s). Bij het probleemonderdeel staat de foutregel. Schakel het uit, werk het bij of vervang het.
4. Klik bovenin op Herstelmodus verlaten en controleer de site in een privévenster.

Goed om te weten: de link verloopt na 1 dag (“Om je site veilig te houden, verloopt deze link in 1 dag”). WordPress stuurt zo’n mail ook niet vaker dan ongeveer eens per dag, dus kijk in je spammap als je hem mist. Komt er nooit mail van je site aan, lees dan mail vanuit WordPress komt niet aan. Wil je de herstelmail naar een ander adres, dan kan dat met define( 'RECOVERY_MODE_EMAIL', 'jij@jouwbedrijf.nl' ); in wp-config.php.

Stap 3: zet de foutregistratie aan (debug.log)

Geen mail, of noemt de mail geen duidelijke oorzaak? Laat WordPress de fout dan wegschrijven. Open via bestandsbeheer of FTP het bestand wp-config.php in de hoofdmap van je site en zet deze regels boven de regel “That's all, stop editing!” (of vervang bestaande WP_DEBUG-regels):

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

Laad de pagina met de fout opnieuw. In wp-content/debug.log verschijnt nu een regel zoals:

PHP Fatal error:  Uncaught Error: Call to undefined function voorbeeld_functie()
in /wp-content/plugins/voorbeeld-plugin/includes/class-main.php:123

Het pad vertelt je waar het misgaat: /plugins/naam/ is een plugin, /themes/naam/ je thema, /wp-includes/ of /wp-admin/ WordPress zelf. Veel hostingpanelen tonen daarnaast een eigen PHP-foutlog. Uitgebreidere uitleg over de instellingen staat in WordPress debug.log aanzetten en lezen.

Let op: debug.log is soms via de browser op te vragen en kan paden en gegevens bevatten. Zet WP_DEBUG na afloop weer op false en verwijder het bestand.

Stap 4: schakel de plugin uit zonder in te loggen

Weet je welke plugin het is, of wil je alle plugins uitsluiten, dan heb je drie manieren.

Via bestandsbeheer of FTP

1. Ga naar wp-content/plugins/.
2. Hernoem de map van de verdachte plugin, bijvoorbeeld woocommerce naar woocommerce-uit. WordPress schakelt de plugin daardoor uit; je instellingen blijven bewaard.
3. Weet je niet welke? Hernoem de hele map plugins naar plugins-uit. Werkt de site weer, zet de naam terug en zet in het beheer de plugins één voor één weer aan tot de fout terugkomt.

Via WP-CLI (als je hosting SSH-toegang heeft):

wp plugin list --status=active
wp plugin deactivate naam-van-plugin
wp plugin deactivate --all
wp plugin list --skip-plugins --skip-themes

Met --skip-plugins --skip-themes draait WP-CLI zonder plugins en thema te laden, handig als de fout ook WP-CLI zelf laat vastlopen.

Via de database (laatste redmiddel): in de tabel wp_options (het voorvoegsel kan anders zijn) staat de rij active_plugins. Als je de waarde daarvan vervangt door a:0:{}, zijn alle plugins uitgeschakeld. Bewaar de oude waarde eerst, zodat je hem terug kunt zetten.

Stap 5: sluit je thema uit

Wijst de foutregel naar /themes/, of werkt de site ook zonder plugins niet, dan is het thema de volgende verdachte.

• Bestandsbeheer/FTP: hernoem de map van je actieve thema in wp-content/themes/. WordPress valt dan terug op een standaardthema (zoals Twenty Twenty-Five), mits dat geïnstalleerd is. Staat er geen standaardthema, upload er dan eerst één.
• WP-CLI: wp theme activate twentytwentyfive (met de naam van een standaardthema dat op je site staat).
• Child-thema: zit de fout in functions.php van je child-thema, zet dan het laatst toegevoegde stuk code tussen commentaar of haal het weg. Dat is vaak een geplakt fragment zonder afsluitende haak of puntkomma.

Gebruik je een paginabouwer als Elementor of Divi, dan oogt de site met een standaardthema anders, maar je inhoud blijft bewaard. Zet het thema terug zodra de oorzaak is weggenomen. Meer over thema’s: WordPress-thema aanpassen.

Stap 6: verhoog de geheugenlimiet

Staat er in de log Allowed memory size of 134217728 bytes exhausted (of een ander getal), dan had PHP te weinig geheugen. Voeg dan in wp-config.php toe:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT geldt voor de site, WP_MAX_MEMORY_LIMIT voor het beheer. Dit werkt alleen tot het maximum dat je hosting toestaat (memory_limit van PHP). Helpt het niet, dan moet die limiet in het hostingpaneel omhoog, of zoek je uit welke plugin zoveel geheugen vraagt. Uitleg: WordPress-geheugenlimiet verhogen.

Stap 7: controleer de PHP-versie

Is de fout ontstaan nadat je hosting de PHP-versie heeft verhoogd, dan gebruikt een plugin of thema waarschijnlijk code die in de nieuwe versie niet meer bestaat. Je ziet dan vaak Call to undefined function of Uncaught TypeError in de log.

1. Werk eerst de plugin of het thema bij: de maker heeft het probleem vaak al opgelost.
2. Is er geen update, zet PHP dan tijdelijk één versie terug in je hostingpaneel, zodat de site weer werkt.
3. Vervang daarna de verouderde plugin of het thema. Blijf niet hangen op een oude PHP-versie: die krijgt geen beveiligingsupdates meer.

In WordPress zie je de PHP-versie onder Gereedschap → Sitestatus → Info → Server. Stap voor stap: PHP-versie van WordPress veilig updaten. Over het PHP-lek van oktober 2026: PHP-lek: wat moet je doen?

Stap 8: herstel kernbestanden of zet een back-up terug

Wijst de fout naar /wp-includes/ of /wp-admin/, of is een update halverwege afgebroken, dan zijn kernbestanden beschadigd of onvolledig.

• Controleren met WP-CLI: wp core verify-checksums vergelijkt je WordPress-bestanden met de officiële versie, wp plugin verify-checksums --all doet hetzelfde voor plugins uit de officiële bibliotheek.
• Opnieuw installeren: kun je inloggen, ga dan naar Dashboard → Updates en kies opnieuw installeren. Anders download je dezelfde versie van wordpress.org en vervang je via FTP alleen de mappen wp-admin en wp-includes. Laat wp-content en wp-config.php staan.
• Staat er een bestand .maintenance in de hoofdmap na een mislukte update, verwijder het dan. Zie WordPress-update mislukt.
• Volle schijf: controleer in je hostingpaneel of er nog ruimte is. Oude back-ups en logbestanden vullen een schijf vaak ongemerkt.
• Back-up terugzetten: werkt niets, zet dan een back-up van vóór het probleem terug. Bij een webshop raak je dan bestellingen sinds die back-up kwijt; overleg eerst.

Vind je in de bestanden onbekende code of bestanden die je niet herkent, dan kan een hack de oorzaak zijn. Lees dan WordPress gehackt: wat nu?

Kritieke fout bij bekende plugins

Bij een paar plugins zien we deze melding vaker, meestal na een update of door een conflict:

• WooCommerce: na een update van WooCommerce of een betaal-, verzend- of factuurplugin die nog niet is bijgewerkt.
• Elementor en Elementor Pro: als de versies van Elementor en Elementor Pro niet bij elkaar passen, of door te weinig geheugen in de editor.
• WP Rocket, LiteSpeed Cache en andere cacheplugins: resten in wp-content (advanced-cache.php, object-cache.php) nadat de plugin is verwijderd.
• Wordfence en andere beveiligingsplugins: een firewallbestand dat nog wordt geladen terwijl de plugin weg is.

Alle uitleg per plugin staat in het overzicht WordPress-plugins: installeren, instellen en problemen oplossen.

Na het oplossen: opruimen en voorkomen

• Zet WP_DEBUG weer op false en verwijder wp-content/debug.log.
• Hernoemde mappen (plugins-uit, naam-uit) terugzetten of opruimen.
• Test de belangrijkste dingen: homepage, inloggen, contactformulier en, bij een webshop, een proefbestelling.
• Werk voortaan bij met een back-up vooraf en test grote updates eerst op een kopie (staging).
• Haal plugins weg die je niet meer gebruikt of die al lang niet zijn bijgewerkt.

Hoe je dat structureel regelt, lees je in WordPress onderhoud. Draait je site op onze WordPress hosting met onderhoud, dan doen wij de updates en back-ups voor je.

Kom je er niet uit?

Kun je niet bij de bestanden, staat de webshop stil of is de fout na deze stappen nog steeds daar? Bij WordPress-spoedhulp kijken we met je mee: we maken eerst een back-up, zoeken de foutregel op en vertellen je vooraf wat we gaan doen. Je hebt daarvoor geen onderhoudscontract nodig.

Lees ook: WordPress-spoedhulp · WordPress-plugins · debug.log aanzetten · geheugenlimiet verhogen · PHP-versie updaten · wit scherm in WordPress · 500-fout in WordPress · WordPress-update mislukt · WordPress hosting

← Terug naar de kennisbank