Was ist WP-Cron?

WordPress hat einen eigenen eingebauten Aufgabenplaner namens WP-Cron. Der kümmert sich um alles, was nach Zeitplan passieren muss: Beiträge zu einem bestimmten Zeitpunkt veröffentlichen, nach Updates suchen, E-Mail-Benachrichtigungen verschicken, Datenbankmüll aufräumen, Plugin-Hintergrundaufgaben ausführen. Klingt vernünftig, bis man versteht, wie das Ganze wirklich funktioniert. Anders als ein echter Cron-Dienst, der nach festem Takt läuft, feuert WP-Cron nur, wenn jemand deine Seite besucht. Keine Besucher, kein Cron. Und diese Designentscheidung führt zu einer ganzen Reihe von Problemen.

Wie WP-Cron bei jedem Seitenaufruf auslöst

Jedes Mal, wenn eine Seite auf deiner WordPress-Installation geladen wird, prüft WordPress eine Liste geplanter Events. Sind davon welche überfällig, werden sie während dieses Seitenaufrufs abgefeuert. Der Besucher, der die Prüfung ausgelöst hat, merkt davon nichts; die Cron-Tasks laufen im Hintergrund (mehr oder weniger). Aber der entscheidende Punkt ist: Es gibt keinen unabhängigen Prozess, der vor sich hin tickt. Das gesamte Scheduling-System hängt am eingehenden HTTP-Traffic.

Das war eine pragmatische Entscheidung. WordPress wurde dafür gebaut, auf günstigem Shared Hosting zu laufen, wo man keine System-Dienste installieren oder auf crontab zugreifen kann. Der Traffic-basierte Ansatz stellte sicher, dass geplante Aufgaben sofort funktionieren, auf jedem Hoster, ohne Serverkonfiguration.

WP-Cron-Probleme: Verpasste Zeitpläne, Performance und Drift

Das Traffic-abhängige Design hat offensichtliche Probleme, die schmerzhafter werden, je mehr deine Seite wächst, oder paradoxerweise, wenn sie nicht genug wächst:

• Seiten mit wenig Traffic verpassen ihren Zeitplan. Bekommt deine Seite 10 Besuche am Tag, können geplante Beiträge Stunden zu spät erscheinen. Ein Beitrag für 8:00 Uhr morgens geht erst dann wirklich online, wenn nach 8:00 Uhr jemand die Seite besucht, das kann mittags sein, wenn deine Zielgruppe in einer anderen Zeitzone sitzt. WooCommerce-Bestellverarbeitung, Backup-Zeitpläne und E-Mail-Zusammenfassungen leiden genauso.
• Seiten mit viel Traffic verschwenden Ressourcen. Auf einer stark besuchten Seite wird WP-Cron bei fast jedem Seitenaufruf ausgelöst. WordPress prüft die Event-Liste, wertet Zeitstempel aus und (meistens) findet nichts zu tun. Das ist verschwendete Rechenleistung bei jedem Request. Schlimmer noch: Mehrere gleichzeitige Besucher können dieselbe Cron-Prüfung gleichzeitig auslösen, was zu Race Conditions führt, bei denen dieselbe Aufgabe doppelt läuft.
• Lang laufende Tasks verlangsamen Seitenaufrufe. Wenn WP-Cron feuert, laufen die Aufgaben als Teil des Seiten-Requests. WordPress versucht, einen separaten Hintergrund-Request für die eigentliche Cron-Arbeit zu starten, aber auf manchen Serverkonfigurationen scheitert das stillschweigend, und die Tasks laufen inline. Ein Backup-Plugin, das einen 500-MB-Datenbank-Dump erzeugt, kann den Seitenaufruf eines Besuchers blockieren, wenn die Loopback-Verbindung nicht sauber funktioniert.
• Cron-Drift akkumuliert sich. Weil Events nur bei Traffic ausgelöst werden, ist das Timing bestenfalls ungefähr. Eine Aufgabe, die stündlich geplant ist, läuft vielleicht um 1:00, 2:17, 3:02, 4:45, wann immer der nächste Besuch nach der geplanten Zeit stattfindet.

Welche WordPress-Aufgaben von WP-Cron abhängen

Du wärst vielleicht überrascht, wie viel von diesem System abhängt:

• Veröffentlichen geplanter Beiträge und Seiten zum eingestellten Datum und Uhrzeit
• Prüfen auf WordPress-Core-, Plugin- und Theme-Updates
• Verarbeiten von WooCommerce-Hintergrundaufgaben (Bestellstatus-Änderungen, geplante Rabattaktionen, Lagerverwaltung)
• Ausführen automatisierter Backup-Plugins (UpdraftPlus, BackWPup, BlogVault)
• Versenden geplanter E-Mail-Kampagnen oder Zusammenfassungen
• Bereinigen abgelaufener Transients, gelöschter Beiträge und Revisionshistorie
• Verarbeiten von Aufgabenwarteschlangen aus Formular-, Mitgliedschafts- und LMS-Plugins
• Erneuern von Let's-Encrypt-SSL-Zertifikaten (bei Hostern, die das über WordPress handhaben)

Wenn WP-Cron unzuverlässig ist, wird all das unzuverlässig.

WP-Cron durch einen echten Server-Cronjob ersetzen

Die Standardempfehlung für jede Seite, die Scheduling ernst nimmt, ist den Traffic-basierten Trigger abzuschalten und durch einen echten System-Cron-Job zu ersetzen. Das geht in zwei Schritten:

Schritt 1: Füge diese Zeile in deine wp-config.php ein, damit WordPress nicht mehr bei jedem Seitenaufruf Cron auslöst:

define('DISABLE_WP_CRON', true);

Schritt 2: Richte einen System-Cron-Job ein, der wp-cron.php in einem festen Intervall aufruft. Die meisten Hosting-Kontrollpanels (cPanel, Plesk) haben einen Cron-Job-Manager, oder du nutzt crontab -e auf einem Server, den du kontrollierst:

# WP-Cron alle 5 Minuten per wget aufrufen
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

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

# Alternative mit WP-CLI (empfohlen für lokale Aufrufe, vermeidet HTTP-Overhead)
*/5 * * * * cd /var/www/html && wp cron event run --due-now >/dev/null 2>&1

Der WP-CLI-Ansatz ist am saubersten, weil er keinen HTTP-Request benötigt. Er führt die Cron-Events direkt über PHP aus und umgeht damit Probleme mit Loopback-Verbindungen, HTTP-Timeouts und Authentifizierung (z. B. HTTP Basic Auth auf Staging-Seiten).

WP-Cron auf Managed WordPress Hosting

Viele Managed-WordPress-Hoster (Kinsta, WP Engine, Cloudways, SiteGround) deaktivieren das Standard-WP-Cron-Verhalten und ersetzen es automatisch durch einen serverseitigen Cron. Wenn du auf Managed Hosting bist, prüfe deren Dokumentation; möglicherweise musst du gar nichts tun. Aber verifiziere, dass es tatsächlich funktioniert, denn manche Hoster stellen ein sehr langes Intervall ein (alle 30 Minuten oder sogar stündlich), was für deine Anforderungen zu selten sein könnte.

Ist wp-cron.php ein Sicherheitsrisiko?

Die Datei wp-cron.php ist standardmäßig öffentlich erreichbar. Ein Aufruf im Browser löst die Cron-Prüfung manuell aus. Das legt zwar keine sensiblen Daten offen, kann aber missbraucht werden: Ein Angreifer, der den Endpunkt mit Anfragen flutet, kann ressourcenintensive Cron-Tasks wiederholt erzwingen und so einen Denial-of-Service-Zustand schaffen.

Hast du auf einen System-Cron umgestellt, gibt es keinen Grund, dass wp-cron.php von außen erreichbar ist. Du kannst den externen Zugriff über deine Webserver-Konfiguration blockieren und trotzdem dem System-Cron erlauben, es lokal aufzurufen.

WordPress-Cronjobs debuggen mit WP Crontrol

Wenn geplante Aufgaben nicht wie erwartet laufen, ist das Plugin WP Crontrol unbezahlbar. Es fügt dem WordPress-Admin eine Seite hinzu, die alle registrierten Cron-Events, ihre nächste geplante Ausführungszeit und ihre Frequenz zeigt. Du kannst jedes Event manuell auslösen, hängengebliebene Events entfernen oder neue benutzerdefinierte Zeitpläne hinzufügen. Es ist das erste Tool, das du installierst, wenn du Cron-Probleme diagnostizierst.

WP-Cron-Konfiguration prüfen mit InspectWP

InspectWP prüft, ob deine wp-cron.php-Datei öffentlich erreichbar ist. Wenn du auf einen System-Cron umgestellt und den eingebauten WP-Cron deaktiviert hast, sollte der Endpunkt von außen nicht erreichbar sein. Der Bericht hilft dir zu bestätigen, dass deine Cron-Konfiguration korrekt eingerichtet ist und du keinen unnötigen Endpunkt offenlässt.