Het beheerscherm meldde zeven beschikbare updates. U klikte op “Alles bijwerken”, zag een paar groene vinkjes en ging koffie halen. Terug bij het scherm: een witte pagina. Of een foutmelding in het Engels. Of een site die er wél is, maar waar de helft van de opmaak is verdwenen. En het is dinsdagochtend, klanten bellen, en u weet niet eens meer precies welke update het was.

Een website die kapot is na een update is de meest voorkomende reden waarom ondernemers ons bellen. Het ziet er ernstig uit, maar het is vrijwel altijd omkeerbaar. De kunst is om in de juiste volgorde te werken en niets te doen wat het erger maakt. Dit stappenplan is daarvoor.

Stap 0: even niets doen

De eerste neiging is om van alles te proberen: nog meer updates draaien, plugins verwijderen, de hosting bellen. Neem eerst een minuut. Noteer wat u ziet (een foto met uw telefoon is prima), welke updates u heeft gedraaid en hoe laat. Kijk of de voorkant van de site het wél doet en alleen het beheer niet, of andersom. Die informatie bepaalt welke route u neemt en is goud waard als u later hulp inschakelt.

Controleer daarna twee simpele dingen. Leeg de cache van uw browser en van een eventuele cacheplugin; soms is de site allang weer in orde en kijkt u naar een oude kopie. En probeer de site in een privévenster of vanaf uw telefoon. Werkt hij daar wel, dan is het geen kapotte site maar een cachekwestie.

Stap 1: herken het symptoom

Wat u ziet, vertelt welke update de schuldige is.

  • Wit scherm of “There has been a critical error”: een PHP-fout in een plugin of thema. Meestal de laatste update in het rijtje. WordPress stuurt in dit geval vaak een e-mail naar het beheerdersadres met daarin de naam van de veroorzaker en een herstelkoppeling; kijk in uw inbox.
  • Lay-out verdwenen of verschoven, maar de site laadt: een thema-update die aanpassingen heeft overschreven, of een pagebuilder die niet meer bij het thema past. Lees verder in ons artikel over een verschoven lay-out.
  • Error 500 op alles: vaak een .htaccess-bestand dat door een plugin is herschreven, of een PHP-geheugenfout.
  • Site zit vast in onderhoudsmodus (“Briefly unavailable for scheduled maintenance”): de update is halverwege afgebroken en heeft een .maintenance-bestand achtergelaten. Verwijder dat bestand via FTP uit de hoofdmap; vaak is dat alles. Zo hoort een onderhoudsmelding er wel uit te zien als u hem zelf inschakelt.
  • Eén functie werkt niet (formulier, slider, checkout): een pluginconflict. Dan is de site niet kapot maar heeft u een zoekopdracht.

Stap 2: de laatste update terugdraaien

Komt u nog in het beheer, dan zet u de verdachte plugin uit onder Plugins. Lukt dat niet, dan gaat u via FTP of de bestandsbeheerder van uw hosting naar wp-content/plugins/ en hernoemt u de map van de verdachte plugin, bijvoorbeeld naar naam-plugin-uit. WordPress schakelt de plugin dan automatisch uit. Laad de site. Werkt hij weer, dan heeft u de schuldige.

Weet u niet welke plugin het is, hernoem dan de hele map plugins naar plugins-uit. Werkt de site nu (zonder functies, maar wel bereikbaar), dan zit het in een plugin. Zet de mapnaam terug en hernoem daarna de pluginmappen één voor één, te beginnen bij de meest recent bijgewerkte. Bij een themaprobleem hernoemt u de map van het actieve thema onder wp-content/themes/; WordPress valt dan terug op een standaardthema.

Wilt u de oude versie van een plugin terug in plaats van hem uit te zetten, dan kan dat met de plugin WP Rollback of door de vorige versie te downloaden van wordpress.org (onder Geavanceerde weergave bij de plugin) en handmatig over de nieuwe te zetten. Doe dat alleen als tijdelijke maatregel; oude versies bevatten vaak beveiligingslekken.

Stap 3: de back-up terugzetten

Als de eerste twee stappen niets opleveren, of als er meerdere dingen tegelijk stuk zijn, is de back-up van vóór de update de snelste weg terug. Dat is precies waarvoor hij is gemaakt. Een paar aandachtspunten:

  1. Kies de back-up van vlak vóór de update, niet die van vorige week. Anders verliest u tussentijdse wijzigingen.
  2. Bij een webshop of een site met inzendingen: zet bij voorkeur alleen de bestanden terug en niet de database, anders verdwijnen bestellingen en berichten van na de back-up. Overleg bij twijfel.
  3. Werk de plugins na het terugzetten niet meteen opnieuw bij. Zoek eerst uit welke update de fout veroorzaakte.
  4. Controleer na het terugzetten de voorkant, het beheer, het formulier en, bij een webshop, een testbestelling.

Heeft u geen back-up van vóór de update, kijk dan bij uw hostingpartij. De meeste Nederlandse hosters bewaren dagelijkse kopieën, soms zonder dat u daar iets voor heeft ingesteld.

Stap 4: uitzoeken waarom het misging

Zodra de site weer draait, komt de vraag die vaak wordt overgeslagen: waarom ging het mis? Meestal is het antwoord een van deze:

  • De plugin of het thema was niet meer geschikt voor de PHP-versie op de server, of juist voor de nieuwe WordPress-versie.
  • Twee plugins zijn na hun update niet meer compatibel met elkaar.
  • Het thema is aangepast zonder child-thema, en de update heeft die aanpassingen gewist.
  • Een verlaten plugin die al jaren geen update meer kreeg, is gestruikeld over een wijziging in WordPress.
  • De server had tijdens de update te weinig geheugen of de verbinding brak af.

Deze analyse is precies het werk waarvoor u een specialist inschakelt als u het zelf niet ziet. Een WordPress-bugfixer leest het foutenlog, herhaalt de update op een testkopie en zegt u wat er structureel moet gebeuren. Dat kost minder dan de volgende mislukte update.

Voorkomen: updaten zonder hartkloppingen

Een timmerbedrijf in Tilburg belde ons na een “Alles bijwerken” op vrijdagmiddag; de site was het hele weekend wit. De oorzaak was een sliderplugin die sinds 2019 niet was bijgewerkt en de nieuwe PHP-versie niet aankon. Het herstel duurde een half uur. De les die de eigenaar trok, is de les voor iedereen:

  • Maak vóór elke update een back-up, of controleer dat er automatisch een is gemaakt.
  • Werk niet alles tegelijk bij. Eerst plugins één voor één, dan het thema, dan WordPress zelf. Test tussendoor.
  • Update niet op vrijdagmiddag of vlak voor een campagne.
  • Lees de wijzigingslijst bij grote versiesprongen, zeker bij WooCommerce en pagebuilders.
  • Test grotere updates op een staging-kopie.
  • Verwijder plugins die al meer dan een jaar geen update hebben gehad.

Conclusie

Een kapotte site na een update herstelt u in deze volgorde: cache legen, symptoom herkennen, laatste update terugdraaien, anders de back-up van vóór de update terugzetten. Daarna zoekt u de oorzaak, zodat u niet volgende maand hetzelfde doormaakt. En als er één ding is dat u uit dit artikel meeneemt: klik nooit meer op “Alles bijwerken” zonder dat er een back-up van vijf minuten geleden klaarstaat.