Wat is WP-Cron?

WordPress heeft zijn eigen ingebouwde taakplanner genaamd WP-Cron. Deze regelt alles wat volgens schema moet gebeuren: berichten publiceren op een ingestelde tijd, controleren op updates, e-mailmeldingen versturen, database-overtollig opruimen, achtergrondtaken van plugins uitvoeren. Klinkt redelijk — totdat u beseft hoe het daadwerkelijk werkt. In tegenstelling tot een echt cronsysteem dat op een vaste timer draait, wordt WP-Cron alleen geactiveerd wanneer iemand uw site bezoekt. Geen bezoekers, geen cron. En die ontwerpkeuze leidt tot een hele reeks problemen.

Hoe WP-Cron wordt geactiveerd

Telkens wanneer een pagina op uw WordPress-site wordt geladen, controleert WordPress een lijst met geplande gebeurtenissen. Als er een achterloopt, wordt deze tijdens dat paginaladen afgevuurd. De bezoeker die de controle activeerde, ziet niets anders — de crontaken draaien (een soort van) op de achtergrond. Maar het is belangrijk te begrijpen: er is geen onafhankelijk proces dat doortikt. Het hele planningssysteem lift mee op binnenkomend HTTP-verkeer.

Dit was een pragmatische keuze. WordPress is ontworpen om te draaien op goedkope shared hosting, waar u geen systeemdiensten kunt installeren of toegang hebt tot crontab. De verkeer-gebaseerde aanpak zorgde ervoor dat geplande taken direct werkten, op elke host, zonder serverconfiguratie.

Waar dit misgaat

Het verkeer-afhankelijke ontwerp heeft duidelijke problemen die pijnlijker worden naarmate uw site groeit — of, paradoxaal genoeg, als deze niet genoeg groeit:

• Sites met weinig verkeer missen hun planning. Als uw site 10 bezoeken per dag krijgt, kunnen geplande berichten uren te laat worden gepubliceerd. Een bericht ingesteld voor 8:00 uur zal pas live gaan nadat iemand na 8:00 uur de site bezoekt — wat tot in de middag kan zijn als uw publiek in een andere tijdzone zit. WooCommerce-orderverwerking, back-upschema's en e-maildigests ondergaan hetzelfde lot.
• Sites met veel verkeer verspillen middelen. Op een drukke site wordt WP-Cron bij vrijwel elk paginaladen geactiveerd. WordPress controleert de gebeurtenislijst, evalueert tijdstempels en — meestal — vindt niets te doen. Dat is verspilde rekenkracht bij elk verzoek. Erger: meerdere gelijktijdige bezoekers kunnen dezelfde croncontrole tegelijkertijd activeren, wat leidt tot race conditions waarbij dezelfde taak twee keer draait.
• Langlopende taken vertragen het laden van pagina's. Wanneer WP-Cron afvuurt, worden de taken uitgevoerd als onderdeel van het paginaverzoek. WordPress probeert een apart achtergrondverzoek voor het feitelijke cronwerk te starten, maar bij sommige serverconfiguraties mislukt dit stilzwijgend en draaien de taken inline. Een back-upplugin die een database-dump van 500 MB genereert, kan het paginaladen van een bezoeker blokkeren als de loopback-verbinding niet goed werkt.
• Crondrift stapelt zich op. Omdat gebeurtenissen alleen draaien wanneer geactiveerd door verkeer, is de timing op zijn best benaderend. Een taak gepland voor elk uur kan draaien om 1:00, 2:17, 3:02, 4:45 — wanneer dan ook het volgende bezoek na de geplande tijd plaatsvindt.

Wat WP-Cron daadwerkelijk afhandelt

U zult misschien verbaasd zijn hoeveel afhangt van dit systeem:

• Geplande berichten en pagina's publiceren op de ingestelde datum en tijd
• Controleren op updates van WordPress core, plugins en thema's
• WooCommerce-achtergrondtaken verwerken (orderstatuswijzigingen, geplande uitverkopen, voorraadbeheer)
• Geautomatiseerde back-upplugins draaien (UpdraftPlus, BackWPup, BlogVault)
• Geplande e-mailcampagnes of digests versturen
• Verlopen transients, prullenbakberichten en revisiegeschiedenis opruimen
• Verwerking van wachtrijtaken van formulierplugins, lidmaatschapsplugins en LMS-plugins
• Let's Encrypt SSL-certificaten verlengen (op hosts die dit via WordPress regelen)

Als WP-Cron onbetrouwbaar is, worden al deze zaken onbetrouwbaar.

De oplossing: vervang WP-Cron door een echte systeemcron

De standaardaanbeveling voor elke site die planning serieus neemt, is om de verkeer-gebaseerde trigger uit te schakelen en te vervangen door een echte systeemcrontaak. Dit is een tweestappenproces:

Stap 1: Voeg deze regel toe aan uw wp-config.php om te voorkomen dat WordPress cron bij elk paginaladen activeert:

define('DISABLE_WP_CRON', true);

Stap 2: Stel een systeemcrontaak in om wp-cron.php aan te roepen op een vast interval. De meeste hostingcontrolepanelen (cPanel, Plesk) hebben een crontaakbeheerder, of u kunt crontab -e gebruiken op een server die u beheert:

# Roep WP-Cron elke 5 minuten aan via wget
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternatief met curl
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternatief met WP-CLI (aanbevolen voor lokale aanroepen, vermijdt HTTP-overhead)
*/5 * * * * cd /var/www/html && wp cron event run --due-now >/dev/null 2>&1

De WP-CLI-aanpak is de schoonste omdat er geen HTTP-verzoek bij betrokken is. Het draait de crongebeurtenissen rechtstreeks via PHP, wat problemen met loopbackverbindingen, HTTP-timeouts en authenticatie (bijv. HTTP basic auth op staging-sites) vermijdt.

Beheerde hosting en WP-Cron

Veel beheerde WordPress-hosts (Kinsta, WP Engine, Cloudways, SiteGround) schakelen het standaard WP-Cron-gedrag uit en vervangen het automatisch door een serverside-cron. Als u beheerde hosting gebruikt, raadpleeg dan hun documentatie — mogelijk hoeft u niets te doen. Maar verifieer dat het ook daadwerkelijk werkt, want sommige hosts stellen een zeer lang interval in (elke 30 minuten of zelfs ieder uur) dat te zelden kan zijn voor uw behoeften.

Beveiliging: het wp-cron.php-eindpunt

Het bestand wp-cron.php is standaard publiek toegankelijk. Het in een browser bezoeken activeert de croncontrole handmatig. Hoewel dit geen gevoelige gegevens blootstelt, kan het worden misbruikt: een aanvaller die het eindpunt overspoelt met verzoeken kan resource-intensieve crontaken herhaaldelijk laten draaien, met als gevolg een denial-of-service-toestand.

Als u bent overgestapt op een systeemcron, is er geen reden voor wp-cron.php om publiek bereikbaar te zijn. U kunt externe toegang blokkeren via uw webserverconfiguratie, terwijl de systeemcron deze nog wel lokaal mag aanroepen.

WP-Cron-problemen oplossen

Als geplande taken niet draaien zoals verwacht, is de plugin WP Crontrol van onschatbare waarde. Deze voegt een pagina toe aan het WordPress-admin die alle geregistreerde crongebeurtenissen, hun volgende geplande uitvoeringstijd en hun frequentie toont. U kunt elke gebeurtenis handmatig activeren, vastgelopen gebeurtenissen verwijderen of nieuwe aangepaste schema's toevoegen. Het is de eerste tool om te installeren bij het diagnosticeren van cronproblemen.

Hoe InspectWP helpt

InspectWP controleert of uw wp-cron.php-bestand publiek toegankelijk is. Als u bent overgestapt op een systeemcron en de ingebouwde WP-Cron hebt uitgeschakeld, mag het eindpunt niet van buitenaf bereikbaar zijn. Het rapport helpt u te bevestigen dat uw cronconfiguratie correct is opgezet en dat u geen onnodig eindpunt blootstelt.