Geplante Beiträge in WordPress verpasst: Ursachen finden und dauerhaft beheben
Wenn geplante Beiträge als „Überfällig“ liegen bleiben, läuft WP-Cron nicht zuverlässig. Die Anleitung zeigt Ursachen, Prüfung im Website-Zustand, Sofortmaßnahmen und einen dauerhaften Cronjob.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
Ein Beitrag ist für Montag, 8 Uhr, geplant, doch am Vormittag steht in der Beitragsliste in roter Schrift „Überfällig“ statt „Veröffentlicht“. Das liegt fast nie am Beitrag selbst, sondern an der Art, wie WordPress zeitgesteuerte Aufgaben ausführt. Diese Anleitung erklärt, warum geplante Beiträge liegen bleiben, wie Sie die Ursache auf Ihrer Website eingrenzen und wie Sie das Problem dauerhaft lösen. Die wichtigsten Fehlerbilder haben wir auf einer Testinstallation mit WordPress 7.1.2 nachgestellt.
Voraussetzungen
- WordPress: eine aktuelle Installation, getestet mit WordPress 7.1.2 in deutscher Sprache.
- PHP: die Version Ihres Hostings, im Labor PHP 8.4.
- Zugriff: Rolle Administrator im Backend. Für die dauerhafte Lösung Zugang zur Cronjob-Verwaltung Ihres Hosters oder SSH, optional WP-CLI. Zum Prüfen der
wp-config.phpSFTP. - Backup: ein aktuelles Backup, bevor Sie die
wp-config.phpändern. Ein Syntaxfehler in dieser Datei legt die gesamte Website lahm.
Schritt 1: Verstehen, wie WordPress Beiträge zeitgesteuert veröffentlicht
Wenn Sie einen Beitrag planen, erhält er den Status „Geplant“, und WordPress legt ein Ereignis mit dem Namen publish_future_post für genau diesen Zeitpunkt an. Um den Zeitpunkt kümmert sich WP-Cron, der eingebaute Aufgabenplaner. Laut Plugin-Handbuch auf developer.wordpress.org prüft WP-Cron bei jedem Seitenaufruf, ob fällige Aufgaben anstehen, und läuft nicht dauerhaft wie der Cron-Dienst eines Linux-Servers. Das Handbuch nennt selbst das Beispiel: Ist eine Aufgabe für 14 Uhr geplant und kommt bis 17 Uhr kein Besucher, läuft sie erst um 17 Uhr.
Daraus folgen drei Grundregeln. Auf Websites mit wenig Besuch kommen Beiträge verspätet. Wird WP-Cron abgeschaltet, muss ein anderer Mechanismus einspringen. Und wenn WP-Cron zwar startet, aber die interne Anfrage an wp-cron.php scheitert, bleibt ebenfalls alles liegen.
Verifizieren: Sie wissen, dass geplante Beiträge von WP-Cron und damit von Seitenaufrufen oder einem externen Aufruf abhängen.
Schritt 2: Das Fehlerbild genau ansehen
Öffnen Sie Beiträge > Alle Beiträge. Überfällige Beiträge zeigen in der Spalte „Datum“ in roter Schrift „Überfällig“ und darunter den geplanten Zeitpunkt. WordPress setzt diese Kennzeichnung, sobald ein Beitrag noch den Status „Geplant“ hat, obwohl sein Termin in der Vergangenheit liegt.
Prüfen Sie danach Werkzeuge > Website-Zustand. Zwei Tests sind hier wichtig:
- Geplante Ereignisse: Im Idealfall steht dort „Geplante Ereignisse werden ausgeführt“. Bei Problemen meldet WordPress „Ein geplantes Ereignis ist überfällig“ und nennt den Namen des Ereignisses.
- Loopback-Anfrage: Meldet der Test, dass Loopback-Anfragen funktionieren, kann WordPress sich selbst aufrufen. Genau diesen Weg nutzt WP-Cron, um
wp-cron.phpim Hintergrund zu starten.
Beachten Sie, dass der Website-Zustand mit Verzögerung warnt. Im Quellcode von WordPress 7.1.2 gilt ein Ereignis bei abgeschaltetem WP-Cron erst nach 15 Minuten als überfällig. Im Test stand deshalb in der Beitragsliste schon „Überfällig“, während der Website-Zustand noch „Geplante Ereignisse werden ausgeführt“ anzeigte. Die Beitragsliste ist also der schnellere Hinweis.
Mit WP-CLI sehen Sie die anstehenden Veröffentlichungen direkt:
wp cron event list --hook=publish_future_post --fields=hook,next_run_gmt,argsDie Spalte args enthält die Beitrags-ID, next_run_gmt den Zeitpunkt in UTC.
Verifizieren: Sie wissen, welche Beiträge betroffen sind, und haben notiert, was der Website-Zustand zu geplanten Ereignissen und Loopback-Anfragen meldet.
Schritt 3: Die häufigsten Ursachen prüfen
WP-Cron abgeschaltet, aber kein Ersatz eingerichtet. Öffnen Sie die wp-config.php per SFTP und suchen Sie nach DISABLE_WP_CRON. Steht dort define( 'DISABLE_WP_CRON', true );, startet WordPress WP-Cron nicht mehr selbst. Das ist sinnvoll, wenn ein Cronjob des Servers diese Aufgabe übernimmt. Fehlt der Cronjob, etwa nach einem Umzug zu einem anderen Hoster, bleiben alle geplanten Beiträge stehen. Genau so haben wir das Problem im Test ausgelöst. WP-CLI bestätigt den Zustand mit einer eindeutigen Meldung:
$ wp cron test
Error: The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled.Loopback-Anfrage scheitert. Meldet der Website-Zustand, dass die Website keine Loopback-Anfrage abschließen konnte, kommt der Hintergrundaufruf nicht an. Typische Gründe sind ein Passwortschutz für die ganze Website (HTTP-Authentifizierung), eine Firewall, die Anfragen des eigenen Servers sperrt, oder eine falsche Namensauflösung auf dem Server. Wie Sie einen Passwortschutz so einrichten, dass er nur das Backend betrifft, beschreibt Adminbereich per IP-Freigabe und HTTP-Auth schützen.
Sicherheitsregeln sperren wp-cron.php. Manche Sicherheits-Plugins und Serverregeln blockieren direkte Aufrufe von PHP-Dateien. Rufen Sie zum Test https://www.example.de/wp-cron.php im Browser auf. Eine leere weiße Seite ist richtig, ein Fehler 403 oder eine Sperrseite ist die Ursache.
Zeitzone falsch eingestellt. Unter Einstellungen > Allgemein legen Sie die Zeitzone fest. Steht dort „UTC+0“ statt „Berlin“ oder „Wien“, wird ein für 8 Uhr geplanter Beitrag eine bzw. zwei Stunden später veröffentlicht als erwartet. Eine Stadt statt eines festen Versatzes berücksichtigt auch die Umstellung auf Sommerzeit.
Wenig Besucher und Seiten-Cache. Liefert ein Caching-Plugin oder der Hoster fertige Seiten aus, ohne PHP zu starten, zählt ein Besuch nicht als Seitenaufruf für WP-Cron. Auf Websites mit wenig Verkehr verschiebt sich die Veröffentlichung dann um Stunden.
Verifizieren: Sie haben mindestens eine der Ursachen bestätigt oder ausgeschlossen: Konstante in der wp-config.php, Loopback-Test, direkter Aufruf von wp-cron.php, Zeitzone.
Schritt 4: Überfällige Beiträge sofort veröffentlichen
Bevor Sie die Ursache beheben, bringen Sie die liegengebliebenen Beiträge online. Im Backend öffnen Sie den Beitrag und klicken auf „Veröffentlichen“. Alternativ nutzen Sie in der Beitragsliste die Schnellbearbeitung und setzen den Status auf „Veröffentlicht“. Prüfen Sie dabei das Datum: Soll der Beitrag mit dem ursprünglich geplanten Datum erscheinen oder mit dem aktuellen?
Oft genügt es auch, WP-Cron einmal von Hand anzustoßen. Im Test veröffentlichte ein einzelner Aufruf von wp-cron.php einen überfälligen Beitrag sofort, obwohl DISABLE_WP_CRON gesetzt war. Die Datei führt fällige Ereignisse auch dann aus, die Konstante verhindert nur den automatischen Start bei Seitenaufrufen:
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/wp-cron.phpDie Ausgabe sollte 200 lauten.
Verifizieren: In Beiträge > Alle Beiträge steht bei den betroffenen Beiträgen „Veröffentlicht“, und sie sind auf der Website sichtbar.
Schritt 5: WP-Cron dauerhaft zuverlässig machen
Die robuste Lösung ist ein Cronjob auf Serverebene, der wp-cron.php in festen Abständen aufruft, unabhängig von Besuchern. Das Plugin-Handbuch beschreibt genau diesen Weg und empfiehlt, anschließend WP-Cron bei Seitenaufrufen abzuschalten, weil die Prüfung dann nur noch Last erzeugt:
define( 'DISABLE_WP_CRON', true );Die Zeile gehört in die wp-config.php oberhalb des Kommentars „That's all, stop editing!“. Tragen Sie sie erst ein, wenn der Cronjob läuft, nicht umgekehrt. Bei den meisten Hostern legen Sie im Kundenbereich einen Cronjob mit einer Adresse an. Auf einem eigenen Linux-Server sieht ein Eintrag in der Crontab des Webserver-Benutzers so aus:
*/5 * * * * wget -q -O /dev/null https://www.example.de/wp-cron.phpAlle fünf Minuten ist für geplante Beiträge ein guter Takt. Wer WP-CLI auf dem Server hat, kann stattdessen wp cron event run --due-now im Cronjob ausführen. Wie Sie das Schritt für Schritt einrichten, inklusive Benutzerrechten und Protokollierung, zeigt WP-Cron durch echten System-Cron via WP-CLI ersetzen. Die Grundlagen der Zeitangaben erklärt Cron und crontab richtig nutzen.
Ein Cronjob ist allerdings nur so gut wie seine Überwachung. Nach einem Hoster-Wechsel, einer PHP-Umstellung oder einer neuen Firewall-Regel kann er unbemerkt ausfallen. Werfen Sie deshalb regelmäßig einen Blick in den Website-Zustand. Wer diese Kontrollen nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein, sichert die Website wöchentlich auf externen Speicher und richtet eine Firewall ein.
Verifizieren: Planen Sie einen Testbeitrag zehn Minuten in die Zukunft und rufen Sie die Website in dieser Zeit nicht auf. Nach spätestens fünf weiteren Minuten muss er den Status „Veröffentlicht“ haben. Löschen Sie den Testbeitrag danach.
Typische Fehler
- „Überfällig“ nach Umzug: Die
wp-config.phpwurde mitDISABLE_WP_CRONübernommen, der Cronjob beim alten Hoster blieb zurück. Legen Sie ihn beim neuen Hoster an. - Cronjob läuft, Beiträge bleiben trotzdem liegen: Der Aufruf endet mit 403 oder einer Anmeldeseite, etwa wegen Passwortschutz oder Firewall. Prüfen Sie den Aufruf mit
curlund dem Statuscode. - Beitrag erscheint eine oder zwei Stunden zu spät: Die Zeitzone steht auf einem festen Versatz wie UTC+0. Stellen Sie auf „Berlin“ oder „Wien“ um.
- „Error: '11' is not a valid schedule name for recurrence.“ Diese Meldung von
wp cron event schedulesahen wir beim Versuch, ein Ereignis mit Beitrags-ID von Hand anzulegen. Der Befehl erwartet an dieser Stelle ein Intervall, keine Argumente. Veröffentlichen Sie überfällige Beiträge besser im Backend. - Website-Zustand meldet nichts: Die Warnung erscheint bei abgeschaltetem WP-Cron erst mit Verzögerung. Die Beitragsliste zeigt das Problem früher.
Häufige Fragen
Brauche ich ein Plugin gegen verpasste Veröffentlichungen?
Solche Plugins veröffentlichen überfällige Beiträge bei einem späteren Seitenaufruf nach. Sie behandeln das Symptom. Ein Cronjob auf Serverebene behebt die Ursache und funktioniert auch für Updates, Backups und alle anderen geplanten Aufgaben.
Wie oft sollte der Cronjob laufen?
Alle fünf Minuten reicht für die meisten Websites. Kürzere Abstände bringen bei geplanten Beiträgen kaum Gewinn und erhöhen die Last. Manche Hoster erlauben nur größere Intervalle, dann verschiebt sich die Veröffentlichung entsprechend.
Betrifft das Problem nur Beiträge?
Nein. Automatische Updates, die Suche nach Updates, Aufräumaufgaben und viele Plugins nutzen dasselbe System. Verpasste Beiträge sind oft nur das sichtbarste Zeichen dafür, dass im Hintergrund noch mehr liegen bleibt.
Testumfang
Auf einer Testinstallation mit WordPress 7.1.2 haben wir WP-Cron abgeschaltet und einen Beitrag kurz in die Zukunft geplant. Er blieb als „Überfällig“ hängen, ohne dass der Website-Zustand warnte. Ein einziger Aufruf von wp-cron.php hat ihn sofort veröffentlicht.
Andere Ursachen wie Loopback-Probleme oder Sicherheits-Plugins konnten wir nicht nachstellen. Kommt eine davon bei Ihnen in Frage, prüfen Sie sie mit den Tests aus Schritt 3.
Fazit
Verpasste Veröffentlichungen sind ein Zeichen dafür, dass WP-Cron nicht zuverlässig läuft. Prüfen Sie die Konstante in der wp-config.php, den Website-Zustand und die Zeitzone, veröffentlichen Sie liegengebliebene Beiträge von Hand und richten Sie einen Cronjob ein, der wp-cron.php regelmäßig aufruft. Dann erscheinen Beiträge pünktlich, und auch Updates und andere Hintergrundaufgaben laufen verlässlich. Wenn Sie Updates und Backups lieber abgeben möchten, übernimmt das die WordPress-Wartung.
