Block-Themes vs Classic Themes: Der SEO-Vergleich

Seit WordPress 5.9 gibt es eine zweite Theme-Architektur, die viele Website-Betreiber bis heute übersehen: Block-Themes mit Full Site Editing (FSE). Daneben existiert weiter die klassische Theme-Welt mit header.php, functions.php und PHP-Templates. Beide rendern dieselbe Website - aber technisch entstehen dabei zwei völlig unterschiedliche HTML-Dokumente. Und genau dieser Unterschied entscheidet, wie gut Google Ihre Seite versteht und wie schnell sie lädt.

Dieser Artikel ist bewusst kein Theme-Auswahl-Guide. Hier geht es um den technischen SEO-Vergleich zwischen Block-Themes und Classic Themes - Code-Output, Performance, Schema, Wartbarkeit - damit Sie wissen, welche Architektur 2026 die bessere SEO-Basis liefert.

Block-Themes (FSE) vs Classic Themes erklärt

Der Unterschied liegt in der Frage, wo das Layout Ihrer Website definiert wird.

Ein Classic Theme beschreibt das Layout in PHP-Dateien. Header, Footer, Sidebar und Beitrags-Templates sind festverdrahtete Code-Dateien. Wer den Footer ändern will, bearbeitet footer.php - per Code oder über einen Page-Builder wie Elementor, der diese Struktur überlagert. Das ist das klassische WordPress, wie es seit 2003 funktioniert.

Ein Block-Theme dagegen baut die komplette Seite aus Blöcken - inklusive Header und Footer. Statt PHP-Dateien liegen HTML-Templates im Theme, die der Block-Editor rendert. Über Full Site Editing bearbeiten Sie jeden Teil der Seite direkt im Browser, ohne eine einzige PHP-Zeile anzufassen. Das Fundament dafür ist Gutenberg und die Block-Struktur, nur eben auf die gesamte Seite ausgeweitet.

Der entscheidende Punkt für SEO: Block-Themes erzeugen ihr HTML aus einem zentralen, standardisierten Render-System von WordPress. Classic Themes überlassen den Output dem Theme-Entwickler - mit allen Qualitätsschwankungen, die das mit sich bringt. Mittlerweile laufen über 30 % der neu erstellten WordPress-Sites auf Block-Themes. Die Richtung ist klar.

HTML-Output und Code-Sauberkeit im Vergleich

Google liest kein PHP. Google liest das fertige HTML. Und genau hier zeigt sich der härteste Unterschied zwischen beiden Architekturen.

Block-Themes produzieren im Kern semantisches, flaches HTML. Eine Überschrift wird ein <h2>, ein Absatz ein <p>, eine Galerie eine <figure>. Die Verschachtelung bleibt gering, weil das Block-System keine eigene Layout-Engine darüberlegt. Was Sie im Editor sehen, kommt fast eins zu eins im Quelltext an.

Classic Themes können genauso sauber sein - viele schlanke Themes wie GeneratePress beweisen das täglich. Das Problem entsteht erst durch Page-Builder, die typischerweise auf Classic-Architektur aufsetzen. Elementor, Divi oder WPBakery legen ihre eigene Rendering-Schicht über das Theme und erzeugen tief verschachtelte <div>-Strukturen mit kryptischen Klassennamen.

Ein konkreter Vergleich aus unserem Agenturalltag: Dieselbe Landingpage, einmal als Block-Theme-Template, einmal in einem Page-Builder gebaut.

Die fast vierfache HTML-Größe ist kein kosmetisches Problem. Jedes überflüssige <div> vergrößert das DOM, verlangsamt das Rendering und erschwert es Crawlern, die inhaltliche Hierarchie zu erkennen. Google nennt als groben Richtwert maximal 1.500 DOM-Knoten pro Seite - Page-Builder-Seiten sprengen diese Marke bei mittelgroßen Layouts regelmäßig, während Block-Themes meist deutlich darunter bleiben.

Es gibt noch einen unterschätzten Aspekt: Wiederholbarkeit. Block-Themes rendern denselben Block immer identisch, weil der Output aus einer einzigen Quelle stammt. Bei Page-Buildern hängt die HTML-Qualität davon ab, welche Widgets ein Redakteur zusammenklickt - und ob er aus Versehen drei verschachtelte Spalten-Container für etwas verwendet, das ein einzelner Absatz hätte sein können. Genau diese Inkonsistenz lässt Page-Builder-Sites über die Zeit immer unsauberer werden.

Sauberes HTML ist eine Grundlage, die in unseren WordPress SEO Grundlagen ganz oben steht - und Block-Themes liefern sie quasi gratis mit. Wer prüfen will, wie der eigene Output aussieht, öffnet per Rechtsklick den Seitenquelltext und sucht nach der eigentlichen Überschrift. Liegen davor zehn <div>-Ebenen, ist das ein klares Warnsignal.

Performance und Core Web Vitals

Hier wird der Vergleich besonders interessant, denn die Theme-Architektur entscheidet über die Startbedingungen Ihrer Core Web Vitals in WordPress.

Block-Themes haben einen strukturellen Vorteil: WordPress lädt seit Version 5.9 das CSS einzelner Blöcke nur dann, wenn der Block auf der Seite tatsächlich vorkommt. Diese sogenannte Block-Style-Auslieferung verhindert, dass jede Seite das komplette Theme-CSS schleppt. Eine Seite ohne Tabelle lädt auch kein Tabellen-CSS.

Classic Themes laden in der Regel ihr gesamtes Stylesheet auf jeder Seite - egal, welche Elemente vorkommen. Bei Page-Builder-Themes verschärft sich das: Elementor lädt oft mehrere Stylesheets plus JavaScript-Bundles für Funktionen, die auf der jeweiligen Seite gar nicht genutzt werden.

Was das für die drei Core Web Vitals bedeutet:

• LCP (Largest Contentful Paint). Block-Themes rendern das größte Element früher, weil weniger Render-blockierendes CSS und JS im Weg steht.
• CLS (Cumulative Layout Shift). Native Block-Strukturen reservieren Platz für Bilder zuverlässiger als nachgeladene Builder-Widgets.
• INP (Interaction to Next Paint). Weniger JavaScript bedeutet weniger Hauptthread-Blockaden bei der ersten Interaktion.

Ein Kunde von uns wechselte 2025 von einem Divi-Setup auf ein schlankes Block-Theme. Der Lighthouse-Mobile-Score sprang von 54 auf 96, ohne dass ein einziges Caching-Plugin im Spiel war. Der LCP fiel von 3,8 auf 1,1 Sekunden, das übertragene JavaScript schrumpfte um rund 320 KB. Welche Hebel danach noch greifen, zeigen wir im Detail im Artikel zur WordPress-Ladezeit.

Wichtig zur Einordnung: Ein Block-Theme garantiert keine Top-Performance. Es schafft eine bessere Ausgangslage, aber ungenutzte Schriften, unkomprimierte Bilder oder zu viele aktive Plugins können auch ein Block-Theme ausbremsen. Der Unterschied ist, dass die Optimierung von einer schlanken Basis aus startet, statt erst tonnenweise Builder-Ballast wegräumen zu müssen, bevor überhaupt Fortschritt sichtbar wird.

Schema und semantische Struktur

Strukturierte Daten sind 2026 keine Kür mehr. Google AI Overview, Perplexity und ChatGPT bevorzugen Quellen, deren Inhalte sie eindeutig zuordnen können. Und das beginnt bei der semantischen HTML-Grundstruktur, lange bevor JSON-LD ins Spiel kommt.

Block-Themes liefern hier einen subtilen Vorteil: Weil sie aus dem WordPress-Kern rendern, nutzen sie semantische Tags wie <article>, <nav>, <header> und <figure> standardmäßig korrekt. Ein Crawler erkennt sofort, was Inhalt, was Navigation und was Bildunterschrift ist. Die Heading-Hierarchie bleibt sauber, solange Sie im Editor das richtige Heading-Level wählen.

Bei Schema.org selbst gilt: Weder Block- noch Classic-Theme liefern automatisch vollständiges JSON-LD. Beide brauchen dafür entweder Theme-Funktionen oder ein SEO-Plugin. Der Unterschied liegt im Detail - bei Page-Builder-Themes haben wir mehrfach erlebt, dass der Builder selbst fehlerhaftes oder doppeltes Markup ausliefert, das mit dem SEO-Plugin kollidiert.

Worauf es bei beiden Architekturen ankommt:

• Article oder BlogPosting auf Beitragsseiten, sauber befüllt
• BreadcrumbList genau einmal pro Seite, nicht doppelt aus zwei Quellen
• Organization oder LocalBusiness einmal zentral, nicht je Template wiederholt
• Eine <h1> pro Seite, gefolgt von hierarchischen <h2> und <h3> ohne Sprünge

Block-Themes erleichtern diese Sauberkeit, weil sie die Templates zentralisieren. In Classic Themes verstecken sich Heading-Fehler gern in einzelnen PHP-Dateien, die niemand mehr anfasst. Ein typischer Klassiker: Das Theme rendert den Seitentitel als <h1>, der Page-Builder setzt aber im Hero-Bereich noch eine zweite <h1> - und schon hat die Seite zwei Hauptüberschriften, was Google verwirrt. Bei Block-Themes mit zentralem Header-Template passiert das praktisch nicht.

Auch für die KI-Sichtbarkeit zahlt sich semantische Klarheit aus. Sprachmodelle parsen HTML, um Inhalt von Beiwerk zu trennen. Eine Seite, deren Hauptinhalt in einem klar erkennbaren <article>-Element steht, lässt sich von ChatGPT oder Perplexity leichter als zitierfähige Quelle einordnen als eine <div>-Wüste, in der Navigation, Werbung und Text optisch identisch ausgezeichnet sind.

Wartbarkeit und Zukunftssicherheit

Dies ist der Punkt, an dem die strategische Entscheidung kippt. Die offizielle Gutenberg-Roadmap macht keinen Hehl daraus, wohin die Reise geht: Full Site Editing ist die definierte Zukunft von WordPress. Phase 3 mit Echtzeit-Kollaboration und Phase 4 mit Mehrsprachigkeit bauen vollständig auf der Block-Architektur auf.

Für Classic Themes bedeutet das nicht das sofortige Aus. Sie werden auf absehbare Zeit unterstützt, und Millionen Sites laufen stabil darauf. Aber neue Kernfunktionen erscheinen zuerst und manchmal ausschließlich für Block-Themes. Wer heute Classic baut, baut auf einer Architektur, die laufend Aufmerksamkeit verliert.

Bei der Wartbarkeit punkten Block-Themes im Alltag durch zwei Eigenschaften. Erstens: Layout-Änderungen erfolgen visuell im Site Editor statt im Code, was Tippfehler und kaputte PHP-Dateien vermeidet. Zweitens: Es gibt kein separates Plugin-Ökosystem für das Layout, das eigene Update-Zyklen und Sicherheitslücken mitbringt.

Page-Builder-Themes sind hier am anfälligsten. Sie koppeln Inhalt und Layout so eng, dass ein späterer Wechsel teuer wird - der Builder-Code ist tief mit den Inhalten verzahnt. Ein veraltetes Theme oder ein eingestellter Page-Builder wird damit gleichzeitig zum Sicherheits- und SEO-Risiko, weil die Performance mit jeder neuen WordPress-Version weiter abfällt.

Migration von Classic zu Block

Der Wechsel ist machbar, aber kein Knopfdruck. Wer von einem Classic Theme - besonders mit Page-Builder - auf ein Block-Theme migriert, sollte methodisch vorgehen, sonst riskiert er Ranking-Einbrüche.

Die bewährte Reihenfolge:

• Bestandsaufnahme. Welche Templates, Custom Fields und Shortcodes nutzt das alte Theme? Page-Builder-Shortcodes funktionieren nach dem Wechsel nicht mehr.
• Staging-Umgebung. Nie live migrieren. Eine Kopie der Seite aufsetzen und dort das Block-Theme aktivieren.
• Inhalte neu blocken. Page-Builder-Inhalte müssen in native Blöcke überführt werden. Reiner Text und Bilder gehen oft automatisch, komplexe Layouts brauchen Handarbeit.
• URLs und Redirects prüfen. Permalink-Struktur unverändert lassen. Ändert sich eine URL, gehört eine 301-Weiterleitung gesetzt.
• Schema und Meta-Tags kontrollieren. Nach dem Wechsel prüfen, ob das SEO-Plugin weiterhin korrektes JSON-LD und alle Meta-Daten ausliefert.

Rechnen Sie für eine mittelgroße Unternehmensseite mit ein bis zwei Wochen sauberer Migration. Das klingt nach viel, ist aber günstiger als jahrelang gegen eine schwerfällige Architektur anzukämpfen. Wichtig: Nach dem Go-Live die Indexierung in der Search Console im Auge behalten und Core Web Vitals neu messen.

Ein häufiger Fehler bei der Migration ist die Hektik beim Abschalten alter Plugins. Wer das Page-Builder-Plugin deaktiviert, ohne vorher jeden Builder-Shortcode in native Blöcke überführt zu haben, sieht plötzlich rohe Shortcode-Reste wie [et_pb_section] im Frontend stehen. Gehen Sie deshalb Seite für Seite vor und kontrollieren Sie jede wichtige Landingpage einzeln, bevor das alte System endgültig fällt. Halten Sie zudem ein vollständiges Backup bereit, damit ein Rollback jederzeit möglich bleibt.

Wann was sinnvoll ist

Es gibt nicht für jeden Fall die eine richtige Antwort. Die Architektur sollte zum Projekt passen.

Block-Theme ist die richtige Wahl, wenn: Sie eine neue Website starten, Wert auf Performance und schlanken Code legen, langfristig zukunftssicher bauen wollen und Ihr Layout mit nativen Blöcken abbildbar ist - was für die allermeisten Dienstleister-, Unternehmens- und Blog-Seiten zutrifft.

Classic Theme bleibt vertretbar, wenn: Ihre Seite auf einem schlanken, gut gepflegten Classic Theme wie GeneratePress läuft, das bereits sauberes HTML und gute Core Web Vitals liefert. Ein laufendes, schnelles System ohne Not umzubauen, bringt selten SEO-Gewinn.

Vorsicht ist geboten, wenn: Sie ein Page-Builder-Theme nutzen und mit langsamen Ladezeiten oder Ranking-Stagnation kämpfen. Hier zahlt sich der Wechsel zu einer Block-Architektur am deutlichsten aus.

Custom-Anforderungen wie hochkomplexe Mitgliederbereiche oder spezielle Shop-Layouts können in Einzelfällen weiter für ein Classic-Setup sprechen, weil nicht jede Funktion schon als Block existiert. Diese Fälle werden aber von Quartal zu Quartal seltener.

Empfehlung

Meine ehrliche Meinung nach Dutzenden WordPress-Projekten: Für jede neue Website ist 2026 das Block-Theme die bessere SEO-Entscheidung. Der HTML-Output ist sauberer, die Core-Web-Vitals-Basis ist besser, und die Architektur wächst mit WordPress mit, statt dagegen.

Classic Themes sind nicht tot, und ein schlankes, schnelles Classic-Setup ohne Page-Builder ist weiterhin völlig in Ordnung. Wer aber heute auf einem Page-Builder festsitzt und sich über mäßige Rankings wundert, sollte den Wechsel ernsthaft prüfen. Der Unterschied zwischen 118 KB und 31 KB HTML für denselben Inhalt ist kein Detail - er ist die Grundlage dafür, ob Performance-Optimierung später überhaupt greift.

Die Theme-Architektur ist eine der wenigen technischen Entscheidungen, die Sie nicht im Nachhinein mal eben korrigieren. Wer sie von Anfang an richtig trifft, spart sich die teure Migration, die früher oder später ohnehin ansteht.