Automatische Updates in WordPress steuern: Kern, Plugins und Themes gezielt festlegen

WordPress kann sich selbst aktualisieren: den Kern, Plugins, Themes und Übersetzungen. Wer diese Automatik nicht bewusst einstellt, verlässt sich auf Voreinstellungen, die je nach Installationsweg und Hoster unterschiedlich ausfallen. Diese Anleitung zeigt, wie Sie für jede Komponente festlegen, was automatisch aktualisiert wird und was nicht, im Backend, per WP-CLI, über wp-config.php und mit einem kleinen Must-Use-Plugin. Alle Befehle und Einstellungen wurden in einer Testinstanz mit WordPress 7.1.2 und PHP 8.4 geprüft.

Voraussetzungen

• WordPress ab Version 5.6 (die Plugin- und Theme-Schalter gibt es seit 5.5, die Kernschalter im Backend seit 5.6), getestet mit WordPress 7.1.2
• PHP in einer von WordPress unterstützten Version (Test: PHP 8.4)
• Benutzerkonto mit der Rolle Administrator im Backend
• Für die Schritte 3 bis 5: Zugriff auf die Dateien per SFTP oder SSH, für Schritt 2 zusätzlich WP-CLI auf dem Server
• Ein aktuelles, getestetes Backup von Dateien und Datenbank, bevor Sie wp-config.php bearbeiten oder Updates freigeben
• Hosting, bei dem WordPress Dateien selbst schreiben darf (kein reines Nur-Lese-Dateisystem), sonst greifen automatische Updates gar nicht

Schritt 1: Ist-Zustand im Backend prüfen und Kern-Updates einstellen

Bevor Sie etwas ändern, sehen Sie nach, was aktuell gilt. Öffnen Sie Dashboard > Aktualisierungen. Oben steht ein Satz, der den Kernmodus beschreibt. Bei einer Standardinstallation lautet er: „Diese Website wird ausschließlich durch Wartungs- und Sicherheitsaktualisierungen für WordPress automatisch auf dem neuesten Stand gehalten.“ Darunter finden Sie den Link „Automatische Aktualisierungen für alle neuen WordPress-Versionen aktivieren“.

WordPress unterscheidet zwei Arten von Kernversionen. Kleine Versionen wie der Sprung von 7.1.2 auf 7.1.3 enthalten Fehlerkorrekturen und Sicherheitskorrekturen, sie ändern keine Funktionen. Große Versionen wie 7.2 bringen neue Funktionen, neue Editor-Bausteine und manchmal geänderte Anforderungen an Plugins und Themes. Die kleinen Versionen sollten Sie nie abschalten: Sicherheitslücken im Kern werden über genau diese Versionen geschlossen, oft innerhalb weniger Tage nach Bekanntwerden.

Ob Sie auch große Versionen automatisch einspielen lassen, hängt von Ihrer Website ab. Eine schlanke Firmenseite verkraftet das meist problemlos. Ein Shop mit individuellem Theme, Buchungssystem oder Schnittstellen zu Warenwirtschaft und CRM sollte große Versionen dagegen erst nach einem Test in einer Staging-Umgebung erhalten. Halten Sie die Entscheidung schriftlich fest.

Das Backend speichert die Wahl in der Option auto_update_core_major. Eine Konstante in wp-config.php (Schritt 3) hat Vorrang.

Verifizieren: Auf Dashboard > Aktualisierungen steht der Satz, der Ihrer Entscheidung entspricht. Per WP-CLI zeigt wp option get auto_update_core_major den gespeicherten Wert, im Test nach dem Umschalten disabled.

Schritt 2: Plugins und Themes einzeln freigeben

Für Plugins öffnen Sie Plugins > Installierte Plugins. Die Spalte „Automatische Aktualisierungen“ zeigt je Plugin den Link „Automatische Aktualisierungen aktivieren“ bzw. „Automatische Aktualisierungen deaktivieren“. Über „Mehrfachaktionen“ ändern Sie mehrere Plugins auf einmal. Für Themes öffnen Sie Design > Themes, klicken auf ein Theme und nutzen in der Detailansicht denselben Link.

Welche Plugins Sie freigeben, ist eine Abwägung. Sicherheits-, Spam- und Backup-Plugins profitieren von schnellen Updates, weil ihre Aufgabe gerade das Reagieren auf neue Bedrohungen ist. Shop-, Formular- und Mitgliedschaftssysteme führen bei Versionssprüngen oft Datenmigrationen aus; diese stoßen Sie besser selbst an.

Auf Servern mit WP-CLI geht dasselbe schneller und lässt sich dokumentieren. Die folgenden Befehle haben wir in der Testinstanz ausgeführt:

# Status aller Plugins anzeigen
wp plugin auto-updates status --all

# Einzelnes Plugin freigeben
wp plugin auto-updates enable akismet

# Alle Themes freigeben
wp theme auto-updates enable --all

# Alle aktuell freigegebenen Plugins wieder sperren
wp plugin auto-updates disable --all --enabled-only

Die Ausgabe im Test lautete zum Beispiel Success: Enabled 1 of 1 plugin auto-updates. und nach dem Sperren Success: Disabled 1 of 1 plugin auto-updates.

Verifizieren: wp plugin list --fields=name,auto_update zeigt in der Spalte auto_update für jedes Plugin on oder off. In der Plugin-Übersicht im Backend steht derselbe Zustand.

Schritt 3: Kernverhalten mit WP_AUTO_UPDATE_CORE festschreiben

Der Schalter im Backend lässt sich von jedem Administrator ändern, auch versehentlich. Wenn Sie eine verbindliche Regel wollen, setzen Sie die Konstante WP_AUTO_UPDATE_CORE in wp-config.php. Sichern Sie die Datei vorher: Ein Tippfehler legt die Website lahm. Die Konstante kennt drei Werte:

Die rechte Spalte zeigt das Ergebnis von Core_Upgrader::should_update_to_version() in der Testinstanz für angenommene Versionen 7.1.3 und 7.2. Für die meisten Unternehmensseiten ist 'minor' der passende Wert: Sicherheitskorrekturen kommen sofort, große Sprünge planen Sie selbst.

Tragen Sie die Zeile oberhalb des Kommentars /* That's all, stop editing! */ ein:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Oder per WP-CLI, dann ohne Anführungszeichen und ohne --raw:

wp config set WP_AUTO_UPDATE_CORE minor
wp config get WP_AUTO_UPDATE_CORE

Die Werte true und false dagegen sind PHP-Wahrheitswerte und brauchen --raw, zum Beispiel wp config set WP_AUTO_UPDATE_CORE true --raw. Ohne --raw würde WP-CLI den Text 'true' schreiben, und das ist ein anderer Wert.

Verifizieren: wp config get WP_AUTO_UPDATE_CORE gibt minor aus. Auf Dashboard > Aktualisierungen ist der Umschalt-Link verschwunden, weil die Konstante die Einstellung im Backend überschreibt.

Schritt 4: Feste Regeln je Plugin mit einem Must-Use-Plugin

Manchmal reicht ein Schalter nicht. Beispiel: Das Spamschutz-Plugin soll sich immer aktualisieren, auch wenn jemand den Schalter im Backend abstellt. Das Shop-Plugin dagegen nie automatisch, weil jede neue Version erst getestet wird. Dafür bietet WordPress den Filter auto_update_plugin (und entsprechend auto_update_theme). Er erhält den bisherigen Wert und ein Objekt mit dem Slug des Plugins. Gibt der Filter true zurück, wird aktualisiert, bei false nicht, bei unverändertem Wert gilt die Einstellung aus dem Backend.

Legen Sie den Code nicht in die functions.php des Themes: Beim Theme-Wechsel wäre die Regel weg. Besser ist ein Must-Use-Plugin. WordPress lädt jede PHP-Datei im Ordner wp-content/mu-plugins automatisch, sie lässt sich im Backend nicht deaktivieren. Legen Sie den Ordner an, falls er fehlt, und speichern Sie dort die Datei update-regeln.php:

<?php
/**
 * Plugin Name: Update-Regeln
 * Description: Legt fest, welche Plugins und Themes automatisch aktualisiert werden.
 */
add_filter( 'auto_update_plugin', function ( $update, $item ) {
	$immer = array( 'akismet' );      // Slugs, die immer aktualisiert werden
	$nie   = array( 'hello-dolly' );  // Slugs, die nie automatisch aktualisiert werden
	if ( isset( $item->slug ) && in_array( $item->slug, $immer, true ) ) {
		return true;
	}
	if ( isset( $item->slug ) && in_array( $item->slug, $nie, true ) ) {
		return false;
	}
	return $update; // alle anderen: Einstellung aus dem Backend
}, 10, 2 );

// Themes nie automatisch aktualisieren
add_filter( 'auto_update_theme', '__return_false' );

Den Slug eines Plugins finden Sie in der Ausgabe von wp plugin list in der Spalte name oder im Ordnernamen unter wp-content/plugins. Prüfen Sie die Datei nach dem Speichern auf Syntaxfehler, bevor die Website sie lädt:

php -l wp-content/mu-plugins/update-regeln.php

Im Test meldete PHP No syntax errors detected. Eine praktische Folge: Sobald ein Filter den Wert für ein Plugin erzwingt, zeigt die Plugin-Übersicht statt des Links nur noch den Zustand an, Administratoren können ihn dort nicht mehr umschalten. Informieren Sie das Team darüber.

Verifizieren: wp plugin list --status=must-use führt update-regeln mit Status must-use. Den Filter selbst prüfen Sie so:

wp eval '$i = (object) array( "slug" => "akismet" ); var_dump( apply_filters( "auto_update_plugin", false, $i ) );'

Erwartet wird bool(true), obwohl der Ausgangswert false war. Die Gegenprobe mit hello-dolly ergab im Test bool(false).

Schritt 5: Absicherung und Kontrolle nach Updates

Automatische Updates laufen über WP-Cron. WordPress prüft alle zwölf Stunden auf neue Versionen; im Test standen die Ereignisse wp_version_check, wp_update_plugins und wp_update_themes jeweils mit dem Intervall „12 hours“ in der Liste. Auf Websites mit wenig Besuchern startet WP-Cron nur selten, dann kommen Updates spät an. Die Lösung ist ein echter Cronjob auf dem Server, beschrieben in der Anleitung WP-Cron durch echten System-Cron ersetzen.

wp cron event list --fields=hook,next_run_relative,recurrence

Seit WordPress 6.6 prüft der Updater nach jedem automatischen Plugin-Update, ob die Website einen schweren PHP-Fehler wirft. Ist das der Fall, stellt WordPress die vorherige Plugin-Version aus einer temporären Sicherung wieder her. Das ersetzt kein Backup: Datenbankänderungen werden nicht zurückgedreht, Fehler auf einzelnen Unterseiten erkennt die Prüfung nicht.

Deshalb gehören drei Dinge zu jeder Update-Automatik: ein tägliches oder mindestens wöchentliches Backup außerhalb des Webspace, eine Kontrolle der wichtigsten Seiten nach Updates (Startseite, Kontaktformular, Kasse) und das Lesen der Benachrichtigungen. WordPress schickt nach automatischen Updates eine E-Mail an die Administrator-Adresse unter Einstellungen > Allgemein.

Spätestens hier wird deutlich, dass Update-Steuerung keine einmalige Einstellung ist, sondern laufende Pflege: Backups kontrollieren, Benachrichtigungen auswerten, große Versionen testen, Ausnahmen pflegen. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung und die Einrichtung und Wartung einer Firewall.

Verifizieren: Unter Werkzeuge > Website-Zustand erscheint bei den bestandenen Tests der Eintrag „Hintergrundaktualisierungen funktionieren“. Steht er bei den Problemen, nennt WordPress dort den Grund, zum Beispiel fehlende Schreibrechte oder eine gesetzte Sperrkonstante.

Typische Fehler

Fatal error „Undefined constant "minor"“ nach wp config set: Im Test führte wp config set WP_AUTO_UPDATE_CORE minor --raw zu der Zeile define( 'WP_AUTO_UPDATE_CORE', minor ); ohne Anführungszeichen. Jeder folgende Aufruf brach mit PHP Fatal error: Uncaught Error: Undefined constant "minor" ab, auch die Website selbst. Abhilfe: Zeile in wp-config.php per SFTP korrigieren oder löschen, dann ohne --raw neu setzen. --raw gehört nur zu true und false.

Keine automatischen Updates, obwohl alles freigegeben ist: Prüfen Sie wp-config.php auf AUTOMATIC_UPDATER_DISABLED und DISALLOW_FILE_MODS. Beide Konstanten schalten den Updater vollständig ab; im Test meldete WP_Automatic_Updater::is_disabled() in beiden Fällen true. DISALLOW_FILE_MODS setzen manche Hoster oder Sicherheitsanleitungen, um Plugin-Installationen im Backend zu verbieten, oft ohne zu erwähnen, dass damit auch Updates wegfallen.

Updater meldet eine Versionsverwaltung: Liegt im WordPress-Verzeichnis oder darüber ein Ordner .git, .svn, .hg oder .bzr, hält WordPress die Installation für versionsverwaltet und aktualisiert den Kern nicht automatisch. Entfernen Sie den Ordner nur, wenn die Website wirklich nicht per Git ausgeliefert wird.

Plugin-Schalter fehlt in der Übersicht: Ein Filter in einem Must-Use-Plugin oder im Code eines Hosters erzwingt den Wert. Suchen Sie in wp-content/mu-plugins nach auto_update_plugin.

Häufige Fragen

Soll ich alle Plugins automatisch aktualisieren lassen?

Für kleine Websites mit wenigen, verbreiteten Plugins ist das meist sicherer als manuelle Updates, die liegen bleiben. Ausnahmen sind Plugins mit Datenmigrationen, Shop- und Zahlungsfunktionen oder individuell angepasstem Code. Diese aktualisieren Sie gezielt, nach Backup und mit Kontrolle danach.

Was passiert, wenn ein automatisches Update die Website stört?

Bei schweren PHP-Fehlern stellt WordPress seit 6.6 die vorherige Plugin-Version selbst wieder her. Bei allen anderen Fehlern hilft nur das Backup oder die manuelle Rückkehr zur alten Version. Wie Sie den Fehler eingrenzen, zeigt die Anleitung WordPress-Debug-Modus aktivieren und Error-Logs auswerten.

Wie teste ich große Versionen, bevor sie live gehen?

Mit einer Kopie der Website in einer Staging-Umgebung. Dort spielen Sie das Update ein und prüfen die wichtigsten Abläufe. Eine Möglichkeit für eine eigene Testumgebung beschreibt die Anleitung WordPress auf dem Synology NAS als Staging-Umgebung.

Testumfang

Wir haben alles am 30.09.2026 in einer isolierten Testinstanz mit WordPress 7.1.2 durchgespielt. Geprüft haben wir die Update-Schalter und das Must-Use-Plugin mit beiden Filtern, dabei trat auch der beschriebene Fehler mit --raw auf.

Ein echtes automatisches Update und die Rücksicherung nach einem PHP-Fehler haben wir nicht ausgelöst, weil keine neuere Version vorlag. Testen Sie diese Fälle deshalb zuerst auf einer Kopie Ihrer Seite.

Fazit

Mit vier Werkzeugen steuern Sie automatische Updates vollständig: dem Backend für einzelne Entscheidungen, WP-CLI für schnelle und dokumentierbare Änderungen, WP_AUTO_UPDATE_CORE für eine verbindliche Kernregel und einem Must-Use-Plugin für feste Ausnahmen. Die sinnvolle Grundeinstellung für die meisten Unternehmensseiten: kleine Kernversionen immer automatisch, verbreitete Plugins automatisch, geschäftskritische Plugins und große Kernversionen gezielt nach Backup und Test. Ohne Backup und Kontrolle nach den Updates bleibt jede Automatik ein Risiko. Wenn Sie diese Kontrolle dauerhaft abgeben möchten, übernimmt die WordPress-Wartung von Marcel Schönfelder Updates und wöchentliche Backups für Ihre Website.

Weiterführende Anleitungen und Quellen

• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben
• Automatische Sicherheitsupdates unter Debian und Ubuntu mit unattended-upgrades (für den Server unter WordPress)
• WordPress-Dokumentation: Configuring Automatic Background Updates
• WordPress-Dokumentation: Plugins and Themes Auto-Updates
• WP-CLI-Handbuch: wp plugin auto-updates
• Entwicklerreferenz: Filter auto_update_{$type}
• Advanced Administration Handbook: Must-Use-Plugins