Ein automatisches Plugin-Update legte die Website in fünf Minuten lahm: Analyse und Sicherungen

Um 18:06 aktualisierte WordPress auf einer von uns betreuten Website selbst ein Plugin. Um 18:11 ließ sich die Website nicht mehr öffnen. Niemand hatte etwas angeklickt, niemand hatte die Verwaltung betreten, es gab keinen Einbruch und keine Hosting-Störung. Das System tat einfach, wofür es Jahre zuvor eingerichtet worden war — und tat es fehlerfrei.

Diese Analyse handelt davon, warum ein automatisches Update, das die Website schützen soll, sie manchmal lahmlegt, und was zu tun ist, damit Ihnen das nicht passiert. Ohne Theorie: Alles Folgende ist die Chronologie eines Abends und des Morgens danach.

Chronologie: fünf Minuten vom Update zur toten Website

18:06. WordPress startet das planmäßige automatische Update des Plugins Elementor — des Baukastens, mit dem alle Seiten der Website gebaut sind. Auf der Website lief Version 3.6.5 aus dem Jahr 2022. Das Update installiert gleich 4.3.5 und überspringt damit mehrere Jahre an Änderungen.

18:11. Die Startseite liefert einen Fehler. Besucher sehen einen weißen Bildschirm statt der Website. Die Redaktion in der Verwaltung kann eine Seite weder öffnen noch speichern.

18:14. In der Arbeitsgruppe landet eine Nachricht: „Die Seite speichert nicht“. Dass die ganze Website liegt, weiß noch niemand.

19:25. Die Website läuft. Zwischen diesen beiden Punkten liegt eine Stunde Analyse — und genau die ist interessant.

Warum es passierte: drei Ursachen, die zusammenfielen

1. Eine Plugin-Version aus 2022

Das Auto-Update hatte dieses Plugin vier Jahre nicht angerührt — und dann griff es zu. Warum genau an diesem Abend, ist unwichtig; wichtig ist, dass der Sprung von Version 3.6 auf 4.3 kein „Flicken“ ist, sondern ein Generationswechsel. Die Entwicklung hat in dieser Zeit einen Teil des alten Codes entfernt, den sie für veraltet hielt. Das ist übliche Praxis — aber nur für die, die regelmäßig aktualisieren und die Warnungen unterwegs bemerken.

2. Das Theme stützte sich auf denselben alten Code

Das Theme ist ebenfalls von 2022 und wurde ebenfalls nie aktualisiert. In acht seiner Blöcke kamen Funktionen vor, die im neuen Elementor verschwunden sind. Das Theme ruft eine Funktion auf, die Funktion ist nicht da, PHP hält die Ausführung an. Für Besucher sieht das wie eine leere Seite mit Fehler aus.

3. Ein Nachbarplugin verlor seine Einstellungen

Auf der Website lief noch ein Plugin, das die Standardadressen von WordPress vor Robots und Scannern verbirgt. Beim Update verlor es die Regel zum Umschreiben der Adressen genau für die Dateien von Elementor. So konnte die Redaktion selbst dort, wo das Theme nicht brach, die eigenen Dateien nicht laden: Der Server antwortete „nicht gefunden“.

Ein Auto-Update weiß nicht, dass Ihr Theme von 2022 ist, dass daneben ein Plugin Adressen abfängt und dass auf dieser Website vier Jahre niemand aktualisiert hat. Es weiß nur eines: Es gibt eine neue Version, und die soll installiert werden.

Wie behoben wurde

• Das Plugin auf 3.6.5 zurückgesetzt — die Version, die morgens lief. Die neue wurde nicht gelöscht, sondern beiseitegelegt: Der Rückweg dauert eine Minute, sobald das Theme bereit ist.
• Die verlorene Regel wiederhergestellt im Plugin, das die Adressen verbirgt.
• Das automatische Update genau für Elementor abgeschaltet. Sonst hätte sich nachts alles wiederholt — WordPress erinnert sich nicht daran, dass es letztes Mal schlimmer wurde.
• Startseite und Unterseiten geprüft — sie öffnen sich, keine Fehler, die Gestaltung sitzt.

Und der Inhaberschaft haben wir gesondert offen gesagt: Version 3.6.5 ist vier Jahre alt und sollte nicht lange bleiben. In alten Versionen werden mit der Zeit Schwachstellen gefunden, und dann wird gerade das Nicht-Aktualisieren gefährlich. Die neueste mit diesem Theme verträgliche Version ist 3.25. Aber auch das Theme ist von 2022: Früher oder später stößt es wieder an dieselbe Grenze. Der richtige Weg ist eine Kopie der Website, auf der das Update in Ruhe geprüft wird, ohne Risiko für die laufende.

Ein zweites Warnsignal am nächsten Morgen

Um 9:49 eine neue Nachricht: „Fehler 503“ beim Speichern einer Seite. Auf den ersten Blick die Fortsetzung des Vorabends. Tatsächlich eine andere Geschichte, und ebenfalls eine lehrreiche.

Der Server verweigerte nichts. Beim Speichern starb der PHP-Prozess selbst, und der Browser zeigte das als 503. Die Seite erwies sich als sehr schwer: 226 Blöcke, davon 111 Bilder. Die PHP-Grenzen der Website standen dagegen auf dem Minimum ab Werk des Hosters: 128 MB Speicher und 30 Sekunden pro Anfrage. Der Baukasten braucht für ordentliches Arbeiten mindestens 256 MB und 300 Sekunden. Die Website lief jahrelang an der Grenze — und auf der schwersten Seite war diese Grenze erreicht.

Wir erhöhten die Grenzen und starteten PHP neu — es half nicht. Das Protokoll zeigte: Speicher und Zeit haben damit nichts zu tun, der Prozess stirbt am Speichern selbst. Die Ursache war eine der Beschleunigungseinstellungen von PHP, ein bekanntes Problem in dieser Version. Abgeschaltet — und es lief.

Die Lehre ist einfach: Eine Störung hat selten eine einzige Ursache. Das Update vom Vortag hat hier nichts damit zu tun, aber eine Website, die jahrelang an minimalen Grenzen lebt, bricht früher oder später an etwas anderem.

Was Betreibende tun sollten

1. Finden Sie heraus, was sich bei Ihnen selbst aktualisiert. In der WordPress-Verwaltung: „Plugins“ → Spalte „Automatische Updates“. Dasselbe für Themes. Kennen Sie die Antwort nicht, ist das schon das erste Problem.
2. Trennen Sie Updates in „Sicherheit“ und „groß“. Kleine Korrekturen innerhalb einer Version (3.25.10 → 3.25.11) können automatisch bleiben. Der Wechsel zwischen großen Versionen (3 → 4) nur von Hand und nur nach einer Prüfung.
3. Prüfen Sie große Updates auf einer Kopie. Hoster bieten meist mit einem Klick eine Testkopie der Website. Dort aktualisieren, nachsehen, dass nichts abgefallen ist — dann die laufende aktualisieren.
4. Legen Sie vor jedem Update eine Kopie an. Nicht „eine Sicherung liegt beim Hoster“, sondern eine Kopie, von der Sie selbst wissen, wie Sie in zehn Minuten zurückkehren.
5. Behalten Sie keine vier Jahre alten Versionen. Je länger Sie nicht aktualisieren, desto schmerzhafter wird der Sprung und desto mehr Schwachstellen sammeln sich. Ein planmäßiges Update einmal im Monat ist billiger als eine Nacht ohne Website.
6. Haben Sie jemanden, der es in fünf Minuten merkt. Die Website lag ab 18:11, die Nachricht kam um 18:14 — und sie betraf die Redaktion, nicht die Website. Ohne Überwachung erfährt die Inhaberschaft von der toten Website durch Kundschaft, die nicht bestellen konnte.

Das Paradox: nicht zu aktualisieren ist auch gefährlich

Es könnte scheinen, der Schluss lautet: „Automatische Updates abschalten und in Ruhe leben“. Nein. Kürzlich haben wir über die kritischen PHP-Schwachstellen geschrieben, wo der einzige Schutz genau ein Update ist und Aufschub nicht infrage kommt. Dort kostet Zögern einen übernommenen Server. Hier kostete Eile einen Abend ohne Website.

Der Unterschied liegt in einem Punkt: Sicherheitsupdates gehören schnell und vollständig eingespielt, funktionale bewusst und nach einer Prüfung. Diesen Unterschied sieht ein Auto-Update nicht. Sehen muss ihn ein Mensch.

---

Nicht sicher, was sich bei Ihnen selbst aktualisiert und was nach dem nächsten Update passiert? Schreiben Sie uns — wir sehen uns Ihre Website an und sagen Ihnen offen, wo sie an der Grenze läuft.