WP-Cron (wp-cron.php): deaktivieren und System-Cron einrichten | WordPress-Performance optimieren
In WordPress sind Cron-Jobs eine Funktion, die zu einer bestimmten Zeit oder an einem bestimmten Datum geplante Aufgaben automatisch ausführt. Sie laufen über die Datei wp-cron.php, und WordPress ruft diese Datei bei jedem Seitenaufruf auf, um geplante Aufgaben abzuarbeiten. Das ist bequem, kann auf Websites mit viel Traffic aber die Performance bremsen.
Ⅰ. Wie WP-Cron läuft und seine Performance-Probleme
Statt des klassischen Cron-Systems von Linux-Servern bringt WordPress eine eigene Cron-Funktion mit: WP-Cron. WP-Cron arbeitet über die Datei wp-cron.php: ⓐ Bei jedem Besuch der Website prüft es, ob geplante Aufgaben anstehen, und führt sie aus, und ⓑ Plugins wie Rank Math und WP Rocket führen ihre eigenen geplanten, regelmäßigen Aufgaben aus.
Auf Websites mit viel Traffic kann wp-cron.php dagegen viel zu oft aufgerufen werden und den Server überlasten. Vor allem wenn viele Nutzer gleichzeitig zugreifen, laufen Cron-Aufgaben doppelt, was zu höherer CPU-Auslastung, langsameren Antworten, langsamerem Seitenaufbau und ähnlichen Problemen führen kann.
Diese strukturellen Grenzen von WP-Cron können die Performance von WordPress drücken und vor allem auf leistungshungrigen Websites, Onlineshops und Nachrichtenportalen zu ernsten Engpässen führen.
🔄 Wie WP-Cron läuft und aufgebaut ist
Ⅱ. WordPress-Performance optimieren
Es gibt viele Wege, die WordPress-Performance zu optimieren. Nach Caching, Frontend und Datenbank lässt sich mit den WP-Cron-Einstellungen noch mehr herausholen.
Bei jedem Laden einer WordPress-Seite werden geplante Ereignisse geprüft, und wegen der regelmäßigen Plugin-Aufgaben muss das ineffiziente WP-Cron effizienter genutzt werden.
1️⃣ WP-Cron testen
Prüft man die Cron-Aufgaben mit WP-CLI, sieht man die aktiven Cron-Ereignisse laufen. Plugins wie Rank Math und WP Rocket führen ihre geplanten Aufgaben täglich oder im Minutentakt aus.
2️⃣ WP-Cron einrichten
WP-Cron ist ein virtueller Scheduler für die geplanten Aufgaben von WordPress; wp-cron.php läuft, wenn Nutzer die Website besuchen. Die trafficabhängige Ausführung ist aber unzuverlässig und kann durch zu viele Aufrufe den Server belasten, daher ergänzt man sie meist mit einem System-Cron.
Bei Bedarf empfiehlt es sich, in wp-config.php DISABLE_WP_CRON zu setzen, WP-Cron abzuschalten und es regelmäßig per Linux-Cron auszuführen.
|
Kategorie |
WP-Cron deaktivieren + nur System-Cron ausführen |
|---|---|
|
Einstellung |
WP-Cron abschalten und wp-cron.php über den System-Cron ausführen |
|
Vorteile |
Keine doppelten Läufe, exakt zeitgesteuerte Ausführung und wenig Serverlast |
|
Nachteile |
Manche Plugin-Funktionen können ausfallen, und Einrichtungsfehler können Aufgaben ausfallen lassen |
|
Empfohlen · Situation |
Geeignet für Websites mit viel Traffic und vielen geplanten Aufgaben |
Methode ① hat allerdings einen Nachteil: Sie schaltet die Preload-Funktion von Cache-Plugins wie WP Rocket ab, die jede Minute den Cache vorab erzeugt, bevor Besucher kommen.
⚙️ Die Datei wp-config.php bearbeiten
Du kannst es einrichten, indem du WP_CRON deaktivierst.
# WP_CRON deaktivieren
define( 'DISABLE_WP_CRON', true );Während WP-Cron läuft, ist WP_CRON_LOCK_TIMEOUT eine [zeitbasierte Sperre], die weitere Startversuche blockiert.
# 5 Minuten = 300, alle 60 Minuten = 3600
define('WP_CRON_LOCK_TIMEOUT', 300);Aus diesen Gründen empfehle ich, WP-Cron in der Datei wp-config.php nicht nur zu deaktivieren, sondern danach auch einen System Cron Job hinzuzufügen – so ist auch der Server eingerichtet, den ich derzeit betreue.
⚙️ System-Cron auf einem Linux-Server aktivieren [Grundlagen]
Du kannst es pro Domain aktivieren.
# Alle 5 Minuten ausführen
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Alle 30 Minuten ausführen
*/30 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Jede Stunde ausführen
0 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Einmal am Tag ausführen
0 3 * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Die vier Zeilen oben sind Beispiele je Intervall für die crontab: Zu jeder festgelegten Zeit ruft curl die Adresse [wp-cron.php] auf, sodass geplante Aufgaben auch ohne Besucher laufen.
# Wenn der Server ein lokaler Server ist
*/5 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Alle 30 Minuten ausführen
*/30 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Jede Stunde ausführen
0 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Einmal am Tag ausführen
0 3 * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1Ist WP-CLI installiert, richtest du nur eine Zeile mit dem gewünschten Intervall ein. ▼
# Alle 5 Minuten ausführen
*/5 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet
# Alle 30 Minuten ausführen
*/30 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet
# Jede Stunde ausführen
0 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet
# Einmal am Tag ausführen
0 3 * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quietHier führt WP-CLI auf dem Server mit der Option [--due-now] nur fällige geplante Aufgaben aus, und [flock -n] überspringt einen neuen Lauf, solange der vorherige nicht beendet ist.
⚙️ WP-CLI und System-Cron im Minutentakt, doppelte Cron-Läufe verhindern
Standardmäßig ignoriert (überspringt) WP_CRON Aufgaben einfach, wenn viel zu tun ist, und führt sie später erneut aus. Schalte das Standard-WP-Cron ab und lass geplante Aufgaben eine 5-Minuten-Sperre halten, damit System-Cron und WP-Cron nicht gleichzeitig laufen.
define('DISABLE_WP_CRON', true); // automatische Ausführung von WP-Cron aus
define('WP_CRON_LOCK_TIMEOUT', 300); // kein Warten → übersprungen; hält während einer geplanten Aufgabe 5 Minuten lang eine Sperre
/* That's all, stop editing! Happy publishing. */Ergänze im System-Cron die Option flock -n, damit ein Lauf auf System-Cron-Seite sofort beendet wird.
# wp-cron-Einstellung: flock -n → kein Warten → sofort beenden
*/1 * * * * cd /sites/example.com/files/ && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quietDas Ergebnis dieser Kombination:
- Die interne Auto-Ausführung von WP ist aus → geplante Aufgaben laufen unabhängig von der Besucherzahl
- Der System-Cron versucht jede Minute einen Lauf → stehen geplante Aufgaben an, laufen sie
- Ist die Sperre aktiv, gibt es 5 Minuten lang keinen neuen Lauf → verhindert doppelte Läufe (mit flock -n ist WP_CRON_LOCK_TIMEOUT eigentlich gar nicht nötig.)
Mit der Doppellauf-Sperre sieht der tatsächliche Ablauf so aus:
- 08:00 → der System-Cron ruft wp-cron.php auf
- Geplante Aufgabe A läuft → 5-Minuten-Sperre gesetzt
- 08:01 → der System-Cron ruft erneut auf
- Aufgabe A ist gesperrt → läuft nicht
- 08:02–08:04 → ebenso
- 08:05 → Sperre aufgehoben → steht die nächste geplante Aufgabe an, läuft sie
Statt dass WordPress Aufgaben automatisch ausführt, übernimmt das System die Ausführung. Und WP_CRON_LOCK_TIMEOUT dient als zusätzliche Absicherung gegen doppelte Läufe.
|
Kategorie |
WP_CRON_LOCK_TIMEOUT |
flock -n |
|---|---|---|
|
Sperrart |
Innerhalb von WordPress |
Systemebene |
|
Ort der Sperre |
In der DB: doing_cron in wp_options |
Als Systemdatei: ~/.wp_cron.lock |
|
Wartet? |
❌ Wartet nicht → überspringt |
❌ Wartet nicht → beendet sofort |
|
Schutz vor Doppelläufen |
✅ Verhindert Doppelläufe |
✅ Verhindert Doppelläufe |
Danach kannst du per WP-CLI-Befehl prüfen, ob Cron wie gewohnt funktioniert.
wp cron event list+-------------------------------------------+---------------------+-----------------------+---------------+
| hook | next_run_gmt | next_run_relative | recurrence |
+-------------------------------------------+---------------------+-----------------------+---------------+
| rocket_saas_pending_jobs | 2026-10-17 12:00:57 | now | 1 minute |
| action_scheduler_run_queue | 2026-10-17 12:00:57 | now | 1 minute |
| action_scheduler_run_queue_rucss | 2026-10-17 12:00:58 | now | 1 minute |
| rocket_saas_on_submit_jobs | 2026-10-17 12:00:58 | now | 1 minute |
| rocket_preload_process_pending | 2026-10-17 12:00:59 | now | 1 minute |
| rocket_purge_time_event | 2026-10-17 12:16:59 | 15 minutes 8 seconds | 1 hour |
| wp_privacy_delete_old_export_files | 2026-10-17 12:28:46 | 26 minutes 55 seconds | 1 hour |
| wp_update_user_counts | 2026-10-17 20:15:52 | 8 hours 14 minutes | 12 hours |
| rocket_preload_revert_old_failed_rows | 2026-10-17 20:17:59 | 8 hours 16 minutes | 12 hours |
| wp_version_check | 2026-10-17 20:28:34 | 8 hours 26 minutes | 12 hours |
| wp_update_plugins | 2026-10-17 20:58:34 | 8 hours 56 minutes | 12 hours |
| wp_update_themes | 2026-10-17 21:28:34 | 9 hours 26 minutes | 12 hours |
| recovery_mode_clean_expired_keys | 2026-10-18 07:28:46 | 19 hours 26 minutes | 1 day |
| wp_privacy_personal_data_cleanup_requests | 2026-10-18 07:28:46 | 19 hours 26 minutes | 1 day |
| wp_scheduled_delete | 2026-10-18 08:15:52 | 20 hours 14 minutes | 1 day |
| delete_expired_transients | 2026-10-18 08:15:52 | 20 hours 14 minutes | 1 day |
| wp_scheduled_auto_draft_delete | 2026-10-18 08:15:54 | 20 hours 14 minutes | 1 day |
| wp_delete_temp_updater_backups | 2026-10-18 08:16:17 | 20 hours 14 minutes | 1 week |
| rocket_update_dynamic_lists | 2026-10-18 08:16:57 | 20 hours 15 minutes | 1 week |
| rocket_saas_clean_rows_time_event | 2026-10-18 08:16:57 | 20 hours 15 minutes | 1 week |
| rocket_performance_hints_cleanup | 2026-10-18 08:16:58 | 20 hours 15 minutes | 1 day |
| rocket_preload_clean_rows_time_event | 2026-10-18 08:26:57 | 20 hours 25 minutes | 1 week |
| rocket_database_optimization_time_event | 2026-10-18 09:34:25 | 21 hours 32 minutes | 1 day |
| wp_site_health_scheduled_check | 2026-10-19 07:28:46 | 1 day 19 hours | 1 week |
| rocket_remove_saas_failed_jobs | 2026-10-19 08:16:58 | 1 day 20 hours | 3 days |
+-------------------------------------------+---------------------+-----------------------+---------------+Die Ausgabe zeigt die registrierten Hook-Namen, den nächsten Ausführungszeitpunkt und das Intervall; Aufgaben, bei denen in der Spalte [next_run_relative] [now] steht, werden beim nächsten Cron-Lauf sofort abgearbeitet.
Ⅲ. Wenn geplante WP-Cron-Aufgaben nicht laufen
Man nimmt leicht an, eine Aufgabe laufe von selbst, sobald ihre geplante Zeit erreicht ist, doch WP-Cron prüft nicht zu einer Uhrzeit, sondern dann, wenn eine Seitenanfrage eingeht. Eine für 14 Uhr geplante Aufgabe läuft erst bei der ersten Anfrage um 17 Uhr, wenn bis dahin keine kommt.
Hängt die Ausführung hinterher, erscheinen geplante Beiträge in der Beitragsliste als [Planung verpasst](Missed schedule). Unter [Empfohlene Verbesserungen] im Tab Status von [Werkzeuge › Website-Zustand] steht dann [Ein geplantes Ereignis ist fehlgeschlagen]. Aufgaben, die Plugins registrieren, etwa das Vorladen des Caches, warten aus demselben Grund.
Geplante Aufgaben laufen in [wp-cron.php], nachdem sie Seitenanfrage, Prüfung fälliger Arbeit und Loopback-Anfrage durchlaufen haben; reißt eines dieser Glieder ab, laufen sie auch nach ihrer Zeit nicht.
1️⃣ Wenn keine Besuche kommen oder der Seiten-Cache antwortet
WP-Cron prüft fällige Arbeit nur bei Anfragen, die WordPress ausführen; in Zeiten ohne Besuche stauen sich überfällige Aufgaben einfach auf. Auch mit Besuchen ist das Ergebnis dasselbe, wenn eine Seiten-Cache-Datei antwortet, weil WordPress dann nicht läuft.
Auf einem WordPress mit aktivem WP-Rocket-Seiten-Cache wurde beim Öffnen der gecachten Startseite kein Aufruf von [wp-cron.php] protokolliert. Beim Öffnen einer nicht gecachten URL wurde in derselben Sekunde ein Aufruf protokolliert, und die fünf liegengebliebenen Aufgaben liefen.
Überfällige Aufgaben siehst du, wenn du die WP-CLI-Liste auf Zeilen mit [next_run_relative] gleich [now] filterst.
wp cron event list --next_run_relative=now --fields=hook,next_run_gmt,next_run_relative+----------------------------------+---------------------+-------------------+
| hook | next_run_gmt | next_run_relative |
+----------------------------------+---------------------+-------------------+
| rocket_saas_pending_jobs | 2026-10-17 14:49:57 | now |
| action_scheduler_run_queue | 2026-10-17 14:49:57 | now |
| action_scheduler_run_queue_rucss | 2026-10-17 14:49:58 | now |
| rocket_saas_on_submit_jobs | 2026-10-17 14:49:58 | now |
| rocket_preload_process_pending | 2026-10-17 14:49:59 | now |
+----------------------------------+---------------------+-------------------+[now] bedeutet, dass die geplante Zeit schon vorbei ist. Auch dieser Listenbefehl lädt WordPress und ruft daher bei überfälligen Aufgaben im Moment seines Endes [wp-cron.php] auf. Führst du denselben Befehl gleich noch einmal aus, sind die eben angezeigten Aufgaben aus der Liste verschwunden.
Willst du die überfälligen Aufgaben abarbeiten, bevor du die Ursache behebst, führst du mit WP-CLI sofort nur die fälligen aus.
wp cron event run --due-nowExecuted the cron event 'rocket_saas_pending_jobs' in 0.005s.
Executed the cron event 'action_scheduler_run_queue' in 0.006s.
Executed the cron event 'action_scheduler_run_queue_rucss' in 0.006s.
Executed the cron event 'rocket_saas_on_submit_jobs' in 0.005s.
Executed the cron event 'rocket_preload_process_pending' in 0.007s.
Success: Executed a total of 5 cron events.Dieser Befehl führt die Aufgaben ohne HTTP-Anfrage auf dem Server aus; um sie unabhängig von Besuchen in festen Abständen abzuarbeiten, trägst du denselben Befehl im System-Cron ein.
2️⃣ Wenn nur DISABLE_WP_CRON aktiv ist und kein System-Cron existiert
Steht [DISABLE_WP_CRON] auf true, prüft WP-Cron auch bei eingehenden Seitenanfragen keine fällige Arbeit. Auch die offizielle Dokumentation empfiehlt, zuerst im System-Taskplaner einzutragen und erst dann diese Konstante zu setzen; setzt du nur die Konstante ohne Eintrag, führt nichts mehr die geplanten Aufgaben aus.
Mit gesetzter Konstante blieb ein gut eine Minute später geplanter Beitrag nach Ablauf der Zeit auf [Geplant], und in der Datumsspalte der Beitragsliste stand [Planung verpasst]. In der Zwischenzeit wurde kein einziger Aufruf von [wp-cron.php] protokolliert.
Ob die Konstante aktiv ist, prüfst du mit [wp cron test].
wp cron testError: The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled.Erscheint dieser Fehler, prüfe, ob der System-Cron eine Zeile hat, die [wp-cron.php] aufruft oder [wp cron event run] ausführt. Ist die crontab des Website-Kontos leer, sieht das so aus.
crontab -lno crontab for exampleFehlt die Zeile, richte einen System-Cron ein; lässt deine Umgebung das nicht zu, lösche die Zeile [DISABLE_WP_CRON] und nutze wieder WP-Cron.
3️⃣ Wenn die Loopback-Anfrage des Servers blockiert ist
Gibt es etwas zu tun, lässt WP-Cron den Server eine Anfrage an [wp-cron.php] unter der eigenen Website-Adresse schicken, um die Aufgaben auszuführen – das ist die Loopback-Anfrage. Blockiert eine Sicherheitsregel [wp-cron.php], kommt die Loopback-Anfrage mit 403 zurück, und die Aufgaben laufen nicht.
Auf einem Server mit Nginx + Apache blockierte eine Regel, die [wp-cron.php] nur für 127.0.0.1 öffnet, die Loopback-Anfrage mit 403. Der Grund: Die Anfrage, die der Server an seine eigene Domain schickt, kommt über die öffentliche IP herein, und auch [wp cron test] liefert denselben Statuscode.
wp cron testError: WP-Cron spawn returned HTTP status code: 403 ForbiddenMit mehr als fünf Minuten überfälligen Aufgaben zeigte der Bildschirm [Website-Zustand] unter [Empfohlene Verbesserungen] eine Loopback-Warnung und ein fehlgeschlagenes geplantes Ereignis zusammen an.
Nach dem Entfernen der Regel war [wp cron test] wieder erfolgreich. Musst du die Regel behalten, führst du die Aufgaben per WP-CLI aus dem System-Cron aus. Ein WP-CLI-Lauf geht nicht über eine HTTP-Anfrage, daher wurden die überfälligen Aufgaben auch mit derselben Regel verarbeitet.
🔢 FAQ & empfohlene Inhalte
ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt(bei Aktionsrabatten sinkt er ↓), steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.