Je schrikt je rot: je WordPress-site toont ineens een witte pagina met de melding “There has been a critical error on this website” (in het Nederlands: Er is een kritieke fout op deze website opgetreden). Dit gebeurt opvallend vaak na een update of aanpassing. Wat betekent deze foutmelding, en – belangrijker – hoe krijg je je site weer terug online? Geen paniek: hieronder leg ik uit wat er aan de hand is en geef ik een stappenplan om het probleem op te lossen.
Wat betekent de foutmelding?
Deze melding betekent dat WordPress op een probleem is gestuit: een PHP-script (een stukje code) is vastgelopen door een fatale fout en kon niet voltooid worden. In feite heeft WordPress zichzelf stopgezet om schade te voorkomen. Goed nieuws: dit is een ernstige fout voor dat specifieke script, maar niet voor je hele website – het is niet het teken van een hack of een onherstelbare ramp. Je bestanden en inhoud zijn hoogstwaarschijnlijk nog intact; er is “alleen maar” iets misgegaan in de code.
Waarom zie je deze fout dan zo vaak na updates of wijzigingen? Simpel: nieuwe updates of veranderingen kunnen onbedoelde problemen veroorzaken. Misschien is een plugin niet compatibel met de nieuwste WordPress-versie, zit er een fout in de code van je thema, of heb je net een plugin geüpdatet die alles platlegt. Zo’n conflict of bug treedt vaak direct op na een update en kan de hele site laten crashen. WordPress 5.2 en hoger tonen in zo’n geval deze kritieke foutmelding in plaats van een volledig wit scherm, en proberen je zelfs te helpen de oorzaak te vinden. Vaak krijg je bijvoorbeeld de instructie om je e-mail te checken voor meer informatie.
Kortom: de melding “There has been a critical error on this website” is WordPress’ manier om te zeggen dat er iets mis is gegaan (vaak na een update) waardoor de site niet kan laden. Het klinkt eng, maar meestal is het probleem goed op te lossen. Hieronder lood ik je stap voor stap door een aantal oplossingen. (Geen technische achtergrond? Geen zorgen – ik houd het eenvoudig en leg technische termen uit waar nodig.)
Stappenplan: WordPress “critical error” verhelpen
Volg onderstaande stappen om de kritieke fout op te lossen. Je hoeft mogelijk niet álle stappen te doorlopen; zodra je de oorzaak vindt en oplost, zou je site het weer moeten doen. Begin bij stap 1 en werk naar beneden tot de site weer werkt.
Stap 1: Controleer de e-mail van WordPress (herstelmodus)
WordPress heeft een ingebouwde veiligheidsfunctie die bij zo’n kritieke fout een e-mail stuurt naar het beheerdersadres van je site. In die e-mail staat meestal welke plugin of welk thema de fout veroorzaakte, plus een speciale link om je site in herstelmodus te openen. Dit is de snelste manier om het probleem te vinden en te verhelpen.
Wat je moet doen: check de inbox van het e-mailadres dat aan je WordPress-admin is gekoppeld (kijk ook in je spamfolder). Heb je een bericht met als onderwerp zoiets als “Your Site is Experiencing a Technical Issue” of “Er heeft zich een kritische fout voorgedaan op je website”? Zo ja, open die e-mail. Hierin vind je meestal welke plugin of welk thema de boosdoener is, én een login-link voor de herstelmodus. Klik op die speciale link en log in. Je site laadt nu in veilige modus – WordPress heeft de foutgevende plugin of het thema tijdelijk uitgeschakeld.
Volg de instructies in de melding (vaak zie je meteen welk onderdeel is uitgeschakeld). Ga in je dashboard naar Plugins of Thema’s en verwijder of deactiveer het betreffende onderdeel dat de fout gaf. Meestal is daarmee het probleem binnen enkele minuten opgelost. Herstelmodus afsluiten doe je gewoon door uit te loggen; WordPress activeert de problematische plugin/thema niet opnieuw totdat jij besluit een fix toe te passen (bijvoorbeeld een update patchen of vervangen).
Wat als je geen e-mail hebt ontvangen? Het kan gebeuren dat je geen mail krijgt, bijvoorbeeld als je hostingmail niet goed is ingesteld. Geen zorgen, ga dan door naar de volgende stap om zelf de fout op te sporen.
Stap 2: Schakel debug-modus in en bekijk de error logs
Als je geen aanwijzing via e-mail hebt, speel ik zelf detective. WordPress heeft een ingebouwde debug-modus (foutopsporingsmodus) die je kunt inschakelen om precies te zien welke fout er optreedt. Dit toont de technische foutmelding op je site en/of schrijft details weg naar een logbestand (debug.log). Zo kun je zonder programmeerkennis achterhalen waar het misgaat.
Debug-modus aanzetten: gebruik de bestandsbeheerder van je hosting (bijvoorbeeld cPanel File Manager) of een FTP-programma (zoals FileZilla) om het bestand wp-config.php in de hoofdmap van je WordPress-site te bewerken. In wp-config.php vind je een regel met define('WP_DEBUG', false);. Wijzig deze naar define('WP_DEBUG', true);. Voeg ook de volgende regels toe (of zet ze op true als ze al bestaan):
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);Hiermee zorg je dat fouten niet op het scherm aan bezoekers getoond worden, maar wel worden gelogd in een bestand genaamd debug.log in de /wp-content/ map. Sla de wijziging op en refresh de site.
Open nu via FTP/cPanel het bestand wp-content/debug.log (of download het). Hierin staat de exacte foutmelding, inclusief de bestandsnaam en regelnummer waar het mis ging. Vaak zie je bijvoorbeeld dat een specifiek plugin-bestand of thema-bestand een “fatal error” gaf. Je hebt nu de speld in de hooiberg gevonden: je weet welk onderdeel de boosdoener is. Noteer de plugin- of thema-naam en ga door naar de volgende stap om het op te lossen. (Vergeet niet WP_DEBUG later weer op false te zetten als je klaar bent.)
Alternatief: heeft je hosting een eigen error log in het controlepaneel? Daarin vind je mogelijk dezelfde informatie. In cPanel heet dit bijvoorbeeld Errors of PHP Error Log. Je kunt daar kijken of rond het tijdstip van de crash een “Fatal error” of “Uncaught Exception” vermeld staat, inclusief de naam van een plugin of thema-bestand. Dat geeft dezelfde hint. Als je via debug-modus of error log de foutcode hebt gevonden, kun je gericht de plugin of het thema identificeren.
Stap 3: Deactiveer plugins om een conflict op te sporen
Veruit de meest voorkomende oorzaak van de kritieke fout is een conflict of fout in een plugin. Een simpele plugin-update kan al chaos veroorzaken als er iets misgaat. Om te testen of een plugin het probleem is, schakel ik ze allemaal even uit.
Omdat je niet in je wp-admin kunt (de site ligt er immers uit), doe je dit via je hosting bestandsbeheer of FTP. Ga naar de map wp-content/plugins en hernoem de map plugins naar iets als plugins_uit (de exacte naam maakt niet uit). Hiermee deactiveer je in één klap alle plugins (WordPress “ziet” de plugins niet meer onder de gewijzigde mapnaam).
Probeer nu je site opnieuw te laden. Doet de site het weer? Bingo – dan was een plugin de schuldige. Het is tijd om uit te vinden wélke. Hernoem de map plugins_uit terug naar plugins om de plugins terug te zetten. Ga nu één voor één de plugin-mappen binnen wp-content/plugins hernoemen of activeer de plugins stuk voor stuk via het dashboard (als je weer in wp-admin kunt). Tip: zet steeds één plugin actief en refresh de site. Zodra de site weer crasht met de kritieke fout, heb je de boosdoener gevonden. De plugin die je als laatst inschakelde veroorzaakt de fout.
Heb je de foutgevende plugin gevonden, laat deze dan uitgeschakeld. Check of er een bekende bug of update voor is, of zoek een alternatief plugin als het een conflict is. In veel gevallen kun je het probleem verhelpen door de plugin te verwijderen of vervangen, of door contact op te nemen met de ontwikkelaar als het een betaalde plugin betreft.
Stap 4: Schakel over naar een standaardthema
Is het probleem met stap 3 nog niet opgelost (of kwam uit de debug-log naar voren dat het aan je thema ligt)? Dan kan een fout in je actieve thema de boosdoener zijn. Ook thema’s kunnen na updates incompatibel raken of een codefout bevatten, vooral als je maatwerk in het thema hebt gedaan. De aanpak lijkt op die bij plugins: ik schakel het actieve thema tijdelijk uit, zodat WordPress terugvalt op een standaardthema.
Via FTP of de bestandsmanager ga je naar wp-content/themes. Zoek de map van je actieve theme en hernoem die, bijvoorbeeld voeg _old toe: mijntheme_old. Hierdoor kan WordPress dat thema niet laden. Als er nog een standaard WordPress-theme in de map staat (bijv. Twenty Twenty-One of Twenty Twenty-Three), zal WordPress automatisch daarop overschakelen. Heb je geen ander thema in de map, kun je via wordpress.org even een standaardthema downloaden en in de themes-map uploaden.
Laadt je site nu weer zonder foutmelding? Dan lag het aan het thema. Je kunt proberen het theme opnieuw te installeren of updaten naar de nieuwste versie, of schakel (tijdelijk) over op een ander theme. Neem contact op met de thema-ontwikkelaar als het een premium theme is, of overweeg een ander thema als de fout blijft optreden. In elk geval kun je weer in je dashboard; van daaruit kun je een nieuw thema activeren of het defecte thema verwijderen/herstellen.
Stap 5: Controleer de PHP-versie en geheugenlimiet
Als plugins en thema’s uitgesloten zijn, kijk dan naar de server-instellingen. Twee veelvoorkomende technische oorzaken van kritieke errors zijn een PHP-versieconflict of een opgebruikt geheugen.
- PHP-versie: WordPress draait op de programmeertaal PHP. Een te oude PHP-versie (onder 7.4) of juist een gloednieuwe versie waar een plugin niet op voorbereid is, kan je site breken. Controleer in het hostingcontrolepaneel (bij veel hosts via Select PHP Version of PHP-instellingen) welke PHP-versie actief is. Idealiter gebruik je PHP 8.x, maar check de compatibiliteit: als je net geüpdatet bent naar PHP 8 en de site crasht, probeer tijdelijk terug te schakelen naar de vorige versie (bijv. 7.4) – werkt de site dan weer, dan lag het aan PHP-incompatibiliteit. Andersom, als je host nog een oude PHP gebruikt, upgrade naar 7.4 of hoger, want WordPress vereist minstens PHP 7.4. Veel hosts laten je dit zelf instellen in cPanel of een ander panel. Na wijzigen van de PHP-versie, probeer de site opnieuw.
- Geheugenlimiet: iedere site heeft een maximale PHP-geheugenlimiet. Als een plugin of script te veel geheugen vergt en die limiet overschrijdt, ontstaat een “Allowed memory size exhausted” fout – wat ook resulteert in de kritieke foutmelding. In de
debug.logzou je dat expliciet zien staan als dit het geval is. De oplossing is de limiet verhogen. Dit kun je doen door inwp-config.phpde volgende regel toe te voegen (net boven “That's all, stop editing”):
define('WP_MEMORY_LIMIT', '256M');Hiermee vraagt WordPress om 256 MB PHP-geheugen te gebruiken (pas het getal aan naar behoefte). Sla op en test de site. Geen effect of kun je het bestand niet bewerken? Je kunt ook aan je hostingpartij vragen of zij de PHP memory_limit voor je kunnen verhogen. Let op dat een structureel hoog verbruik vaak door een inefficiënte plugin komt – probeer overbodige plugins uit te schakelen als je herhaaldelijk memory errors krijgt.
Stap 6: Herstel de site of WordPress-bestanden (laatste redmiddel)
In de meeste gevallen heb je tegen deze stap al gevonden wat er mis was. Mocht de fout nog steeds niet zijn opgelost, overweeg dan een meer ingrijpende hersteloptie:
- Herstellen vanuit backup: heb je een recente backup van je site? Dan kan het simpelweg terugzetten van de backup (bestanden en database) de snelste weg zijn naar een werkende site. Dit zet alles terug naar een moment vóór de fout optrad. Gebruik bij voorkeur de backup-tool van je hostingpanel (bijv. in cPanel of Plesk) om een backup terug te zetten, of een plugin zoals UpdraftPlus als je die al had geïnstalleerd. (Waarschuwing: je verliest wel wijzigingen die na het backup-tijdstip zijn gedaan.)
- WordPress core opnieuw uploaden: het kan zijn dat een WordPress-systeembestand corrupt is geraakt of een update niet volledig was. Je kunt dan de kernbestanden van WordPress overschrijven met schone exemplaren. Download van wordpress.org de laatste versie van WordPress en upload via FTP alle bestanden behalve de
wp-contentmap naar je server, zodat je de kernbestanden vervangt. Dit herstelt eventuele beschadigde core-files. (Maak altijd eerst een backup voordat je dit doet!). Start hierna de site opnieuw op.
Deze maatregelen zijn wat technischer. Als je dit spannend vindt of er niet uitkomt, ga dan door naar de afsluitende tip hieronder.
Kom je er niet uit? Hulp inschakelen
Hopelijk is je site na bovenstaande stappen weer bereikbaar. Zo niet, of als je liever geen risico neemt met zelf prutsen, onthoud dat er altijd hulp beschikbaar is. Neem contact op met je hostingprovider – een goede host helpt met het identificeren van foutoorzaken en kan je vaak door lastige stappen heen praten. Ook kun je een WordPress-expert inschakelen om het probleem voor je op te lossen.