WP-Cron deaktivieren und die Performance steigern

Wer WordPress unter realen Bedingungen betreibt, kommt um WP-Cron nicht herum – er steuert Updates, Backups und geplante Beiträge. Das Problem: Er basiert auf einem Trick. Statt eines echten systemseitigen Cronjobs hängt sich WordPress in jeden Seitenaufruf ein und prüft dort, ob eine Aufgabe ansteht. Auf Seiten mit viel Traffic erzeugt das messbare Mehrbelastung; auf Seiten mit wenig Traffic werden Aufgaben schlicht übersprungen. Dieser Beitrag erklärt, wie WP-Cron intern funktioniert, wann er zum Problem wird, wie man ihn sauber abschaltet und durch einen echten Cronjob ersetzt – inklusive Verifikation und typischen Fehlern.

Wie WP-Cron intern funktioniert

WordPress hängt bei jedem Seitenaufruf einen Callback an den init-Hook. Dort ruft die Funktion wp_cron() intern spawn_cron() auf – sofern überhaupt ein Event fällig ist. spawn_cron() setzt einen Transient namens doing_cron als Lock mit einer Laufzeit von 60 Sekunden und schickt anschließend einen nicht-blockierenden HTTP-Request an die eigene wp-cron.php. Diese Datei verarbeitet alle fälligen Events der Reihe nach.

Das Muster ist clever, weil es ohne Cron-Zugang auf dem Server funktioniert – genau das Szenario auf günstigem Shared Hosting. Der Haken liegt im Detail: Jeder Seitenaufruf läuft den kompletten Check durch, auch wenn kein Event ansteht. Und unter Last können innerhalb eines 60-Sekunden-Fensters mehrere wp-cron.php-Requests gleichzeitig unterwegs sein, weil der Lock nur das erneute spawn_cron() verhindert, nicht Aufrufe, die direkt an die Datei gehen.

Was genau in eurem WP-Cron steckt, zeigt das Plugin WP Crontrol. Typische Events sind:

• Prüfung auf Plugin-, Theme- und Core-Updates
• Geplante Beiträge veröffentlichen
• Backups erstellen (UpdraftPlus, BackWPup u. a.)
• Datenbanktabellen optimieren
• E-Mails versenden und Queues abarbeiten

Was konkret läuft, hängt von euren Plugins ab. Jedes Plugin, das regelmäßige Hintergrundarbeit braucht, registriert eigene Events.

Wann WP-Cron zum Problem wird

Bei hohem Traffic: Mehrere hundert gleichzeitige Besucher bedeuten mehrere hundert init-Aufrufe pro Sekunde. Selbst wenn spawn_cron() durch den Transient gedrosselt ist, addiert sich die Prüflogik auf jedem Request auf. Dazu kommt, dass manche Plugins sehr kurze Intervalle registrieren – etwa alle fünf Minuten –, was die Trigger-Frequenz erhöht. Das Ergebnis: überflüssige PHP-Prozesse, die Serverressourcen belegen.

Bei niedrigem Traffic: Hat eine Seite nachts kaum Besucher, kann ein Backup, das für 3:00 Uhr geplant ist, komplett ausbleiben – weil niemand die Seite aufruft und den Cron auslöst. WP Crontrol zeigt dann Events mit überfälliger Ausführungszeit, die sich immer weiter ansammeln.

Erkennbare Symptome: Geplante Beiträge erscheinen mit Verzögerung oder gar nicht. Transactional Mails kommen zu spät an. Plugin-Update-Checks passieren nicht täglich. Backup-Plugins wie UpdraftPlus melden überfällige Läufe.

Schritt für Schritt: WP-Cron deaktivieren

1. Backup der wp-config.php anlegen

Bevor wir irgendetwas ändern: eine Kopie der wp-config.php anlegen. Ein Tippfehler in dieser Datei macht die gesamte WordPress-Installation unerreichbar.

2. DISABLE_WP_CRON setzen

Öffnet die wp-config.php im Wurzelverzeichnis eurer WordPress-Installation. Sucht diese Zeile:

/* Das ist alles, hören Sie mit der Bearbeitung auf! Happy Blogging. */

Fügt unmittelbar davor folgendes ein:

// WP-Cron deaktiviert – wird durch echten Server-Cronjob ersetzt
define( 'DISABLE_WP_CRON', true );

Ab diesem Moment löst kein Seitenaufruf mehr spawn_cron() aus. WP-Cron-Events bleiben in der Datenbank eingetragen – sie werden nur nicht mehr automatisch ausgeführt. Deshalb sofort weiter zu Schritt 3.

3. Echten Cronjob einrichten

Option A: cPanel oder Plesk

In cPanel findet ihr unter „Cron-Jobs” ein Formular. Intervall auf */5 * * * * setzen (alle fünf Minuten), Befehl:

/usr/bin/php /absoluter/pfad/zur/wordpress-installation/wp-cron.php >/dev/null 2>&1

Den absoluten Pfad bekommt ihr im Dateimanager eures Hosters oder via SSH mit pwd im WordPress-Verzeichnis. IONOS, Strato und All-Inkl. bieten ähnliche Oberflächen mit Dropdown-Intervallen an.

Option B: SSH und crontab

Verbindet euch via SSH, öffnet den Crontab-Editor mit crontab -e und fügt eine der folgenden Zeilen ein:

# Empfohlen: PHP direkt aufrufen – kein HTTP-Overhead, kein curl/wget nötig
*/5 * * * * /usr/bin/php /var/www/html/wp-cron.php >/dev/null 2>&1

# Alternativ: curl – sinnvoll, wenn der Pfad nicht bekannt ist oder SSL geprüft werden soll
*/5 * * * * /usr/bin/curl -s 'https://domain.tld/wp-cron.php?doing_wp_cron' > /dev/null 2>&1

# Alternativ: wget – für ältere Server-Setups
*/5 * * * * /usr/bin/wget -q -O /dev/null 'https://domain.tld/wp-cron.php?doing_wp_cron' 2>&1

Zur Erklärung: */5 * * * * heißt „jede fünfte Minute, jede Stunde, jeden Tag, jeden Monat, jeden Wochentag”. Der Anhang >/dev/null 2>&1 verwirft jede Ausgabe, damit der Cronjob keine automatischen Mails an den System-User verschickt.

Option C: WP-CLI

Falls WP-CLI auf eurem Server installiert ist, ist das oft die ressourcenschonendste Lösung – kein HTTP-Request, kein Netzwerk-Overhead:

*/5 * * * * cd /var/www/html && /usr/local/bin/wp cron event run --due-now --quiet 2>&1

wp cron event run --due-now startet alle fälligen Events direkt im laufenden PHP-Prozess. Voraussetzung: WP-CLI ist installiert und der Crontab-Nutzer hat Leserechte auf das WordPress-Verzeichnis.

Option D: Externer Cron-Dienst

Hat euer Hoster keine Cron-Oberfläche und SSH ist nicht verfügbar, helfen externe Dienste: cron-job.org (kostenlos), EasyCron (kostenlos bis zu einem Volumen) oder Uptime Robot (primär Monitoring, aber für HTTP-Pings ausreichend). Konfiguriert dort die URL:

https://domain.tld/wp-cron.php?doing_wp_cron

Intervall: fünf Minuten. Achtung: Diese Methode schickt immer einen HTTP-Request von außen – bei sehr restriktiven Firewalls oder IP-Whitelisting kann das scheitern.

Verifikation: Läuft der Cronjob wirklich?

Nach dem Einrichten wartet ihr mindestens zehn Minuten und öffnet dann WP Crontrol im WordPress-Backend. Das Plugin zeigt für jedes Event den Zeitstempel der letzten Ausführung. Überfällige Events, die sich vorher angesammelt hatten, sollten nun abgearbeitet sein.

Zusätzlicher Check: Ruft https://domain.tld/wp-cron.php?doing_wp_cron einmal manuell im Browser auf. Die Seite liefert eine leere Antwort ohne Fehlermeldung – das ist korrekt und zeigt, dass die Datei erreichbar ist. Anschließend schaut ihr ins Access-Log eures Servers und sucht nach regelmäßigen GET /wp-cron.php-Einträgen im gewählten Intervall.

Typische Fehler und wie ihr sie behebt

Geplante Beiträge erscheinen nicht pünktlich: Häufigste Ursache ist ein falscher Pfad zur wp-cron.php im Crontab-Eintrag. PHP gibt in diesem Fall keinen Fehler aus – der Cron läuft durch, aber ohne Wirkung. Prüft den Pfad mit ls /euer/pfad/wp-cron.php direkt auf dem Server.

UpdraftPlus zeigt einen roten Warnhinweis: Backup-Plugins erkennen, ob WP-Cron aktiv ist. Nach dem Setzen von DISABLE_WP_CRON erscheint dieser Hinweis, bis ein echter Cronjob vorhanden ist. Nach korrekter Einrichtung verschwindet er automatisch.

Crontab-Zeile wird nicht ausgeführt: Mit crontab -l prüfen, ob die Zeile korrekt gespeichert wurde. Dann manuell testen: bash -c "/usr/bin/php /pfad/zu/wp-cron.php". Schlägt das fehl, fehlen dem ausführenden Nutzer Rechte auf die Datei.

Server schickt E-Mails nach jedem Cron-Lauf: Der Anhang >/dev/null 2>&1 fehlt. Zeile im Crontab korrigieren und speichern.

Wann man WP-Cron lieber behalten sollte

Shared Hosting ohne Cron-Zugang: Wer weder cPanel-Crons noch SSH hat und keine externen Dienste nutzen möchte, ist mit WP-Cron besser dran als ohne jede Automatisierung. In diesem Fall lieber WP-Cron aktiv lassen und mit WP Crontrol überflüssige Events deregistrieren, um die Frequenz zu senken.

Sehr einfache Seiten ohne Hintergrundaufgaben: Ein Portfolio ohne Backup-Plugin, ohne geplante Beiträge und ohne E-Mail-Queue hat kaum Events. Der Umbauaufwand überwiegt den Nutzen.

Direkt vor einer Migration oder einem Major-Update: Änderungen an der wp-config.php gehören nicht in ein enges Zeitfenster vor einer Systemumstellung. Erst stabilisieren, dann optimieren.

---

---

Ihr seid unsicher, ob WP-Cron bei euch bremst oder Aufgaben nicht laufen? Schreibt uns kurz – wir richten den Cronjob sauber ein.

Weitere Performance-Hebel für WordPress findet ihr in der Übersicht Core Web Vitals für WordPress.