Er heeft zich een kritieke fout voorgedaan op deze site: het complete WordPress herstelplan voor MKB (en hoe je dit voorgoed voorkomt)

Je opent je website en in plaats van je homepage zie je één zin: “Er heeft zich een kritieke fout voorgedaan op deze site.” Geen menu, geen producten, geen contactformulier. Klanten zien hetzelfde. Voor een MKB-ondernemer is dat geen technisch ongemak, maar omzetverlies dat per uur oploopt. In dit artikel lees je precies wat er aan de hand is, hoe je je site binnen het uur weer online krijgt en, minstens zo belangrijk, hoe je voorkomt dat het ooit nog gebeurt.

We zien deze melding in 2026 vaker dan ooit. Niet omdat WordPress slechter is geworden, maar omdat plugin-ecosystemen complexer worden, PHP-versies sneller verouderen en updates vaker door derden worden uitgerold zonder dat iemand het mee-test. Hieronder geven we de aanpak die we zelf bij PC Patrol toepassen als een klant in paniek belt met deze foutmelding.

Wat betekent “Er heeft zich een kritieke fout voorgedaan op deze site” eigenlijk?

Sinds WordPress 5.2 toont je site deze melding zodra er een fatale PHP-fout optreedt. Vroeger zag je dan een leeg wit scherm, beter bekend als de White Screen of Death. WordPress vangt die situatie nu netjes af, mailt de beheerder en zet de site in een tijdelijke onderhoudsmodus. De foutmelding zelf is dus niet meer dan een signaal: ergens in de code is iets misgegaan dat WordPress niet meer kon negeren.

Belangrijk om te begrijpen: de melding is een symptoom, niet de oorzaak. Ergens in een plugin, een thema, een PHP-functie of een corrupt core-bestand gaat het mis. Pas als je weet waar de fout vandaan komt, kun je hem gericht oplossen. Klikken in het admin-paneel zonder die kennis is meestal niets meer dan tijd verliezen.

Eerste hulp: controleer altijd eerst je beheerders-mailbox

Voordat je via FTP of het hostingpaneel iets gaat doen: log in op het mailadres dat aan de WordPress-beheerdersaccount gekoppeld is. WordPress stuurt automatisch een mail met als onderwerp “Je site ondervindt een technisch probleem”. In die mail staat exact welke plugin of welk thema de fout veroorzaakte, in welk bestand en op welke regel de fout optrad, en daarnaast een speciale herstelmoduslink waarmee je inlogt in een veilige beheerdersomgeving.

Via die herstelmoduslink kun je de boosdoener met één klik deactiveren, zonder dat je iets aan FTP, databases of wp-config hoeft te doen. Dit is verreweg de snelste route. Bij driekwart van de incidenten die we zien bij klanten is dit voldoende om een site binnen vijf minuten terug online te krijgen. Sla deze stap dus nooit over.

Geen mail ontvangen? Zo zet je je WordPress site stap voor stap weer aan

De mail kan vastlopen door een verkeerd of vol mailadres, een SMTP-probleem of een te zware fout die nog vóór de mailfunctie afgaat. In dat geval pak je het zelf op. We raden onderstaande volgorde aan, van veilig en snel naar ingrijpend.

Stap 1. Maak eerst een back-up

Hoe acuut het ook voelt, eerst back-uppen. Maak via je hostingpaneel of File Manager een kopie van je wp-content-map en exporteer je database. Een herstelactie die misgaat zonder back-up is weer een probleem erbij, en dat wil je niet. Bij onze klanten staat dit automatisch elke nacht ingeregeld via de onderhoudspakketten, juist omdat herstelacties op dit moment het verschil maken.

Stap 2. Zet debug-modus aan zodat je weet wát er stuk is

Open wp-config.php in de root van je site (via FTP, SSH of File Manager) en zoek de regel That’s all, stop editing! Happy publishing. Direct daarboven plak je:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Bezoek je site opnieuw. WordPress schrijft de fout nu weg naar wp-content/debug.log. Open dat bestand en zoek naar regels die beginnen met “Fatal error” of “PHP Fatal”. Daar staat letterlijk welk bestand de crash veroorzaakte, vaak inclusief regelnummer. Meestal herken je direct de plugin- of themamap. Vergeet niet om WP_DEBUG weer op false te zetten zodra je klaar bent, anders lekt deze informatie bij elke fout en is dat een security-risico op zichzelf.

Stap 3. Deactiveer alle plugins in één keer

De grote meerderheid van kritieke fouten komt door één plugin die conflicteert na een update of door een verouderd thema dat botst met een nieuwe PHP-versie. Sluit dat snel uit:

1. Ga via FTP of File Manager naar wp-content/.
2. Hernoem de map plugins naar plugins_uit.
3. Bezoek je site. Werkt hij weer? Dan zit de fout in een plugin.
4. Hernoem de map terug naar plugins en activeer in WordPress de plugins één voor één opnieuw. Zodra de fout terugkomt, ken je de schuldige.

Stap 4. Schakel naar een standaardthema

Werkt je site nog steeds niet? Dan zit de fout vermoedelijk in het thema. Hernoem in wp-content/themes/ de map van je actieve thema. WordPress valt automatisch terug op een standaardthema zoals Twenty Twenty-Four, als dat tenminste aanwezig is. Is dat niet zo, upload dan via FTP een schone kopie. Verlies je daarbij veel ontwerpwerk? Nee, het thema komt zo weer terug. Je wisselt nu alleen om de oorzaak vast te stellen.

Stap 5. Controleer de PHP-versie

Veel kritieke fouten verschijnen direct na een PHP-upgrade door je host. Een plugin of thema dat nog niet volledig PHP 8.x ondersteunt, gooit dan de handdoek in de ring. Controleer in je hostingpaneel welke PHP-versie actief is. Werkt je site weer als je tijdelijk een versie lager kiest, bijvoorbeeld PHP 8.0 in plaats van 8.3? Dan weet je waar het zit. Werk daarna alsnog je plugins en thema bij, want oude PHP-versies krijgen geen beveiligingsupdates meer en zijn dus geen lange-termijn oplossing.

Stap 6. Verhoog het PHP-geheugen

Een minder bekende, maar veelvoorkomende oorzaak: je site heeft te weinig werkgeheugen. Zet dit in wp-config.php tijdelijk hoger:

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

Helpt dit? Dan zit er waarschijnlijk een geheugenvretende plugin in je installatie, of is je hostingpakket te krap bemeten voor de site die er nu op draait. Op goedkope shared hosting met 128 MB PHP-geheugen lopen wat zwaardere webshops of page-builder sites hier vrij snel tegenaan. Een upgrade naar Managed WordPress hosting met realistische geheugenlimieten lost dit type fout structureel op.

Stap 7. Zet de laatste werkende back-up terug

Lukt het je niet om de oorzaak te vinden? Zet een back-up terug van vóór het moment dat de fout optrad. Dit kost vaak vijf tot tien minuten en je site staat weer overeind. Wel een waarschuwing: alle wijzigingen na dat moment ben je kwijt. Bestellingen, formulierinzendingen, nieuwe pagina’s, het verdwijnt allemaal. Bij webshops is dit dus echt een laatste redmiddel en, voor de duidelijkheid, een reden temeer waarom je back-ups altijd dagelijks moeten draaien en getest moeten zijn.

Wat je hostingpartij in dertig seconden ziet wat jij niet ziet

Eén ding dat in vrijwel elke tutorial ontbreekt: een goede hostingpartner kijkt niet in je WordPress, maar in de server-error logs. Daar staat de fatale fout, vaak inclusief regel- en bestandsverwijzing, zonder dat we überhaupt iets aan je site hoeven aan te raken. Vijf minuten loganalyse vervangt een uur klikken in het admin-paneel.

Wij zien daar direct of de oorzaak in de PHP-versie zit, in een specifieke plugin, in een geheugenlimiet, in een corrupt core-bestand of in een rate-limit die door een aanval is veroorzaakt. Voor MKB-ondernemers die de site nodig hebben voor klanten en omzet, is dat het verschil tussen “een halve dag onbereikbaar” en “binnen het kwartier weer online”. Voor onze klanten op Managed WordPress hosting is dit standaard onderdeel van de dienstverlening: zien we een fatale fout in de logs, dan grijpen we in voordat jij de melding op je site ziet.

Hoe je voorkomt dat dit ooit nog gebeurt

Een kritieke fout overkomt je niet zomaar. In 9 van de 10 gevallen heeft hij een aanloop: een plugin die te lang niet bijgewerkt werd, een PHP-versie die stilletjes verouderde, of een update die zonder testomgeving direct op productie werd uitgerold. Drie maatregelen voorkomen verreweg het meeste leed.

1. Update niet op gevoel, maar volgens een vast ritme

Plugin- en core-updates zijn nodig, maar ze zijn óók de meest voorkomende crash-oorzaak. Zet één vast moment per week in waarop updates worden gedraaid, bij voorkeur op een laag-bezocht tijdstip. Maak vóór elke update een back-up. En draai grote updates eerst op een staging-omgeving, waar je rustig kunt checken of formulieren, checkouts en integraties nog werken voordat de update live gaat. Hoe je dat opzet, lees je in onze gids waarom een staging-omgeving onmisbaar is voor veilige WordPress updates.

2. Houd je hostingomgeving up-to-date

PHP-versies krijgen na een paar jaar geen security updates meer. Een site die in 2026 nog op PHP 7.4 draait, is niet alleen onveilig, hij kan elk moment crashen zodra je iets bijwerkt. Op onze Managed WordPress hosting draaien we altijd op een actief ondersteunde PHP-versie en testen we updates eerst zelf. Daarbovenop draaien we LiteSpeed met LSCache, wat het PHP-geheugengebruik per request gevoelig verlaagt en dus ook het risico op out-of-memory crashes.

3. Zorg voor monitoring én een terugvalplan

Een storing die je pas merkt als een klant je belt, kost vaak veel meer omzet dan een monitoringsabonnement per jaar. Goede monitoring controleert je site elke minuut, geeft een seintje zodra hij eruit ligt en, als het meezit, zet de laatste werkende back-up automatisch terug. Welke maandelijkse taken hier allemaal bij horen, lees je in onze complete maandelijkse takenlijst voor WordPress beheer.

Zelf doen of laten doen?

Eerlijk verhaal: een kritieke fout zelf oplossen is technisch heel goed te doen als je een rustige middag hebt, comfortabel bent met FTP en wp-config, en je back-ups op orde zijn. Voor een hobbysite of een nevenproject is dit het experiment wel waard. Je leert er bovendien veel van.

Voor een zakelijke site, een webshop of een site die direct aan je omzet hangt, ligt het anders. Daar telt elk uur downtime. En daar is het verstandiger om vooraf afspraken te maken met een partij die op server-niveau kijkt, dagelijks back-ups draait en pluginupdates eerst test voor ze live gaan. In 5 verborgen kosten van zelf je WordPress site beheren reken we voor wat één kritieke fout op jaarbasis kost als je er zelf voor staat, en hoe snel dat oploopt vergeleken met een vast onderhoudspakket.

Onze WordPress onderhoudspakketten zijn precies daarvoor gemaakt. Vanaf 79 euro per maand monitoren we je site, draaien we updates op een vast moment, maken we dagelijks back-ups en grijpen we in voordat een kritieke fout überhaupt zichtbaar wordt voor je bezoekers. Geen verrassingen, geen paniekuren, gewoon een website die het doet. Wat dat in de praktijk kost ten opzichte van zelf doen, lees je in onze prijsvergelijking voor 2026.

Veelgestelde vragen

Is een WordPress kritieke fout hetzelfde als een hack?

Niet automatisch. De foutmelding zegt alleen dat er een fatale PHP-fout is opgetreden. In de meeste gevallen is dat een plugin- of themaprobleem. Een hack kán wel een kritieke fout veroorzaken, bijvoorbeeld doordat geïnjecteerde code crasht, maar zonder verdere signalen zoals rare doorverwijzingen, spam-bestanden of onbekende admin-accounts ga je daar niet vanuit. Controleer eerst de logbestanden. Zie je daarna nog verdachte signalen, lees dan ons noodprotocol voor een gehackte WordPress site.

Hoe lang duurt het om een kritieke fout op te lossen?

Met de WordPress-herstelmodus, de mail die je ontvangt, ben je vaak binnen vijf minuten terug online. Zonder die mail, zelf via FTP plugins uitschakelen, ben je gemiddeld 20 tot 45 minuten kwijt. Als de oorzaak in de PHP-versie of een corrupt core-bestand zit, kan het oplopen tot een paar uur. Een ervaren hostingpartij doet het in vrijwel alle gevallen onder het halve uur, omdat we direct in de server-logs kijken in plaats van in WordPress.

Kan ik mijn site beter zelf updaten of laten updaten?

Voor een MKB-site die je echt nodig hebt: laten doen. Niet omdat je het niet zou kunnen, maar omdat de risico’s, zoals een verkeerde update-volgorde, geen back-up of geen staging, zich altijd op het verkeerde moment manifesteren. Meestal vrijdagmiddag. Een onderhoudscontract met vaste updaterondes en monitoring kost minder dan de schade van één serieuze crash. Lees ook onze checklist 7 signalen dat je WordPress site het zelf niet meer aankan.

Helpt overstappen op betere hosting?

Vaak wel, vooral als je nu op gedeelde budgethosting zit. Snellere servers, recente PHP-versies, hogere geheugenlimieten en goede error-logs maken een groot verschil bij het voorkomen én oplossen van fouten. Onze Managed WordPress hosting is daar specifiek op ingericht. Hoe je veilig overstapt zonder downtime, lees je in onze migratiegids.

Tot slot

Een kritieke fout op je WordPress site voelt op het moment zelf groot, maar in negen van de tien gevallen is het op te lossen voordat het echt schade doet, mits je weet waar je moet kijken. De combinatie van een vaste hostingpartner, dagelijkse back-ups en updates die getest worden op een staging-omgeving brengt het risico naar bijna nul.

Heb je nu een site die er uit ligt en wil je dat iemand erin duikt, of wil je voorkomen dat je hier ooit op deze manier mee te maken krijgt? Plan een gratis adviesgesprek of bekijk onze WordPress onderhoudspakketten. Maandelijks opzegbaar, gratis verhuizing, en geen weekend-paniek meer.