WordPress site kapot na automatische update: fix in 60 min

WordPress site kapot na automatische update is een van de vervelendste meldingen die je ’s ochtends op je telefoon kunt zien. Vorige maand belde een ondernemer uit Hulst me om 07:12: “Ik open de webshop, en er staat alleen ‘briefly unavailable for scheduled maintenance’. Ik heb vannacht niks gedaan.”

De boosdoener bleek een nachtelijke WooCommerce-update. Die brak halverwege af omdat het PHP-memory op de shared hosting vollopt.

In dit stuk lees je hoe ik zulke incidenten systematisch afhandel. Je krijgt de commando’s die je zelf kunt draaien, plus de stappen per hostingpaneel voor cPanel, Plesk, DirectAdmin, Hostinger en managed VPS. Reken op 30 tot 90 minuten van diagnose tot volledige recovery, mits je een recente backup hebt en bij het hostingpaneel kunt.

WordPress site kapot na automatische update: wat er onder de motorkap gebeurt

Automatische updates in WordPress lopen via wp-cron.php of via de nightly-cron van je hostingpaneel. De updater zet eerst een .maintenance-bestand in je siteroot, downloadt de nieuwe versie, ontpakt die naar /wp-content/upgrade/, verplaatst de bestanden, draait de database-migratie, en verwijdert daarna het .maintenance-bestand. Als dat proces halverwege sneuvelt, blijft je site vaak achter in een gebroken staat. Er zijn drie klassen problemen die ik het vaakst tegenkom.

1. Fatal PHP-error na de update. De nieuwe plugin- of core-versie roept een functie aan die verdwenen is (bijvoorbeeld create_function() op PHP 8.3) of doet iets wat botst met een andere plugin. Op de frontend krijg je een White Screen of Death (WSOD) of “There has been a critical error on this website”. WordPress schrijft de error naar /wp-content/debug.log als je debug hebt aanstaan, en probeert een recovery mode-mail te versturen naar het admin-adres.

2. Onderbroken update = stuck maintenance mode. Als de PHP-worker een timeout hit tijdens het overschrijven van bestanden (bij grote plugin-updates en shared hosting met korte max_execution_time), wordt het .maintenance-bestand nooit verwijderd. Iedereen die de site opent, ziet Briefly unavailable for scheduled maintenance tot je het bestand handmatig weggooit.

3. Server-side 500-error. Vaak een .htaccess die tijdens de update herschreven is, memory limit overschreden, of een corrupte wp-content/upgrade/-map. De browser toont “500 Internal Server Error” of “HTTP ERROR 500” en Apache/Nginx logt de exacte oorzaak in /var/log/apache2/error.log of het hosting-specifieke logbestand.

De 2026-standaard is PHP 8.3 of hoger en MySQL 8.0+ met 256 MB memory. Sites die nog op PHP 7.4 hangen ontwikkelen letterlijk elk kwartaal nieuwe update-issues, want plugin-developers vallen die versie steeds vaker af.

Stap 1: Symptomen triage voordat je iets aanraakt

Voor je een backup restore-t of plugins deactiveert: kijk twee minuten wat je precies ziet. De vijf meest voorkomende symptomen vragen elk om een andere eerste stap.

Symptoom A: Witte pagina, geen tekst (WSOD). PHP-fatal error, output-buffer leeggegooid. Ga naar stap 2 (debug aanzetten) om de exacte error te lezen.

Symptoom B: “There has been a critical error on this website”. WordPress 5.2+ heeft een fatal error afgevangen. Check je admin-mailbox voor een recovery mode-mail. Ga naar stap 3.

Symptoom C: “Briefly unavailable for scheduled maintenance”. Stuck .maintenance-file. Ga direct naar stap 5. Dit is meestal een fix van 30 seconden.

Symptoom D: HTTP 500-error op zowel frontend als /wp-admin/. Serverfout, geen PHP-error zichtbaar. Check je .htaccess (soms overschreven) en de server-error-log via je hostingpaneel.

Symptoom E: Frontend werkt maar /wp-admin/ geeft foutmelding. Vaak een plugin die alleen in admin-context laadt (bijvoorbeeld een backup-plugin of een security-plugin). De frontend cache blijft nog werken. Ga naar stap 4 (plugins-off).

Belangrijk: maak eerst een snapshot van de huidige gebroken staat voordat je begint met fixen. Ik download altijd een ZIP van /wp-content/plugins/ en een dump van wp_options voor ik wat aanraak. Als een fix het erger maakt, kun je terug.

Stap 2: Recovery mode van WordPress zelf gebruiken

Sinds WordPress 5.2 stuurt de core bij een fatal error automatisch een mail naar het admin-emailadres. Die mail bevat een link zoals https://jouwsite.nl/wp-login.php?action=enter_recovery_mode&rm_token=...&rm_key=.... Als je op de link klikt, log je in in een speciale admin-sessie waarin de foutende plugin of theme is uitgeschakeld, voor jou, niet voor bezoekers.

De recovery mode-documentatie legt uit wat er onder de motorkap gebeurt. WordPress noteert welke plugin de fatal veroorzaakte in de recovery_keys-optie in wp_options. Die plugin wordt alleen voor jouw sessie gedeactiveerd. De rest van de admin blijft bruikbaar om te fixen.

De mail komt echter niet altijd. Redenen.

• Site heeft geen werkende mail-config (geen SMTP, sends via PHP mail() die op veel shared hostings gefilterd wordt).
• Admin-emailadres is verouderd of gaat naar een spamfilter.
• De fatal error zit in code die vóór de mail-functionaliteit laadt (mu-plugins, wp-config.php).
• De site is domweg te kapot om überhaupt de mail-code uit te voeren.

Check als eerste je mailbox inclusief spam-folder voor onderwerp “Your Site is Experiencing a Technical Issue”. Als de mail er niet is en niet komt binnen 5 minuten, ga naar stap 3.

Stap 3: Debug aanzetten via wp-config.php

Zonder debug tast je in het duister. Open wp-config.php via FTP, SSH of de File Manager van je hostingpaneel. Zoek de regel /* That's all, stop editing! */ en voeg direct daarboven toe.

// Zet WP_DEBUG aan, maar toon errors NIET op de frontend
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // Log naar wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // Toon niet aan bezoekers
@ini_set('display_errors', 0);     // PHP-level unterdrücken

Deze config is de officiële Kinsta-aanbeveling voor productie-debug: je krijgt de errors in een logbestand zonder dat je bezoekers ze zien.

Bezoek nu je frontend of /wp-admin/. WordPress schrijft alles naar /wp-content/debug.log. Download dat bestand en zoek naar de laatste “Fatal error” of “Uncaught” regels. Voorbeeld van wat je ziet bij een typische plugin-update-crash.

[03-Aug-2026 06:14:22 UTC] PHP Fatal error:  Uncaught Error: 
Call to undefined function create_function() in 
/home/site/public_html/wp-content/plugins/some-security-plugin/
inc/scanner.php:47

Die regel wijst één plugin aan (some-security-plugin) én de exacte functie (create_function(), sinds PHP 8.0 verwijderd). Dat is 90% van je diagnose in één regel.

Belangrijk: WP_DEBUG aan laten staan op een live site is een security-risico als WP_DEBUG_DISPLAY per ongeluk true staat. Zet debug uit zodra je klaar bent (WP_DEBUG op false) of verwijder de regels weer.

Stap 4: Plugins-off via FTP of hostingpaneel

Als debug een specifieke plugin aanwijst, of als je geen recovery mail hebt gekregen, deactiveer je plugins buiten wp-admin om. De klassieke manier: hernoem de plugins-map naar plugins-off. WordPress vindt de map niet meer en deactiveert alle plugins automatisch. Zonder data-verlies, want plugin-configuratie zit in de database.

Via DirectAdmin (Antagonist, Vimexx, mijn.host)

1. Log in in cPanel → File Manager → public_html/wp-content/.
2. Rechtermuisknop op de map plugins → Rename → plugins-off.
3. Refresh je site. Als ‘ie werkt: probleem is een plugin.
4. Hernoem terug naar plugins en activeer plugins één voor één in wp-admin totdat de fout terugkomt.

Bij Antagonist worden er standaard elke 2 uur snapshots gemaakt, dus als plugin-toggle niks oplevert is een restore relatief goedkoop.

Via Plesk (Argeweb, en op VPS bij TransIP en Combell)

1. Domains → jouwsite.nl → Files.
2. Navigeer naar httpdocs/wp-content/.
3. Selecteer plugins → rechtsklik → Rename → plugins-off.

Via cPanel (o.a. Neostrada)

1. File Manager → domains/jouwsite.nl/public_html/wp-content/.
2. Klik plugins aan → Rename in de bovenbalk.

Via Hostinger hPanel

1. Files → File Manager.
2. domains/jouwsite.nl/public_html/wp-content/.
3. Rechtsklik plugins → Rename → plugins-off.

Via RunCloud, ServerAvatar, GridPane (managed VPS)

SSH-connect naar je server, of gebruik de web-shell.

# Ga naar wp-content
cd /home/username/webapps/jouwsite/wp-content

# Hernoem plugins-map
mv plugins plugins-off

# Test frontend en admin. Als werkend, hernoem terug:
mv plugins-off plugins

Via WP-CLI (elke SSH-omgeving)

Als je één specifieke plugin verdenkt (uit debug.log), skip je de rename-truc en deactiveer je gericht.

# Deactiveer alle plugins in één klap
wp plugin deactivate --all

# Of alleen de verdachte plugin
wp plugin deactivate some-security-plugin

# Test site, herstel gewenste plugins
wp plugin activate yoast-seo woocommerce wpforms

# Verwijder de kapotte plugin volledig
wp plugin delete some-security-plugin

WP-CLI werkt zelfs als wp-admin volledig onbereikbaar is, mits je database nog draait.

Stap 5: Stuck maintenance mode oplossen

Als je site “Briefly unavailable for scheduled maintenance. Check back in a minute” toont, is het antwoord bijna altijd hetzelfde: een achtergebleven .maintenance-file in de siteroot. WordPress maakt dat bestand aan zodra een update start en verwijdert het als de update klaar is. Bij een crash blijft ‘ie liggen.

De fix:

Via FTP of File Manager:

1. Ga naar de root van je WordPress (waar wp-config.php staat).
2. Zet “toon verborgen bestanden” aan (bestand begint met een punt, dus verborgen op Unix).
3. Delete het bestand .maintenance.
4. Refresh je site. Direct weer online.

Via SSH / WP-CLI:

# Simpel via shell
rm /home/username/public_html/.maintenance

# Of via WP-CLI (WordPress 5.5+)
wp maintenance-mode deactivate

Als het .maintenance-bestand steeds terugkomt, is de update-cron zelf kapot. Check /wp-content/upgrade/: daar staan de gedeeltelijk uitgepakte plugin-bestanden. Leeg die map.

rm -rf /home/username/public_html/wp-content/upgrade/*

Daarna kun je in wp-admin de plugin opnieuw handmatig updaten met een schone lei.

Stap 6: Backup restore als niks anders werkt

Als de plugin-toggle-test niks oplevert of je te weinig tijd hebt om debug uit te pluizen, is een restore van de laatste werkende backup vaak sneller. De workflow verschilt per tool.

UpdraftPlus (populair, gratis + premium)

De UpdraftPlus 1.26.5+ (gratis) en 2.26.5+ (Premium) uit 2026 zijn de actuele versies. Draai je op een lagere versie: eerst updaten (CVE-2026-10795, gepatcht in 1.26.5 / 2.26.5 op 3 juni 2026). Restore-flow.

1. WP-admin → Instellingen → UpdraftPlus Backup/Restore → tab Existing Backups.
2. Kies backup van vóór de crash → klik Restore.
3. Vink aan wat je terug wilt: Plugins, Themes, Uploads, Others, Database.
4. Bij een auto-update-crash volstaat vaak alleen Plugins + Database restoren, uploads laten staan.
5. Bevestig → wacht 2–10 minuten afhankelijk van sitegrootte.

Als wp-admin onbereikbaar is: UpdraftPlus heeft een UpdraftClone/Migrator standalone-tool waarmee je backups via FTP kunt herstellen zonder toegang tot admin.

Jetpack VaultPress Backup

VaultPress kost $9.95/maand billed yearly na de introductie-korting. Voordeel: real-time backups op activity-basis, dus je kunt terug naar een specifiek moment (bijvoorbeeld “5 minuten voor de auto-update”). Restore verloopt via je Jetpack-account op cloud.jetpack.com, kies de site → Activity Log → klik “Restore to this point”.

JetBackup WordPress plugin

JetBackup for WordPress Pro 5 kost $49.95/jaar voor 5 sites met 50 GB storage. De restore zit in het WP-admin dashboard onder JetBackup → Backups → Restore. Werkt goed voor bureaus met meerdere sites.

Hosting-native snapshots

• Antagonist: elke 2 uur een snapshot bij standaardplan, restore via klantpaneel → Website → Backups → Restore.
• TransIP: dagelijkse snapshots 14 dagen terug, TransIP-controlepaneel → Webhosting → Backups.
• Combell: dagelijkse backups, herstel via My Combell → Hosting → Backups.
• Hostinger: dagelijkse backups op Business-plans en hoger, hPanel → Files → Backups.
• Vimexx: tot 60 dagen backup-historie, langste in de Nederlandse markt.

Bij hosting-native restore: check of het over de hele hosting-account gaat of alleen deze site. Bij shared hosting met meerdere WordPress-installaties kan een full-account restore andere sites overschrijven.

Drie concrete scenario’s uit mijn praktijk

Scenario A: Site plat na WP core 6.7 auto-update

Symptoom: Frontend toont “There has been a critical error on this website”. Wp-admin geeft dezelfde foutmelding.

Debug-log: Fatal error: Uncaught TypeError: WP_HTML_Tag_Processor::next_token(): Return value must be of type bool, string returned in /themes/custom-theme/functions.php:127.

Oorzaak: WordPress 6.7 introduceerde wijzigingen in de HTML_Tag_Processor-klasse die botsten met theme-code die niet was bijgewerkt. Custom theme’s die HTML-parsing deden zoals de core, kregen een type-mismatch.

Fix: Deactiveer het theme via FTP (hernoem wp-content/themes/custom-theme naar custom-theme-off, WordPress valt automatisch terug op Twenty Twenty-Five). Neem contact op met de theme-developer voor een compatible versie. Interim: fork het theme, corrigeer de return-type in functions.php, en push terug via FTP.

Scenario B: 500 error na auto-update van security-plugin

Symptoom: Frontend toont HTTP 500. Debug-log leeg, want fatal gebeurt vóór debug-init.

Server-error-log: PHP Fatal error: Uncaught Error: Class 'IPS_Country_DB' not found in /wp-content/plugins/wordfence/lib/wfUtils.php:892.

Oorzaak: Update van Wordfence 8.x brak op een missing helper-class die in de update-package niet meegekomen was (partial download door PHP-timeout).

Fix: Deactiveer via SSH.

wp plugin deactivate wordfence

Download een verse ZIP van Wordfence.com (Premium-plan is $149/jaar in 2026), upload via FTP naar /wp-content/plugins/wordfence/ (overschrijven), en activeer opnieuw.

wp plugin activate wordfence

De partial-download-bug is te voorkomen door PHP max_execution_time naar 300 seconden te zetten en memory_limit naar 512M. In wp-config.php.

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

Scenario C: Stuck in “briefly unavailable” na WooCommerce-update

Symptoom: Site toont “Briefly unavailable for scheduled maintenance. Check back in a minute” al vier uur.

Debug-log: WooCommerce-migratie halverwege afgebroken door MySQL-timeout op grote wp_woocommerce_order_items-tabel (150.000 orders).

Fix stap 1: Delete .maintenance uit siteroot om de site zichtbaar te maken.

Fix stap 2: WooCommerce moet z’n database-migratie afmaken. Ga naar wp-admin → WooCommerce → Status → Tools en klik “Update WooCommerce Database”. Of via WP-CLI.

wp wc update

Fix stap 3: Draai HPOS-migratie opnieuw als je op WooCommerce 9.x zit met High-Performance Order Storage aan.

wp wc cot sync
wp wc cot verify_cot_data

Preventie: dit voorkomt herhalingsproblemen

Één keer een gebroken site na een auto-update is pech. Twee keer is een workflow-probleem. Dit is de setup die ik bij klanten aanraad.

1. Staging-omgeving voor major updates

De meeste Nederlandse hostings bieden 1-klik staging: Antagonist, TransIP (developer-plan), Combell, SiteGround. Alle plugin- en core-updates test je eerst daar. Klik pas "Deploy to production" na visuele check van homepage, checkout, contactformulier en admin-dashboard. Vimexx heeft officieel geen staging; daar gebruik ik lokaal Local by Flywheel of een tijdelijke staging.jouwsite.nl subdomain.

2. Selectieve auto-updates via WP_AUTO_UPDATE_CORE

De WP_AUTO_UPDATE_CORE-constante accepteert deze waarden: true, false, 'minor', 'beta', 'rc', 'development' en 'branch-development'.

// In wp-config.php, bovenaan bij de andere define()'s
define('WP_AUTO_UPDATE_CORE', 'minor');   // Alleen security + minor (aanbevolen)
// define('WP_AUTO_UPDATE_CORE', true);   // Alles inclusief major (riskant)
// define('WP_AUTO_UPDATE_CORE', false);  // Niks automatisch (veilig, maar handmatig werk)
// define('WP_AUTO_UPDATE_CORE', 'beta'); // Beta/RC (alleen voor developers)

De default op nieuwe WordPress-installs is minor, dus alleen security-fixes en punt-releases zoals 6.7.1 gaan automatisch. Major releases (6.7 → 6.8) moet je handmatig triggeren.

3. Plugin auto-updates gericht uitzetten

Voor plugins die je frontend visueel raken (page-builders, sliders, popup-plugins, custom-post-type-plugins) zet ik auto-update UIT. Voor security-plugins en backup-plugins zet ik 'm AAN. In wp-admin → Plugins → klik "Enable auto-updates" of "Disable auto-updates" per plugin.

Voor bulk-control: filter in functions.php van een mu-plugin (nooit in wp-config.php, want filters laden pas na wp-config).

// /wp-content/mu-plugins/auto-update-control.php
add_filter('auto_update_plugin', function($update, $item) {
    // Lijst van plugins die NIET automatisch mogen updaten
    $no_auto_update = [
        'elementor/elementor.php',
        'js_composer/js_composer.php',
        'slider-revolution/revslider.php',
    ];
    if (in_array($item->plugin, $no_auto_update, true)) {
        return false;
    }
    return $update;
}, 10, 2);

4. Backup-cadans: nightly + pre-update

Mijn standaardconfig voor UpdraftPlus.

• Elke nacht database naar externe storage (Dropbox/Google Drive/S3).
• Wekelijks volledige files (plugins + themes + uploads).
• Pre-update trigger via een backup-plugin die automatisch een snapshot maakt vlak voor een core- of plugin-update.

Met VaultPress krijg je real-time incrementele backups, wat handiger is voor webshops met tientallen orders per uur. Voor gewone bedrijfssites is nightly + pre-update ruim voldoende.

5. Uptime-monitoring met keyword-check

Simpel: UptimeRobot gratis monitort elke 5 minuten of je site 200 OK teruggeeft. Handiger: keyword-monitoring die alarm slaat als een specifieke tekst niet meer op de pagina staat ("Bestel nu" op de homepage bijvoorbeeld). Bij een WSOD zie je die tekst niet meer, dus krijg je binnen minuten een SMS in plaats van pas als een klant belt.

Wanneer een echte webmaster inschakelen

Los dit zelf op als je binnen 60 minuten een oorzaak vindt. Daarna wordt doorgaan duurder dan uitbesteden. Bel in deze gevallen iemand in.

• Meerdere fixes proberen geen resultaat oplevert en de site al 2+ uur plat ligt voor bezoekers.
• Je geen werkende backup hebt (of ontdekt dat de laatste backup ook al maanden oud is).
• De site iDEAL of Mollie draait en checkout affected is, waardoor omzetimpact per uur oploopt.
• Debug-log toont fatale errors in core-bestanden (/wp-includes/), wat vaak wijst op een dieper corruptieprobleem.
• Recovery mode-mail komt niet én je hebt geen SSH- of FTP-toegang.

Voor mijn klanten kost dit type incident meestal 1 tot 2 uur werk (€70 tot €140), inclusief root-cause-documentatie en een preventie-checklist voor de volgende keer. Als je hosting het toelaat, zet ik meteen staging op, configureer ik selectieve auto-updates en installeer ik UpdraftPlus met pre-update-hook.

Vast door dit type incident?

Als je in de bovenstaande stappen vastloopt of geen tijd hebt om onder tijdsdruk te troubleshooten met omzetimpact, stuur me een mail via /contact/. Ik kijk binnen 4 uur mee tijdens kantoortijden (spoedhulp buiten kantoor in overleg), en factureer alleen de daadwerkelijk bestede tijd zonder minimumafname. Meer over mijn aanpak op /diensten/, en de bredere achtergrond in /wordpress-popup-slider-werkt-niet-na-update/.