Je klikt op bijwerken en even later kom je niet meer in je site. Soms geeft alleen bewerken een wit scherm, soms zie je een kritieke fout en lukt inloggen niet meer. Het korte antwoord: werk nooit alles tegelijk bij, controleer eerst of er een back-up is die je zelf kunt terugzetten, en houd de terugweg bij de hand.
Dit artikel is voor wie een WordPress-site of WooCommerce-shop zelf beheert, met een gekocht thema, een handvol plugins en hosting waarvan je niet precies weet wat die doet.
Zo herken je dat een update is misgegaan
De site hoeft niet helemaal weg te zijn. Vaak werkt de voorkant nog, terwijl het beheer stuk is.
Een wit scherm zonder tekst, op de voorkant of zodra je op bewerken klikt; de documentatie van WordPress noemt dit het White Screen of Death.
De melding dat er een kritieke fout is opgetreden op deze website, met het verzoek je e-mail te controleren.
De melding dat de site even niet beschikbaar is voor gepland onderhoud (Briefly unavailable for scheduled maintenance), die niet meer weggaat.
Inloggen lukt niet meer, of de editor opent maar blijft leeg, zonder foutmelding.
Een pagina toont ineens de inhoud van een andere pagina, of een pluginfunctie (labels printen, betalen) geeft een fout die er gisteren niet was.
Schrijf op wat je ziet en wat je als laatste bijwerkte; daar vraagt je host als eerste naar.
Vier onderdelen die bij elkaar moeten passen
Een WordPress-site draait op vier lagen die elkaar moeten verdragen: de PHP-versie op de server, WordPress zelf, het thema en de plugins. De officiële foutenlijst van WordPress noemt als oorzaken van de kritieke fout precies die combinatie. Conflicten tussen plugins, een thema dat niet meekan, een PHP-versie die niet past, de geheugenlimiet of beschadigde bestanden.
Welke oorzaak het bij jou is, valt op afstand niet te zeggen en ook niet af te lezen aan de melding. Uitsluitsel geeft de foutlog bij je host, of het logbestand dat WordPress kan bijhouden. In een van de forumvragen stond dit: een gekocht thema dat lang niet was bijgewerkt, en een PHP-versie die omhoog ging omdat het thema dat op papier vroeg. Daarna was het dashboard weg; PHP terugzetten hielp. Of het thema of een plugin de oorzaak was, is in die draad niet vastgesteld.
Onze volgorde in acht stappen
Illustratie, gegenereerd met AI. De vier treden staan voor thema en plugins, WordPress zelf, PHP en de eindcontrole; de oranje lijn is de terugweg via de back-up.
Dit is de volgorde die wij aanhouden. WordPress schrijft geen volgorde voor; de documentatie zegt alleen dat je vooraf een back-up maakt en die terugzet bij problemen. Onze reden: thema en plugins hangen van een externe maker af en lopen daardoor het makkelijkst achter. Die krijgen eerst de kans om de nieuwe WordPress-versie en PHP-versie te ondersteunen; pas daarna verhoog je de lagen daaronder. En je doet een ding per keer, zodat je weet wat het was als iets omvalt.
Controleer de back-up bij je host: is er een van vandaag of gisteren, en kun jij die zelf terugzetten? Maak daarnaast een eigen kopie van de database en van alle bestanden in je WordPress-map, dus ook wp-config.php en .htaccess en niet alleen wp-content. Een back-up bestaat uit die twee delen: database en bestanden.
Open Tools > Site Health (in een Nederlandstalige installatie: Tools > Sitediagnose). Onder Status zie je of je PHP-versie verouderd is en of er plugins op een update wachten; onder Info staat de versie van het actieve thema.
Zoek bij de leverancier van je thema op hoe oud die versie is; Site Health toont de versie, niet de leeftijd. Kijk voor betaal- en verzendplugins of de maker de nieuwe WordPress-versie ondersteunt.
Werk het thema bij, daarna de plugins, een voor een. Na elke update laad je de voorkant, log je in en open je een pagina in de editor.
Werk WordPress zelf bij via Dashboard > Updates. Kleine onderhouds- en beveiligingsupdates installeren de meeste sites vanzelf; voor een grote versie klik je zelf op Update Now.
Test opnieuw: voorkant, inloggen, editor en contactformulier. Bij een webshop doe je een proefbestelling.
Pas nu de PHP-versie verhogen in het hostingpaneel, alleen als thema en plugins die versie ondersteunen. Test nog een keer; werkt iets niet, zet PHP dan terug.
Maak de cache leeg, van een cacheplugin en van je host. Anders zie je mogelijk nog de oude versie.
Voorbeeldsituatie: je host mailt dat een oudere PHP-versie wordt uitgezet, en je gekochte thema is anderhalf jaar niet bijgewerkt omdat de licentie is verlopen. Verhoog dan niet eerst PHP. Verleng of vervang de licentie, werk het thema bij, test, en verhoog daarna pas PHP. Heb je daar geen tijd voor, vraag dan nu hulp, niet na het witte scherm.
Voor een webshop geldt de volgorde van WooCommerce
Bij een WooCommerce-shop volgen wij de handleiding van WooCommerce, die een andere volgorde aanhoudt. Maak een actuele back-up en test de update waar mogelijk op een staging-kopie: een kopie van je live site waarop je bijwerkt voordat klanten er iets van merken. Zet de winkel tijdens de update in de modus Coming soon, zodat niemand afrekent terwijl bestanden en database veranderen. Werk eerst WooCommerce bij en voer de database-update uit als de melding daarom vraagt, met een back-up klaar. Pas daarna werk je extensies, thema en betaalkoppelingen bij; de waarde Tested up to is daarbij het signaal voor compatibiliteit. Sluit af met een proefbestelling en controleer verzending, btw, betaling en ordermails.
Als het al mis is: drie regels noodplan
Zit je nu voor een wit scherm of een kritieke fout, dan zijn dit de drie routes, in deze volgorde.
De e-mail. Bij een kritieke fout stuurt WordPress een bericht met instructies naar het beheerdersadres van de site. Controleer dat adres, ook de ongewenste post; daar staan de details die je op je scherm niet ziet.
Alle plugins in een klap uit. Ga via FTP of de bestandsbeheerder van je host naar wp-content en hernoem de map plugins naar plugins_old. Log daarna in op het beheer via /wp-admin/plugins.php; WordPress meldt dan dat de plugins ontbreken en zet ze uit. Kom je er nu wel in, dan zat het in een plugin. Pas dan hernoem je de map terug en schakel je de plugins een voor een weer in tot je de boosdoener hebt. Helpt dat niet, activeer dan een standaardthema.
De back-up van je host terugzetten, de versie van voor de update; de documentatie noemt dit zelf als uitweg. Werkt je eigen back-up niet, wat in een forumvraag precies het probleem was, dan is de kopie bij de host je enige terugweg. Daarom staat die controle bij ons op nummer een.
Blijft de melding staan dat de site even niet beschikbaar is voor gepland onderhoud? Die hangt aan een bestand met de naam .maintenance in de hoofdmap van je site, dat na een afgebroken update kan achterblijven. Verwijder het via FTP, zoals de documentatie voorschrijft; zet zo nodig het tonen van verborgen bestanden aan.
Op fora lees je vaak het advies om WP_DEBUG aan te zetten. Dat werkt, maar de documentatie raadt het af op een live site. Wil je toch weten wat er misgaat, zet dan in wp-config.php WP_DEBUG en WP_DEBUG_LOG op true en WP_DEBUG_DISPLAY op false. De fouten komen dan in wp-content/debug.log en niet op je scherm. Zet het weer uit zodra je het antwoord hebt. Eenvoudiger is de foutlog bij je host opvragen.
Eerst wat niets kost, daarna pas hulp
Back-up controleren en Site Health nakijken kosten niets. De volgende trede is een staging-kopie bij je host; vraag je host of die dat aanbiedt. Een onderhoudsafspraak, waarbij iemand anders de updates doet en de terugweg bewaakt, is de trede daarna. Laat het doen in deze gevallen:
Je gekochte thema heeft geen geldige licentie meer, of de geïnstalleerde versie is ouder dan een jaar
Je hebt een webshop met een betaal- of verzendplugin waar je omzet van afhangt
Je host bewaart geen dagelijkse back-up die je zelf kunt terugzetten
Je hebt bij een eerdere update al eens een wit scherm gehad en weet niet waardoor
Is het thema aan zijn einde, omdat de maker ermee stopt of elke update iets breekt, dan is bijwerken symptoombestrijding. De opties, van verbeteren tot vernieuwen, staan op onze pagina over een website laten maken of vernieuwen. Hoe wij WordPress-sites bouwen en onderhouden lees je bij onze WordPress-specialisatie.
Controleer dit voordat je op bijwerken klikt
Er staat een back-up bij de host van vandaag of gisteren, en je weet hoe je die zelf terugzet
Je hebt een eigen kopie van de database en van alle bestanden van je site
Je weet welke PHP-versie je draait en welke versie je thema en plugins ondersteunen
Je hebt FTP-gegevens of de bestandsbeheerder van je host bij de hand, en je weet waar de beheerdersmail binnenkomt
Bij een webshop: de winkel kan even in Coming soon en er ligt een proefbetaling klaar
De eerste twee stappen veranderen niets aan je site
Begin met stap een en twee: de back-up controleren en Site Health openen kost een kwartier. Blijkt de back-up te ontbreken of het thema jaren oud, dan weet je genoeg om te beslissen of je verder gaat of hulp vraagt. Wil je dat wij meekijken, stuur ons dan via contact je WordPress-versie, je thema en je PHP-versie: de drie gegevens uit Site Health.
Hoe dit artikel tot stand kwam: we lazen acht recente vragen op de Nederlandstalige en Engelstalige WordPress-supportfora (vijf Nederlandstalig, drie Engelstalig) en een oudere Nederlandstalige vraag uit 2024. We noemen ze niet en linken er niet naar, omdat er herleidbare gegevens van de vraagstellers in staan. De stappen zijn getoetst aan de documentatie hieronder. Het artikel is geschreven en gecontroleerd met AI-hulp door VORMVOLT.