Du willst einen WordPress Cron Job einrichten, der wirklich zuverlässig läuft? Dann musst du das Standardverhalten von WP-Cron verstehen und durch einen echten System-Cronjob ersetzen. WP-Cron ist kein klassischer Cron im Linux-Sinne, sondern ein pseudo-geplanter Mechanismus, der nur bei Seitenaufrufen ausgelöst wird. Auf Seiten mit wenig Traffic führt das dazu, dass geplante Aufgaben wie Backups, Plugin-Updates, Newsletter-Versand oder das Veröffentlichen geplanter Beiträge verspätet oder gar nicht laufen. In dieser Anleitung zeigen wir dir, wie du das pageload-abhängige Verhalten deaktivierst und einen echten Cronjob via WP-CLI einrichtest. Die Anleitung richtet sich an Admins und Selfhoster mit SSH-Zugriff auf ihren Server.

Kurzfassung: define('DISABLE_WP_CRON', true); in die wp-config.php eintragen, danach einen System-Cron anlegen, der alle 15 Minuten wp cron event run --all ausführt. Mit dem Plugin WP Crontrol behältst du alle Events im Blick.

Was ist WP-Cron und warum echter Cron besser ist

WP-Cron ist das interne Planungssystem von WordPress. Es verarbeitet zeitgesteuerte Aufgaben (Scheduled Tasks) wie das Prüfen auf Updates, das Löschen alter Transients, geplante Veröffentlichungen oder von Plugins registrierte Hintergrundjobs. Der entscheidende Unterschied beim Thema WP-Cron vs Real Cron: Das System wird nicht von einem zeitbasierten Daemon angestossen, sondern bei jedem Frontend-Aufruf der Datei wp-cron.php. WordPress prüft dann, ob fällige Aufgaben anstehen, und arbeitet sie ab.

Das hat zwei Probleme. Erstens: Hat deine Seite wenig Besucher, werden Aufgaben verspätet oder gar nicht ausgeführt - geplante Beiträge erscheinen Stunden zu spät, Backups fallen aus. Zweitens: Bei viel Traffic wird wp-cron.php bei jedem Aufruf erneut geladen, was unnötig Ressourcen kostet. Die saubere Lösung ist, WP-Cron vom Pageload zu entkoppeln und stattdessen einen echten System-Cron einzurichten, der in festen Intervallen prüft. So machst du deine WordPress-Aufgaben planbar und unabhängig vom Besucherverhalten.

Voraussetzungen

SSH-Zugriff auf den Server, auf dem WordPress läuft (Root oder ein Benutzer mit Schreibrechten auf das Webroot).
Schreibzugriff auf die wp-config.php deiner Installation.
WP-CLI installiert und im PATH verfügbar (Befehl wp). Prüfen mit wp --info.
Ein funktionierender Cron-Daemon auf dem System (z. B. cron bzw. crond unter Linux).
Den absoluten Pfad zu deiner WordPress-Installation, z. B. /var/www/html.
Ein aktuelles Backup von Datenbank und Dateien, bevor du Änderungen vornimmst.

Schritt 1: WP-CLI prüfen und WP-Cron-Status ansehen

Bevor du etwas änderst, verschaffe dir einen Überblick über die aktuell geplanten Events. Logge dich per SSH ein und wechsle in das WordPress-Verzeichnis.

cd /var/www/html
wp --info
wp cron event list

Der Befehl wp cron event list zeigt dir alle registrierten Cron-Events mit Hook-Name, nächster Ausführungszeit und Wiederholungsintervall. Notiere dir, ob hier Events mit now oder lange überfälligen Zeitpunkten stehen - das ist ein typisches Symptom für ein nicht laufendes WP-Cron.

Schritt 2: wp-cron.php deaktivieren in der wp-config.php

Jetzt deaktivierst du das automatische Auslösen bei Seitenaufrufen. Öffne die wp-config.php im Webroot mit einem Editor deiner Wahl.

nano /var/www/html/wp-config.php

Füge die folgende Zeile oberhalb der Zeile /* That's all, stop editing! */ ein. Damit setzt du die Konstante, die das pageload-abhängige WP-Cron abschaltet.

define( 'DISABLE_WP_CRON', true );

Speichere die Datei. Ab jetzt führt WordPress bei normalen Seitenaufrufen keine Cron-Verarbeitung mehr durch. Das bedeutet aber auch: Solange du in Schritt 3 keinen Ersatz einrichtest, laufen gar keine geplanten Aufgaben mehr. Mache also direkt weiter.

Schritt 3: WordPress Cronjob automatisieren mit System-Cron

Nun richtest du den echten Cronjob ein, der WP-Cron in festen Intervallen anstößt. Öffne die Crontab des Benutzers, unter dem der Webserver bzw. PHP läuft (häufig www-data).

crontab -u www-data -e

Füge folgende Zeile hinzu. Sie ruft alle 15 Minuten WP-CLI auf und arbeitet alle fälligen Events ab. Damit Cron wp sicher findet, nutze gleich den absoluten Pfad zur WP-CLI (Cron hat eine minimale Umgebung mit kurzem PATH) und leite die Ausgabe in ein Logfile um.

*/15 * * * * /usr/local/bin/wp cron event run --all --path=/var/www/html >> /var/log/wp-cron.log 2>&1

Liegt wp bei dir an einem anderen Ort, finde den Pfad vorab mit which wp heraus und setze ihn entsprechend ein. Erst wenn du den vollen Pfad genutzt hast, ist der Cronjob zuverlässig - die folgende Kurzform funktioniert nur, falls wp wirklich im PATH des Cron-Kontexts liegt.

*/15 * * * * wp cron event run --all --path=/var/www/html

Speichere die Crontab. Das Intervall von 15 Minuten ist ein guter Kompromiss aus Zuverlässigkeit und Last. Brauchst du genauere Veröffentlichungszeiten, kannst du auf */5 (alle 5 Minuten) gehen.

Schritt 4: WP Crontrol Plugin zur Überwachung installieren

Damit du WordPress Scheduled Tasks komfortabel im Backend überwachen und debuggen kannst, empfiehlt sich das Plugin WP Crontrol. Es zeigt alle Events, erlaubt manuelles Auslösen und das Anlegen eigener Cron-Hooks über die Oberfläche. Installation per WP-CLI.

wp plugin install wp-crontrol --activate --path=/var/www/html

Nach der Aktivierung findest du die Übersicht im Backend unter Werkzeuge → Cron-Ereignisse. Dort siehst du auf einen Blick, welche Hooks überfällig sind und ob dein System-Cron sie zuverlässig abarbeitet.

Schritt 5: Verifikation und erster Test

Teste jetzt, ob der echte Cron wie erwartet greift. Führe den Lauf einmal manuell aus und schau dir die Ausgabe an.

wp cron event run --all --path=/var/www/html

WP-CLI listet die abgearbeiteten Hooks mit Erfolgsstatus auf. Prüfe anschließend, ob keine Events mehr stark überfällig sind.

wp cron event list --path=/var/www/html

Ein guter Praxistest: Plane einen Beitrag mit Veröffentlichungszeitpunkt in wenigen Minuten in der Zukunft und beobachte, ob er nach dem nächsten Cron-Lauf automatisch erscheint. Kontrolliere zusätzlich dein Logfile.

tail -n 20 /var/log/wp-cron.log

Erscheinen dort regelmäßig Einträge im 15-Minuten-Takt, läuft dein WordPress Cron Job korrekt.

Schritt 6: Updates, Wartung und Transient-Cleanup

Ein häufig übersehener Wartungspunkt sind veraltete Transients - temporäre, gecachte Werte in der Datenbank. Mit der Zeit sammeln sich abgelaufene Transients an und blähen die wp_options-Tabelle auf. WP-CLI räumt das mit einem Befehl auf.

wp transient delete --expired --path=/var/www/html

Willst du alle Transients löschen (etwa nach einem Cache-Problem), nutze die radikalere Variante. Vorsicht: Das entfernt auch gültige Transients, die danach neu aufgebaut werden.

wp transient delete --all --path=/var/www/html

Du kannst diesen Cleanup ebenfalls als eigenen, selteneren Cronjob einrichten, etwa einmal täglich nachts.

30 3 * * * /usr/local/bin/wp transient delete --expired --path=/var/www/html >> /var/log/wp-cron.log 2>&1

Backup-Hinweis

Änderungen an wp-config.php und Crontab sind reversibel, aber sichere vor jeder größeren Wartung Datenbank und Dateien. Ein DB-Dump ist mit WP-CLI schnell erstellt und gehört in jede Routine.

wp db export /var/backups/wp-$(date +%F).sql --path=/var/www/html

Troubleshooting

Cron läuft nicht: Prüfe mit crontab -u www-data -l, ob der Eintrag wirklich gespeichert wurde, und ob der Cron-Daemon aktiv ist (systemctl status cron).
wp: command not found im Log: Cron nutzt einen minimalen PATH. Verwende immer den absoluten Pfad zur WP-CLI, z. B. /usr/local/bin/wp.
Permission denied: Der Cron muss unter dem richtigen Benutzer laufen. Falsche Dateirechte führen zu Fehlern - der Webserver-User (oft www-data) ist meist die richtige Wahl.
Events bleiben überfällig: Prüfe in WP Crontrol, ob ein Plugin-Hook einen Fehler wirft. Einzelne Events lassen sich mit wp cron event run <hook> gezielt testen.
DISABLE_WP_CRON wirkt nicht: Stelle sicher, dass die Zeile vor /* That's all, stop editing! */ steht und kein Caching-/Object-Cache-Plugin die Konstante überschreibt.

Häufige Fragen

Was ist der Unterschied zwischen WP-Cron und echtem Cron?

WP-Cron wird bei Seitenaufrufen ausgelöst und ist daher von Besuchertraffic abhängig. Ein echter System-Cron läuft zeitgesteuert durch den Cron-Daemon - unabhängig davon, ob jemand die Seite besucht. Für zuverlässige geplante Aufgaben ist echter Cron deutlich besser.

Macht das Deaktivieren von wp-cron.php meine Seite kaputt?

Nein - solange du sofort einen Ersatz einrichtest. DISABLE_WP_CRON schaltet nur das automatische Auslösen bei Pageloads ab. Ohne den System-Cron aus Schritt 3 würden allerdings keine geplanten Aufgaben mehr laufen, daher gehören beide Schritte zusammen.

Welches Intervall sollte ich für den Cronjob wählen?

Für die meisten Seiten sind 15 Minuten (*/15) ein guter Wert. Brauchst du präzisere Veröffentlichungszeiten geplanter Beiträge oder zeitkritische Plugin-Jobs, setze auf 5 Minuten (*/5). Sehr kurze Intervalle erhöhen die Serverlast unnötig.

Brauche ich WP-CLI zwingend?

Für diese Methode ja - wp cron event run --all ist der sauberste Weg, fällige Events abzuarbeiten. Alternativ liesse sich wp-cron.php per curl oder wget aufrufen, aber WP-CLI ist robuster, gibt Statusmeldungen aus und ist nicht vom HTTP-Stack abhängig.

Wie überwache ich meine WordPress Scheduled Tasks?

Das Plugin WP Crontrol zeigt alle Cron-Events im Backend, markiert überfällige Hooks und erlaubt manuelles Auslösen. In Kombination mit dem Logfile deines System-Crons hast du volle Kontrolle über alle geplanten Aufgaben.

Fazit

Mit dieser Anleitung hast du einen WordPress Cron Job eingerichtet, der unabhängig vom Besucherverhalten läuft. Du hast WP-Cron via DISABLE_WP_CRON vom Pageload entkoppelt, einen echten System-Cron mit WP-CLI angelegt, das Plugin WP Crontrol zur Überwachung installiert und den Lauf verifiziert. Geplante Beiträge, Backups und Plugin-Jobs laufen jetzt zuverlässig und planbar - genau so, wie ein produktives WordPress-System es braucht. Ergänze den täglichen Transient-Cleanup, und deine Datenbank bleibt zusätzlich schlank.

Weiterführende Artikel und Quellen

Wenn du dich um die Sicherheit deiner WordPress-Plugins kümmerst, lies auch unsere Analyse zum Auth-Bypass in Burst Statistics sowie unseren Beitrag zum Bluesky-AT-Protocol-Plugin Atmosphere. Weitere praktische Anleitungen findest du in unserer WordPress-Kategorie.

Quellen: WordPress Developer Handbook - Hooking WP-Cron Into the System Task Scheduler, WP-CLI Command Reference - wp cron event run, WP Crontrol auf wordpress.org.