Ein WordPress Cron Job läuft nur dann zuverlässig, wenn ein echter System-Cronjob das Standardverhalten von WP-Cron ersetzt. 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. Diese Anleitung zeigt, wie Sie das pageload-abhängige Verhalten deaktivieren und einen echten Cronjob via WP-CLI einrichten. Die Anleitung richtet sich an Admins und Selfhoster mit SSH-Zugriff auf ihren Server.

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 angestoßen, 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 Ihre Seite wenig Besucher, laufen Aufgaben verspätet oder gar nicht; geplante Beiträge erscheinen Stunden zu spät, Backups fallen aus. Zweitens: Bei viel Traffic startet WordPress die Cron-Prüfung laufend neu, was 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.

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 Ihrer 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 Ihrer WordPress-Installation, z. B. /var/www/html.
Ein aktuelles Backup von Datenbank und Dateien, bevor Sie Änderungen vornehmen.
Ressourcen: keine zusätzlichen; ein Webhosting-Paket mit SSH und Cron oder ein kleiner VPS (1 vCPU, 1 GB RAM) reicht.

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

Verschaffen Sie sich vor Änderungen einen Überblick über die geplanten Events. Melden Sie sich per SSH an und wechseln Sie in das WordPress-Verzeichnis.

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

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

Verifizieren: wp --info gibt die WP-CLI-Version aus, wp cron event list zeigt eine Tabelle mit Hooks und Ausführungszeiten.

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

Deaktivieren Sie das automatische Auslösen bei Seitenaufrufen. Öffnen Sie die wp-config.php im Webroot mit einem Editor.

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

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

define( 'DISABLE_WP_CRON', true );

Speichern Sie die Datei. Ab jetzt verarbeitet WordPress bei Seitenaufrufen keine Cron-Events mehr; bis Schritt 3 erledigt ist, laufen keine geplanten Aufgaben. Machen Sie deshalb direkt weiter.

Verifizieren: wp config get DISABLE_WP_CRON --path=/var/www/html gibt 1 aus.

Schritt 3: WordPress Cronjob automatisieren mit System-Cron

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

crontab -u www-data -e

Fügen Sie folgende Zeile hinzu. Sie ruft alle 15 Minuten WP-CLI auf und arbeitet nur die fälligen Events ab (--due-now; --all würde auch nicht fällige Events sofort ausführen). Cron hat einen minimalen PATH: Nutzen Sie den absoluten Pfad zur WP-CLI und leiten Sie die Ausgabe in ein Logfile um. Das Logfile muss für www-data beschreibbar sein, z. B. nach sudo touch /var/log/wp-cron.log && sudo chown www-data /var/log/wp-cron.log.

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

Liegt wp an einem anderen Ort, ermitteln Sie den Pfad mit which wp. Die folgende Kurzform funktioniert nur, wenn wp im PATH des Cron-Kontexts liegt:

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

Speichern Sie die Crontab. 15 Minuten sind ein guter Kompromiss aus Zuverlässigkeit und Last; für genauere Veröffentlichungszeiten wählen Sie */5.

Verifizieren: crontab -u www-data -l zeigt die neue Zeile, und systemctl status cron meldet active (running).

Schritt 4: WP Crontrol Plugin zur Überwachung installieren

Zum Überwachen der geplanten Aufgaben im Backend eignet 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 finden Sie die Übersicht im Backend unter Werkzeuge → Cron-Ereignisse. Dort sehen Sie, welche Hooks überfällig sind.

Verifizieren: wp plugin status wp-crontrol --path=/var/www/html meldet Status: Active, und die Seite Werkzeuge → Cron-Ereignisse listet die Events.

Schritt 5: Verifikation und erster Test

Testen Sie, ob der echte Cron greift. Führen Sie den Lauf einmal manuell aus:

wp cron event run --due-now --path=/var/www/html

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

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

Praxistest: Planen Sie einen Beitrag wenige Minuten in der Zukunft und beobachten Sie, ob er nach dem nächsten Cron-Lauf erscheint. Kontrollieren Sie zusätzlich das Logfile.

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

Verifizieren: Das Logfile enthält im 15-Minuten-Takt Zeilen wie Executed the cron event … oder Success: Executed a total of …, und der geplante Testbeitrag ist veröffentlicht.

Schritt 6: Updates, Wartung und Transient-Cleanup

Ein häufig übersehener Wartungspunkt sind veraltete Transients, also 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

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

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

Den Cleanup richten Sie als eigenen, täglichen Cronjob ein:

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; sichern Sie trotzdem 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

Verifizieren: wp transient delete --expired meldet Success:, und ls -l /var/backups/ zeigt den SQL-Dump mit aktuellem Datum.

Troubleshooting

Cron läuft nicht: Prüfen Sie 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. Verwenden Sie 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üfen Sie 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: Die Zeile muss vor /* That's all, stop editing! */ stehen und darf nicht doppelt mit false in der Datei vorkommen.

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.

Beeinträchtigt das Deaktivieren von wp-cron.php die Seite?

Nein, solange Sie sofort einen Ersatz einrichten. 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 ist für den Cronjob sinnvoll?

Für die meisten Seiten sind 15 Minuten (*/15) ein guter Wert. Für präzisere Veröffentlichungszeiten oder zeitkritische Plugin-Jobs wählen Sie 5 Minuten (*/5). Sehr kurze Intervalle erhöhen die Serverlast unnötig.

Ist WP-CLI zwingend nötig?

Für diese Methode ja. Alternativ rufen Sie wp-cron.php per curl oder wget auf (so beschreibt es das WordPress Developer Handbook); WP-CLI ist aber robuster, gibt Statusmeldungen aus und ist nicht vom HTTP-Stack abhängig.

Wie überwache ich geplante WordPress-Aufgaben?

Das Plugin WP Crontrol zeigt alle Cron-Events im Backend, markiert überfällige Hooks und erlaubt manuelles Auslösen. Zusammen mit dem Logfile des System-Crons haben Sie alle geplanten Aufgaben im Blick.

Fazit

Mit dieser Anleitung haben Sie einen WordPress Cron Job eingerichtet, der unabhängig vom Besucherverhalten läuft. Sie haben 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 planbar. Der tägliche Transient-Cleanup hält zusätzlich die Datenbank schlank.

Weiterführende Artikel und Quellen

Zur Sicherheit von WordPress-Plugins: Analyse zum Auth-Bypass in Burst Statistics und Beitrag zum Bluesky-AT-Protocol-Plugin Atmosphere. Verwandte Anleitungen: WordPress Debug-Modus aktivieren, WordPress nativ auf Ubuntu installieren. Weitere Anleitungen finden Sie in der 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.