Ein Block-Theme ändert an Ihrem SEO weniger, als der Umbau vermuten lässt. Titel, Meta-Description, Canonical, Robots-Angabe und die strukturierten Daten kommen auch unter Full Site Editing aus dem SEO-Plugin, nicht aus dem Theme. Google sieht am Ende HTML und interessiert sich nicht dafür, ob eine PHP-Datei oder ein Blockbaum es erzeugt hat.
Was sich ändert, ist etwas anderes: Wer im Alltag Überschriften, Templates und Bildeinstellungen anfasst und wie leicht dabei etwas kaputtgeht. Genau daraus entstehen die Fehler, die wir bei FSE-Projekten regelmäßig finden. Dieser Artikel geht die Stellen durch, an denen Block-Themes wirklich SEO-relevant werden, und lässt den Rest weg.
Was sich mit einem Block-Theme für SEO ändert und was nicht
Seit WordPress 5.9 gibt es die zweite Theme-Architektur: Layout, Header, Footer und Archivseiten stecken nicht mehr in header.php, single.php und der klassischen Template-Hierarchie, sondern in HTML-Dateien voller Blockmarkup, gesteuert über eine zentrale theme.json. Bearbeitet wird das im Website-Editor, nicht im Code-Editor.
Für die Suchmaschine bleibt der Großteil unverändert. Das Plugin schreibt weiterhin die Meta-Angaben, erzeugt das JSON-LD, verwaltet die XML-Sitemap und entscheidet, was auf noindex läuft. Auch die Ladezeit wird nicht automatisch besser, nur weil ein Theme blockbasiert ist. Ein schlecht konfiguriertes Block-Theme liefert genauso viel unnötiges CSS aus wie ein schlecht konfiguriertes klassisches Theme.
Wer also ein Block-Theme installiert und erwartet, dass die Rankings anziehen, wird enttäuscht. Die Entscheidung fällt aus anderen Gründen, und welche Kriterien dabei zählen, steht in unseren Kriterien für die Theme-Wahl. Der SEO-Teil beginnt erst danach, im Betrieb. Wie sich die beiden Bauarten grundsätzlich unterscheiden, steht im Architektur-Vergleich von Block-Themes und klassischen Themes; hier geht es darum, was im laufenden Betrieb schiefgeht.
Überschriften und Vorlagen: wo FSE im Alltag wirklich weh tut
Jeder Überschriften-Block hat ein Auswahlfeld für die Ebene. H1 bis H6, ein Klick, keine Rückfrage. In der klassischen Welt kam die H1 fast immer vom Template und die Redaktion konnte sie gar nicht anfassen. Unter FSE steckt der Titel-Block in der Vorlage, ist aber ebenfalls frei einstellbar, und im Inhalt darf zusätzlich jede H1 gesetzt werden, die jemand für passend hält.
Das Ergebnis sehen wir in fast jedem Audit nach einem Umstieg. Bei einem Kunden mit einem selbst gebauten Block-Theme trugen 14 von 61 Seiten zwei H1, weil die Redaktion die erste Zwischenüberschrift optisch zu klein fand. Dazu kamen Sprünge von H2 direkt auf H4, weil die H4-Größe besser ins Layout passte.
Google straft mehrere H1 nicht ab, das sagt Google selbst seit Jahren. Trotzdem ist es ein Problem, denn die Überschriftenebenen sind das einzige Signal, mit dem Sie Google mitteilen, welcher Absatz zu welchem Thema gehört. Eine kaputte Hierarchie ist außerdem fast immer ein Symptom: Wenn niemand auf die Ebenen achtet, achtet auch niemand auf die Gliederung.
Absichern lässt sich das mit drei Handgriffen. Die Dokumentübersicht im Editor zeigt unter „Gliederung" die komplette Überschriftenstruktur und markiert ungültige Sprünge, das ist die schnellste Kontrolle vor dem Veröffentlichen. Den Titel-Block in der Vorlage sperren Sie über die Blocksperre, dann kann die Ebene nicht mehr verstellt werden. Und statt leerer Seiten geben Sie der Redaktion Block-Patterns mit vorgefertigter Struktur, wie es auch beim Arbeiten mit Gutenberg-Blöcken sinnvoll ist.
Praxis-Tipp: Crawlen Sie nach jedem größeren Redaktionsmonat die Seiten mit einem Crawler und filtern Sie nach der Anzahl der H1 pro URL. Der Fehler entsteht schleichend, nicht auf einen Schlag, und fällt im Editor niemandem auf.
Die zweite Stelle sind die Vorlagen selbst, und dort passiert der häufigste Unfall beim Umstieg. In einem klassischen Theme brauchte eine Template-Änderung einen FTP-Zugang oder wenigstens ein Child-Theme. Diese Hürde war lästig, sie war aber auch ein Schutz. Im Website-Editor liegt die Vorlage einen Klick neben dem Inhalt, und der Unterschied ist für Redakteure kaum sichtbar.
Der typische Ablauf: Jemand bearbeitet einen Beitrag, findet die Beitragsüberschrift zu groß, klickt sich versehentlich in die Vorlage „Einzelner Beitrag" und stellt den Titel-Block von H1 auf H2. Gespeichert, fertig. Ab diesem Moment hat kein einziger Beitrag der Website mehr eine H1. Dasselbe passiert mit entfernten Breadcrumbs, gelöschten Beitragsbildern und ausgeblendeten Datumsangaben, nur fällt es dort noch später auf.
Dagegen hilft eine klare Rechtevergabe. Vorlagen darf nur bearbeiten, wer die Berechtigung edit_theme_options hat, also standardmäßig die Rolle Administrator. Redakteure brauchen sie nicht, und wenn doch jemand danach fragt, ist die Antwort meistens, dass eine Vorlage geändert werden soll, die eigentlich ein Pattern sein müsste. Ein zweiter Rettungsanker: Jede im Website-Editor geänderte Vorlage lässt sich mit einem Klick auf den Auslieferungszustand des Themes zurücksetzen, weil WordPress die Anpassung als eigenen Datensatz speichert und die Theme-Datei unberührt lässt.
theme.json, Blockstile und Bilder: was am Ende ausgeliefert wird
Block-Themes laden die Stile der Core-Blöcke einzeln statt als eine große Stylesheet-Datei. Auf einer Seite mit fünf Blocktypen ist das ein Vorteil, auf einer Seite mit dreißig entstehen viele kleine Anfragen und Inline-Blöcke. Dazu kommt der Teil, den theme.json erzeugt: Für jede deklarierte Farbe, jede Schriftgröße, jeden Abstandswert und jedes Duotone-Preset schreibt WordPress CSS-Variablen und Utility-Klassen in den Quelltext, und zwar auf jeder einzelnen Seite.
Messen Sie das, statt es zu schätzen. Im Quelltext einer beliebigen Seite finden Sie den Block global-styles-inline-css. Alles, was dort steht, geht bei jedem Seitenaufruf mit über die Leitung und lässt sich nicht seitenübergreifend cachen. Wenn Ihr Theme fünfzig Farben mitbringt und Sie vier davon benutzen, streichen Sie die restlichen aus der theme.json. Was dort einstellbar ist, dokumentiert WordPress unter Global Settings and Styles.
Bei Bildern arbeitet WordPress inzwischen von allein recht sauber. Seit Version 5.5 setzt der Core loading="lazy", seit WordPress 6.3 zusätzlich fetchpriority="high" auf das vermutete LCP-Bild. Zwei Fallen bleiben. Erstens der Cover-Block: Sein Bild liegt in vielen Konstellationen als CSS-Hintergrund vor, damit ohne srcset und ohne Lazy-Load-Steuerung. Zweitens Bilder im Header-Template, die auf jeder Seite gleich sind und trotzdem in voller Auflösung ausgeliefert werden. Prüfen Sie beides an drei Seitentypen im Quelltext, das dauert zehn Minuten.
Query Loop und Paginierung: welche URLs dabei entstehen
Der Query-Loop-Block ist der Grund, warum Archivseiten unter FSE ohne PHP funktionieren. Er bringt aber eine Eigenheit mit, die im Editor unsichtbar bleibt: Steht er auf einer Archivvorlage und ist die Option „Abfrage von der Vorlage erben" aktiv, erzeugt die Paginierung die gewohnten Adressen im Muster /blog/page/2/. Steht derselbe Block auf einer normalen Seite, hängt WordPress stattdessen einen Parameter an, etwa ?query-17-page=2.
Damit haben Sie plötzlich Parameter-URLs im Umlauf, die fast denselben Inhalt zeigen wie die Ausgangsseite und über die Paginierungslinks auch verlinkt sind. Auf einer Leistungsseite mit angehängter Beitragsliste ist das unnötig. Entscheiden Sie bewusst: Entweder die Liste zeigt eine feste Anzahl Beiträge ohne Paginierung und verlinkt auf das echte Archiv, oder die Parameter-Seiten gehen über das SEO-Plugin auf noindex. Für echte Archivseiten gilt weiterhin der Normalfall, indexierbar mit selbstreferenzierendem Canonical je Seite. Google wertet rel="prev" und rel="next" seit 2019 nicht mehr aus, das brauchen Sie nicht nachzurüsten.
Gut zu wissen: Ist das Häkchen bei „Abfrage von der Vorlage erben" auf einer Archivvorlage nicht gesetzt, zeigt Seite 2 dieselben Beiträge wie Seite 1. Der Fehler fällt im Editor nicht auf, weil dort nur die erste Seite gerendert wird.
An den Grundlagen ändert der Blockaufbau übrigens nichts: Ein Archiv braucht weiterhin einen eigenen Titel und eine eigene Description, genau wie es die Onpage-Grundlagen in WordPress für jede andere Seite auch verlangen.
Umstieg vom klassischen Theme: erst messen, dann wechseln
Der häufigste Fehler beim Wechsel ist nicht technischer Natur, sondern methodischer. Es wird umgestellt, und drei Monate später weiß niemand, ob es besser oder schlechter geworden ist, weil der Zustand davor nie festgehalten wurde. Nehmen Sie sich vorher einen halben Tag.
- Vollständiger Crawl. Alle URLs mit Statuscode, Title, Description, H1, Canonical und Indexierbarkeit als Datei ablegen. Nach dem Umstieg denselben Crawl fahren und die beiden Listen vergleichen.
- Interne Links pro Seite. Header, Footer und Sidebars werden im Block-Theme neu gebaut. Dabei verschwinden regelmäßig ganze Linkblöcke, und die interne Verlinkung sieht hinterher völlig anders aus.
- Felddaten zu den Core Web Vitals. Der Bericht in der Search Console arbeitet mit einem 28-Tage-Fenster. Wer erst nach dem Wechsel hinschaut, hat wochenlang keinen Vergleichswert.
- Klicks und Impressionen je Seite. Ein Export über die letzten drei Monate, aufgeschlüsselt nach URL. Das ist die einzige Zahl, die am Ende zählt.
- Quelltextgröße an drei Seitentypen. Startseite, Beitrag, Archiv. Wenn das HTML nach dem Umstieg wächst statt zu schrumpfen, war das Versprechen des schlanken Outputs eine Behauptung.
Meine Meinung dazu, nach einer Reihe solcher Projekte: Ein Umstieg auf FSE ist kein SEO-Projekt, sondern ein Redaktionsprojekt. Er lohnt sich, wenn Ihr Team Layouts selbst ändern können soll, ohne jedes Mal einen Entwickler zu rufen, und wenn Sie bereit sind, Rechte und Vorlagen sauber zu ordnen. Wer sich davon Rankings verspricht, investiert das Budget an der falschen Stelle.
Für wen es sich nicht lohnt: für eine bestehende, funktionierende Website mit einem schlanken klassischen Theme und einer Redaktion, die zweimal im Monat einen Beitrag schreibt. Dort bleiben Sie besser, wo Sie sind, und holen die Ladezeit über die Theme-Einstellungen heraus, etwa so, wie wir es beim Feintuning von Astra beschrieben haben.
Fazit
Full Site Editing verschiebt für SEO keine großen Blöcke. Die Meta-Angaben, das Schema und die Indexsteuerung bleiben beim Plugin, und ein Block-Theme rankt nicht von allein besser. Die vier Stellen, an denen es tatsächlich klemmt, sind die Überschriftenebenen, die global wirkenden Vorlagen, das aus theme.json erzeugte CSS und die Paginierung der Query Loops. Wer die im Griff hat, kann FSE ohne Sorge einsetzen.
