--- title: "Automatische Updates in WordPress steuern: Kern, Plugins und Themes gezielt festlegen" date: 2026-09-30T20:59:18+02:00 modified: 2026-11-08T22:35:39+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-automatische-updates-steuern-core-plugins-themes keywords: - WordPress - Updates - WP-CLI - wp-config - Sicherheit reading_time: 10 --- # 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. **Kurzfassung:** Kleinere Kernversionen (Wartungs- und Sicherheitsaktualisierungen) sollten immer automatisch laufen, große Versionssprünge nur, wenn Sie ein aktuelles Backup und eine Kontrolle danach haben. Plugins und Themes schalten Sie einzeln unter „Plugins“ bzw. „Design“ oder per `wp plugin auto-updates enable` frei. Die Konstante `WP_AUTO_UPDATE_CORE` in wp-config.php mit dem Wert `'minor'` begrenzt den Kern auf kleine Versionen und sperrt die Umschaltung im Backend. Feste Regeln für einzelne Plugins setzen Sie mit dem Filter `auto_update_plugin` in einem Must-Use-Plugin. `AUTOMATIC_UPDATER_DISABLED` schaltet alles ab und ist für normale Unternehmenswebsites die falsche Wahl. ## Voraussetzungen - [ ] WordPress ab Version 5.6 (die Plugin- und Theme-Schalter gibt es seit 5.5, die Kernschalter im Backend seit 5.6) - [ ] PHP in einer von WordPress unterstützten Version - [ ] 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 Ö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. > **Prüfen:** Auf **Dashboard > Aktualisierungen** steht der Satz, der Ihrer Entscheidung entspricht. Per WP-CLI zeigt `wp option get auto_update_core_major` den gespeicherten Wert, nach dem Umschalten zum Beispiel `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 erledigen das: ```bash # Status aller Plugins anzeigen ``` ```bash $ wp plugin auto-updates status --all ``` ```bash # Einzelnes Plugin freigeben ``` ```bash $ wp plugin auto-updates enable akismet ``` ```bash # Alle Themes freigeben ``` ```bash $ wp theme auto-updates enable --all ``` ```bash # Alle aktuell freigegebenen Plugins wieder sperren ``` ```bash $ wp plugin auto-updates disable --all --enabled-only ``` Die Ausgabe lautet zum Beispiel `Success: Enabled 1 of 1 plugin auto-updates.` und nach dem Sperren `Success: Disabled 1 of 1 plugin auto-updates.` > **Prüfen:** `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: | Wert | Wirkung | Update auf 7.1.3 / 7.2 | | --- | --- | --- | | `'minor'` | nur kleine Versionen automatisch | ja / nein | | `true` | kleine und große Versionen automatisch | ja / ja | | `false` | keine Kern-Updates automatisch | nein / nein | Die rechte Spalte zeigt das Ergebnis von `Core_Upgrader::should_update_to_version()` 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: ```php define( 'WP_AUTO_UPDATE_CORE', 'minor' ); ``` Oder per WP-CLI, dann ohne Anführungszeichen und ohne `--raw`: ```bash $ 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. > **Prüfen:** `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 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`: Datei: `update-regeln.php` ```php 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: ```bash php -l wp-content/mu-plugins/update-regeln.php ``` Bei fehlerfreiem Code meldet 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. Den Filter selbst prüfen Sie so: ```bash $ wp eval '$i = (object) array( "slug" => "akismet" ); var_dump( apply_filters( "auto_update_plugin", false, $i ) );' ``` > **Prüfen:** `wp plugin list --status=must-use` führt `update-regeln` mit Status `must-use`, und der Filtertest gibt `bool(true)` aus, obwohl der Ausgangswert `false` war. Die Gegenprobe mit `hello-dolly` ergibt `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; in der Liste stehen die Ereignisse `wp_version_check`, `wp_update_plugins` und `wp_update_themes` jeweils mit dem Intervall „12 hours“. 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](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten). ```bash $ 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**. Update-Steuerung ist laufende Pflege: Backups kontrollieren, Benachrichtigungen auswerten, große Versionen testen, Ausnahmen pflegen. Wer diese Aufgaben abgeben möchte: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=2) ü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. > **Prüfen:** 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:** Der Befehl `wp config set WP_AUTO_UPDATE_CORE minor --raw` führt zu der Zeile `define( 'WP_AUTO_UPDATE_CORE', minor );` ohne Anführungszeichen. Jeder folgende Aufruf bricht 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; `WP_Automatic_Updater::is_disabled()` meldet 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](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben). ### 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](https://s-edv.com/anleitungen/wordpress-synology-docker-eigene-website). ## 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. Wenn Sie diese Kontrolle dauerhaft abgeben möchten, übernimmt die [WordPress-Wartung](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=2) 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](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [Automatische Sicherheitsupdates unter Debian und Ubuntu mit unattended-upgrades](https://s-edv.com/anleitungen/unattended-upgrades-automatische-sicherheitsupdates-debian-ubuntu) (für den Server unter WordPress) - [WordPress-Dokumentation: Configuring Automatic Background Updates](https://wordpress.org/documentation/article/configuring-automatic-background-updates/) - [WordPress-Dokumentation: Plugins and Themes Auto-Updates](https://wordpress.org/documentation/article/plugins-themes-auto-updates/) - [WP-CLI-Handbuch: wp plugin auto-updates](https://developer.wordpress.org/cli/commands/plugin/auto-updates/) - [Entwicklerreferenz: Filter auto_update_{$type}](https://developer.wordpress.org/reference/hooks/auto_update_type/) - [Advanced Administration Handbook: Must-Use-Plugins](https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/)