Zum Inhalt springen 
Ein WordPress Sicherheits-Audit beim Hoster zeigt mir, welche Schutzmaßnahmen wirklich greifen, wo Lücken bestehen und welche Sofortschritte die Verfügbarkeit sichern. Ich orientiere mich an einer klaren Checkliste für Core, Plugins, Server, Protokolle und Wiederherstellung, damit ich Risiken schnell eliminiere und meine Website belastbar betreibe.
Zentrale Punkte
Ich fasse die wichtigsten Schwerpunkte zusammen und setze die Reihenfolge so, dass ich zuerst Angriffsflächen minimiere und dann Monitoring, Alarmierung und Wiederherstellung absichere. Priorität und Transparenz stehen im Mittelpunkt, damit ich jede Maßnahme nachvollziehbar dokumentiere. Ich halte die Liste kurz, weil ich in der Tiefe der folgenden Abschnitte in die Umsetzung gehe. Praxis schlägt Theorie, deshalb formuliere ich jeden Punkt handlungsorientiert. Vor der Umsetzung kläre ich Rollen, Zugänge und den Zugriff auf die Hosting-Konsole, damit ich sofort starten kann.
Die folgende Liste führt mich in der richtigen Reihenfolge durch den Audit.
- Updates & Integrität: Core, Themes, Plugins aktuell halten und Dateien verifizieren.
- Zugänge & 2FA: Nutzer prüfen, Passwörter stärken, Zwei‑Faktor aktivieren.
- Hoster & Server: WAF, DDoS-Schutz, Backups und Log-Analyse sicherstellen.
- HTTPS & Rechte: SSL, Redirects, Dateipermissions und Konfiguration härten.
- Monitoring & Backups: Logs, Alerts, Wiederherstellungen regelmäßig testen.
Ich nutze diese Punkte als Start und erweitere sie projektspezifisch um Besonderheiten wie Multisite, Staging oder Headless-Setups. Disziplin im Ablauf senkt die Fehlerquote und beschleunigt die Umsetzung. Jede Maßnahme dokumentiere ich knapp, damit ich spätere Prüfungen lückenlos belegen kann. Transparente Notizen helfen mir auch beim Onboarding neuer Admins. So halte ich den Audit reproduzierbar und spare mir spätere Rückfragen.
Audit-Start: Bestandsaufnahme und Scope
Ich beginne mit einer klaren Inventur: Welche Domains, Subdomains, Staging-Instanzen und Cron-Jobs gehören zur Installation? Ich erfasse Core-Version, aktive und inaktive Plugins, Themes und Must-Use-Komponenten, damit ich keine vergessenen Altlasten überspringe. Zugänge prüfe ich für WordPress, SFTP/SSH, Datenbank und Hosting-Panel, inklusive Berechtigungen und 2FA-Status. Ich dokumentiere Besonderheiten wie Bedarfs-Plugins, Custom Code im Theme oder Drop-Ins, damit ich sie beim Integritätscheck berücksichtige. Prioritäten setze ich nach Risiko und Aufwand, etwa zuerst kritische Lücken und öffentlich erreichbare Komponenten.
Für die zeitliche Planung definiere ich Wartungsfenster, lege ein Backup vor Beginn an und stimme die Kommunikation mit Stakeholdern ab. Rollen kläre ich eindeutig: Wer darf was, wer genehmigt Änderungen, wer wird bei Alarm benachrichtigt? Ich halte außerdem Basis-Metriken fest, damit ich vor und nach dem Audit Effekte auf Performance, Fehler und Sicherheit vergleichen kann. Transparente Basisdaten erleichtern spätere Audits und Revisionen. So lege ich den Grundstein für eine zügige und saubere Durchführung.
Core, Plugins und Themes: Updates und Integrität
Zuerst aktualisiere ich Core, aktive Plugins und das aktive Theme, danach entferne ich inaktive und verlassene Erweiterungen. Laut [2] liegen bis zu 90% der Einfallstore bei unsicheren oder alten Plugins, deshalb behandle ich diesen Schritt mit hoher Priorität. Integrität verifiziere ich mit Hash-Prüfungen und Dateiscans, etwa über Security-Plugins, die Abweichungen zur Repository-Version melden. Drittquellen meide ich konsequent, weil manipulierte Pakete unbemerkt Hintertüren einschleusen können. Change-Logs lese ich gezielt, um sicherheitsrelevante Fixes zu erkennen und die Reihenfolge der Updates richtig zu wählen.
Nach den Updates führe ich einen vollständigen Scan auf Malware, unerwartete Dateien und verdächtige Code-Signaturen durch. Child-Themes prüfe ich auf veraltete Template-Overrides und hartcodierte Pfade, die nach Updates brechen könnten. Ich deaktiviere Funktionen, die ich nicht brauche, zum Beispiel XML-RPC, wenn keine App- oder Integrationszugriffe notwendig sind. Automatische Updates setze ich differenziert ein: Minor-Updates automatisch, Major-Updates nach Staging-Tests. Zum Abschluss sichere ich eine neue Momentaufnahme, um bei Problemen schnell zurückspringen zu können.
Benutzer und 2FA: Kontrollen mit Augenmaß
Ich gehe die Benutzerliste durch und entferne inaktive, doppelte oder unbekannte Konten konsequent. Rollen vergebe ich nach dem Minimalprinzip und vermeide überhöhte Rechte für Redakteure oder externe Agenturen. Passwörter setze ich auf starke, einzigartige Kombinationen und erzwinge regelmäßige Erneuerung bei Administratoren. Danach aktiviere ich 2FA im Admin-Bereich und sichere Backup-Codes, damit ich im Notfall den Zugang behalte. Benachrichtigungen richte ich so ein, dass Anmeldeversuche, neue Admin-Konten und Passwort-Resets sofort auffallen.
Ich deaktiviere die öffentliche Autorenseite, wenn sie E-Mail-Adressen oder Logins verraten könnte. REST-API-Endpunkte prüfe ich auf ungewollte Exponierung von Nutzerinformationen. Gast-Accounts verwende ich nicht, stattdessen arbeite ich mit temporären Konten mit Ablaufdatum. Protokolle zu Logins archiviere ich ausreichend lang, um Muster und Brute-Force-Versuche erkennen zu können. So schließe ich eine große Quelle für Missbrauch.
Hosting- und Server-Sicherheit: Hoster-Audit
Beim Hoster schaue ich zuerst auf WAF, DDoS-Schutz, tägliche Backups, Malware-Scan und 24/7-Monitoring. Ich prüfe, ob Serverisolierung, aktuelle PHP-Versionen, automatische Sicherheitsfixes und Log-Zugriff verfügbar sind. Netzwerkfilter für Bot-Traffic entlasten die Anwendung spürbar und reduzieren die Angriffsfläche. Ich dokumentiere, wie schnell der Support auf Sicherheitsvorfälle reagiert und welche Wiederherstellungszeiten realistisch sind. Den gesamten Prozess halte ich im Änderungsprotokoll fest und ordne ihn meinem Hoster-Audit prüfen zu.
Die folgende Tabelle zeigt eine knappe Gegenüberstellung zentraler Sicherheitsmerkmale.
| Hosting-Anbieter | Sicherheits-Features | Bewertung |
|---|---|---|
| webhoster.de | Tägliche Backups, WAF, DDoS-Schutz, Malware-Scan, Experten-Support | Platz 1 |
| Anbieter B | Tägliche Backups, DDoS-Schutz, Basisschutz | Platz 2 |
| Anbieter C | Backups auf Anfrage, Grundschutz | Platz 3 |
Ich teste zusätzlich die Wiederherstellungsgeschwindigkeit aus dem Hosting-Backup, um echte RTO-Werte zu kennen. Fehlerhafte Annahmen über Restore-Zeiten führen im Ernstfall zu vermeidbaren Ausfällen. Forensik-Optionen wie Zugriff auf Raw-Logs oder isolierte Staging-Container bringen einen großen Vorteil bei der Ursachenanalyse. Ich aktiviere IP-Blocklisten auf Netzwerkebene und kombiniere sie mit WordPress-seitigen Regeln. So schirme ich den Stack mehrschichtig ab.
SSL/TLS und HTTPS-Erzwingung
Ich installiere ein gültiges SSL-Zertifikat für jede Domain und Subdomain und aktiviere automatische Erneuerung. Alle Aufrufe leite ich per 301 auf HTTPS, damit keine Cookies, Logins oder Formulardaten unverschlüsselt fließen. HSTS setze ich nach einem Testzeitraum, um Browser dauerhaft auf HTTPS festzunageln. In der .htaccess und in der wp-config.php prüfe ich, ob die HTTPS-Erkennung korrekt greift, besonders hinter Proxys oder CDNs. Für Plesk-Umgebungen nutze ich praktische Plesk-Tipps, um Redirects, Zertifikate und Security-Header konsistent zu setzen.
Ich prüfe die Gültigkeit und Konfiguration regelmäßig und halte eine Erinnerung im Kalender. Mixed-Content Trackings oder harte HTTP-Links bereinige ich mit Suchen-Ersetzen in der Datenbank und im Theme. Security-Header wie X-Frame-Options, X-Content-Type-Options und Content-Security-Policy ergänze ich schrittweise. SEO profitiert von sauberem HTTPS, und Nutzer sehen keine Warnungen im Browser. Dadurch kombiniere ich Sicherheit und Vertrauen in einem Schritt.
Dateirechte und Konfiguration härten
Ich setze Berechtigungen streng: 644 für Dateien, 755 für Verzeichnisse, 600 für die wp-config.php. Schreibrechte beschränke ich auf Uploads und temporäre Verzeichnisse, damit Schadcode keinen einfachen Anker findet. Directory Listing deaktiviere ich mit Options -Indexes und lege leere index-Dateien in empfindliche Ordner. In der wp-config.php schalte ich Debug auf produktiven Systemen ab und definiere klare Pfade. Disallow von Datei-Editoren im Backend verhindert spontane Codeänderungen im Live-System.
Ich prüfe Besitzer und Gruppen, insbesondere nach Migrationen oder Restore-Prozessen. Schlüssel und Salts erneuere ich regelmäßig, damit entwendete Cookies nutzlos werden. Upload-Dateitypen begrenze ich auf das Nötigste und blocke potenziell gefährliche Endungen. Read-Only-Mounts für Core-Dateien, wo der Hoster es unterstützt, senken das Risiko weiterer Manipulationen nach einem Einbruch. So bleibt das Dateisystem aufgeräumt und schwer missbrauchbar.
Sicherheitsplugins und WAF richtig einstellen
Ich setze ein Sicherheitsplugin ein, das Malware-Scan, Integritätsprüfung, Login-Schutz und Rate Limiting abdeckt. Die Regeln schärfe ich schrittweise, damit echte Nutzer nicht blockiert werden, während Angriffe ins Leere laufen. Echtzeit-Monitoring und E-Mail-Alerts informieren mich über verdächtige Änderungen an Dateien oder über Login-Events. Ich prüfe die Server-WAF, kombiniere sie mit den Plugin-Regeln und vermeide doppelte oder widersprüchliche Filter. Für die Produktwahl hilft mir dieser Überblick: Sicherheitsplugins 2025.
Ich dokumentiere, welche Regeln ich aktiv setze, und markiere Ausnahmen für bestimmte Integrationen, etwa Zahlungsanbieter oder Webhooks. Whitelist-Einträge halte ich minimal und überprüfe sie regelmäßig. Rollenbasierte Regeln für XML-RPC, REST-API und Dateiänderungen reduzieren unnötige Freigaben. Rate-Limits passe ich an Besucherzahlen und Login-Frequenzen an. So finde ich ein gutes Gleichgewicht zwischen Schutz und Bedienbarkeit.
Backup- und Restore-Proben
Ich verlasse mich auf Backups erst, wenn die Wiederherstellung unter Zeitdruck geklappt hat. Deshalb teste ich Restore-Prozesse regelmäßig auf Staging oder in einer isolierten Umgebung beim Hoster. Versionierung, Aufbewahrungszeit und Speicherort halte ich fest und kombiniere Hoster-Backups mit externen Kopien. Ich dokumentiere genaue Schritte, Ansprechpartner und Zugangscodes, damit ich im Ernstfall keine Zeit verliere. Verschlüsselung der Backups schützt Daten auch außerhalb des Produktivsystems.
Ergänzend sichere ich Datenbank-Dumps und Uploads getrennt und gleiche Prüfsummen ab. Zeitpläne richte ich so ein, dass sie Lastspitzen meiden und vor Deployments zusätzliche Snapshots erstellen. Nach größeren Updates führe ich eine zusätzliche Sicherung durch. Wiederherstellungsziele (RPO/RTO) halte ich realistisch und messe sie. So weiß ich genau, wie lange mein Projekt einen Ausfall verkraftet.
Datenbank- und wp-config-Härtung
Ich überwache die Datenbank auf neue Administratoren, veränderte Optionen und verdächtige Cron-Einträge. Der Tabellenpräfix liefert Angreifern keine echte Sicherheit, aber er erschwert Standard-Skripte geringfügig. Rechte der DB-Nutzer beschränke ich auf das Nötigste und vermeide mehrere Admin-Zugänge ohne Bedarf. Sicherheits-Schlüssel (Salts) erneuere ich bei Verdacht oder regelmäßig nach Plan, um Session-Diebstahl zu erschweren. Automatisierte Scans melden mir Anomalien im Options- und Users-Table.
In der wp-config.php kapsle ich schützenswerte Konstanten und halte klare Trennungen für Staging und Live. Debug-Einstellungen setze ich nur temporär und niemals offen auf Produktiv. Ich prüfe Cron-Verhalten und setze optional System-Crons, wenn das Hosting es zulässt. Ladezeiten optimiere ich nebenbei mit Objekt-Cache, ohne dabei Sicherheitskontrollen zu lockern. So bleibt die Datenhaltung aufgeräumt und wenig angreifbar.
Informationsleckagen und Fehlerseiten vermeiden
Ich unterdrücke Fehlermeldungen und Debug-Ausgaben auf Live-Systemen, damit Angreifer keine Hinweise auf Pfade oder Versionen erhalten. Directory Indexing deaktiviere ich und lege leere Index-Dateien in sensiblen Ordnern ab. Versionshinweise im HTML-Quellcode oder in RSS-Feeds entferne ich, soweit praktikabel. Ich prüfe Robots.txt und Sitemaps, um keine internen Pfade oder Staging-Instanzen preiszugeben. Fehlerseiten gestalte ich so, dass sie keine technischen Details verraten.
Ich überprüfe Caching-Header und Browser-Caches, damit keine privaten Inhalte an weitere Nutzer geraten. Uploads validiere ich serverseitig und verhindere die Ausführung von Skripten in Upload-Verzeichnissen. Test-Plugins, PHP-Info-Dateien oder alte Migrations-Skripte lösche ich konsequent. Security-Header setze ich konsistent auf Webserver- und WordPress-Ebene. So senke ich stille Informationsabflüsse deutlich.
Monitoring, Audit-Logs und Alarmierung
Ich aktiviere Audit-Logs für Logins, Dateiänderungen, Benutzer- und Rollenänderungen. Fehlgeschlagene Loginversuche und wiederkehrende IPs analysiere ich, um Regeln nachzuschärfen. Alerts sende ich an einen dedizierten Verteiler, damit sie nicht im Tagesgeschäft untergehen. Ich verknüpfe Hoster-Logs, WAF-Logs und WordPress-Logs, um Ereignisse sauber zu korrelieren. Dashboards mit wenigen, aussagekräftigen Metriken halten mich auf Stand.
Ich archiviere Logs ausreichend lang, abhängig von Compliance-Anforderungen und Projektgröße. Anomalien untersuche ich zeitnah und dokumentiere Maßnahmen und Entscheidungen. Rate-Limits, IP-Blocklisten und Captchas passe ich nach den Erkenntnissen an. Regelmäßige Reviews der Notifications verhindern Alarmmüdigkeit. So bleibt das Monitoring nützlich und fokussiert.
Schutz vor Bots, Brute-Force und DDoS
Ich setze Rate-Limits, IP-Blocklisten und Captchas am Login ein und blocke bekannte Botnetze frühzeitig. Hoster-seitige Filter auf Netzwerkebene reduzieren den Druck auf die Anwendung wirkungsvoll. Geoblocking kann sinnvoll sein, wenn ich auf klare Zielregionen eingegrenzt veröffentliche. Ich begrenze Anfragen pro Minute je IP und entlaste so PHP und Datenbank. Reports nutze ich, um neue Muster schnell zu erkennen und Regeln zu justieren.
Ich schirme XML-RPC und REST-API mit Regeln ab und lasse nur benötigte Methoden durch. Edge-Caching und CDN-Rate-Limits helfen bei Traffic-Spitzen zusätzlich. Ich halte Bypass-Pfade geschlossen, damit Angreifer nicht um WAF und CDN herumgehen. Fail2ban oder vergleichbare Mechanismen am Server greifen, falls verfügbar. So bleibt die Anwendung auch unter Last handlungsfähig.
Regelmäßige Schwachstellenscans
Ich plane Scans wöchentlich oder nach Änderungen und kombiniere Hoster-Scanner mit WordPress-Plugins. Automatisierte Prüfungen decken vieles ab, händische Checks finden jedoch Konfigurationsfehler und Logik-Lücken. Priorisierung erfolgt nach Schweregrad und Ausnutzbarkeit, nicht nach Lautstärke der Tools. Ich wiederhole Scans nach jedem Fix, um sicherzugehen, dass die Lücke geschlossen bleibt. Berichte archiviere ich revisionssicher und referenziere sie im Änderungsprotokoll.
Neben dem Code prüfe ich Abhängigkeiten wie PHP-Module, Webserver-Module und Cron-Aufgaben. Third-Party-Integrationen wie Zahlungs- oder Newsletter-Dienste durchleuchte ich auf Webhooks, Secrets und IP-Ranges. Ich visualisiere Fortschritt und Rest-Risiken für Entscheider klar und knapp. Wiederkehrende Probleme adressiere ich mit Schulungen oder Prozessanpassungen. So steigere ich die Sicherheit Schritt für Schritt.
Deployment, Staging und Releases sicher ausrollen
Ich strukturiere Deployments klar: Änderungen landen zuerst auf Staging, werden dort mit produktionsnahen Daten getestet und erst danach live geschaltet. Atomic Deploys und Maintenance-Fenster verhindern halbfertige Zustände. Datenbank-Migrationen plane ich mit Rollback-Pfaden und dokumentiere, welche Post-Deploy-Schritte notwendig sind (Permalinks, Caches, Reindexing).
Meine Release-Checkliste umfasst: Backup-Status prüfen, Health-Check, Fehlermeldungen ausschalten, Caches leeren/warmlaufen lassen, Monitoring scharf schalten und nach dem Go-Live gezielt Tests (Login, Checkout, Formulare). So halte ich Releases reproduzierbar und riskominimiert.
Secrets, API-Keys und Integrationen
Ich lagere Secrets (API-Keys, Webhook-Tokens, Zugangsdaten) aus dem Code aus und nutze getrennte Werte für Staging und Live. Schlüssel vergebe ich nach dem Least-Privilege-Prinzip, rotiere sie regelmäßig und protokolliere Besitz und Ablaufdaten. Webhooks beschränke ich auf bekannte IP-Ranges und validiere Signaturen serverseitig.
Für Integrationen setze ich Timeouts, wiederhole fehlgeschlagene Requests kontrolliert und unterdrücke sensible Daten in Logs. Ich verhindere, dass Secrets in Backups, Crash-Reports oder Debug-Plugins landen. So bleiben Integrationen nützlich, aber nicht zum Einfallstor.
Formulare, Uploads und Media-Härtung
Ich sichere Formulare gegen CSRF und Spam ab, prüfe Captchas auf Barrierefreiheit und setze Nonces sowie Server-seitige Validierung. Fehlertexte formuliere ich allgemein, damit Angreifer keine Felderkennung oder Nutzerzustände ableiten können.
Uploads begrenze ich auf erwartete MIME-Typen, validiere sie am Server und verhindere das Ausführen von Skripten in Upload-Verzeichnissen. SVG nutze ich nur mit Sanitizing, Bild-Metadaten (EXIF) entferne ich bei Bedarf. Größen- und Mengenlimits schützen Speicher und verhindern DOS über große Dateien.
SSH, Git und Panel-Zugänge
Ich nutze SSH-Keys statt Passwörter, deaktiviere Root-Login und setze, wo möglich, IP-Allowlisting für SSH, SFTP und das Hosting-Panel. Git-Deployments kapsle ich mit schreibgeschützten Rechten für Core/Plugins und nutze Deploy-Keys mit nur Lesezugriff. phpMyAdmin oder Adminer halte ich, wenn überhaupt, durch IP-Filter, temporäre Passwörter und separate Subdomains eng begrenzt.
Service-Accounts erhalten nur die Rechte, die sie benötigen, und ich versehe sie mit Ablaufdaten. Änderungen am Panel protokolliere ich und überprüfe sie im Vier-Augen-Prinzip. So reduziere ich Risiken durch Fehlbedienung und gestohlene Zugänge.
Incident-Response und Recovery-Plan
Ich halte einen Notfallplan vor: Wer stoppt den Traffic (WAF/Firewall), wer friert das System ein, wer kommuniziert nach außen? Ich sichere unmittelbar Beweise (Server-Snapshots, Raw-Logs, Dateilisten), bevor ich bereinige. Danach erneuere ich alle Secrets, prüfe Nutzerkonten und aktiviere zusätzliche Telemetrie, um Wiederholungen zu erkennen.
Eine kurze Nachbereitung mit Ursachenanalyse, Maßnahmenliste und Zeitplan schließt den Vorfall ab. Ich speise die Erkenntnisse in meine Checklisten ein, passe Regeln an und übe die wichtigsten Schritte regelmäßig, damit sie im Ernstfall sitzen. So verkürze ich Ausfälle und verhindere Wiederholungen.
Automatisierung mit WP-CLI und Playbooks
Ich automatisiere wiederkehrende Prüfungen mit WP-CLI und Hostingskripten: Liste von veralteten Plugins ausgeben, Integritätschecks starten, verdächtige Administratoren finden, Cron-Status prüfen, Caches leeren. Ergebnisse schreibe ich in Berichte und lasse sie an den Verteiler senden.
Playbooks für „Update-&-Test“, „Rollback“, „User-Audit“ und „Malware-Scan“ senken Fehlerquoten. Ich ergänze sie um Zeitmessungen, damit ich RPO/RTO-Ziele realistisch bewerte und Bottlenecks erkenne. So wird Sicherheit Teil der täglichen Betriebsroutine.
Spezialfälle: Multisite, Headless und APIs
In Multisite-Netzwerken prüfe ich Netzwerk-Admins separat, deaktiviere ungenutzte Themes/Plugins netzwerkweit und setze konsistente Security-Header über alle Sites. Site-isolierte Uploads und restriktive Rollen verhindern Seitensprünge im Kompromittierungsfall.
Bei Headless-Setups härte ich die REST-/GraphQL-Endpunkte, setze CORS und Rate-Limits bewusst und trenne schreibende von lesenden Tokens. Ich überwache Fehlversuche auf API-Routen, weil sie sensibel und häufig übersehen sind. Webhooks werden nur aus definierten Netzen zugelassen und signiert validiert.
Recht, Datenschutz und Aufbewahrung
Ich richte Aufbewahrungsfristen für Logs und Backups nach rechtlichen Anforderungen und minimiertem Datenumfang aus. PII in Logs schwärze ich, wo möglich. Rollen und Verantwortlichkeiten dokumentiere ich (wer ist technisch, wer organisatorisch zuständig), inklusive Vertreterregelungen.
Ich prüfe Datenexporte, Löschprozesse und Zugriffe externer Dienstleister. Backups verschlüssele ich und halte die Schlüssel getrennt. Änderungen an Datenschutz-Texten synchronisiere ich mit technischen Einstellungen (Cookies, Consent, Security-Header). So bleiben Betriebs- und Compliance-Aspekte im Gleichgewicht.
E-Mail- und Domain-Sicherheit für Admin-Benachrichtigungen
Ich stelle sicher, dass Admin-Mails zuverlässig ankommen: Absenderdomänen sind mit SPF, DKIM und DMARC korrekt konfiguriert, Bounce-Handling ist eingerichtet und Warnmails laufen in ein sicheres, 2FA-geschütztes Postfach. Ich vermeide, dass Fehlermeldungen sensible Informationen enthalten, und versende Alarme zusätzlich per alternativer Kanäle, wenn verfügbar.
Für Formular- und Systemmails setze ich separate Absender, um Zustellbarkeit und Reputation zu trennen. Ich überwache Zustellraten und reagiere auf Auffälligkeiten (z. B. viele Soft-Bounces nach Domainwechsel). So bleibt die Alarmierung wirksam.
Kurz zusammengefasst
Ein strukturiertes WordPress Sicherheits-Audit beim Hoster verbindet Technik, Prozesse und klare Verantwortlichkeiten. Ich beginne mit Updates und Integrität, sichere Zugänge, stärke Hosting-Features, erzwinge HTTPS und härte Rechte sowie Konfiguration. WAF, Security-Plugins, Backups und Log-Analysen laufen danach kontinuierlich und messbar. Ich halte alles in kurzen Notizen fest, teste Restore-Prozesse und bleibe mit regelmäßigen Scans wachsam. So bleibt die Website verfügbar, nachvollziehbar geschützt und auditierbar über den gesamten Lebenszyklus.
