Digitalisierung

WordPress-Wartung & Betrieb: planbar statt Feuerwehr

1. Der unsichtbare Teil, der über alles entscheidet

Niemand bekommt einen Award für eine gewartete WordPress-Site. Wartung ist der unsichtbare Teil — und wird im Mittelstand zuerst gestrichen, wenn das Budget knapp wird. Bis zu dem Tag, an dem die Site nach einem Update weiß bleibt und niemand weiß, wie der Zustand von gestern zurückkommt.

Wir betreiben das selbst, nicht in der Theorie: Staging, ein Monitoring das uns vor dem Kunden warnt, automatisierte Backups die regelmäßig zurückgespielt werden — für eigene Sites und Kundenprojekte. Dieser Text ist die ehrliche Version dessen, was Betrieb wirklich heißt.

Er ist die operative Vertiefung zum WordPress Enterprise-Leitfaden. Drückt dich die Sicherheitsseite mehr, lies parallel WordPress Security — Betrieb und Sicherheit sind zwei Seiten derselben Medaille.


2. Die vier Säulen des Betriebs

Betrieb ist kein diffuses „sich kümmern". Es sind vier konkrete Säulen: Updates, Backups, Monitoring und Staging. Fehlt eine, tragen die anderen drei nicht.

Die vier Säulen — eine fehlt, alle wackeln Updates Core, Theme, Plugins aktuell schließt bekannte Lücken Backups getestet, nicht nur vorhanden der Notausgang, wenn alles brennt Monitoring Uptime, Speed, Zertifikate du weißt es, nicht der Chef Staging identische Kopie zum Testen kein Test mehr in Produktion Updates ohne Staging ist Roulette · Backups ohne Test ist Hoffnung Die Säulen wirken nur zusammen — einzeln sind sie ein falsches Sicherheitsgefühl Visualisierung: Medienstürmer

3. Updates: nicht ob, sondern wie

Die häufigste Frage im Mittelstand: „müssen wir wirklich jedes Plugin updaten?". Die ehrliche Antwort: Nicht jedes Update sofort — aber jedes sicherheitsrelevante zeitnah, und du musst wissen, welche das sind.

Der Reflex „lieber nicht anfassen, läuft ja" ist verständlich, aber falsch. Eine nicht aktualisierte Site ist nicht stabil, sie ist nur noch nicht aufgefallen. Veraltete Plugins sind die häufigste Einfallstür für automatisierte Angriffe — die Lücken sind öffentlich dokumentiert.

Der richtige Umgang ist „kontrolliert updaten": erst auf Staging einspielen, dort die Kernflows durchklicken (Startseite, Formular, Login, Checkout), und erst nach erfolgreichem Smoke-Test in Produktion übernehmen — mit frischem Backup davor. So wird aus dem Risiko eine umkehrbare Routine.

Wann NICHT sofort updaten: Bei großen Major-Versionen zentraler Plugins (Page-Builder, Shop, mehrsprachiges Setup) lohnt ein paar Tage Wartezeit, bis Folgefehler gemeldet und gefixt sind — aber nur, wenn es kein Sicherheitsupdate ist. Sicherheitsupdates haben keine Wartezeit.

4. Backups: das einzige, das im Ernstfall zählt

Hier liegt der gefährlichste blinde Fleck im Mittelstand. Fast jede Site hat „Backups". Fast keine hat einen jemals getesteten Restore. Im Ernstfall ist das der Unterschied.

Ein Backup besteht aus zwei Teilen, die beide vollständig sein müssen: die Dateien (Core, Theme, Plugins, Uploads) und die Datenbank (Inhalte, Einstellungen, Benutzer). Fehlt eines, ist es wertlos. Wir haben Fälle gesehen, in denen monatelang die Datenbank gesichert wurde, aber nicht das Upload-Verzeichnis — das fällt erst auf, wenn man wiederherstellen will und alle Bilder weg sind.

Die Regel, nach der wir arbeiten: Ein Backup, dessen Wiederherstellung nicht getestet wurde, existiert nicht. Wir spielen Restores planmäßig isoliert zurück und prüfen, ob die Site vollständig hochkommt. Das klingt nach Aufwand — bis zu dem Tag, an dem es der Unterschied zwischen „zwanzig Minuten Ausfall" und „drei Tage und ein verlorener Kunde" ist.

„Backup vorhanden" ist nicht „Backup funktioniert" Der Trugschluss „Wir haben ein Backup-Plugin" → nie zurückgespielt → DB gesichert, Uploads nicht → fällt erst im Ernstfall auf Die Praxis, die trägt Dateien + Datenbank vollständig extern gespeichert, versioniert automatisiert, täglich Restore planmäßig getestet Ein ungetestetes Backup ist kein Backup Es ist eine Hoffnung in Dateiform — und der Notfall ist der falsche Zeitpunkt, das zu merken Visualisierung: Medienstürmer

5. Monitoring: damit du es zuerst weißt

Der schlimmste Weg zu erfahren, dass die Website down ist, ist der Anruf vom Chef. Monitoring sorgt dafür, dass du es vor allen anderen weißt — und reagieren kannst, bevor es jemand merkt.

Sinnvolles Monitoring deckt mehr ab als „Seite antwortet". Es prüft die Erreichbarkeit aus mehreren Regionen, die Antwortzeit (langsame Seiten sind ein Frühwarnzeichen, kein Komfortthema), den Ablauf des SSL-Zertifikats (abgelaufen sperrt es Besucher mit einer Browser-Warnung aus — komplett vermeidbar) und idealerweise eine inhaltliche Prüfung: Zeigt die Seite nicht nur Status 200, sondern auch noch den erwarteten Inhalt? Eine gehackte oder leergelaufene Seite liefert oft brav einen 200er — und trotzdem Müll.

Wir fahren genau dieses Setup für die betreuten Sites. Der Wert liegt nicht im Dashboard, sondern in der Benachrichtigung im richtigen Moment.

6. Staging: die Versicherung, die du vorher abschließt

Staging ist eine vollständige, separate Kopie deiner Live-Site zum Testen, bevor echte Besucher die Änderung sehen. Es ist die Säule, die im Mittelstand am häufigsten fehlt — weil sie als „doppelter Aufwand" gilt. Tatsächlich ist sie das Gegenteil: die einzige Säule, die verhindert, dass die anderen drei dich im falschen Moment im Stich lassen.

Ohne Staging gibt es nur eine Umgebung — jeder Test läuft in Produktion, vor echten Kunden, mit echtem Umsatz im Risiko. Mit Staging wird jede riskante Operation — großes Update, Theme-Umbau, neues Plugin, PHP-Sprung — erst auf einer Kopie durchgespielt. Funktioniert es dort nicht, hat es niemand außer dir gesehen.

Wann Staging weniger kritisch ist: Bei einer sich nie ändernden Visitenkarten-Site ohne Formulare, Shop oder Redaktion ist der Aufwand schwer zu rechtfertigen. Sobald aber Inhalte oder Updates regelmäßig dazukommen — bei fast jeder geschäftsrelevanten Site der Fall — ist Staging keine Option, sondern Grundausstattung.

7. Selbst machen oder auslagern — die ehrliche Rechnung

Wir beantworten sie ohne Verkaufsinteresse: Vieles kannst du selbst machen. Updates auf Staging testen, Backups einrichten, Uptime-Monitoring aufsetzen — das ist erlernbar und für ein motiviertes internes Team machbar.

Der Punkt, an dem Auslagern günstiger wird, ist nicht technisch, sondern organisatorisch. Er ist erreicht, wenn (a) niemand intern klar verantwortlich ist und es deshalb faktisch nicht passiert, (b) die Person, die es kann, als Single Point of Failure in Urlaub oder krank ist, oder (c) die intern aufgewendete Zeit teurer ist als ein Wartungsvertrag und von wertvollerer Arbeit abgezogen wird.

Unsere ehrliche Empfehlung: Hast du ein internes Team, das es zuverlässig und dokumentiert macht — mach es selbst, behalte die Kontrolle. Ist „macht jemand mit" der Status, dann macht es niemand, und Auslagern ist nicht Bequemlichkeit, sondern Risikomanagement. Die Plattformfrage dahinter behandelt der Enterprise-Leitfaden; geht der Bedarf über ein CMS hinaus, lohnt der Leitfaden individuelle Softwareentwicklung.

8. Fazit

WordPress-Betrieb ist unsichtbar, bis er fehlt — dann ist er das Teuerste an der Website. Die vier Säulen wirken nur zusammen: Updates ohne Staging ist Roulette, Backups ohne getesteten Restore ist Hoffnung, Monitoring ohne Reaktion ist Dekoration.

Du musst nicht alles auslagern, aber eine ehrliche Entscheidung treffen: Gibt es einen benannten Verantwortlichen, der es zuverlässig und dokumentiert macht? Wenn ja — mach es selbst. Lautet die Antwort „macht jemand mit", macht es niemand — und das merkst du erst im Ernstfall.

9. Nächste Schritte

Du willst wissen, ob euer WordPress-Betrieb auf vier Säulen steht oder auf Hoffnung? Wir betreiben Staging, Monitoring und getestete Backups selbst, jeden Tag. Lass uns einen ehrlichen Blick auf euer Setup werfen — bevor der Ernstfall die Lücke zeigt.

10. Quellen