Kan ik wp-cron uitschakelen op shared hosting?

Alleen als je hostingpakket een cronjob-panel biedt (cPanel, DirectAdmin, Plesk). Zonder dat blijft wp-cron de enige manier om scheduled events te draaien. Vraag je hoster of check je hostingpaneel voor "cron jobs" of "geplande taken".

Wat gebeurt er met geplande posts als ik wp-cron uitschakel?

Niets bijzonders, mits de system-cron correct staat en op tijd draait. Een geplande post publiceert bij de eerstvolgende cron-run na het gekozen tijdstip. Zonder vervanging blijven publicaties liggen tot de eerstvolgende bezoeker de site opent.

Hoe vaak moet de system-cron lopen?

Elke 15 minuten is een veilige default voor gemiddelde sites. Kleine brochure-sites kunnen elk uur. WooCommerce, LMS en membership-platforms lopen soepeler op elke 5 minuten omdat Action Scheduler-taken vaak nog kleine intervallen hebben.

Is wp-cron.php uitschakelen hetzelfde als de file verwijderen?

Nee. Nooit verwijderen. Je zet alleen de automatische trigger uit (via DISABLE_WP_CRON) of je vervangt de trigger door een system-cron. Het bestand wp-cron.php blijft nodig om cron-events uit te voeren.

Werkt dit ook voor WooCommerce Action Scheduler?

Ja. Action Scheduler haakt in op WP-Cron. Als je system-cron staat en die roept wp-cron correct aan, draaien Action Scheduler-taken mee. Check WooCommerce → Status → Scheduled Actions om te zien of er niets vastloopt.

wp-cron uitschakelen: 3 directe redenen (2026)

wp-cron uitschakelen is één van de eerste optimalisaties op high-traffic WordPress-sites, en één van de eerste die verkeerd wordt uitgevoerd. Deze deep-dive legt uit waarom pseudocron de TTFB drukt, hoe je hem correct vervangt door een systeem-cronjob elke 15 minuten en waar het misgaat als je de rollback niet klaar hebt.

De verwarring komt vaak door de naam. wp-cron is geen echte cron. Het is een pseudo-cronsysteem dat meelift op bezoekersverkeer. Op een site met tienduizend bezoekers per dag is dat overhead. Op een site met tien bezoekers per dag is dat een risico op gemiste taken. Wat “beter” is, hangt volledig van je traffic-patroon af.

Crontab-config met system-cron elke 15 minuten

Wat wp-cron eigenlijk is (en waarom het geen echte cron is)

Een klassieke Unix-cron is een daemon die op vaste tijden taken start, onafhankelijk van bezoekers. wp-cron is anders. Bij elke pageload checkt WordPress of er geplande taken openstaan. Zo ja, dan spawnt hij een tweede HTTP-request naar /wp-cron.php die die taken afwerkt.

Concrete gevolgen:

Geen bezoekers = geen taken. Op een lage-traffic-site kunnen geplande posts te laat gepubliceerd worden. Automatische back-ups slaan over.
Veel bezoekers = veel checks. Op een piek-moment kunnen er tientallen simultane spawn-pogingen zijn. De eerste doet het werk, de rest zit klaar en vertraagt.
Elke spawn is een tweede HTTP-request. Dat tikt aan in TTFB voor de request die de spawn triggert.

Voor de exacte werking en API-hooks is de WordPress-documentatie over WP-Cron de bron.

Waarom wp-cron uitschakelen zin heeft

Drie concrete redenen om wp-cron uitschakelen te overwegen:

Reden 1: TTFB-piek per visitor. Elke pageload die een cron-spawn triggert, betaalt de rekening voor die extra HTTP-request. Op cache-hits merk je het niet (die gaan niet door PHP), maar op cache-misses (inloggers, checkout, admin) wel. Op sites boven ongeveer 10.000 pageviews per maand zie ik dit consistent terug in de logs.

Reden 2: dubbele spawns bij pieken. Als twee visitors binnen milliseconden een spawn triggeren, kunnen beide een cron-run starten. Één doet het werk, de ander loopt tegen lock-timeouts aan of doet werk dubbel. Op WooCommerce-checkouts is dat concreet vervelend.

Reden 3: missed jobs bij lage traffic. Draai je een landingssite met 100 bezoekers per week? Dan draait wp-cron ook 100 keer per week. Geplande posts of transient cleanup blijven liggen. Een echte system-cron heeft dit probleem niet.

De impact hangt af van je situatie. Voor extra achtergrond over waar TTFB nog meer aan raakt, zie snelheid-optimalisatie voor WordPress.

Wanneer je wp-cron beter aan laat staan

Niet elke site profiteert. Drie situaties waar ik het bewust aan laat:

Zeer kleine sites met stabiele lage traffic en geen kritische scheduled taken. Als je één update per week doet en verder niets: laat het staan.
Shared hosting zonder cronjob-panel. Sommige budget-pakketten hebben geen cron-scheduler. Dan is wp-cron je enige optie.
Sites waar je geen shell-toegang hebt en de hoster geen alternatief biedt. Zonder een manier om een system-cron te scheduelen heeft uitschakelen geen zin.

Voor twijfelgevallen kijk ik eerst naar wp cron event list om te zien welke taken er zijn en hoe vaak ze moeten lopen. Als er alleen standaard-taken staan (wp_scheduled_delete, wp_version_check, wp_update_plugins), is de urgentie laag.

Stap voor stap: uitschakelen via wp-config.php

Één regel in wp-config.php:

define('DISABLE_WP_CRON', true);

Plaats hem direct boven /* That's all, stop editing! Happy blogging. */. Daar staat WordPress niet meer overheen bij updates. Bewaar het bestand.

Belangrijke waarschuwing: op dit moment draaien er geen cron-taken meer, tenzij je een system-cron hebt ingericht. Als je die eerste minuten geen system-cron hebt: geplande posts publiceren niet, back-ups slaan over, updates worden niet meer gecheckt. Doe deze stap dus altijd samen met de volgende.

DISABLE_WP_CRON constante in wp-config.php

Een echte system-cron opzetten

Er zijn twee routes: via curl (eenvoudiger, universeel) of via WP-CLI (schoner, sneller).

Optie A: curl in crontab. Voor hosting met crontab-toegang (VPS, dedicated, sommige managed):

*/15 * * * * curl -s https://voorbeeld.nl/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Dit triggert wp-cron elke 15 minuten via een externe HTTP-request. Werkt overal, mits wp-cron.php publiek bereikbaar blijft.

Optie B: WP-CLI in crontab (voorkeur). Voor VPS of managed hosting met WP-CLI beschikbaar:

*/15 * * * * cd /var/www/voorbeeld.nl && /usr/local/bin/wp cron event run --due-now --quiet

WP-CLI draait de cron-events direct via de CLI, zonder een extra HTTP-request. Sneller, minder overhead, geen risico dat een externe scanner je wp-cron.php-endpoint constant aanroept.

Intervalkeuze. De defaults die ik hanteer:

Kleine sites (blog, brochure): elke 60 minuten.
Gemiddelde sites: elke 15 minuten.
WooCommerce, LMS, membership-sites: elke 5 minuten.

Onder de 5 minuten is meestal onnodig en kost onnodig CPU. Boven het uur mis je transient-refreshes.

Via hostingpaneel. Op shared hosting met een cron-scheduler (cPanel, DirectAdmin, Plesk) plak je hetzelfde curl-commando in het cron-formulier. De hoster draait het dan zelf.

Testen en debuggen

Na de setup wil je weten of alles draait. WP-CLI heeft de handigste tools.

Overzicht van geplande events:

wp cron event list --format=table

Toont alle geplande events, wanneer ze het volgende moeten draaien, hoe vaak ze herhalen. Draai dit een dag na de switch en check dat er geen events zijn met next_run in het verleden.

Handmatig een event draaien:

wp cron event run --due-now

Wat een cron zou doen, maar dan direct. Handig om te zien of er errors zijn.

Stuck event verwijderen:

wp cron event delete <hook_name>

Alleen als een event blijft hangen en telkens opnieuw geplaatst wordt.

Voor WooCommerce: ga naar WooCommerce → Status → Scheduled Actions. Daar zie je Action Scheduler-taken, die apart van wp-cron werken maar wel via wp-cron worden getriggerd. Als je systeem-cron staat, draaien deze mee.

WP-CLI cron event list output in terminal

Terugdraaien: DISABLE_WP_CRON op false zetten

Een rollback duurt tien seconden. Verander de regel in wp-config.php:

define('DISABLE_WP_CRON', false);

Of verwijder de regel. Verwijder ook de crontab-entry (of comment hem uit met een #) om te voorkomen dat je én pseudocron én system-cron tegelijk draait. Beide is niet stuk, wel dubbel werk.

Ik bewaar altijd een korte notitie bij de klant: welke crontab-entry er staat, waarom, en hoe je hem uit zet. In mijn ervaring is dat het eerste wat een volgende beheerder mist en waar hij een uur naar zoekt.

Multi-stack notitie

Hetzelfde patroon zie je terug in andere frameworks. Laravel gebruikt php artisan schedule:run in een crontab-entry (elke minuut), en de scheduler zelf beslist welke taken draaien. Drupal heeft drush cron als tegenhanger. Joomla heeft sinds versie 4 een eigen Scheduled Tasks-component die met een crontab werkt.

De valkuil is overal dezelfde: een applicatie die op bezoekersverkeer leunt voor scheduling, mist taken bij lage traffic en betaalt overhead bij hoge traffic. De oplossing is overal dezelfde: OS-level cron plus applicatie-scheduler.

Wanneer laten opzetten door een webmaster

Voor een standaard-site met SSH-toegang en een simpele WooCommerce is dit één uur werk: uitschakelen, crontab-entry, test met wp-cron event list, korte overdracht. Dat past bij mij binnen het uurtarief van 95 euro voor het serverwerk.

Complexer wordt het bij:

WooCommerce met veel Action Scheduler-taken (subscriptions, bulk product updates).
LMS-platforms (LifterLMS, LearnDash) die eigen scheduled events hebben.
Multisite waar cron per site correct moet lopen.
Managed hosting waar de hoster eigen cron-oplossingen aanbiedt en integratie nodig is.

Voor die scenario’s zit ik op 105 of 175 euro per uur (technisch specialistisch, of spoed). Ik werk in de source-code en op de shell, geen dashboard-magie: crontab, WP-CLI, logs, en een rollback-plan dat op één papiertje past. Voor doorlopende technische begeleiding is WordPress-onderhoud met server-toegang meestal goedkoper dan losse uren per kwartaal.