Wat betekent een kritieke fout in WordPress?

WordPress heeft een fatale PHP-fout opgevangen waardoor de aangevraagde pagina niet veilig kon worden afgemaakt. Een incompatibele plugin of thema komt vaak voor, maar ook maatwerkcode, een onvolledige update, geheugenuitputting of een ontbrekende functie kan de oorzaak zijn.

Wat doet WordPress Recovery Mode?

Recovery Mode geeft je via een speciale link toegang tot een beheersessie waarin het onderdeel dat de fatale fout veroorzaakte voor die sessie wordt gepauzeerd. Je kunt het onderdeel dan deactiveren of herstellen, maar je moet daarna nog controleren of de publieke site werkelijk foutvrij is.

Wat doe ik als de e-mail met de herstellink niet aankomt?

Controleer het beheerdersadres en de spammap en open daarna de PHP- of hostinglog op het exacte fouttijdstip. Wijst die log naar één plugin, hernoem alleen die pluginmap tijdelijk via SFTP of het hostingpaneel en bewaar de oorspronkelijke naam.

Moet ik alle WordPress-plugins uitschakelen?

Alleen als de foutlog geen verdachte plugin aanwijst en een gerichte test niet mogelijk is. Leg eerst de actieve lijst vast, hernoem de hele pluginmap tijdelijk, herstel de mapnaam en activeer daarna onderdelen één voor één zodat je de veroorzaker kunt bewijzen.

Kan het actieve WordPress-thema de kritieke fout veroorzaken?

Ja. Een fout in functions.php, een ontbrekende afhankelijkheid of incompatibiliteit kan fataal zijn. Schakel alleen naar een geïnstalleerd en getest standaardthema en herstel het oorspronkelijke thema als de fout blijft.

Kan een PHP-update de kritieke fout veroorzaken?

Ja, een verouderde plugin, themafunctie of maatwerkcode kan botsen met een nieuwe PHP-versie. Zoek de exacte fout en werk de code of component bij. Zet PHP alleen tijdelijk terug via een door de host ondersteunde versie en met een duidelijk terugkeerplan.

Wanneer heb ik hosting of een ontwikkelaar nodig?

Schakel hulp in wanneer je geen herstel-, bestands- of logtoegang hebt, de fout uit een must-use plugin of serverlaag komt, corebestanden niet door de checksumcontrole komen of de site na rollback nog steeds faalt.

Kritieke fout in WordPress oplossen (2026)

De melding “Er heeft zich een kritieke fout voorgedaan op deze website” betekent dat een fatale PHP-fout de aangevraagde WordPress-pagina heeft gestopt. Zoek de exacte fout in de Recovery Mode-mail of serverlog en pauzeer alleen het aangewezen onderdeel omkeerbaar, nadat je bestanden en database hebt veiliggesteld.

Laatst bijgewerkt: 8 augustus 2026.

Wat de kritieke melding wel en niet vertelt

WordPress toont een algemene melding om te voorkomen dat bezoekers technische details, bestandspaden of andere gevoelige informatie zien. De tekst bewijst niet dat WordPress-core kapot is. Veelvoorkomende bronnen zijn:

een plugin die na een update niet meer kan laden;
een fout in het actieve thema of een codefragment;
een ontbrekende PHP-functie of klasse;
een gedeeltelijk uitgevoerde update;
een overschreden geheugen- of uitvoeringstijd;
maatwerk dat niet bij de actieve PHP-versie past.

Een leeg scherm kan dezelfde onderliggende soort fout hebben, maar zonder zichtbare WordPress-melding. Gebruik daarvoor ook de uitleg over een wit scherm in WordPress. Zie je letterlijk Allowed memory size exhausted, ga dan naar de WordPress memory-limit-fout. Bij Maximum execution time exceeded hoort de aparte timeoutdiagnose.

Stappenplan: een kritieke WordPress-fout herstellen

1. Leg de fout vast en maak een herstelset

Noteer de volledige URL, het tijdstip met tijdzone, de laatste geslaagde actie en alle updates vlak vóór de fout. Maak screenshots en download de PHP-, webserver- en updatelog als je hostingpaneel die aanbiedt.

Maak vervolgens een back-up van de huidige bestanden en database. Gebruik daarnaast bij voorkeur een complete, bekende goede back-up van vóór de fout. De officiële WordPress-handleiding voor back-ups legt uit dat bestanden en database samen nodig zijn voor volledig herstel.

Voer geen databasezoek-en-vervangactie uit en verwijder geen pluginmap. Een kritieke fout wordt zelden opgelost door contenttabellen te wijzigen, terwijl een verwijdering je rollback moeilijker maakt.

2. Gebruik de officiële Recovery Mode-link

Controleer de inbox en spammap van het sitebeheerdersadres op een bericht van WordPress. De officiële documentatie over Recovery Mode beschrijft dat de e-mail foutdetails en een speciale inloglink bevat.

Open de link alleen als het domein exact bij je eigen site hoort en log daarna normaal in. WordPress pauzeert de verdachte plugin of het thema alleen voor jouw Recovery Mode-sessie. Noteer:

het genoemde onderdeel;
het fouttype;
bestand en regelnummer;
de actie die WordPress voorstelt.

Deactiveer het verdachte onderdeel vanuit het beheer, maar verwijder het niet. Open daarna de publieke site in een gewoon privévenster, dus buiten je beschermde beheersessie. Klik pas op Recovery Mode afsluiten nadat de oorzaak is gerepareerd en de publieke controles slagen.

3. Zoek zonder e-mail de PHP-fout in de logs

Komt de herstelmail niet aan of crasht de fout in een achtergrondtaak, open dan de PHP-errorlog van je hosting op het genoteerde tijdstip. Zoek op Fatal error, Uncaught, TypeError, Parse error of Allowed memory size.

Lees het volledige pad:

wp-content/plugins/pluginnaam/...
wp-content/themes/themanaam/...
wp-content/mu-plugins/...
wp-includes/...

Een pad in plugins of themes is een sterke aanwijzing voor dat onderdeel. Een regel in wp-includes is niet automatisch een corefout, omdat plugin- of themacode de corefunctie kan hebben aangeroepen. Lees daarom ook de stacktrace en de eerste regel die naar niet-corecode wijst.

Een fout in mu-plugins hoort bij automatisch geladen must-use code en verdwijnt niet door de gewone pluginmap te hernoemen. Vraag bij een door hosting beheerde must-use plugin eerst de provider om de concrete logregel te beoordelen.

4. Schrijf tijdelijk naar een log zonder details te tonen

Heb je geen bruikbare PHP-log, maak dan eerst een kopie van wp-config.php. Voeg vóór de afsluitende commentaarregel alleen tijdelijk deze officiële debuginstellingen toe:

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

De officiële WordPress-uitleg voor debuggen beschrijft deze combinatie en adviseert staging of een passende back-up. Roep de fout één keer op en lees daarna wp-content/debug.log.

Zet de oorspronkelijke wp-config.php terug zodra je genoeg informatie hebt. Laat debugging niet actief staan en bewaar het logbestand niet publiek bereikbaar. Logs kunnen paden, gebruikersgegevens of informatie uit verzoeken bevatten.

5. Isoleer één verdachte plugin via SFTP

Wijst de fout naar één plugin en kun je niet inloggen, open dan via SFTP of het hostingbestandsbeheer:

wp-content/plugins/

Hernoem alleen de betrokken map, bijvoorbeeld:

formulier-plugin
formulier-plugin.disabled-20260728

Vraag de site opnieuw op. Verdwijnt de fout, laat de map uitgeschakeld en onderzoek op staging of een actuele compatibele versie of een bekende goede back-up nodig is. Blijft de fout, herstel direct de oorspronkelijke mapnaam.

Weet je niet welke plugin de oorzaak is, leg dan eerst de actieve pluginlijst vast als die beschikbaar is. Hernoem vervolgens tijdelijk plugins naar plugins.disabled-20260728. Werkt de site, zet de mapnaam terug en activeer plugins één voor één. WordPress kan ontbrekende actieve plugins als gedeactiveerd registreren, dus alleen de mapnaam terugzetten activeert niet per se alles.

De officiële WordPress-pagina over plugins beheren adviseert bij conflicten eveneens één voor één te deactiveren. Verwijder pluginbestanden en gegevens pas na een afzonderlijk besluit en een gecontroleerde back-up.

6. Test het actieve thema met een veilige terugweg

Wijst de log naar het actieve thema, controleer dan eerst of een geïnstalleerd standaardthema werkt met je huidige WordPress-versie. Schakel in Recovery Mode of het gewone beheer tijdelijk naar dat thema. Noteer het oorspronkelijke thema en herstel het wanneer de fout blijft.

Kun je niet inloggen, hernoem het actieve themapad alleen als een bruikbaar standaardthema al aanwezig is. Zonder fallback kan WordPress geen thema laden en krijg je een nieuwe fout. Laat hosting of een ontwikkelaar deze stap uitvoeren wanneer het thema maatwerk, een child-thema of noodzakelijke templates bevat.

Pas functions.php of een geleverd thema niet rechtstreeks op productie aan als snelle oplossing. Reproduceer de fout op staging, herstel de code daar en implementeer de geteste wijziging met een rollback.

7. Controleer PHP-versie, geheugen en uitvoeringstijd

Ontstond de fout direct na een PHP-wijziging, vergelijk dan de compatibiliteitsinformatie van plugin, thema en maatwerk met de actieve PHP-versie. Werk het incompatibele onderdeel bij of herstel een bekende goede componentversie. Een PHP-downgrade is alleen een tijdelijke noodroute als je host die versie nog veilig ondersteunt en je een gepland pad terug naar een actuele versie hebt.

Verhoog geen geheugen of uitvoeringstijd zonder de exacte melding. Meer geheugen repareert geen ontbrekende klasse, en een langere timeout verbergt mogelijk een lus. Gebruik de gerichte decoders voor geheugenuitputting en Maximum execution time.

Geeft de log in plaats daarvan aan dat WordPress geen databaseverbinding krijgt, volg dan de aparte stappen voor Error establishing a database connection.

8. Controleer of een update onvolledig is

Begon de fout tijdens een core-, plugin- of thema-update, controleer dan of .maintenance nog bestaat en of er geen updateproces meer actief is. Gebruik de veilige aanpak voor een vastgelopen WordPress-onderhoudsmodus voordat je bestanden aanraakt.

Met bevoegde WP-CLI-toegang kun je corebestanden tegen WordPress.org controleren:

wp core verify-checksums

De officiële documentatie van wp core verify-checksums legt uit dat het commando WordPress-bestanden vergelijkt met checksums voor de geïnstalleerde versie en locale. Een mismatch vraagt onderzoek of een gecontroleerde herinstallatie van dezelfde coreversie. Overschrijf wp-content of wp-config.php niet.

Volg bij een onvolledige core-update de officiële procedure voor WordPress bijwerken en werk met de volledige back-up van vóór de update.

9. Herstel de oorzaak, niet alleen de zichtbare melding

Kies de reparatie op basis van bewijs:

werk een incompatibele plugin of thema gecontroleerd bij;
herstel de vorige werkende componentversie uit je back-up;
laat een maatwerkfout op staging corrigeren en testen;
maak een onvolledige update volgens de officiële procedure af;
laat hosting een servermodule, PHP-handler of beheerde must-use plugin controleren.

Installeer geen willekeurige vervanger terwijl de foutoorzaak onbekend is. Een nieuwe plugin kan dezelfde hook, tabel of PHP-functie gebruiken en extra variabelen toevoegen.

10. Valideer en ruim de diagnose op

Test na de reparatie:

de homepage en meerdere contentpagina’s;
login, dashboard en bewerkschermen;
formulieren, zoeken, uploads en geplande taken;
de functie van het herstelde onderdeel;
een afgemelde sessie en een tweede apparaat;
PHP-, WordPress- en serverlogs op nieuwe fatale fouten.

Activeer uitgeschakelde onderdelen één voor één. Leeg alleen de relevante cache en test daarna opnieuw. Herstel tijdelijke mapnamen, verwijder of bescherm debuglogs, zet wp-config.php terug en documenteer oorzaak, reparatie en rollback.

Veelgemaakte fouten

De algemene melding als diagnose gebruiken. Je hebt de recoverymail, PHP-log of stacktrace nodig.
Alle plugins en het thema tegelijk uitschakelen. Daardoor weet je niet welk onderdeel de fout veroorzaakte.
Een pluginmap verwijderen in plaats van hernoemen. Je verliest dan je snelste rollback en mogelijk maatwerkbestanden.
Alleen naar het laatste bestand in de fout kijken. De eerste relevante niet-coreaanroep kan de werkelijke bron zijn.
Debugdetails publiek tonen. Bestandspaden en verzoekinformatie horen in een afgeschermd log.
Een standaardthema aannemen dat niet is geïnstalleerd. Zonder fallback kan de thematest een tweede fout geven.
PHP blind terugzetten of limieten verhogen. Los de concrete incompatibiliteit, geheugenfout of timeout op.
Recovery Mode afsluiten zonder publieke test. De beschermde beheersessie kan anders werken dan de gewone site.
Een onvolledige update opnieuw starten zonder back-up. Daarmee kun je een gedeeltelijke bestandenset verder beschadigen.

Nieuwe kritieke fouten voorkomen

Test WordPress-, plugin-, thema- en PHP-updates eerst op staging. Maak vooraf één herstelset van bestanden en database, update onderdelen afzonderlijk en controleer na iedere wijziging frontend, beheer en logs. Bewaar maatwerk in versiebeheer en wijzig geen geleverde plugin- of parent-themabestanden rechtstreeks.

Bekijk voor meer foutdecoders en herstelroutes de WordPress-hub. Wil je dat iemand de foutlog, component en rollback gecontroleerd onderzoekt, stel je vraag via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.