WordPress Block Themes sollten der nächste große Schritt für WordPress werden. Der Moment, in dem Themes, Templates und Design endlich vollständig im Editor ankommen. Weniger Code, mehr Kontrolle im Backend, mehr Freiheit für Nutzer. So zumindest das Versprechen.
Vier Jahre nach der Einführung von Full Site Editing wirkt die Bilanz deutlich nüchterner.
Der Artikel State of WordPress Themes 2026 zeigt eine Lücke, die wir schon lange beobachten: Das Angebot an Block Themes wächst sichtbar. Die tatsächliche Nutzung bleibt aber weit hinter dem Anspruch zurück. Laut wp.md lag der Anteil nicht gebündelter Block Themes an der aktiven Installationsbasis Ende Juni 2026 bei nur 8,3 Prozent. Nur fünf nicht gebündelte Block Themes überschritten 100.000 aktive Installationen.
Für uns bestätigt das eine These, die wir schon seit Jahren haben: Der Markt hat nicht auf Full Site Editing gewartet. Nicht, weil der Block Editor schlecht ist. Im Gegenteil. Sondern weil professionelle Websites andere Probleme lösen müssen als maximale Gestaltungsfreiheit im Editor.
Redakteure brauchen gute Werkzeuge für Inhalte. Unternehmen brauchen stabile Websites, klare Zuständigkeiten und wartbare Systeme. Genau deshalb nutzen wir Blöcke. Aber wir setzen WordPress Block Themes und FSE nicht als Standard ein.
Die Lücke zwischen Angebot und Nutzung
Der State of WordPress Themes 2026 ist deshalb spannend, weil er nicht nur zeigt, dass Block Themes wachsen. Er zeigt vor allem, wie ungleich dieses Wachstum verteilt ist.
Auf der Angebotsseite ist Bewegung: Es gibt deutlich mehr Block Themes als noch vor ein paar Jahren. Das passt zur Richtung von WordPress Core. Blocks, Patterns, globale Styles und Site Editor sind seit Jahren zentrale Bestandteile der WordPress-Entwicklung.
Auf der Nutzungsseite sieht das Bild anders aus. Laut wp.md lag der Anteil nicht gebündelter Block Themes an der aktiven Installationsbasis Ende Juni 2026 bei nur 8,3 Prozent. Das heißt nicht, dass Block Themes irrelevant sind. Aber es heißt: Der Marktdurchbruch sieht anders aus.
Gerade diese Lücke ist entscheidend. Wenn eine Technologie über Jahre stark priorisiert wird, aber außerhalb der Default-Themes und weniger Ausreißer nur begrenzt Zugkraft entwickelt, lohnt sich die Frage: Löst sie wirklich ein Problem, das der Markt hat?
Warum uns diese Zahlen nicht überraschen
Für uns kommt diese Entwicklung nicht aus dem Nichts. Wir beobachten die Adoption von FSE und Block Themes schon länger, früher auch datenbasiert über das WP Data Dashboard.
Bereits 2022 haben wir beim Blick auf die ersten 100 FSE-Themes im Repository gesehen, dass die bloße Zahl neuer Themes wenig über echte Nutzung aussagt. Ein Jahr später zeigte das Follow-up zur Entwicklung von FSE-Themes ein ähnliches Muster: mehr Angebot, aber weiterhin verhaltene Adoption außerhalb der WordPress-Default-Themes.
Der aktuelle wp.md-Artikel ist deshalb kein einzelner Datenpunkt, der plötzlich alles erklärt. Er bestätigt eine Entwicklung, die schon länger sichtbar ist: Das WordPress Projekt hat FSE stark nach vorne geschoben, aber der freie Markt hat deutlich vorsichtiger reagiert.
Warum Blöcke nicht das Problem sind
Unsere Kritik an FSE ist keine Kritik am Block Editor. Diese Trennung ist wichtig, weil sonst schnell der falsche Eindruck entsteht: als würden wir moderne WordPress-Funktionen grundsätzlich ablehnen.
Das Gegenteil ist der Fall. Der Block Editor löst ein echtes Problem in der täglichen Redaktionsarbeit. Inhalte bestehen nicht nur aus Fließtext. Sie brauchen Teaser, Bilder, Zitate, Downloads, Kontaktbereiche, Akkordeons, Karten, Logos, Call-to-Actions und wiederkehrende Strukturen. Genau dafür sind Blöcke stark.
Ein guter Block macht Inhalte leichter pflegbar, ohne die komplette Gestaltung freizugeben. Er bildet einen klaren Inhaltstyp ab, setzt sinnvolle Grenzen und schützt das Design vor zufälligen Einzelentscheidungen. Das ist für Redakteure hilfreich und für die Website langfristig stabiler.
Deshalb halten wir den Block Editor für einen der besten Content Editoren im Markt. Nicht, weil er alles kann. Sondern weil er für Inhalte genau die richtige Ebene trifft.
Unsere frühe Arbeit mit Gutenberg
Wir bewerten den Block Editor nicht aus sicherer Entfernung. Wir haben früh mit Gutenberg gearbeitet, lange bevor der Editor im WordPress-Alltag selbstverständlich war.
Schon 2018 hat WP Tavern über ein Gutenberg-Projekt von uns für Mimimi Games berichtet. Damals ging es genau um das, worum es heute noch geht: Inhalte sollten flexibel gepflegt werden können, ohne dass das Layout bei jeder Änderung neu erfunden wird.
Diese Erfahrung prägt unsere Haltung bis heute. Blöcke sind stark, wenn sie redaktionelle Arbeit strukturieren. Sie werden problematisch, wenn aus dieser Logik eine komplette Website-Architektur gemacht wird.
Genau dort beginnt für uns die Grenze zwischen Block Editor und Full Site Editing.
Warum FSE das falsche Problem löst
Full Site Editing stellt eine verführerische Frage: Was wäre, wenn sich möglichst viel an einer Website direkt im Editor bearbeiten ließe?
Für WordPress als Produkt klingt das konsequent. Ein Editor für Inhalte, Templates, globale Styles, Header und Footer. Weniger Brüche im Backend. Mehr visuelle Kontrolle. Mehr Eigenständigkeit für Nutzer.
Das Problem ist nur: Der Markt hatte diese Frage längst anders beantwortet.
Wer mit Page Buildern, Designsystemen oder professionellen Website-Workflows arbeitet, erwartet bestimmte Grundfunktionen. Responsive Controls gehören dazu. Nicht als Sonderfall. Nicht als spätere Ergänzung. Sondern als normale Voraussetzung, um Layouts für Desktop, Tablet und Smartphone sauber zu steuern.
Genau hier wirkt FSE bis heute marktfern. Während andere Systeme responsive Steuerung als Selbstverständlichkeit behandeln, folgte der Block Editor lange einer anderen Idee: Layouts sollten möglichst intrinsisch funktionieren, also sich aus Inhalt, Container und verfügbaren Designregeln ergeben. Als Konzept klingt das sauber. In der Praxis hat die Industrie aber anders entschieden. Professionelle Teams wollen responsive Verhalten kontrollieren können.
Too little, too late
Das Timing sagt eigentlich alles: Das zentrale Gutenberg-Issue zu block-spezifischen Responsive Controls wurde 2019 eröffnet. Die offizielle Anerkennung, dass solche Controls nötig sein könnten, kam erst beim State of the Word 2024. Der Merge erster Responsive Controls im Gutenberg Plugin folgte erst Mitte 2026.
2019 erkannt. 2024 offiziell eingeräumt. 2026 gemerged.
Für ein System, das seit 2022 Full Site Editing als Zukunft der WordPress-Architektur verkauft, ist das schwer anders zu lesen als: too little, too late.
Nicht, weil Responsive Controls allein über Erfolg oder Scheitern von FSE entscheiden. Sondern weil sie zeigen, wie groß die Lücke zwischen WordPress-Produktlogik und Marktstandard geworden ist. FSE wollte professionelle Website-Gestaltung in den Editor holen, hat aber zentrale Erwartungen professioneller Website-Gestaltung viel zu spät ernst genommen.
Damit löst FSE aus unserer Sicht nicht das eigentliche Problem von Kundenprojekten. Es macht mehr Bereiche editierbar, aber nicht automatisch besser steuerbar. Es öffnet Gestaltung, ohne an vielen Stellen die Kontrolle zu bieten, die Teams aus anderen Systemen längst gewohnt sind.
Warum Designfreiheit schnell zur Last wird
FSE verkauft Designfreiheit als Vorteil. In vielen Kundenprojekten ist genau das aber der heikle Punkt.
Denn sobald Templates, Abstände, Farben, Größen, Spalten und Layoutvarianten im Editor liegen, verschiebt sich Verantwortung. Redakteure pflegen dann nicht mehr nur Inhalte. Sie treffen laufend Gestaltungsentscheidungen, oft nebenbei, oft unter Zeitdruck und oft ohne den gesamten Designkontext der Website im Blick zu haben.
Das ist kein Vorwurf an Redakteure. Es ist eine Frage des Systems.
Eine gute Redaktionsoberfläche sollte nicht ständig fragen: Wie soll dieser Bereich aussehen? Sie sollte helfen, Inhalte sauber einzugeben, Varianten bewusst auszuwählen und bewährte Muster wiederzuverwenden. Gestaltung muss dabei nicht unsichtbar sein. Aber sie sollte so geführt sein, dass das Ergebnis konsistent bleibt.
Natürlich kann man Designmöglichkeiten in WordPress Block Themes mittlerweile rollenbasiert einschränken. Das ist grundsätzlich richtig und wichtig. Für uns kommt diese Ebene aber zu spät und wirkt in der Praxis nicht stabil genug, um darauf eine verlässliche Architektur für Kundenprojekte aufzubauen. Auch hier zeigt sich wieder das Muster: too little, too late.
Decision Fatigue als UX-Problem
Je mehr Gestaltungsoptionen offen sind, desto mehr kleine Entscheidungen entstehen:
- Welcher Abstand passt hier?
- Welche Überschriftengröße ist richtig?
- Soll dieser Bereich zweispaltig oder dreispaltig sein?
- Braucht der Abschnitt eine andere Hintergrundfarbe?
- Ist diese Variante noch konsistent mit dem Rest der Website?
Einzeln wirken diese Fragen harmlos. Zusammen erzeugen sie Reibung. Genau hier wird Decision Fatigue relevant: Zu viele Entscheidungen führen nicht automatisch zu besseren Ergebnissen. Sie können Entscheidungen schlechter, zufälliger oder vermeidender machen.
Für professionelle Websites ist das ein echtes Risiko. Design lebt nicht von ständiger Neuerfindung. Es lebt von Wiederholung, Rhythmus, Hierarchie und klaren Regeln.
Was wir stattdessen bauen
Unsere Alternative zu FSE und WordPress Block Themes ist nicht weniger WordPress. Es ist eine klarere Aufgabenverteilung innerhalb von WordPress.
Der Block Editor ist für uns dort stark, wo Inhalte gepflegt werden: Texte, Teaser, Logos, Downloads, Ansprechpartner, wiederkehrende Inhaltsbereiche, Kampagnenmodule und strukturierte Sektionen. Genau dort setzen wir Blöcke ein.
Ein guter Block ist dabei kein leerer Baukasten. Er ist ein redaktionelles Werkzeug. Er gibt Felder, Varianten und sinnvolle Optionen vor, damit Inhalte schnell gepflegt werden können und trotzdem sauber aussehen.
Das ist der Unterschied zwischen Freiheit und Beliebigkeit. Redakteure sollen nicht bei jedem Abschnitt entscheiden müssen, wie das Design grundsätzlich funktioniert. Sie sollen Inhalte einpflegen, auswählen, kombinieren und veröffentlichen können, ohne die Website dabei jedes Mal neu zu gestalten.
Kontrollierte Theme-Architektur für den Rest
Alles, was Struktur, Layoutsystem, globale Gestaltung und langfristige Wartbarkeit betrifft, gehört für uns nicht ungefiltert in den Editor. Dort arbeiten wir lieber mit kontrollierter Architektur: Custom Themes, Hybrid Themes, eigenen Blöcken, klaren Komponenten und nachvollziehbarer Theme-Logik.
Wie wir das je nach Projekt abwägen, haben wir bereits in unserem Artikel Welche WordPress Themes wir nutzen beschrieben. Kleine, überschaubare Websites können mit einem Builder-Ansatz sinnvoll umgesetzt werden. Komplexere Projekte brauchen dagegen eine Architektur, die langfristig stabil bleibt.
Für uns heißt das konkret:
- Inhalte werden im Block Editor gepflegt.
- Wiederkehrende Elemente werden als klare Komponenten gebaut.
- Designregeln werden im System abgesichert.
- Templates bleiben nachvollziehbar wartbar.
- Redakteure bekommen die Freiheit, die sie wirklich brauchen.
So entsteht keine maximale Editor-Freiheit. Aber eine Website, die über Jahre sauber gepflegt, erweitert und verstanden werden kann.
Wo Elementor trotzdem sinnvoll ist
Auch Elementor ist für uns kein Dogma. Wir setzen es dort ein, wo es zum Projekt passt. Vor allem bei kleineren, überschaubaren Websites, bei denen schnelle visuelle Umsetzung, einfache Pflege und ein klarer Umfang wichtiger sind als eine hochindividuelle Theme-Architektur.
Der Punkt ist nicht, ob Elementor, Hybrid Theme oder Custom Theme grundsätzlich besser ist. Der Punkt ist, welches System das jeweilige Projekt am saubersten trägt.
Genau deshalb entscheiden wir bei FSE offenbar ähnlich wie große Teile des Marktes: Es passt nicht zu der Art, wie wir WordPress-Projekte bauen möchten. Wir brauchen keine Website-Architektur, die möglichst viel im Editor erlaubt. Wir brauchen Systeme, die sauber wartbar bleiben, Redakteure führen und technische Entscheidungen nachvollziehbar halten. FSE kann für bestimmte Projekte funktionieren. Für unsere Arbeit ist es aber keine Option.
