Die häufigste Sorge, die uns bei Migrationsgesprächen begegnet, lässt sich auf einen Satz verdichten: "Wir haben Jahre in unser Yoast-Setup investiert — ist das beim Headless-Wechsel weg?" Die Antwort ist beruhigend und technisch zugleich: Nein, es ist nicht weg. Aber es funktioniert anders. Yoast SEO läuft auf über 10 Millionen WordPress-Installationen, Rank Math auf rund 4 Millionen (WordPress.org Plugin-Verzeichnis, Stand Juni 2026) — die Frage betrifft also fast jedes WordPress-Projekt im Markt. Wer den Unterschied versteht, verliert die Angst und gewinnt meist sauberere SEO-Strukturen als zuvor. Wie das im Detail aussieht, zeigt der Leitfaden zu Headless WordPress SEO; die Architektur an sich ordnet Was ist Headless WordPress ein.
Der Kern des Missverständnisses liegt darin, was ein SEO-Plugin eigentlich tut. Yoast und Rank Math sind zwei Dinge gleichzeitig: ein Editor für SEO-Felder und ein Renderer, der diese Felder im klassischen Theme als HTML in den Seitenkopf schreibt. Im Headless-Setup bleibt der erste Teil bestehen — der zweite wandert ins Frontend. Das ist die ganze Geschichte, und sie ist weniger dramatisch, als sie zunächst klingt.
Warum entsteht die Angst überhaupt?
Die Angst entsteht, weil ein SEO-Plugin im klassischen WordPress zwei Rollen gleichzeitig spielt: Es verwaltet die SEO-Felder und rendert sie als HTML in den Seitenkopf. Beide Rollen fallen im selben System physisch zusammen, sodass es wie eine untrennbare Einheit wirkt — und das Trennen von Backend und Frontend wie ein Verlust aussieht.
Im klassischen WordPress laufen Backend und Frontend im selben System. Wenn Yoast einen Meta-Titel speichert, rendert dasselbe WordPress-Theme diesen Titel direkt in den <head> der ausgelieferten Seite. Sie sehen das Plugin arbeiten, weil Ausgabe und Verwaltung physisch zusammenfallen. Das fühlt sich an wie eine Einheit — und genau daraus entsteht die Sorge, dass beim Trennen von Backend und Frontend die ganze SEO-Schicht zerbricht.
Im Headless-Setup wird das Frontend von einem separaten System ausgeliefert, typischerweise Next.js. Dieses Frontend ruft die Inhalte über eine Schnittstelle ab — und genau hier greift Yoasts HTML-Ausgabe nicht mehr automatisch. Die <head>-Tags, die das Plugin im klassischen Theme schreibt, erreichen das neue Frontend nicht. Wer nur diese Hälfte betrachtet, kommt verständlicherweise zum Schluss: "SEO ist weg."
Die andere Hälfte ist die wichtigere: Alle SEO-Daten, die Sie über Jahre gepflegt haben — Meta-Titel pro Seite, handgeschriebene Descriptions, gesetzte Canonicals, Schema-Konfigurationen — liegen weiterhin in der WordPress-Datenbank. Sie sind nicht an die Theme-Ausgabe gebunden. Sie sind abrufbar. Und genau das macht den geordneten Übergang möglich.
Funktioniert Yoast & Rank Math im Headless-Setup noch?
Ja — beide Plugins bleiben als Datenquelle vollständig erhalten. Yoast und Rank Math verwalten im Headless-Setup weiterhin Meta-Titel, Descriptions, Canonicals und Schema-Felder im Backend. Das Frontend ruft diese Werte über WPGraphQL oder REST ab und rendert sie selbst. Nur die HTML-Ausgabe im Theme-Head entfällt, weil das Theme im Headless-Frontend nicht mehr existiert.
Ihre Redaktion arbeitet im WordPress-Backend weiter wie gewohnt: Fokus-Keyphrase setzen, Snippet-Vorschau prüfen, Meta-Description schreiben, Canonical anpassen. An diesem Arbeitsablauf ändert die Headless-Architektur nichts — was die Redaktion auch spürt, wie der Beitrag Was sich für die Redaktion bei Headless WordPress ändert im Detail zeigt.
Der Zugriff auf diese Daten erfolgt über eine Schnittstelle — und hier unterscheiden sich die beiden Plugins im Weg, nicht im Prinzip.
Yoast bindet seine Felder über das WPGraphQL-Yoast-SEO-Addon in das GraphQL-Schema ein und stellt ein seo-Feld pro Seite und Beitrag bereit. Eine GraphQL-Abfrage fordert zusammen mit dem Beitrag ein verschachteltes seo-Objekt an — etwa seo { title metaDesc canonical opengraphImage { sourceUrl } schema { raw } fullHead }. Das Addon exponiert genau diese Felder inklusive canonical, metaRobotsNoindex, breadcrumbs und schema (ashhitch/wp-graphql-yoast-seo, README). Damit kommt jede SEO-Information in einem einzigen Request mit, ohne dass das Frontend Felder aus dem HTML zurückparsen muss.
Rank Math geht den REST-Weg: Nach Aktivierung der Option Headless CMS Support (unter SEO → General Settings → Others) liefert der Endpunkt /wp-json/rankmath/v1/getHead?url=https://ihre-domain.ch/beitrag die fertige Head-Information zu jeder URL — Meta-Tags, Canonical und JSON-LD im Block (Rank Math, Headless-CMS-Support-Doku). Das Frontend kann diesen Block übernehmen oder die einzelnen Werte herauslösen und über die eigene Rendering-Pipeline neu setzen. Die Mechanik ist dieselbe wie bei Yoast: Die Redaktion pflegt im Backend, das Frontend rendert.
Genau diese Geschlossenheit ist der praktische Vorteil gegenüber dem klassischen Theme: Was die Redaktion im Backend pflegt, landet als strukturiertes Datenobjekt im Frontend — vorhersehbar und unabhängig davon, welches Template später daraus HTML macht.
Konkret bleiben über die Schnittstelle abrufbar:
- Meta-Titel und Meta-Descriptions — pro Seite, Beitrag und Taxonomie, exakt wie im Backend gepflegt.
- Canonical-URLs — inklusive manueller Überschreibungen, die Sie gesetzt haben.
- OpenGraph- und Twitter-Card-Felder — Titel, Beschreibung und Bildreferenz für Social-Sharing.
- Schema-Felder — Article, FAQ, Breadcrumb, Person und Organisation als strukturierte Datenobjekte.
- robots-Direktiven —
index/noindexundfollow/nofollowpro Inhalt.
Headless verliert kein SEO — es verlagert die Verantwortung vom Plugin ins Frontend.
Anders gesagt: Die intellektuelle Arbeit, die in Ihrem SEO-Setup steckt, bleibt vollständig erhalten. Was wechselt, ist nur die Maschine, die diese Arbeit am Ende in HTML übersetzt.
Was übernimmt das Frontend neu?
Das Frontend übernimmt alles, was zuvor das Theme über die Plugins gerendert hat: Meta-Tags, XML-Sitemap, robots.txt, JSON-LD, OpenGraph-Bilder und Redirects. Bei Next.js erzeugt die Metadata API für jede Seite einen <head> aus den abgerufenen Yoast- oder Rank-Math-Daten. Hier liegt der eigentliche Aufwand einer Headless-Migration — und gleichzeitig die Chance auf ein saubereres Ergebnis.
Diese Aufgaben verlagern sich konkret ins Frontend:
- Meta-Tags — Titel, Description, Canonical und robots-Direktiven werden in der Next.js Metadata API gesetzt, gespeist aus den Plugin-Daten.
- XML-Sitemaps — statt der Yoast-Sitemap generiert das Framework die Sitemap aus den tatsächlich ausgelieferten Frontend-Routen.
- robots.txt — wird vom Frontend ausgeliefert und spiegelt die echte Crawl-Strategie der ausgelieferten Site.
- JSON-LD / Schema — die Schema-Felder aus dem Plugin werden als ein konsolidierter, kontrollierter Block neu ausgegeben.
- OpenGraph-Bilder — lassen sich dynamisch pro Seitentyp generieren, statt statisch im Plugin zu hängen.
- Redirects — die im klassischen Setup oft im Yoast-Premium-Redirect-Manager liegen, werden im Frontend oder auf der Hosting-Ebene abgebildet.
Der Aufwand ist real, aber einmalig: Sobald die Templates stehen, läuft jede neue Seite automatisch durch dieselbe SEO-Pipeline. Und das Ergebnis ist oft präziser als zuvor. Ein typisches Beispiel ist doppeltes oder veraltetes JSON-LD: Im klassischen Theme stapeln sich gern ein Article-Block vom SEO-Plugin, ein zweiter vom Theme und ein dritter von einem alten Schema-Plugin — drei @type: Article-Knoten auf einer Seite, die sich teils widersprechen. Im Headless-Frontend wird genau ein Block aus den gepflegten Plugin-Feldern erzeugt; die Altlasten entfallen, weil das Theme, das sie eingeschleust hat, nicht mehr existiert.
hreflang für Schweizer Sites: de-CH, fr-CH, it-CH sauber getrennt
Für Schweizer und DACH-Sites ist die Mehrsprachigkeit der Punkt, an dem die Headless-Architektur ihren grössten praktischen Vorteil ausspielt. Eine typische Konstellation: dieselbe Marke auf Deutsch für die Schweiz (de-CH) und für Deutschland (de-DE), dazu Französisch (fr-CH) und Italienisch (it-CH) für die übrigen Sprachregionen. Diese Varianten müssen über hreflang-Tags verknüpft sein, sonst konkurrieren de-CH und de-DE in der Suche miteinander statt sich zu ergänzen.
Im klassischen WordPress entsteht das hreflang-Geflecht aus dem Zusammenspiel mehrerer Plugins: Polylang oder WPML verwalten die Übersetzungen, das SEO-Plugin gibt die Tags im <head> aus. Bei WPML etwa muss dafür explizit die Option Display alternative languages in the HEAD section aktiviert sein, sonst fehlen die Tags (WPML-Dokumentation, Yoast SEO Multilingual); Polylang erzeugt die hreflang-Tags für verknüpfte Übersetzungen automatisch (Polylang, Yoast-SEO-Integration). Das funktioniert — hängt aber an der korrekten Konfiguration von zwei bis drei Plugins, und ein vergessener Self-Reference-Tag bringt das ganze Cluster ins Wanken.
Im Headless-Frontend übernimmt das die Next.js Metadata API über alternates.languages. Sie geben pro Seite die Sprachvarianten als Map an — { "de-CH": "...", "de-DE": "...", "fr-CH": "...", "it-CH": "..." } plus x-default —, und das Framework rendert daraus die <link rel="alternate" hreflang="…">-Tags samt Self-Reference auf allen Varianten (Next.js, generateMetadata-Referenz). Die Sprachzuordnung bleibt dabei in WordPress (Polylang/WPML als Übersetzungsverwaltung), die Tag-Ausgabe wird im Frontend kontrolliert und versioniert. Statt drei Plugins korrekt zu verzahnen, liegt die hreflang-Logik an einer Stelle im Code — nachvollziehbar und testbar. Die Plugin-Wahl und die hreflang-Feinheiten für den Schweizer Markt vertieft der Beitrag Headless WordPress mehrsprachig in der Schweiz.
Wo liegt welche SEO-Funktion im Headless-Setup?
Die folgende Übersicht ist die direkte Antwort auf die Migrations-Frage: Was liefert das Plugin weiter, und wer rendert es am Ende? Sie ist die Landkarte, die der Unsicherheit den Boden entzieht.
| SEO-Funktion | Liefert das Plugin (Yoast / Rank Math) | Wer rendert im Headless-Frontend |
|---|---|---|
| Meta-Titel & Description | Ja — pro Seite und Beitrag | Next.js Metadata API |
| Canonical-URL | Ja — inkl. manueller Overrides | Next.js Metadata API |
| robots (index/noindex) | Ja — als Direktive pro Inhalt | Metadata API + robots.ts |
| XML-Sitemap | Nein — Theme-gebunden | Framework (sitemap.ts) |
| robots.txt | Nein — Theme-gebunden | Framework (robots.ts) |
| Schema / JSON-LD | Ja — als Datenfelder | Frontend rendert JSON-LD neu |
| OpenGraph-Bilder | Referenz vorhanden | Frontend, dynamisch pro Typ |
| Redirects | Ja (Yoast Premium / Rank Math) | Frontend oder Hosting-Ebene |
Die Tabelle macht das Muster sichtbar: Was inhaltliche Daten sind, bleibt beim Plugin. Was Ausgabe-Logik ist, wandert ins Frontend. Diese Trennung ist kein Bug der Headless-Architektur — sie ist ihr Kern. Wie diese Schnittstelle technisch entsteht, vertieft der Beitrag WPGraphQL vs. REST API als Entscheidungshilfe.
SEO ist nur die halbe Miete — die Brücke zu KI-Suchmaschinen
Es gibt einen zweiten Grund, warum die Headless-Migration für SEO oft ein Gewinn ist, kein Risiko. Suchmaschinen wie ChatGPT, Perplexity und Gemini ziehen ihre Antworten zunehmend aus strukturierten Daten und sauberer Meta-Information. Genau diese beiden Bausteine kontrolliert ein Headless-Frontend präziser als ein theme-basiertes Setup mit gestapelten Plugins.
Saubere Canonicals, korrektes Article- und FAQ-Schema, eine Sitemap, die die echten Routen spiegelt — das sind die Signale, an denen KI-Suchmaschinen erkennen, ob ein Inhalt zitierfähig ist. Yoast und Rank Math liefern die Rohdaten dafür weiterhin; das Frontend gibt sie als einzelnen, eindeutigen Block aus. Welche konkreten Schritte einen Inhalt für diese Systeme zitierbar machen, behandelt der Beitrag Headless WordPress für KI-Suchmaschinen zitierbar machen.
Wichtig ist die Reihenfolge: Strukturierte Daten und saubere Meta sind die Basis, nicht die Kür. Wer beim Headless-Wechsel die Plugin-Daten sauber überträgt und das Frontend-Rendering korrekt aufsetzt, legt damit zugleich das Fundament für Sichtbarkeit in klassischen wie in KI-Suchmaschinen. Beides läuft über dieselbe Pipeline — und das ist der eigentliche Hebel.
Wie aufwändig ist die SEO-Migration auf Headless?
Der SEO-Anteil einer Headless-Migration ist überschaubar und einmalig: Die Plugin-Daten wandern unverändert mit, neu gebaut wird nur die Rendering-Pipeline im Frontend. Den grössten Aufwand fordert nicht das SEO selbst, sondern die saubere Redirect-Übertragung — der Punkt, an dem die meisten Migrationen scheitern.
Die Zahlen unterstreichen, warum dieser Punkt zählt: Studien zu Website-Migrationen beziffern den Traffic-Verlust durch fehlende oder fehlerhafte 301-Redirects auf 30 bis 50 Prozent, und nur etwa eine von zehn Migrationen verbessert die Rankings überhaupt (Numen Technology, Website Migration SEO). Der Verlust kommt fast nie aus der Architektur — er kommt aus der Sorgfalt der Umsetzung.
In eigenen Schweizer Projekten 2024–2026 verlief der SEO-kritische Teil typischerweise in drei Schritten: Redirect-Map und Canonical-Liste aus dem Backend exportieren, die Yoast- oder Rank-Math-Felder im Frontend-Template verdrahten, dann vor dem Go-live die <head>-Ausgabe Seite für Seite gegen den Altbestand abgleichen. Wo dieser Abgleich diszipliniert lief, blieben die Rankings nach Launch stabil — und die Sichtbarkeit zog mit den verbesserten Core Web Vitals oft sogar an.
Wie gestalten Sie den Übergang ohne Ranking-Verlust?
Rankings gehen nicht durch die Architektur verloren, sondern durch Migrationsfehler. Drei Punkte entscheiden über einen sauberen Übergang — und sie sind alle vermeidbar.
| Migrations-Risiko | Folge bei Vernachlässigung | Saubere Lösung |
|---|---|---|
| Redirects nicht übertragen | Alte URLs liefern 404, Linkkraft verloren | Vollständige Redirect-Map vor Launch, im Frontend abgebildet |
| Canonicals falsch gesetzt | Duplicate-Content-Signale, gesplittete Rankings | Yoast-Canonicals 1:1 in Metadata API übernehmen |
| Schema nicht neu gerendert | Verlust von Rich Results und Zitierfähigkeit | JSON-LD aus Plugin-Feldern im Frontend ausgeben |
Der häufigste Fehler ist der vergessene Redirect. Im klassischen WordPress verwalten viele Teams ihre Weiterleitungen im Yoast-Premium-Redirect-Manager — und übersehen beim Wechsel, dass diese Liste mitwandern muss. Eine vollständige Redirect-Map vor dem Launch ist die günstigste SEO-Versicherung, die es gibt. Weitere typische Fallstricke sammelt der Beitrag Stolperfallen bei der Headless-WordPress-Migration.
Wer diese drei Punkte ernst nimmt, erlebt die Migration nicht als Risiko, sondern als Aufräumen: Veraltete Redirects fallen auf, doppelte Canonicals werden bereinigt, das Schema wird konsolidiert. Die Site kommt sauberer aus der Migration heraus, als sie hineingegangen ist.
Nächster Schritt
Wenn Sie wissen wollen, wie Ihr aktuelles SEO-Setup beim Thema strukturierte Daten, Meta und Crawlbarkeit dasteht, liefert der kostenlose Website-Check in unter einer Minute eine erste Orientierung — ohne dass Sie Daten preisgeben müssen. Daraus ergibt sich oft schon, welche Yoast- oder Rank-Math-Felder beim Wechsel besonders sorgfältig übertragen werden sollten.
Wenn Sie die SEO-seitige Migration konkret durchsprechen wollen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos. In dieser Zeit klären wir, welche SEO-Daten Sie heute pflegen, wie diese im Headless-Frontend gerendert werden und worauf es bei Redirects und Canonicals ankommt.