Im Juli 2026 verschickten Sicherheitsbehörden eine Warnung, die viele Agenturen ins Wochenende hinein beschäftigte: In WordPress selbst – nicht in einem Plugin, sondern im Kern – klaffte eine kritische Lücke. Das österreichische CERT dokumentierte gleich zwei Schwachstellen, CVE-2026-60137 und CVE-2026-63030, deren Kombination eine Remote Code Execution ermöglichte – also die vollständige Übernahme der Seite, ohne Anmeldung, auf Standardinstallationen. Ein Proof-of-Concept war öffentlich. Wer ein Portfolio aus zwanzig, dreißig Kundenseiten betreut, hatte an diesem Wochenende genau eine Aufgabe: patchen, bevor die Angreifer schneller sind.
Solche Nächte kennt jede Agentur, die viele WordPress-Seiten pflegt. Und sie werfen eine Frage auf, die man sich zwischen zwei Notfällen selten stellt: Muss eigentlich jede Kundenseite ein vollwertiges CMS mit Datenbank und Dutzenden Plugins sein? Für einen Teil der Projekte lautet die ehrliche Antwort: nein. Und genau da kommen statische Websites ins Spiel.
Statische Websites: die sichere Antwort auf die WordPress-Lücke
Um das Prinzip zu verstehen, hilft ein Blick darauf, warum WordPress überhaupt angreifbar ist. Ein klassisches WordPress verarbeitet jeden Seitenaufruf live: Der Server führt PHP-Code aus, fragt die Datenbank ab, setzt die Seite zusammen und liefert sie aus. Diese Dynamik ist mächtig, aber sie ist auch die Angriffsfläche. Jede Zeile ausführbarer Code auf dem Server, jedes Plugin, jede veraltete PHP-Version ist eine potenzielle Tür. Warum das Aktualisieren der PHP-Version allein ein Dauerthema ist, kennt jeder, der es schon einmal aufgeschoben hat.
Eine statische Website funktioniert grundlegend anders. Statt die Seite bei jedem Aufruf neu zu erzeugen, wird sie einmal vorab gebaut – aus Inhalten und Vorlagen entstehen fertige HTML-, CSS- und JavaScript-Dateien. Diese liegen anschließend einfach auf dem Server oder einem CDN und werden ausgeliefert, ohne dass dabei Code ausgeführt oder eine Datenbank abgefragt wird. Werkzeuge, die das übernehmen, heißen Static Site Generatoren – bekannte Vertreter sind Astro, Eleventy, Hugo oder Next.js im statischen Modus.
Der Sicherheitseffekt ist unmittelbar. Wo kein PHP läuft und keine Datenbank hängt, gibt es auch keine SQL-Injection und keine unauthentifizierte Remote Code Execution über den CMS-Kern. Die WordPress-Lücke vom Juli 2026 hätte eine statische Seite schlicht nicht betroffen, weil die verwundbaren Komponenten dort gar nicht existieren. Das macht statische Seiten nicht unverwundbar – aber ihre Angriffsfläche ist um Größenordnungen kleiner.
Was du dir mit dem Ansatz einhandelst – und was nicht
Bevor du jetzt dein halbes Portfolio umbauen willst: Der Ansatz hat klare Grenzen, und Ehrlichkeit an dieser Stelle erspart Enttäuschungen.
Ideal für Seiten, die sich selten ändern
Statische Websites spielen ihre Stärken bei Projekten aus, deren Inhalte überschaubar oft wechseln: Unternehmensauftritte, Portfolios, Landingpages, Broschüren-Seiten, Kanzlei- und Praxis-Websites, kleinere Blogs. Für diesen Typ – und das ist ein großer Teil des Alltags kleiner Agenturen – ist ein vollständiges CMS mit Datenbank oft überdimensioniert. Die Seite ändert sich vielleicht monatlich, trägt aber die komplette Wartungslast eines Systems, das für ständige Aktualisierung gebaut wurde.
Grenzen bei echter Dynamik
Sobald eine Seite hochdynamisch ist, wird es aufwendiger. Ein großer Onlineshop mit Warenkorb und Echtzeit-Beständen, ein Community-Portal mit Nutzerkonten, eine Seite mit ständig wechselnden, redaktionell gepflegten Inhalten im Minutentakt – das lässt sich statisch zwar abbilden, aber nur mit zusätzlichem Aufwand und Zusatzdiensten für die dynamischen Teile. Hier bleibt ein klassisches CMS oder eine dynamische Anwendung häufig die pragmatischere Wahl.
Die Redaktionsfrage
Der häufigste Einwand lautet: „Aber mein Kunde will seine Texte selbst ändern." Berechtigt – und lösbar. Moderne Setups koppeln einen statischen Generator mit einem sogenannten Headless-CMS, das dem Kunden eine gewohnte Redaktionsoberfläche bietet, während die eigentliche Auslieferung statisch bleibt. Es gibt schlanke, teils quelloffene Optionen dafür. Der Kunde pflegt Inhalte wie gewohnt, ein automatischer Build erzeugt daraus die fertige Seite. Das ist etwas mehr Einrichtungsaufwand als ein WordPress aus der Schublade, dafür entfällt hinterher ein Gutteil der laufenden Pflege.
Hosting und Betriebskosten
Ein oft unterschätzter Nebeneffekt betrifft das Hosting. Reine HTML-Dateien brauchen keinen PHP-fähigen Server und keine Datenbank; sie lassen sich auf schlanken, teils kostenlosen Hosting-Diensten oder direkt über ein CDN ausliefern. Das senkt nicht nur die laufenden Kosten pro Kundenseite, sondern nimmt dir auch eine ganze Klasse von Betriebsproblemen ab: keine überlasteten Datenbanken bei Traffic-Spitzen, keine PHP-Versionssprünge, die halbe Seiten lahmlegen, keine Server, die unter einem Ansturm zusammenbrechen. Eine statische Seite hält einem plötzlichen Besucheransturm – etwa nach einem Presseartikel – meist problemlos stand, weil der Server nur fertige Dateien reicht, statt für jeden Aufruf zu rechnen.
Dazu kommt ein SEO- und Sichtbarkeitsvorteil, der 2026 an Gewicht gewinnt. Sauberes, schnell ausgeliefertes HTML ist nicht nur für Google gut lesbar, sondern auch für die Crawler der KI-Suchsysteme, die zunehmend darüber entscheiden, ob eine Kundenseite in Antworten auftaucht. Wo klassische WordPress-Seiten mit trägem Rendering und aufgeblähtem Code kämpfen, liefert eine statische Seite von Haus aus, was diese Systeme bevorzugen.
Rechnet sich das für deine Agentur?
Hier wird es strategisch interessant, denn der Wechsel berührt dein Geschäftsmodell. Ein ehrlicher Punkt vorweg: Wenn ein erheblicher Teil deiner wiederkehrenden Einnahmen aus WordPress-Wartung stammt, sägst du mit statischen Seiten scheinbar am eigenen Ast. Weniger Updates, weniger Notfälle, weniger Wartungsstunden – das klingt zunächst nach weniger Umsatz.
Der Gedanke greift aber zu kurz. Erstens ist ein guter Teil der WordPress-Wartung reaktive Feuerwehrarbeit, die schlecht planbar ist und dich an Wochenenden aus dem Bett holt – Arbeit, die du nicht vermisst. Zweitens lässt sich auch für statische Seiten ein Betreuungspaket verkaufen: Hosting, Monitoring, inhaltliche Updates, Weiterentwicklung, Sicherheits-Header und Performance-Pflege. Nur ist es kalkulierbarer und margenstärker, weil du nicht mehr für das Löschen von Bränden bezahlt wirst, die das System selbst legt. Und drittens ist Geschwindigkeit ein Verkaufsargument: Ausgelieferte HTML-Dateien sind von Natur aus schnell, was direkt auf gute Core Web Vitals und damit auf Sichtbarkeit einzahlt.
Das Ganze fügt sich in einen größeren Trend. WordPress ist mit einem Anteil von rund 62 Prozent unter den Websites mit bekanntem CMS weiter marktbeherrschend, aber der Sockel bröckelt an den Rändern, während schlanke, moderne Ansätze zulegen. Warum der sinkende WordPress-Marktanteil für Agenturen kein Grund zur Panik, aber ein Grund zum Nachdenken ist, haben wir gesondert eingeordnet. Statische Seiten sind ein Werkzeug in diesem Übergang – nicht das einzige und nicht für alles, aber für die richtigen Projekte ein starkes.
So gehst du es praktisch an
Du musst nicht alles auf einmal umstellen. Der sinnvolle Einstieg ist ein einzelnes, gut geeignetes Projekt: die nächste Unternehmenswebsite ohne komplexe Interaktion, eine Kampagnen-Landingpage, ein Relaunch, bei dem der Kunde ohnehin bei null anfängt. Wähl einen Generator, der zu deinem Team passt, richte einen automatischen Build ein und teste den Redaktionsweg mit dem Kunden durch, bevor die Seite live geht.
Achte darauf, dass „statisch" nicht „funktionslos" bedeutet. Kontaktformulare, Suchfunktionen, Terminbuchung oder ein Chatbot lassen sich problemlos einbinden – sie laufen dann als eigenständige Dienste neben der statischen Seite, statt sie zu belasten. Ein DSGVO-konformer Chatbot etwa wird als externes Widget eingebunden und funktioniert unabhängig davon, ob die Seite dahinter aus WordPress oder aus statischem HTML besteht. Die statische Basis verliert dadurch nichts von ihrem Sicherheitsvorteil.
Der eigentliche Gewinn zeigt sich erst über die Zeit. Beim nächsten WordPress-Kernproblem – und das nächste kommt so sicher wie das Amen in der Kirche – ist die statische Seite deines Kunden schlicht nicht betroffen. Kein Notfall-Patch, kein banger Blick in die Logs, kein verlorenes Wochenende. Für ein Notfall-Setup rund um WordPress bleibt der Notfallplan für gehackte Seiten trotzdem Pflichtlektüre – aber je mehr passende Projekte du statisch aufsetzt, desto seltener musst du ihn aufschlagen. Und diese ruhigen Nächte sind am Ende bares Geld wert.
- Die WordPress-Kernlücken CVE-2026-60137 und CVE-2026-63030 (Juli 2026) erlaubten unauthentifizierte Remote Code Execution – ein Portfolio aus vielen WP-Seiten musste unter Zeitdruck gepatcht werden.
- Statische Websites führen beim Aufruf keinen Server-Code aus und haben keine Datenbank; die typischen CMS-Angriffe wie SQL-Injection oder Kern-RCE laufen dort ins Leere.
- Ideal sind Seiten mit selten wechselnden Inhalten (Unternehmensauftritte, Portfolios, Landingpages); bei hoher Dynamik wie großen Shops oder Community-Portalen bleibt ein CMS oft die pragmatischere Wahl.
- Die Redaktionsfrage lösen Headless-CMS: Der Kunde pflegt Inhalte gewohnt, ein automatischer Build erzeugt die statische Seite – weniger laufende Pflege bei vertrauter Oberfläche.
- Statische Seiten sägen nicht am Wartungsumsatz: planbare Betreuungspakete ersetzen unplanbare Feuerwehrarbeit, und die hohe Geschwindigkeit zahlt direkt auf die Core Web Vitals ein.