Goodbye WordPress
Anfang 2026 war zeitkuenstler.de zerschossen. Ein WordPress-Plugin hatte Schadsoftware eingeschleust, aus meinem gewohnten CMS wurde über Nacht eine Baustelle.
Ein Alptraum! Es dauerte lange, bis ich die Seite über Updates wieder hergestellt hatte.
Zur gleichen Zeit wollte ich stärker mit KI arbeiten. Allerdings habe ich gezögert, ein Plugin zu installieren, das einer KI über MCP vollen Zugang zu meiner WordPress-Installation gegeben hätte. Das wäre ein weiteres Einfallstor für Angriffe gewesen.
Der Hack und diese Sorge führten zum selben Wunsch: ein lokales CMS, das die Texte verwaltet, ohne selbst zum dauernden Sicherheitsprojekt zu werden.
Die Entscheidung: keine Backend-Anwendung mehr
Die Antwort war eigentlich ganz simpel: Die Website sollte keine Anwendung mehr sein, bei der Pflege und Auslieferung auf dem gleichen System stattfindet.
Ich wollte Inhalte lokal als Markdown-Dateien schreiben und sie mit einem Prozess als statische HTML-Seiten veröffentlichen.
Die Vorteile:
- kein Admin-Backend
- keine Datenbank
- keine Plugins, die zur Laufzeit fremden oder eigenen Code nachladen
Das bedeutet weniger Komfort im laufenden Betrieb, aber mehr Sicherheit im Betrieb. Der Sicherheitsgewinn entsteht dabei nicht durch ein cleveres Schutztool, sondern dadurch, dass viele riskante Wege gar nicht mehr existieren:
- kein Login für Redakteure im Internet
- kein Passwort für eine Produktionsdatenbank
- keine Upload-Funktion im Backend
- kein Marktplatz von Erweiterungen, dessen Updates auf dem Live-System landen
Alte URLs bleiben gültig - der Build erzwingt es
Die eigentliche Herausforderung bestand darin, die alten URLs zu behalten: Über Jahre haben Menschen, Suchmaschinen und andere Websites auf konkrete Pfade verwiesen. Der Wechsel des Systems durfte nicht bedeuten, dass Leserinnen und Leser auf einer Fehlerseite landen.
Es musste also eine Migration implementiert werden, die jede bestehende Seite mit dem alten Pfad in das neue System überträgt.
Dieser Grundsatz prägt die Architektur. Der Build des neuen Systems erzeugt Seiten, Archive, Sitemap, robots.txt und weitere Ausgabedateien, die nahezu identisch sind mit der Struktur der WordPress-Instanz.
Die meisten WordPress-Lücken stecken in Plugins, nicht im Kern
Die meisten gemeldeten Schwachstellen im WordPress-Umfeld betreffen nicht den Kern, sondern das große Ökosystem aus Plugins und Themes.
Das ist kein Plädoyer gegen WordPress, aber es zeigt, dass eine Webseite auf dieser Basis permanente Aufmerksamkeit erfordert.
Da WordPress sehr bekannt ist, sind auch die Sicherheitslücken sehr bekannt. Das Plugin WordFence hat mir täglich gemeldet, welche Login-Versuche Hacker unternommen haben und welche Angriffe gelaufen sind.
Sie alle konnten abgewehrt werden, doch gefühlt war es nur eine Frage der Zeit, bis einer davon erfolgreich sein würde.
Vollständige Sicherheit gibt es nicht
Ein statisches CMS ist nicht automatisch unverwundbar. Auch hier können fehlerhafte Deployments, offene Verzeichnisse, sensible Dateien oder falsch gesetzte Header Probleme schaffen. Die Sicherheit ist nicht automatisch hergestellt, nur weil ich mich für ein lokales CMS entschieden habe.
Deswegen habe ich Vorkehrungen getroffen:
- Vor jedem Upload zeigt ein Dry-Run - ein Testlauf, der geplante Änderungen anzeigt, ohne sie hochzuladen - was sich ändern würde.
- Es werden nur geänderte Dateien auf den Webserver hochgeladen
- Es gibt festgelegte Remote-Pfade
- Lokal kann die komplette Site getestet werden
- Ein mit KI generiertes Script prüft typische Sicherheitslücken auf dem Webserver (gesperrte Pfade, Security-Header, TLS und Directory Listing - die versehentliche Auflistung von Serververzeichnissen ohne Index-Datei)
Auch die Statistik folgt dem Minimalprinzip: Der Server notiert nur das Nötigste. IP-Adressen, Cookies, Sitzungskennungen und externe Analyseanbieter bleiben außen vor. Aus meiner Sicht ist das gelebte Datensparsamkeit.
Weniger Backend heißt mehr Fokus aufs Schreiben
Der Umzug von zeitkuenstler.de baut ein großes CMS im Kleinen nach und trennt Pflege von Auslieferung und Design. Die technische Gestaltung bleibt getrennt vom Text. Erweiterungen wie A/B-Tests sind dabei weiterhin möglich.
Die Seite fühlt sich wieder wie ein Ort zum Veröffentlichen an - ohne die Sorge um Sicherheit. Ich öffne eine Datei, schreibe, prüfe und veröffentliche. Für mich kein gefühlter Komfortverlust.
Und sollte der Webserver doch einmal gehackt werden: Es braucht nur ein neues Deployment, und der alte Stand ist wiederhergestellt. Das lokale System ist gleichzeitig das Backup.
Fünf Quellen, die den Sicherheitsgedanken einordnen
Die Sicherheitslage im WordPress-Umfeld wird vor allem durch die vielen Erweiterungen geprägt: Neue Funktionen bringen zusätzliche Berechtigungen, Upload-Wege und Schnittstellen auf den Server. Regelmäßige Updates, klar begrenzte Rechte und ein Plan für den Fehlerfall bleiben deshalb unverzichtbar.
Die dokumentierten Fälle rund um Plugins zeigen zusätzlich: Eine moderne Funktion bringt nicht nur ihren sichtbaren Nutzen mit, sondern auch ihre vollständige technische Vertrauenskette.
Ein schlankes, statisch ausgeliefertes CMS umgeht diese Risiken nicht automatisch, reduziert aber die Zahl der Komponenten, die im öffentlichen Betrieb überhaupt angreifbar sind - kontrollierte Deployments, Prüfungen und eine sorgfältige Konfiguration bleiben trotzdem nötig.
Quellen
Häufige Fragen zum sicheren CMS
Was unterscheidet ein statisches CMS von WordPress?
Ein statisches CMS hat kein Admin-Backend und keine Datenbank auf dem Server: Inhalte werden lokal als Markdown geschrieben, zu fertigen HTML-Dateien gebaut, und nur diese Dateien werden hochgeladen. WordPress liefert Seiten dagegen bei jedem Aufruf dynamisch aus einer Datenbank aus und braucht dafür ein Backend mit Logik.
Warum ist ein statisches CMS sicherer als WordPress?
Weil zentrale Angriffsflächen fehlen: kein Redakteur-Login im Internet, keine Produktionsdatenbank, keine Upload-Funktion und keine Plugin-Updates, die live auf dem Server landen. Die meisten gemeldeten WordPress-Schwachstellen betreffen Plugins und Themes, nicht den WordPress-Kern.
Bleiben bei einem CMS-Wechsel alte URLs erreichbar?
Ja, wenn der Build es erzwingt. Jede verbindliche alte Adresse - auch Archive und Medienpfade - muss unter demselben Pfad weiter funktionieren, sonst stoppt der Build mit einem Fehler.
Ist ein statisches CMS automatisch unverwundbar?
Nein. Fehlerhafte Deployments, offene Verzeichnisse oder falsch gesetzte Header bleiben Risiken. Ein Dry-Run vor jedem Upload, eine eigene Staging-Domain und ein Prüfsystem für Security-Header, TLS und Directory Listing fangen diese Risiken ab.
Für wen lohnt sich ein CMS mit klassischem Backend trotzdem?
Für alle, die eine interaktive Website, mehrere Redakteure, Shop-Funktionen oder dynamische Personalisierung brauchen. Wer vor allem veröffentlichen will, kann dagegen ganz auf Backend und Datenbank auf dem Produktionsserver verzichten.