Zum Inhalt springen
findflix live•7 Tage Pro gratis testen•Keine Kreditkarte nötig
Neues Projekt gesucht?Los geht's
Blog Tools & Updates

Website-Sicherheit für Kundenprojekte: SSL, Updates, Backups

Von findflix · 25. August 2026 · 6 Min. Lesezeit
Website-Sicherheit für Kundenprojekte: SSL, Updates, Backups

Websites werden selten gehackt, weil Angreifer brillant sind. Gehackt werden sie, weil nach dem Launch niemand mehr zuständig ist. Das ist die These dieses Artikels, und die Daten stützen sie: Angriffe auf WordPress-Sites laufen automatisiert, rund um die Uhr, gegen jede Domain, egal wie klein. Wer ein Kundenprojekt übergibt und danach nie wieder anfasst, übergibt eine tickende Uhr.

Die gute Nachricht: Sicherheit für typische KMU-Projekte ist kein Hexenwerk, sondern Routine. Hier kommt der Stand 2026 in Zahlen, die Bausteine, die wirklich zählen, und ein Fahrplan für den Fall, dass es doch passiert. Die Zahlen unten sind WordPress-lastig, weil dort die beste Datenlage existiert; die Prinzipien gelten für jedes CMS.

Die Lage in Zahlen: Plugins sind das Einfallstor

Patchstack dokumentiert im Report „State of WordPress Security 2026″ für das Jahr 2025 insgesamt 11.334 neu entdeckte Sicherheitslücken im WordPress-Ökosystem, 42 Prozent mehr als im Vorjahr. Die Verteilung ist eindeutig: 91 Prozent der Lücken steckten in Plugins, 9 Prozent in Themes. Im WordPress-Core selbst wurden ganze 6 Lücken gemeldet, alle als niedrig eingestuft.

Plugins91 %
Themes9 %
WordPress-Core (6 Lücken)0.05 %
Neue WordPress-Sicherheitslücken 2025 nach Komponente · Quelle: Patchstack, State of WordPress Security 2026 (Datenjahr 2025)

Zwei weitere Zahlen aus dem Report gehören in jedes Kundengespräch: 46 Prozent der Lücken hatten zum Zeitpunkt der Veröffentlichung noch keinen Patch, und bei stark angegriffenen Lücken lag die mediane Zeit bis zum ersten Exploit-Versuch bei 5 Stunden. Rund die Hälfte der schweren Lücken wird binnen 24 Stunden aktiv ausgenutzt. „Wir schauen einmal im Quartal nach Updates“ ist gegen diese Taktung keine Strategie.

SSL ist Pflicht, aber kein Schutzschild

HTTPS ist die Basis-Hygiene jedes Projekts: Es verschlüsselt die Verbindung, verhindert Browser-Warnungen und ist längst Standard. Nur schützt es die Übertragung, nicht die Website. Eine Site mit gültigem Zertifikat kann trotzdem verwundbare Plugins, schwache Passwörter und Malware haben. Das Schloss-Symbol heißt „Verbindung verschlüsselt“, nicht „Anbieter vertrauenswürdig“, und genau dieses Missverständnis solltest du im Kundengespräch aktiv ausräumen.

Praktisch heißt das: Zertifikat automatisch verlängern lassen, alle Domain-Varianten sauber auf HTTPS umleiten und nach Relaunches auf Mixed Content prüfen. Damit ist SSL erledigt, und die eigentliche Arbeit beginnt.

Updates sind das eigentliche Sicherheits-Feature

Wenn 91 Prozent der Lücken in Plugins stecken, ist Plugin-Hygiene der wirksamste Schutz. Das beginnt vor der Installation: so wenige Plugins wie möglich, und nur solche, die aktiv gepflegt werden. Letzte Aktualisierung, aktive Installationen und die Reaktionszeit des Entwicklers im Support-Forum sind in fünf Minuten geprüft und sagen mehr als jede Sternebewertung.

Im Betrieb gilt: Sicherheitsupdates zeitnah einspielen, nicht im Quartalsrhythmus. Für unkritische Komponenten sind automatische Updates sinnvoll, bei geschäftskritischen Sites mit Shop oder Buchung testest du besser kurz auf einer Staging-Kopie. Und weil fast die Hälfte der veröffentlichten Lücken zunächst ohne Patch bleibt: Ein Plugin, dessen Entwickler nicht mehr reagiert, wird nicht beobachtet, sondern ersetzt oder entfernt.

Backups: ohne Restore-Test nur ein Gefühl

Ein Backup, das du noch nie zurückgespielt hast, ist keine Sicherung. Es ist eine Hoffnung mit Zeitstempel.

Ein brauchbares Backup-Konzept beantwortet vier Fragen. Was: immer Datenbank und Dateien zusammen. Wohin: an einen zweiten Ort, nicht auf denselben Server, dessen Ausfall du absichern willst. Wie oft: so oft, wie sich die Site ändert, bei Shops täglich, bei Broschüren-Sites reicht wöchentlich. Verlass dich dabei nicht allein auf das Backup des Hosters: Es liegt oft auf derselben Infrastruktur und ist im Ernstfall genauso betroffen wie die Site selbst. Wie lange: mehrere Wochen aufbewahren, denn Malware wird oft erst spät entdeckt, und dann brauchst du einen Stand von vor der Infektion.

Und dann der Teil, der aus einem Gefühl eine Sicherung macht: der Restore-Test. Spiele ein Backup zweimal im Jahr testweise auf einer Subdomain oder lokal ein, stoppe die Zeit und dokumentiere die Schritte. Im Ernstfall entscheidet nicht, ob ein Backup existiert, sondern ob du es unter Stress in einer Stunde wiederherstellen kannst.

Logins härten: 2FA und Aufräumen

Neben veralteter Software sind gestohlene und schwache Zugangsdaten der zweite große Angriffsweg, und dagegen hilft Aufräumen. Zwei-Faktor-Authentifizierung für alle Admin-Konten ist die einzelne Maßnahme mit dem besten Verhältnis von Aufwand zu Nutzen. Dazu: individuelle Konten statt eines geteilten admin-Logins, Rollen nach Bedarf (die Redakteurin des Kunden braucht keine Admin-Rechte), Login-Versuche begrenzen und ein Passwort-Manager statt wiederverwendeter Passwörter.

Vergiss die Nebeneingänge nicht: Hosting-Panel, SFTP und Datenbank haben eigene Zugänge, die bei Personalwechseln rotiert werden müssen. Wo es das Setup erlaubt, lohnt sich zusätzlich ein Blick auf ungenutzte Einfallstore wie XML-RPC oder eine offen gelassene Nutzer-Registrierung. Und wenn du ein Projekt von einer früheren Agentur übernimmst, ist das Löschen alter Konten Teil der Übergabe, nicht optional.

Wenn es doch passiert: der Notfall-Fahrplan

Gehackt wird auch mit guter Pflege, nur deutlich seltener. Entscheidend ist dann, dass du einen Plan hast statt Panik.

  1. Zugriff sichern. Alle Passwörter ändern (WordPress, Hosting, Datenbank, SFTP), aktive Sessions beenden, die Site notfalls in den Wartungsmodus nehmen.
  2. Befund erheben. Malware-Scan laufen lassen, Logs sichern, prüfen, was verändert wurde: neue Admin-Konten, geänderte Dateien, fremde Weiterleitungen.
  3. Sauberen Stand herstellen. Backup von vor der Infektion einspielen oder professionell bereinigen lassen, danach alle Passwörter erneut ändern.
  4. Einfallstor schließen. Die verwundbare Komponente identifizieren und aktualisieren oder entfernen, sonst steht der Angreifer nächste Woche wieder drin.
  5. Kunden informieren. Transparent sagen, was passiert ist und was du getan hast. Das ist unangenehm und trotzdem Teil deines Jobs als Profi.
  6. Nachsorgen. Google Safe Browsing und Blacklists prüfen, Monitoring einrichten, den Vorfall dokumentieren und die Wartungsroutine anpassen.

Sobald personenbezogene Daten betroffen sein könnten, etwa Formulareinsendungen oder Kundenkonten, ist die DSGVO im Spiel: Nach Art. 33 DSGVO muss der Verantwortliche, also in der Regel dein Kunde, die Verletzung unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Bei hohem Risiko sind zusätzlich die Betroffenen selbst zu benachrichtigen. Du lieferst als Dienstleister die technischen Fakten und die Dokumentation, ob und wie gemeldet wird, klärt der Kunde mit Datenschutzbeauftragtem oder Anwalt. Das hier ist Orientierung, keine Rechtsberatung.

Aus Sicherheit ein Geschäftsmodell machen

Alles oben kostet Zeit, und genau deshalb gehört es bepreist. Verkaufe Sicherheit nicht als Angstpaket, sondern als Betrieb: monatliche Wartung mit Updates, Backup-Kontrolle, Monitoring und einem kurzen Bericht. Mit den Zahlen aus diesem Artikel argumentierst du sachlich statt dramatisch, 11.334 neue Lücken im Jahr und 5 Stunden bis zum ersten Exploit reichen völlig ohne Schreckensszenario.

Monatsroutine für jedes Kundenprojekt

  • Core-, Plugin- und Theme-Updates einspielen, kritische sofort
  • Backup-Lauf kontrollieren, halbjährlich Restore testen
  • Malware- und Blacklist-Status prüfen
  • Formulare einmal selbst absenden
  • Benutzerkonten und Rollen durchsehen, verwaiste löschen
  • Zwei Zeilen Bericht an den Kunden schicken, sichtbare Arbeit wird verlängert

Für dich ist Wartung zudem planbarer Umsatz, der Lücken zwischen Projekten glättet, und der natürlichste Einstieg in langfristige Kundenbeziehungen. Wie du systematisch an Betriebe kommst, deren Websites genau diese Betreuung brauchen, liest du unter Webdesign-Leads und im Leitfaden zur Kundengewinnung für Webdesigner. Und weil Wartung von Anfang an ins Projekt gehört, taucht sie als Position in jedem Angebot auf. Was Websites 2026 realistisch kosten, liest du unter Was kostet eine Website?.

Für Webdesigner

Finde Kunden, die deine Webdesign­dienste wirklich brauchen.

Lokale Unternehmen mit veralteten Websites aufspüren, KI-bewerten lassen und als verkaufsfertige Leads exportieren. Starte kostenlos, keine Karte nötig.

Kostenlos starten

Häufige Fragen

Reicht ein Security-Plugin, um eine WordPress-Site zu schützen?

Es hilft, ersetzt aber nichts: Firewall, Malware-Scan und Login-Limits sind sinnvolle Ergänzungen. Die Basis bleiben zeitnahe Updates, wenige gepflegte Plugins, starke Zugangsdaten mit 2FA und getestete Backups. Ein Plugin, das all das verspricht, verkauft ein Gefühl.

Wie oft sollte ich Backups machen und den Restore testen?

Die Backup-Frequenz folgt der Änderungsrate: Shops täglich oder öfter, Broschüren-Sites wöchentlich. Bewahre mehrere Wochen an Ständen auf und speichere extern, nicht nur auf demselben Server. Den Restore testest du mindestens zweimal im Jahr und dokumentierst die Schritte.

Muss jeder Hack der Aufsichtsbehörde gemeldet werden?

Nein. Meldepflichtig nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten, außer sie führt voraussichtlich nicht zu einem Risiko für Betroffene. Ein Defacement ohne Datenzugriff kann anders liegen als ein kopiertes Anfragen-Archiv. Die Einschätzung trifft der Verantwortliche, im Zweifel mit Datenschutzbeauftragtem oder Anwalt, und dokumentiert sie.

Wer haftet, wenn die Website eines Kunden gehackt wird?

Das hängt von der Vereinbarung ab. Ohne Wartungsvertrag bist du nach der Übergabe grundsätzlich nicht für den laufenden Betrieb verantwortlich, im Streitfall wird es trotzdem unangenehm. Regle Zuständigkeiten deshalb schriftlich: wer Updates einspielt, wer sichert, wer im Notfall reagiert.