WordPress Core Auto Updates konfigurieren (WP_AUTO_UPDATE_CORE)

Seit WordPress 3.7 aktualisiert die Plattform Teile von sich selbst automatisch, ohne dass jemand klicken muss. Den meisten Seitenbetreibern ist das vage bewusst, aber wenige haben ein klares Bild davon, was genau wann aktualisiert wird und wie sich das ändern lässt. Diese Anleitung geht durch die vier Stufen automatischer Updates, die WordPress Core unterstützt, was jede Stufe konkret tut und welche die richtige Wahl ist, je nachdem, ob du eine Einzelseite betreust, ein Agentur Portfolio oder ein Managed Hosting Setup.

Was WordPress standardmäßig automatisch aktualisiert

Ab Werk macht jede WordPress Installation im Jahr 2026 folgendes ungefragt:

• Minor Core Updates. Der Sprung von 6.5.1 auf 6.5.2 läuft automatisch im Hintergrund, am selben Tag, an dem das Release veröffentlicht wird. Diese Releases sind Bugfixes und Sicherheits Patches. Sie sind explizit darauf ausgelegt, ohne Testen einspielbar zu sein.
• Übersetzungsdatei Updates. Sprachpakete aktualisieren sich automatisch.
• Core Security Releases für ältere Branches. Selbst wenn deine Seite noch auf 6.4 läuft, weil du das Major Update nicht gemacht hast, werden Sicherheits Fixes zurückportiert und automatisch eingespielt.

Was nicht automatisch passiert:

• Major Core Updates. Der Sprung von 6.5 auf 6.6 erfordert einen manuellen Klick. WordPress zeigt das Banner im Admin, installiert das Update aber nicht von selbst.
• Plugin und Theme Updates. Beide lassen sich seit WordPress 5.5 pro Eintrag im Admin aktivieren, sind aber standardmäßig aus. Das ist ein eigenes Thema, nicht über WP_AUTO_UPDATE_CORE gesteuert.

Hintergrund dieser Trennung ist gutes Engineering: Minor Releases unterliegen einer strengen "Keine Breaking Changes" Policy, sie still einzuspielen ist also genuin risikoarm. Major Releases führen gelegentlich neue APIs ein oder ändern Verhalten, auf das Themes und Plugins sich verlassen, und ein stiller Major Sprung in Produktion hat in der Vergangenheit oft genug Schaden angerichtet, dass das Projekt sich für den konservativen Default entschieden hat.

Die vier Stufen automatischer Core Updates

Die Konstante WP_AUTO_UPDATE_CORE in der wp-config.php steuert das alles. Sie akzeptiert vier Werte:

• true: Alle Core Updates werden automatisch installiert, sowohl Minor als auch Major. Die offensive Variante.
• 'minor': Der Default, falls die Konstante gar nicht definiert ist. Nur Minor und Security Releases laufen automatisch. Major Releases bleiben manuell.
• 'beta' und 'rc': Für Seiten, die Pre Release Builds haben wollen. Realistisch nur in einer Staging oder Test Umgebung, nie in Produktion.
• false: Alle automatischen Core Updates aus. Die Seite tut von sich aus nichts. Du bist für jeden Patch verantwortlich, inklusive Sicherheits Fixes.

Eine dieser Stufen zu setzen ist eine einzige Zeile in der wp-config.php, irgendwo oberhalb des Kommentars /* Das war's, Schluss mit dem Bearbeiten! Viel Spaß. */:

define('WP_AUTO_UPDATE_CORE', true);

oder

define('WP_AUTO_UPDATE_CORE', 'minor');

Speichern, kein Neustart nötig. WordPress prüft regelmäßig auf Updates (standardmäßig zweimal täglich) und installiert das, was die aktuelle Einstellung erlaubt.

Welche Einstellung passt zu welcher Art von Seite?

Die ehrliche Antwort hängt von drei Dingen ab: wie viel vor einem Release tatsächlich getestet wird, wer es bemerkt, wenn etwas bricht, und wie verlässlich die Backup Lage ist.

Standard Produktivseite ohne Wartungsvertrag

Empfehlung: true (alle Updates automatisch).

Die Intuition "automatische Major Updates sind gefährlich" ist weitgehend überholt. WordPress Major Updates sind seit Jahren stabil, und die realistische Alternative lautet "die Seite wird sechs Monate nicht aktualisiert, weil es keinen Vertrag dafür gibt, und ein bekanntes Sicherheitsloch bleibt offen". Eine ungewartete WordPress Seite ist das schlechtere Ergebnis als das sehr seltene Auto Update, das mal etwas zerlegt. Wenn ein Major Release die Seite bricht, ist das Wiederherstellen aus dem Backup schneller, als die Zeit, die du sonst später ins manuelle Update steckst. Die Automatisierung ist der Gewinn.

Managed Hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Empfehlung: was das Hoster Dashboard ohnehin tut, in der Regel 'minor' auf WordPress Ebene.

Die meisten Managed Hoster fahren ihren eigenen Update Flow oben auf WordPress drauf. Sie ziehen vorher einen Snapshot, spielen das Major Release auf einem Staging Klon ein, fahren ein einfaches visuelles Diff und übernehmen es erst dann in Produktion. Das ist messbar sicherer als reine WordPress Auto Updates. Wenn du auf so einem Host bist, kämpft WP_AUTO_UPDATE_CORE auf einen anderen Wert in der Regel gegen die Logik des Hosters. Lass es in Ruhe, lass den Hoster machen, und schau im Dashboard in den Update Verlauf.

Agentur Portfolio mit Wartungsvertrag

Empfehlung: 'minor' in Produktion, true auf Staging.

Wenn ein Wartungsvertrag besagt, dass Updates vor dem Live Gang getestet werden, ist die Agentur das Sicherheitsnetz. Produktion bekommt trotzdem Minor und Security Releases automatisch (das ist aus Sicherheitssicht nicht verhandelbar), Majors laufen durch den Test Flow der Agentur. Staging ist der richtige Ort für die offensivere Einstellung, damit Tester Breakage früh sehen.

Stark angepasste WordPress Installation

Empfehlung: 'minor', plus echter Test Prozess für Major Updates.

Seiten, an denen viel umgebaut wurde (umgebaute Header, eigene Gutenberg Blöcke, exotische Page Builder Integrationen, eigene REST Endpoints) sind genau der Fall, in dem ein Major Update etwas Subtiles brechen kann. Der Default 'minor' ist die richtige Untergrenze: Sicherheits Patches nicht aufgeben, Majors aber als eigene Aufgabe mit echtem Test Durchlauf behandeln.

Hochverfügbarkeits Seite, die unter keinen Umständen brechen darf

Empfehlung: false für Core, plus echter Release Prozess.

Das ist der einzige Fall, in dem es Sinn ergibt, automatische Core Updates komplett abzuschalten. Banken, Healthcare, regulierte Umgebungen, in denen jede Änderung durch einen Release Prozess läuft. Achtung: damit übernimmst du die volle Verantwortung dafür, Sicherheits Patches binnen Stunden nach einem Release manuell auszurollen, auf jeder Seite. Teams, die sich für diese Einstellung entscheiden, haben in der Regel ein Monitoring auf der WordPress Security Mailingliste und eine Deployment Pipeline, die Patches taggleich ausspielen kann.

So prüfst du, dass deine Einstellung greift

1. Im WordPress Admin Werkzeuge, Website Zustand, Bericht öffnen.
2. Den Abschnitt WordPress Konstanten ausklappen.
3. Nach WP_AUTO_UPDATE_CORE suchen. Wenn der Wert deinen Wert zeigt, wird die Konstante gelesen.
4. Für eine tiefere Prüfung in der Sidebar auf Aktualisierungen gehen. Aktuelle automatische Updates erscheinen dort mit Zeitstempel.

Falls der Konstanten Wert in Site Health nicht auftaucht, ist die wahrscheinlichste Ursache, dass die Konstante weiter oben in der Datei schon einmal anders gesetzt wurde (das erste define gewinnt, PHP gibt eine Notice aus, die du eventuell nicht siehst), oder dass du die falsche wp-config.php bearbeitet hast.

Was bei automatischen Core Updates schiefgehen kann

Drei Fehlerbilder sind realistisch und gut zu kennen:

• Update bricht halb ab. Der Download oder das Entpacken hängt mittendrin, oft weil dem Hoster der Plattenplatz ausgeht, ein Inode Limit gerissen wird oder ein temporärer Netzwerkfehler dazwischen kommt. WordPress legt eine .maintenance Datei im Root ab, und die Seite zeigt für immer "Wegen einer geplanten Wartung kurz nicht verfügbar". Fix: per SFTP in den Root, .maintenance Datei löschen, Update aus dem Admin neu starten.
• Update läuft durch, aber ein Plugin wirft danach Fehler. Vor allem nach einem Major Update kann ein ungewartetes Plugin gegen neue Core APIs brechen. Fix: Backup einsatzbereit halten, das problematische Plugin im Error Log identifizieren (oder durch nacheinander Deaktivieren), und entweder das Plugin aktualisieren oder austauschen.
• Update wird still übersprungen. Häufige Ursachen: DISALLOW_FILE_MODS ist in der wp-config.php gesetzt (das blockiert alle Updates, automatisch wie manuell), Dateirechte am WordPress Verzeichnis verhindern, dass PHP schreiben kann, oder die Seite nutzt Git zur Versionskontrolle und WordPress erkennt das .git Verzeichnis und schaltet Updates als Sicherheitsmaßnahme ab. Die Site Health Seite weist solche Fälle in der Regel aus.

Auto Updates und DISALLOW_FILE_MODS

Die zwei Konstanten greifen ineinander, und das übersehen viele. DISALLOW_FILE_MODS (siehe unsere Knowledge Base zum Thema Datei Editor) blockiert alle Datei Modifikationen von WordPress aus, also auch automatische Core Updates. Wenn beide gesetzt sind:

define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);

gewinnt DISALLOW_FILE_MODS. WordPress aktualisiert dann nichts mehr automatisch. Das ist selten so gemeint. Entweder du willst eine abgeschottete Seite, die von außen aktualisiert wird (Deploy Pipeline, WP CLI), dann ist DISALLOW_FILE_MODS = true richtig und WP_AUTO_UPDATE_CORE egal. Oder du willst, dass die Seite sich selbst aktualisiert, dann darf DISALLOW_FILE_MODS nicht gesetzt sein.

Was ist mit automatischen Plugin und Theme Updates?

Plugin und Theme Auto Updates sind ein eigener Mechanismus, eingeführt mit WordPress 5.5. Sie werden pro Eintrag im Admin konfiguriert (Plugins Liste, der Link "Auto Updates aktivieren" in jeder Zeile) oder global per Filter. Die generelle Empfehlung: Auto Updates für alle Plugins einschalten, deren Maintainer eine verlässliche Release Disziplin haben, und für Plugins, die regelmäßig Breaking Changes ausliefern, manuell halten. Vor allem WooCommerce Major Releases sind oft einen manuellen Test wert.

Wenn du Plugin Auto Updates per Code für alle Plugins anschalten willst, reicht dieser Filter:

add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Pack das in ein kleines Must Use Plugin unter wp-content/mu-plugins/ statt in die functions.php, damit ein Theme Wechsel die Einstellung nicht wegfegt.

Fazit zum Core Update Thema: für die meisten Seiten im Jahr 2026 ist der Default 'minor' in die falsche Richtung konservativ. Entweder WP_AUTO_UPDATE_CORE auf true setzen und die Plattform sich selbst aktuell halten lassen, oder einen echten Wartungsprozess aufsetzen, der Majors innerhalb sinnvoller Zeit manuell behandelt. Der Mittelweg "Default und niemand schaut hin" ist das, was ungepatchte WordPress Seiten zwei Versionen hinter dem Stand produziert, und genau das ist der eigentliche Hochrisiko Zustand.