Wer im Frühjahr 2026 ein neues Blog aufsetze, stehe vor einer Wahl, die noch vor zehn Jahren keine gewesen sei: WordPress oder ein Static Site Generator. Die W3Techs-Erhebung vom Mai 2026 weist WordPress weiterhin als CMS mit dem mit Abstand größten Marktanteil aus — rund 43,2 Prozent aller Websites, deren CMS sich erkennen lasse, liefen darauf. Die Zahl sei seit Jahren bemerkenswert stabil. Und doch erzähle sie nur die halbe Geschichte. Im Long Tail der technisch versierten Selbstpublizist:innen, der Entwickler:innen-Blogs, der dokumentationsnahen Magazine sei eine zweite Welle längst angekommen.

Drei Generatoren, drei Sprachen, drei Philosophien

Hugo, 2013 von Steve Francia in Go geschrieben, sei der Geschwindigkeits-Rekordhalter dieses Feldes. Ein Build von zweitausend Markdown-Dateien dauere auf einem aktuellen Notebook keine zwei Sekunden. Hugo habe früh ein Publikum unter Open-Source-Maintainern und in der DevOps-Szene gefunden — überall dort, wo Dokumentation als Code behandelt werde.

Eleventy, kurz „11ty”, veröffentlichte Zach Leatherman 2018 als bewusst minimalistische Antwort auf den damals schon ausufernden JavaScript-Stack. Eleventy bringe keine Client-Side-Runtime mit, akzeptiere zehn Template-Sprachen nebeneinander und werde gern als „der Generator für Leute, die HTML mögen” beschrieben. Leatherman selbst arbeite seit 2024 wieder bei Cloudflare, was Eleventys Infrastruktur-Anbindung in den letzten beiden Jahren spürbar gestärkt habe.

Astro, 2021 erstmals als Beta veröffentlicht, sei der jüngste der drei und zugleich der ehrgeizigste. Die sogenannte Islands-Architektur — statisches HTML als Fundament, in das einzelne interaktive Komponenten als „Inseln” eingestreut würden — habe es geschafft, die Trennlinie zwischen klassischem Static Site Generator und modernem React-Framework durchlässig zu machen. Wer eine inhaltsschwere Site mit gelegentlich aufflackernden Widgets baue, finde in Astro derzeit die wenigsten Reibungspunkte.

JAMstack als Begriff und als Versprechen

„Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.”

So habe Mathias Biilmann, Mitgründer von Netlify, den Begriff JAMstack in einem Vortrag 2016 erstmals formuliert. JavaScript, APIs, Markup — daher das Akronym. Der Gedanke dahinter sei radikal einfach: Der Server liefere fertiges HTML aus, die Dynamik komme über JavaScript und über Drittanbieter-APIs hinzu. Keine Render-Schicht zur Request-Zeit, keine PHP-Datenbank-Roundtrips, keine Plugin-Bedingungen, die im Sekundentakt entscheiden müssten, ob ein Kommentar angezeigt werde.

Was 2016 als Architektur-Idee gedacht gewesen sei, habe sich bis 2026 zu einer ganzen Werkzeugkette ausgewachsen. Vercel, Netlify und Cloudflare Pages böten Build-Pipelines, die einen Git-Push entgegennähmen und binnen Minuten ein global verteiltes CDN bestückten. Headless-CMS wie Sanity, Strapi und Tina füllten die Lücke, die früher das WordPress-Backend besetzt habe. Und Komponenten-Marktplätze von Stripe über Algolia bis Snipcart erlaubten es, klassisch dynamische Funktionen — Bezahlung, Suche, Warenkorb — über APIs anzudocken, ohne dass der Generator selbst etwas davon wisse.

Was WordPress weiterhin gut könne — und wo es ächze

Es wäre unredlich, die Erfolgsgeschichte zu klein zu reden. WordPress habe in seinen zwanzig Jahren eine Infrastruktur aufgebaut, die in der Open-Source-Welt einzigartig sei: über sechzigtausend Plugins im offiziellen Verzeichnis, ein ausdifferenziertes Theme-Ökosystem, eine WYSIWYG-Bearbeitung, die auch ohne Code-Kenntnisse funktioniere, und mit dem 2018 eingeführten Block-Editor „Gutenberg” einen Schritt in Richtung komponentenbasierter Inhaltsgestaltung.

Die Schattenseiten dieses Stacks seien hinlänglich beschrieben. Sicherheits-Updates müssten regelmäßig eingespielt werden; Plugin-Konflikte gehörten zum Alltag; jede dynamische Seite verbrauche Datenbankressourcen. Wer ein WordPress-Blog ein Jahr lang sich selbst überlasse, finde mit hoher Wahrscheinlichkeit eine kompromittierte Installation vor. Static Sites kennten dieses Problem nicht — es gebe schlicht keine Laufzeit, die angegriffen werden könne. Das Worst-Case-Szenario sei ein veraltetes HTML.

Self-Hosting vs. Managed

Ein zweiter, oft unterschätzter Bruch verlaufe zwischen Self-Hosting und Managed-Hosting. WordPress.com (die kommerzielle Variante von Automattic) und WP Engine böten Managed-Pakete, in denen Updates, Backups und Caching automatisiert würden. Die monatlichen Kosten begännen bei rund 25 Euro für ernsthaft betriebene Sites und stiegen schnell auf dreistellige Beträge.

Im SSG-Lager verhalte es sich umgekehrt: Der Generator laufe lokal oder in einer Build-Umgebung, das fertige HTML werde auf einen Hosting-Anbieter geschoben. Netlify, Cloudflare Pages, GitHub Pages und Vercel böten großzügige Free-Tiers. Wer den Build selbst orchestriere, könne eine statische Site faktisch zum Preis der Domain betreiben. Der Preis dafür sei das Kommandozeilen-Wissen, das nötig sei, um Git, Build-Pipelines und Markdown-Konventionen souverän zu handhaben.

Was der Wechsel kostet — und wem er sich lohne

Migrationen von WordPress zu einem SSG seien selten triviale Übungen. Die Inhalte ließen sich via WP-REST-API exportieren; Markdown-Konvertierungen funktionierten für Standardbeiträge zuverlässig, scheiterten aber regelmäßig an Shortcodes, eingebetteten Galerien und an den Gutenberg-Block-Strukturen, die kein Markdown-Pendant kennten. Wer fünfzehn Jahre Bestand in ein neues Format überführe, plane realistisch zwei bis vier Wochen ein — auch bei einem mittelgroßen Blog.

Die Frage, wem dieser Aufwand sich lohne, sei am ehrlichsten so zu beantworten: SSGs taugten für Inhalts-getriebene Sites, deren Form sich nicht im Wochentakt verändere. Magazine, Dokumentationen, persönliche Blogs, Vereins-Auftritte. WordPress bleibe stark, wo Redaktionen mit wechselnden Mitarbeiter:innen, mit komplexen Workflows oder mit hochfrequenten Plugin-Anforderungen arbeiteten. Die Wahl sei keine ideologische, sondern eine architektonische.

Astros Islands-Architektur im Detail

Die Islands-Architektur, die Fred Schott (Astro-Mitgründer) erstmals im November 2020 in einem Konzeptpapier skizziert habe, verdiene einen genaueren Blick. Der Grundgedanke: Eine Seite werde server-seitig zu HTML gerendert; einzelne interaktive Komponenten — eine Suche, ein Lightbox-Player, ein Kommentar-Widget — würden als isolierte JavaScript-Inseln in dieses HTML eingebettet und nur dort hydriert, wo Interaktion nötig sei.

Der praktische Vorteil sei ablesbar an den Performance-Metriken. Die Largest-Contentful-Paint-Werte (LCP) lägen für vergleichbare Inhalts-Sites in Astro typischerweise zwischen 0,8 und 1,4 Sekunden — gegenüber drei bis fünf Sekunden für eine vergleichbare Next.js- oder Nuxt-Seite mit vollständiger Client-seitiger Hydration. Wer Aufmerksamkeit auf die Core Web Vitals von Google legen müsse — sei es aus SEO-Gründen, sei es aus User-Experience-Überzeugung —, finde in Astro derzeit eine der konsequentesten Architekturen.

Was Schott in einem Interview mit der englischsprachigen Publikation Smashing Magazine im Februar 2023 betonte: Die Islands-Idee sei keine Astro-Exklusivität; vergleichbare Ansätze fänden sich in Marko (eBay), in Quik (vom Builder.io-Team) und ansatzweise auch in Eleventys Partial-Hydration-Erweiterungen. Astro habe lediglich den Begriff geprägt und das Konzept als Default-Architektur eines Generators umgesetzt.

Markdown als gemeinsamer Nenner

Was alle drei Generatoren teilten — und worin sich der zentrale kulturelle Unterschied zu WordPress manifestiere —, sei die Verankerung in Markdown. John Gruber und Aaron Swartz veröffentlichten die ursprüngliche Markdown-Spezifikation im März 2004 als Werkzeug, um Klartext leichthändig in HTML zu überführen. CommonMark, die 2014 begonnene Bemühung um eine eindeutige Spezifikation, stabilisierte 2017 in Version 0.28 die Syntax so weit, dass alle ernsthaften Werkzeuge denselben Quelltext identisch interpretieren.

Was banal klinge, sei eine kleine Revolution: Wer Beiträge in Markdown verfasse, könne sie zwischen Generatoren wechseln, ohne den Bestand zu reformatieren. Eine in Hugo gepflegte Bibliothek lasse sich binnen Tagen nach Eleventy oder Astro überführen — die Markdown-Dateien blieben bit-genau dieselben, lediglich die Frontmatter-Felder und die Template-Schicht müssten neu zugeordnet werden. Diese Portabilität fehle der WordPress-Welt strukturell.

Was die Build-Pipeline ändere

Ein zweiter, oft unterschätzter Bruch sei der Build-Schritt selbst. Wer mit WordPress publiziere, klicke „Veröffentlichen” — der Beitrag sei live. Wer mit einem SSG arbeite, schreibe Markdown, commite den Stand nach Git, warte auf die Build-Pipeline und sehe das Resultat nach Sekunden bis wenigen Minuten. Diese Zwischenstufe sei in der täglichen Routine erstaunlich folgenreich.

Sie zwinge zu einer disziplinierteren Arbeit am Text — eine Tippfehler-Korrektur sei ein Commit, kein Quick-Edit im Backend. Sie erlaube aber zugleich Pull-Requests, Vorschau-Deployments und automatisierte Lint-Prüfungen, die im WordPress-Workflow umständlich nachgerüstet werden müssten. Wer in Teams arbeite, gewinne damit eine Versionskontrolle, die die Sammelarbeit am Text auf das Niveau hebt, das Software-Entwicklung längst kenne.

Die Cloudflare-Pages-Telemetrie aus dem Build-Report vom April 2026 weise mittlere Build-Zeiten für Astro-Sites zwischen sieben und vierundzwanzig Sekunden aus; Eleventy-Sites lägen meist zwischen drei und zwölf Sekunden, Hugo-Sites fast immer unter fünf Sekunden. Wer eine Site mit fünfhundert Beiträgen betreue, könne den vollständigen Re-Build problemlos pro Commit wiederholen.

Eleventy in der Cloudflare-Workers-Welt

Die seit 2024 enge Verzahnung Eleventys mit Cloudflare Workers verdiene eine eigene Betrachtung. Mit der im Februar 2025 freigeschalteten WAFL-Schnittstelle (Workers Application Framework Layer) habe Cloudflare einen Build-Pfad geschaffen, der Eleventy-Sites direkt aus dem Git-Repository in eine global verteilte Edge-Pipeline überführe. Build-Zeiten unter zehn Sekunden seien die Norm; die Ausspielzeit bis zur ersten Region liege unter fünfzehn Sekunden.

Was an dieser Architektur interessant sei, sei die Möglichkeit, dynamische Komponenten in der Edge zu rechnen, ohne das statische Fundament zu verlassen. Ein Suchindex könne als KV-Store hinter einer Worker-Route liegen; eine Kommentarfunktion auf einen D1-Datenbank-Layer aufsetzen. Die HTML-Seite bleibe statisch ausgeliefert, die dynamischen Inseln liefen in dedizierten Sub-Requests. Damit löse sich die klassische Trennlinie zwischen statisch und dynamisch in der täglichen Arbeit weitgehend auf.

Eine Zwischenbilanz für 2026

Die Wachstumskurven der drei Generatoren lägen nach Daten von BuiltWith und npmtrends seit Anfang 2025 weiter im positiven Bereich, wenn auch nicht mehr in den exponentiellen Sprüngen der frühen Astro-Jahre. Hugo verzeichne stabile Nutzerzahlen im Dokumentations-Segment, Eleventy gewinne in der Cloudflare-Workers-Welt an Boden, Astro wachse vor allem in der JavaScript-affinen Indie-Szene.

Im deutschsprachigen Raum sei der Wechsel ablesbar an Migrationen prominenter Adressen. Der Übermedien-Auftritt von Stefan Niggemeier laufe seit der Relaunch-Iteration von 2023 auf einem Ghost-Kern mit Astro-Vorbau; das Magazin Krautreporter habe seine Article-Pages 2024 von einer hauseigenen Rails-Anwendung auf eine SSG-Pipeline umgestellt, während die Mitgliederverwaltung weiterhin im Rails-System verbleibe. Diese hybriden Konstruktionen seien sinnvolle Zwischenstufen — die statische Schicht für die öffentlich sichtbare Lektüre, eine schmale dynamische Schicht für Authentication und Zahlungsabwicklung.

Was bleibe, sei eine bemerkenswerte Pluralität: Wer 2026 publiziere, könne zwischen einem ausgereiften, monolithischen CMS und einer Werkzeugkette aus klein-modularen Generatoren wählen. Die Zeiten, in denen WordPress als Default-Antwort galt, seien zwar nicht vorbei. Sie seien aber, vorsichtig formuliert, in Bewegung geraten. Und genau dort werde es interessant.