SEO-Muster für headless WordPress: die sieben Dinge, die die meisten Migrationen kaputt machen
Headless WordPress wird über Core Web Vitals, Wiederverwendung von Inhalten und redaktionelles Tempo verkauft. Wenn niemand aufpasst, begräbt es dabei sieben konkrete SEO-Signale. Wir haben genug dieser Migrationen umgesetzt, um zu wissen, welche davon Wochen an Erholung kosten und welche sich rein mechanisch richtig halten lassen.
Dieser Artikel ist die Checkliste. Er ersetzt nicht den Leistungsbereich headless WordPress, der die architektonische Begründung liefert. Er beschreibt, was wir vor, während und nach jeder Migration prüfen, in genau dieser Reihenfolge.
Kurz zusammengefasst
- Bewahren Sie kanonische URLs auf Ebene der ganzen URL, nicht nur des Slugs.
- Bewahren Sie hreflang im HTML, nicht nur in der Sitemap.
- Rendern Sie Meta-Tags und JSON-LD auf dem Server, nicht im Client.
- Migrieren Sie die Weiterleitungshistorie, bevor Sie URLs ändern, nicht danach.
- Halten Sie eine Sitemap als Quelle der Wahrheit, nicht zwei.
- Machen Sie den WordPress-Origin für den Suchindex unsichtbar.
- Übernehmen Sie Alt-Texte und strukturierte Bilddaten.
Wie Sie kanonische URLs bei einer headless-Migration halten
Eine kanonische URL ist ein Versprechen. Jeder externe Link, jeder Eintrag im Google-Index, jedes Teilen in sozialen Netzwerken verlässt sich darauf. Eine headless-Migration, die stillschweigend ein Pfadsegment kürzt, die Groß- und Kleinschreibung ändert oder Query-Parameter umsortiert, hat jedes dieser Versprechen gebrochen, ohne dass es jemand merkt.
Zwei Regeln. Erstens: Erfassen Sie den vollständigen Satz kanonischer URLs aus der bisherigen WordPress-Installation, bevor Sie das Frontend anfassen. Wir exportieren jeden veröffentlichten Beitrag, jede Seite und jede Taxonomieseite mit der URL, die Google indexiert hat; das ist die Quelle der Wahrheit. Zweitens: Schreiben Sie das Canonical in die HTML-Antwort des headless-Frontends, nicht in eine clientseitige Änderung des <head>. Generative Engines und Answer Engines parsen das initiale HTML; clientseitig geänderte Meta-Tags existieren für sie nicht.
Wenn Sie eine URL ändern müssen, leiten Sie per 301 von der alten auf die neue weiter und behalten Sie das mindestens ein Jahr lang bei.
Hreflang-Tags im HTML von headless WordPress
Mehrsprachige WordPress-Websites verwalten Übersetzungen mit WPML, Polylang oder einer eigenen Lösung. In der Datenbank stimmt die Zuordnung am Ende. Das headless-Frontend muss dann für jede Sprachvariante <link rel="alternate" hreflang="..."> in der HTML-Antwort rendern.
Das Muster, das die meisten Agenturen übersehen: hreflang muss selbstreferenzierend sein. Die englische Seite führt sich selbst und alle übersetzten Alternativen auf. Die polnische Seite führt sich selbst und alle Alternativen auf. Beide Listen stimmen überein. Werkzeuge wie der Bericht zur internationalen Ausrichtung in der Search Console melden die Abweichung, sobald eine Seite etwas vergisst.
Wir behandeln die hreflang-Erzeugung als Teil des Builds, nicht als Laufzeitentscheidung. Die Pfadzuordnung wird beim Build berechnet und gehasht, und jede Abweichung lässt den Build scheitern.
Serverseitiges Rendern von Meta-Tags und JSON-LD
Die häufigste SEO-Regression, die wir bei headless-Migrationen gesehen haben: Meta-Tags und JSON-LD, die nach dem Laden der Seite per JavaScript eingefügt werden. Der Browser sieht sie. Der Googlebot sieht sie manchmal. Generative Engines, Sprachassistenten und die meisten LLM-Crawler sehen sie in der Regel nicht.
Zwei Regeln. Rendern Sie Meta-Tags, Canonical, Open Graph und jeden Schema.org-JSON-LD-Block in der initialen HTML-Antwort. Mit Astro ist das der Standard. Mit Next.js bedeutet das, auf dem Server zu rendern (Metadaten im App Router oder der ältere Weg über getServerSideProps) und sich nicht darauf zu verlassen, dass next/head im Client erneut läuft.
Dasselbe gilt für Bilder: Ein <img>-Element mit alt und src im HTML ist indexierbar. Ein <img>, das erst nach einem Client-Effekt eingefügt wird, ist für die meisten Crawler und für Pipelines von KI-Trainingsdaten unsichtbar.
Yoast-JSON-LD in headless WordPress wiederverwenden
WordPress mit Yoast SEO oder Rank Math erzeugt bereits gutes JSON-LD für Article, Product und Organization. Bei einer headless-Migration ist die Versuchung groß, es im Frontend von Grund auf neu zu schreiben. Widerstehen Sie ihr.
Lesen Sie das vorhandene JSON-LD über den REST- oder GraphQL-Endpunkt aus dem WordPress-Origin. Reichen Sie es durch. Ergänzen Sie nur, was das Frontend tatsächlich weiß und WordPress nicht (zum Beispiel Build-Zeitstempel für dateModified, wenn Ihr redaktioneller Ablauf die Daten nicht anfasst). Zwei Systeme, die sich überschneidendes JSON-LD erzeugen, sind der Weg, auf dem die Berichte zu Rich-Suchergebnissen in der Search Console anfangen zu scheitern.
Für unsere eigenen Seiten nutzen wir die Komponenten aus Phase 0 in src/components/seo/: DirectAnswer, FAQ und Quote. Jede gibt ihr eigenes, minimales JSON-LD aus, ohne sich mit dem Article-Schema der Seite zu überschneiden.
Wie Sie Weiterleitungen vor einer URL-Änderung migrieren
Die Reihenfolge zählt. Die Checkliste vor der Migration erfasst jede interne und externe Weiterleitung, auch die stillen (/wp-content/... nach /uploads/..., Weiterleitungen nach Ländercode, AMP-Varianten). Das neue Frontend liefert diese Weiterleitungen am Tag null aus, bevor öffentlich auf die neuen URLs umgestellt wird.
Auf Cloudflare Pages halten wir die Datei _redirects unter der Plattformgrenze von 2000 Regeln. Ein Build, der die Grenze überschreiten würde, scheitert. Alles, was mehr als 2000 Regeln braucht, landet stattdessen in einem Worker mit Logik für parametrisierte Weiterleitungen.
Wenn das öffentliche DNS schließlich auf das neue Frontend umschaltet, ist in der Produktion keine Weiterleitung neu: Jede Regel wurde vor der Umstellung wochenlang im Build getestet.
Eine XML-Sitemap für headless WordPress
WordPress 5.5 hat eine Standard-/wp-sitemap.xml eingeführt. Yoast SEO und Rank Math bringen eigene Sitemaps mit. Das Frontend-Framework im headless-Setup erzeugt ebenfalls eine Sitemap. Drei Sitemaps auf derselben Domain sind ein sicherer Weg, die Search Console zur Verzweiflung zu bringen.
Die Regel: Wählen Sie eine kanonische Sitemap und deaktivieren oder leiten Sie die anderen weiter. Wir erzeugen die Sitemap in der Regel im Frontend-Framework, damit die URLs exakt zur öffentlichen Website passen, und leiten die Sitemap des WordPress-Origins per 301 auf die des Frontends um. Der WordPress-Origin wird damit für Suchmaschinen unsichtbar.
Wie Sie das Backend von headless WordPress auf noindex setzen
Eine headless-Migration lässt den WordPress-Origin weiterlaufen, meist auf einer Subdomain oder einem privaten Hostnamen. Er liefert weiterhin gerendertes HTML aus, hat eine funktionierende Sitemap und beantwortet REST-Anfragen. Suchmaschinen, die diesen Origin finden, indexieren ihn als Duplikat der öffentlichen Website, und das Duplikat wird nicht dasjenige sein, das rankt.
Drei Kontrollen. Die robots.txt des Origins sperrt alle Pfade außer den REST- und GraphQL-Endpunkten. Der Origin sendet bei jeder HTML-Antwort X-Robots-Tag: noindex, nofollow in den HTTP-Headern. Die Sitemap des Origins wird entfernt oder liefert 410.
Liegt Ihr Origin unter einem Pfadpräfix auf derselben Domain wie die öffentliche Website (zum Beispiel /wp-admin/ oder /wp/), gelten dieselben Kontrollen, beschränkt auf diese Pfade.
Weitere Leitfäden zu SEO für headless WordPress
Dieser Artikel ergänzt den Leistungsbereich headless WordPress. Für die Entscheidungsphase lesen Sie Headless WordPress, Next.js vs Astro 2026. Die größere Sichtbarkeitsfrage einschließlich LLM-Zitaten behandelt der Leitfaden zur Sichtbarkeit in KI und LLMs: Er beschreibt verbindlich, was wir für AEO und GEO auf diesem SEO-Fundament umsetzen.
