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. In dit artikel lees je wat er aan de hand is, hoe je de oorzaak vindt en je site weer online krijgt, en hoe je de kans verkleint dat het opnieuw gebeurt.

Kort antwoord: zo pak je het aan

1. Zoek de herstelmodus-mail. WordPress mailt het beheerdersadres met de naam van de plugin of het thema dat de fout gaf en een link naar de herstelmodus. Daarmee schakel je de boosdoener met één klik uit.
2. Geen mail? Schakel alle plugins uit. Hernoem via FTP of het bestandsbeheer van je hostingpaneel de map wp-content/plugins naar plugins_uit, of gebruik WP-CLI: wp plugin deactivate --all.
3. Nog steeds stuk? Lees het debug-log. Zet WP_DEBUG_LOG aan in wp-config.php en kijk in wp-content/debug.log of het PHP-errorlog van je hosting. Daar staat welk bestand de fout geeft.

Hieronder werken we die stappen verder uit, met de aanpak die we zelf bij PC Patrol volgen als een klant 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 af: bezoekers krijgen de melding te zien, en de beheerder krijgt een mail met details en een link naar de herstelmodus. Dat is geen onderhoudsmodus. Je site blijft voor bezoekers kapot totdat de oorzaak is weggenomen. Alleen jij kunt via de herstelmodus inloggen, terwijl de plugin of het thema dat de fout veroorzaakte voor jou tijdelijk wordt overgeslagen.

Belangrijk om te begrijpen: de melding is een symptoom, niet de oorzaak. Ergens in een plugin, een thema, de PHP-configuratie of een beschadigd core-bestand gaat het mis. Pas als je weet waar de fout vandaan komt, kun je hem gericht oplossen.

Herstel in 7 stappen

Werk de stappen in deze volgorde af, van snel en veilig naar ingrijpend.

Stap 1. Controleer de herstelmodus-mail

Kijk in de mailbox van het adres dat bij de WordPress-beheerder hoort, ook in de spammap. WordPress stuurt een mail met als onderwerp "Je site ondervindt een technisch probleem". Daarin staat welke plugin of welk thema de fout veroorzaakte, in welk bestand en op welke regel, en een speciale link naar de herstelmodus.

Via die link log je in, deactiveer je de boosdoener en zoek je daarna in alle rust naar een update of alternatief. Je hoeft niets aan FTP, databases of wp-config.php te doen. Dit is de snelste route, dus sla hem niet over.

De mail kan uitblijven door een verkeerd of vol mailadres, een site die geen mail kan versturen, of een fout die optreedt voordat WordPress kan mailen. Ga dan door met stap 2. Maak wel eerst een back-up: kopieer via je hostingpaneel de map wp-content en exporteer je database. Een herstelactie die misgaat zonder back-up is een tweede probleem erbij.

Stap 2. Schakel alle plugins uit

Vaak is één plugin de oorzaak, bijvoorbeeld na een update of na een PHP-upgrade bij je host. Sluit dat snel uit:

1. Ga via FTP of het bestandsbeheer van je hostingpaneel 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. WordPress heeft de plugins dan gedeactiveerd. Activeer ze één voor één opnieuw. Zodra de fout terugkomt, ken je de schuldige.

Heb je SSH-toegang, dan gaat het sneller met WP-CLI. Met de opties --skip-plugins --skip-themes laadt WP-CLI de kapotte code niet, zodat het commando zelf niet ook vastloopt:

wp plugin deactivate --all --skip-plugins --skip-themes
wp plugin activate naam-van-plugin

Stap 3. Zet het debug-log aan en lees het PHP-errorlog

Open wp-config.php in de hoofdmap van je site 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. Zoek naar regels met "PHP Fatal error". Daar staat welk bestand de crash veroorzaakte, meestal met regelnummer. Aan het pad herken je de plugin- of themamap. Zet WP_DEBUG weer op false zodra je klaar bent, want een debug-log dat blijft aanstaan kan gevoelige informatie lekken.

Blijft debug.log leeg, kijk dan in het PHP-errorlog van de server. Waar dat staat, hangt af van je omgeving:

• Shared of managed hosting: in je hostingpaneel onder een kopje als "Logs", "Errors" of "Foutlogboek". Soms staat er een bestand error_log in de hoofdmap van je site of in wp-admin.
• Eigen VPS met Nginx: /var/log/nginx/error.log, en het log van PHP-FPM, op Debian en Ubuntu bijvoorbeeld /var/log/php8.3-fpm.log.
• Eigen VPS met Apache: /var/log/apache2/error.log op Debian en Ubuntu, of /var/log/httpd/error_log op AlmaLinux en Rocky Linux.

Stap 4. Schakel naar een standaardthema

Werkt je site nog steeds niet terwijl alle plugins uit staan? Dan zit de fout vermoedelijk in het thema. Hernoem in wp-content/themes/ de map van je actieve thema. WordPress valt dan terug op een standaardthema, bij voorkeur het nieuwste: Twenty Twenty-Five. Staat er geen standaardthema op je site, upload dan een schone kopie via FTP. Je ontwerp ben je niet kwijt: zodra je de map terug hernoemt, is het thema er weer. Je wisselt nu alleen om de oorzaak vast te stellen.

Met WP-CLI installeer en activeer je het standaardthema in één keer:

wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

Stap 5. Controleer de PHP-versie en de PHP-extensies

Veel kritieke fouten verschijnen direct na een PHP-upgrade door je host. Een plugin of thema dat de nieuwe versie nog niet ondersteunt, crasht dan. Kijk in je hostingpaneel welke PHP-versie actief is en of de fout in het log over een verouderde functie gaat.

Terugschakelen naar een oudere PHP-versie kan je site tijdelijk weer online brengen, maar is geen oplossing: oude versies krijgen geen beveiligingsupdates meer. Kies voor de lange termijn een PHP-versie die nog ondersteund wordt, op dit moment 8.3 of hoger, en werk de plugin of het thema bij dat niet meekan. Hoe je dat zonder downtime aanpakt, lees je in PHP-versie updaten in WordPress.

Let ook op ontbrekende PHP-extensies. Na een wissel van PHP-versie staan niet altijd dezelfde extensies aan. Foutmeldingen als Call to undefined function mysqli_connect(), Class "DOMDocument" not found of een verwijzing naar mbstring, intl, zip, curl of imagick wijzen daarop. Op shared hosting zet je de extensie aan in de PHP-instellingen van je paneel. Op een eigen VPS installeer je het pakket voor jouw PHP-versie, bijvoorbeeld php8.3-mbstring, en herstart je PHP-FPM.

Stap 6. Verhoog het PHP-geheugen

Staat er in het log iets als "Allowed memory size exhausted", dan heeft je site 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 voor de site die er nu op draait. Let op: je kunt in wp-config.php niet hoger gaan dan de limiet die je host instelt. Zwaardere webshops en sites met een page builder lopen daar op goedkope shared hosting sneller tegenaan.

Stap 7. Zet de laatste werkende back-up terug

Lukt het niet om de oorzaak te vinden? Zet een back-up terug van vóór het moment dat de fout optrad. 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 een reden temeer om back-ups dagelijks te laten draaien en af en toe te testen. Hoe dat testen gaat, lees je in Back-up testen: zo weet je zeker dat je site terugkomt.

Minder voor de hand liggende oorzaken

Vind je in de stappen hierboven niets, kijk dan naar deze oorzaken. Ze komen minder vaak voor, maar je sluit ze snel uit.

Een volle schijf

Is de opslag van je hostingpakket of server vol, dan kan PHP geen tijdelijke bestanden, sessies of cache meer wegschrijven. Updates breken dan halverwege af, met een kritieke fout als gevolg. In je hostingpaneel zie je hoeveel ruimte je gebruikt. Op een eigen VPS check je het met df -h. Oude back-ups, logbestanden en cachemappen zijn de gebruikelijke ruimtevreters. Voor een VPS hebben we er een aparte besliskaart voor een volle VPS-schijf voor.

Een achtergebleven .maintenance-bestand

Tijdens een update zet WordPress een bestand .maintenance in de hoofdmap van je site. Bezoekers zien dan kort de melding dat de site niet beschikbaar is wegens gepland onderhoud. Loopt de update vast, dan blijft dat bestand staan en blijft je site in die stand hangen. Dat is een andere melding dan de kritieke fout, maar het gebeurt vaak in dezelfde situatie. Verwijder het bestand via FTP of het bestandsbeheer. Het begint met een punt, dus zet in je FTP-programma het tonen van verborgen bestanden aan.

Een half afgebroken update

Valt de verbinding weg of loopt de server vast tijdens een update, dan staan er soms half bijgewerkte bestanden. De fout wijst dan naar een bestand in wp-includes, wp-admin of een pluginmap dat niet compleet is. Zo herstel je dat:

• Core: controleer de bestanden met wp core verify-checksums en zet ze terug met wp core download --force --skip-content. Zonder WP-CLI download je dezelfde WordPress-versie van wordpress.org en upload je de mappen wp-admin en wp-includes opnieuw. Laat wp-content en wp-config.php met rust.
• Plugin: verwijder de map van de betreffende plugin en installeer hem opnieuw, of gebruik wp plugin install naam-van-plugin --force.

Wat je hostingpartij ziet wat jij niet ziet

Eén ding dat in veel tutorials ontbreekt: een hostingpartij kijkt niet eerst in je WordPress, maar in de foutlogs van de server. Daar staat de fatale fout, vaak met bestand en regelnummer, zonder dat er iets aan je site veranderd hoeft te worden. Uit die logs blijkt ook of de oorzaak in de PHP-versie zit, in een plugin, in een geheugenlimiet, in een beschadigd core-bestand, in een volle schijf of in een aanval die de server overbelast.

Wil je dat iemand meekijkt? Neem contact op. Zonder SLA reageren we binnen een werkdag. Moet je site ook buiten kantooruren snel terug zijn, dan heb je afspraken nodig met een vaste reactietijd, zoals bij onze weekendsupport.

Hoe je voorkomt dat dit opnieuw gebeurt

Een kritieke fout heeft vaak een aanloop: een plugin die te lang niet bijgewerkt werd, een PHP-versie die stilletjes verouderde, of een update die zonder test direct op de live site werd uitgerold. Drie maatregelen voorkomen het meeste leed.

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

Plugin- en core-updates zijn nodig, maar ze zijn ook een veelvoorkomende oorzaak van crashes. Kies één vast moment per week voor updates, bij voorkeur op een rustig tijdstip. Maak vóór elke update een back-up. Draai grote updates eerst op een staging-omgeving, waar je rustig kunt checken of formulieren, de checkout en koppelingen nog werken. Hoe je dat opzet, lees je in WordPress veilig updaten: zo voorkom je dat een update je site sloopt en in onze uitleg over een WordPress staging-omgeving.

2. Houd je hostingomgeving actueel

PHP-versies krijgen na een paar jaar geen beveiligingsupdates meer. Een site die nog op een verouderde versie draait, is niet alleen onveilig, hij kan ook crashen zodra je iets bijwerkt. Vraag je host welke PHP-versie je site gebruikt en wanneer die wordt bijgewerkt. Houd daarnaast je schijfruimte en geheugenlimiet in de gaten. Draai je WordPress op Managed WordPress hosting, dan houden wij de serveromgeving bij.

3. Zorg voor monitoring en een terugvalplan

Een storing die je pas merkt als een klant belt, kost meer dan nodig. Goede monitoring controleert je site regelmatig en geeft een seintje zodra hij eruit ligt. Leg daarnaast vast wie wat doet als het misgaat, en waar de laatste werkende back-up staat. Wat er verder bij vast onderhoud hoort, lees je in WordPress beheer: wat hoort erbij en wanneer besteed je het uit.

Zelf doen of laten doen?

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

Voor een zakelijke site of webshop ligt het anders. Daar telt elk uur dat de site eruit ligt. Dan is het verstandig om vooraf afspraken te maken met een partij die updates op een vast moment draait, dagelijks back-ups maakt en bij een storing in de serverlogs kijkt. Wat je zelf blijft betalen als je het niet uitbesteedt, zie je in Wat kost een WordPress-website per jaar?. Wil je het onderhoud overdragen, kijk dan bij WordPress-onderhoud uitbesteden wat daarbij hoort.

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. Meestal is dat een plugin- of themaprobleem. Een hack kán wel een kritieke fout veroorzaken, bijvoorbeeld doordat geïnjecteerde code crasht, maar zonder andere signalen zoals vreemde doorverwijzingen, onbekende bestanden of onbekende beheerdersaccounts ga je daar niet van uit. Controleer eerst de logbestanden. Zie je daarna nog verdachte signalen, lees dan hoe je malware en backdoors opspoort na een hack.

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

Dat hangt af van de oorzaak. Met de herstelmodus-mail ben je vaak het snelst klaar, omdat je direct weet welke plugin of welk thema het probleem is. Moet je zelf via FTP plugins uitschakelen en logs lezen, dan kost het meer tijd. Zit de oorzaak in de PHP-versie, ontbrekende extensies of een beschadigd core-bestand, dan duurt het langer.

Waarom verschijnt de fout direct na een update?

Omdat een update code vervangt. Past de nieuwe versie van een plugin niet bij je PHP-versie, bij een andere plugin of bij je thema, of is de update halverwege afgebroken, dan crasht de site. Schakel de plugin uit die je net hebt bijgewerkt, of zet de vorige versie terug, en kijk in het log wat er precies misgaat.

Kan ik WP-CLI gebruiken als de site kapot is?

Ja, mits je SSH-toegang hebt. Voeg dan --skip-plugins --skip-themes toe aan je commando's. WP-CLI laadt dan de plugins en het thema niet, zodat de fout het commando zelf niet blokkeert.

Helpt overstappen op betere hosting?

Soms wel, vooral als je nu op krappe budgethosting zit. Actuele PHP-versies, ruimere geheugenlimieten en toegang tot goede foutlogs maken een groot verschil bij het voorkomen en oplossen van fouten. Hoe je veilig verhuist zonder dat je site eruit ligt, lees je in WordPress site verhuizen zonder downtime.

Tot slot

Een kritieke fout voelt op het moment zelf groot, maar is meestal goed op te lossen als je weet waar je moet kijken: eerst de herstelmodus-mail, dan de plugins, dan de logs. Een vaste updateroutine, dagelijkse back-ups die je test en updates die eerst op staging draaien, maken de kans op herhaling een stuk kleiner.

Ligt je site er nu uit en kom je er niet uit, neem dan contact op. Wil je het onderhoud structureel uit handen geven, bekijk dan WordPress-onderhoud uitbesteden.