Ein WordPress-Wartungsvertrag soll Risiken begrenzen, Zuständigkeiten klären und dafür sorgen, dass im Fehlerfall nicht erst diskutiert wird, wer eigentlich handeln muss. Er ist kein Sicherheitsversprechen und auch keine Flatrate für beliebige Weiterentwicklung.
Genau an dieser Stelle werden Angebote oft unscharf. „Updates, Backups und Support“ klingt vollständig, sagt aber noch nichts darüber aus, wie Updates geprüft werden, ob sich ein Backup wirklich wiederherstellen lässt und wann jemand auf einen Ausfall reagiert. Ein belastbarer Vertrag macht diese Punkte messbar.
Was ein WordPress-Wartungsvertrag wirklich absichert
WordPress besteht nicht nur aus dem Core. Theme, Plugins, PHP-Version, Hosting, Formulare, externe Schnittstellen und DNS-Einstellungen greifen ineinander. Fällt ein Teil aus, kann die Website weiterhin erreichbar wirken und trotzdem keine Anfrage, Bestellung oder Bewerbung mehr verarbeiten.
Ein Wartungsvertrag reduziert dieses Betriebsrisiko. Er schafft eine Routine für Updates, Prüfungen und Backups. Außerdem legt er fest, welche Reaktion bei einer Störung vereinbart ist. Die offizielle WordPress-Dokumentation beschreibt Sicherheit ausdrücklich als Risikoreduktion, nicht als vollständige Beseitigung jedes Risikos. Genau so sollte auch ein Vertrag formuliert sein.
Wichtig ist die Grenze zwischen drei Rollen:
- Der Hoster verantwortet seine Server- und Netzwerkebene im vereinbarten Umfang.
- Der Wartungsdienstleister betreut die WordPress-Anwendung und die vereinbarten Funktionen.
- Ihr bleibt für Inhalte, Benutzerfreigaben, rechtliche Texte und interne Prozesse verantwortlich, sofern der Vertrag nichts anderes regelt.
Wer diese Rollen einfach mit „Wir kümmern uns“ zusammenfasst, verschiebt die Diskussion nur in den ersten Ernstfall.
Pflichtleistungen und optionale Leistungen
Nicht jede Website braucht denselben Umfang. Eine kleine Informationsseite ohne Formulare hat ein anderes Risiko als ein Shop mit Zahlungen, Warenwirtschaft und mehreren hundert Bestellungen am Tag. Trotzdem gibt es eine Basis, die in einem professionellen WordPress-Wartungsvertrag nicht fehlen sollte.
| Bereich | Gehört in die Basis | Je nach Risiko zusätzlich |
|---|---|---|
| Updates | WordPress, Plugins und Theme; dokumentierter Rhythmus | Staging-Test, definierte Wartungsfenster, Kompatibilitätsprüfung |
| Backups | Dateien und Datenbank; getrennte Aufbewahrung | häufigere Intervalle, längere Historie, regelmäßiger Restore-Test |
| Sicherheit | Benutzer- und Plugin-Prüfung, HTTPS, bekannte Auffälligkeiten | Malware-Scan, Dateiintegrität, WAF-Auswertung, Incident-Prozess |
| Monitoring | externe Erreichbarkeit und Alarmweg | Inhalts-, Formular-, Checkout- und Schnittstellenchecks |
| Support | Kontaktweg, Reaktionszeit und Leistungsgrenze | Rufbereitschaft, priorisierte Eskalation, feste Stundenkontingente |
| Reporting | ausgeführte Arbeiten und offene Risiken | Management-Zusammenfassung, Trend- und Performance-Auswertung |
Ein reiner Uptime-Check reicht nicht. Ein Server kann einen Statuscode 200 liefern, obwohl das Kontaktformular keine Mail verschickt. Deshalb trennen wir Website-Monitoring von echten Funktionsprüfungen.
Auch bei Backups zählt nicht nur die Anzahl. Ein Backup ist erst belastbar, wenn Speicherort, Aufbewahrung und Wiederherstellung geklärt sind. Wie diese Prüfung aussieht, erklären wir im Beitrag über getestete WordPress-Backups.
SLA: Reaktionszeit, Wiederherstellungsziel und Erreichbarkeit
SLA steht für Service Level Agreement. Dahinter sollten konkrete Zeiten und Bedingungen stehen, keine Formulierungen wie „schnellstmöglich“ oder „in der Regel zeitnah“.
Vier Werte sind besonders wichtig:
- Servicezeit: In welchem Zeitfenster werden Meldungen bearbeitet?
- Reaktionszeit: Wann bestätigt jemand den Eingang und beginnt mit der Einordnung?
- Wiederherstellungsziel: Wie schnell soll ein kritischer Dienst im realistischen Rahmen wieder laufen?
- Datenverlustfenster: Wie viele Daten könnten aufgrund des Backup-Intervalls maximal fehlen?
Ein Beispiel: Für eine normale Unternehmenswebsite kann eine Reaktion am nächsten Werktag ausreichen. Bei einem Shop kann derselbe Zeitraum mehrere Stunden verlorenen Umsatz bedeuten. Dort braucht es kürzere Alarmwege, aktuellere Backups und definierte Testkäufe.
Die Reaktionszeit ist nicht automatisch die Lösungszeit. Wenn eine externe Zahlungsplattform gestört ist, kann der Dienstleister prüfen, dokumentieren und eskalieren. Er kann aber nicht versprechen, den fremden Dienst innerhalb einer eigenen Frist zu reparieren. Ein guter Vertrag trennt beeinflussbare Aufgaben von Abhängigkeiten.
Preismodelle und realistische Kostenfaktoren
Ein Wartungsvertrag wird meist als monatliche Pauschale, Stundenkontingent oder Kombination aus Grundpaket und Zusatzaufwand angeboten. Prozentmodelle oder unbegrenzte Flatrates passen selten, weil das technische Risiko nicht linear mit der Seitenzahl wächst.
Für die Budgetplanung ist eine Zahl ohne definiertes Leistungsversprechen wenig hilfreich. Lasst euch stattdessen zeigen, welches Betriebsprofil das Angebot tatsächlich abdeckt:
- Einfache WordPress-Website: Updates, Backups und grundlegendes Monitoring für einen überschaubaren, wenig veränderten Webauftritt.
- Geschäftskritische Unternehmenswebsite: zusätzliche Funktionschecks, Reporting, feste Alarmwege und vereinbarte Reaktionszeiten.
- WooCommerce oder komplexe Schnittstellen: engere Überwachung, Testbestellungen, abgestimmte Wiederherstellung und Prüfungen der angebundenen Systeme.
Entscheidend sind nicht nur Plugin-Anzahl oder Besucher. Die größten Kostentreiber sind:
- Anzahl und Kritikalität der Funktionen;
- notwendige Reaktions- und Servicezeiten;
- Testaufwand nach Updates;
- Häufigkeit und Aufbewahrung der Backups;
- Staging- und Deployment-Prozess;
- individuelle Schnittstellen und Eigenentwicklungen;
- Umfang von Support, Redaktion und Weiterentwicklung.
Ein bewusst reduzierter Vertrag kann für eine einfache Seite völlig ausreichend sein. Er ist nur dann problematisch, wenn er den Eindruck eines umfassenden Schutzes vermittelt, tatsächlich aber lediglich automatische Updates aktiviert.
Sieben Fragen vor der Unterschrift
1. Was wird nach einem Update geprüft?
„Update erfolgreich“ bedeutet nur, dass der technische Vorgang beendet wurde. Fragt nach Formularen, Navigation, Login, Suche, Tracking und – bei Shops – Warenkorb, Zahlung und Transaktionsmails.
2. Gibt es eine Staging-Umgebung?
Für kritische Websites sollten größere Updates außerhalb der Live-Seite getestet werden. Die Umgebung muss technisch nah genug an der Produktion liegen, sonst prüft ihr ein anderes System.
3. Wie oft wird eine Wiederherstellung getestet?
Eine Restore-Probe muss nicht jeden Monat stattfinden. Sie sollte aber regelmäßig, nach größeren Änderungen und bei einem Wechsel des Backup-Systems durchgeführt werden.
4. Was löst einen Alarm aus?
Erreichbarkeit, PHP-Fehler, fehlgeschlagene Jobs, Sicherheitsfunde und Funktionsfehler sind unterschiedliche Signale. Klärt, welche davon überwacht werden und wer die Meldung erhält.
5. Welche Reaktionszeit gilt für welche Priorität?
Ein Tippfehler ist kein Notfall. Ein ausgefallener Checkout schon. Ohne Prioritätsklassen wird jede Meldung entweder unnötig dringend oder gefährlich langsam.
6. Was ist ausdrücklich ausgeschlossen?
Typische Ausschlüsse sind neue Funktionen, Redesign, Rechtsprüfung, fremde Konten, Altlasten vor Vertragsbeginn und Störungen externer Anbieter. Ausschlüsse sind nicht unseriös – versteckte Ausschlüsse schon.
7. Wie endet oder wechselt die Betreuung?
Zugänge, Lizenzen, Backups, Dokumentation und Eigentum an individuellem Code müssen bei einer Übergabe verfügbar bleiben. Ein Vertrag darf euch nicht technisch einsperren.
Wann ein Vertrag nicht lohnt
Eine statische, selten genutzte Testseite ohne personenbezogene Daten oder geschäftskritische Funktion braucht möglicherweise keine laufende Agenturbetreuung. Auch intern kann Wartung sinnvoll organisiert werden, wenn Wissen, Zeit, Vertretung und ein dokumentierter Prozess vorhanden sind.
Nicht sinnvoll ist ein Vertrag, wenn niemand die enthaltenen Reports liest, bekannte Altlasten dauerhaft ausgeklammert werden oder der Anbieter weder Zugänge noch Verantwortungsgrenzen dokumentiert. Dann bezahlt ihr Routine, ohne das eigentliche Risiko zu lösen.
Für alle anderen Fälle ist regelmäßige WordPress-Wartung vor allem eine Frage der Betriebsorganisation: Wer prüft was, wann und mit welchem Rückweg?
Häufige Fragen zum WordPress-Wartungsvertrag
Wer haftet bei einem Ausfall?
Das hängt vom konkreten Vertrag, der Ursache und den vereinbarten Pflichten ab. Ein Wartungsvertrag kann Sorgfalts-, Reaktions- und Dokumentationspflichten festlegen, aber keine vollständige Ausfallsicherheit garantieren. Haftungsfragen gehören bei kritischen Systemen in eine rechtliche Vertragsprüfung.
Sind Plugin-Lizenzen im Vertrag enthalten?
Manchmal. Der Vertrag sollte jede enthaltene Lizenz benennen und erklären, was bei einer Kündigung passiert. Idealerweise bleibt klar, welche Lizenzen euch gehören und welche nur während der Betreuung bereitgestellt werden.
Wie oft sollte WordPress gewartet werden?
Kontrolle und Monitoring laufen sinnvollerweise kontinuierlich. Update-Zyklen richten sich nach Sicherheitsrelevanz, Kompatibilität und Risiko. Kritische Sicherheitsupdates warten nicht auf einen starren Monatstermin.
Braucht jede Website eine Staging-Umgebung?
Nein. Für kleine Seiten kann ein belastbares Backup mit direkter Funktionsprüfung genügen. Bei Shops, Schnittstellen oder stark angepassten Websites ist ein Staging-Prozess deutlich wichtiger.
Was passiert beim Wechsel des Wartungsdienstleisters?
Zugänge, Backups, Dokumentation, Lizenzübersicht und offene technische Risiken müssen geordnet übergeben werden. Klärt außerdem, welche Agenturlizenzen nach dem Wechsel wegfallen und wer laufende Monitoring- oder Backup-Dienste übernimmt.
Nein. Für kleine Seiten kann ein belastbares Backup mit direkter Funktionsprüfung genügen. Bei Shops, Schnittstellen oder stark angepassten Websites ist ein Staging-Prozess deutlich wichtiger.
Unsere Checkliste für euren Vertrag
Vor der Freigabe sollten mindestens diese Punkte schriftlich beantwortet sein:
- Systeme und Funktionen im Leistungsumfang;
- Update- und Testprozess;
- Backup-Intervall, Aufbewahrung und Restore-Probe;
- Monitoring und Alarmwege;
- Servicezeit, Prioritäten und Reaktionszeiten;
- enthaltene Supportzeit und Abrechnung von Mehrarbeit;
- Zuständigkeiten bei Hoster, Drittanbietern und internen Teams;
- Dokumentation, Zugänge, Lizenzen und Übergabe;
- Ausschlüsse, Laufzeit und Kündigung.
Die technische Grundlage dazu liefert die WordPress-Hardening-Dokumentation. Sie ersetzt keinen Vertrag, zeigt aber, warum Updates allein zu kurz greifen.
Wenn ihr euren bestehenden Umfang einordnen oder ein Wartungsangebot vergleichbar machen wollt, schauen wir uns Website, Funktionen und tatsächliches Risiko an. Unsere WordPress-Wartung und unser Service beginnen deshalb mit einem technischen Check – nicht mit einem Paketnamen.
