Sitemap und Canonical bei headless WordPress: eine Quelle der Wahrheit, ausgeliefert vom Frontend

#Sitemap und Canonical bei headless WordPress: eine Quelle der Wahrheit, ausgeliefert vom Frontend

Zwei der sieben SEO-Muster für headless WordPress verdienen einen eigenen Artikel, weil sie zuerst brechen und lautlos brechen. Sitemap und kanonische URL sind die beiden Signale, denen Google am meisten vertraut, wenn es um die Fragen geht, was diese Website ist und welche URL die echte ist. Ein headless Build, der eines davon falsch macht, verliert genau die Rankings, die die Migration erhalten sollte.

Dieser Artikel macht das Muster konkret. Er setzt voraus, dass die Architekturentscheidung (Astro oder Next.js gemäß Entscheidungsmatrix) bereits gefallen ist.

#Was ist das Muster für Sitemap und Canonical bei headless in einem Absatz?

Das Frontend-Framework erzeugt die Sitemap, mit URLs, die der tatsächlichen öffentlichen Website entsprechen. Die kanonische URL wird als <link rel="canonical"> im HTML-Head gerendert: Die Daten stammen aus WordPress (Yoast oder Rank Math), ausgegeben werden sie vom Frontend. Sitemap und Canonical des WordPress-Origins werden deaktiviert oder per 301 umgeleitet. Eine Sitemap, ein Canonical pro Seite, beides serverseitig gerendert.

#Warum haben headless WordPress-Websites am Ende zwei Sitemaps?

WordPress 5.5 hat /wp-sitemap.xml als Core-Funktion eingeführt. Seitdem ist sie in jeder WordPress-Installation standardmäßig aktiv. SEO-Plugins (Yoast, Rank Math) erzeugen eigene Sitemaps, die die Core-Sitemap ersetzen oder ergänzen. Ein headless Build, der das ignoriert, hat am Ende drei Sitemaps auf demselben Hostnamen:

1. /wp-sitemap.xml aus dem WordPress-Core.
2. /sitemap_index.xml aus Yoast oder Rank Math.
3. /sitemap.xml aus dem Frontend-Framework.

Die Search Console sieht Überschneidungen, meldet manchmal Inkonsistenzen, und welche URLs tatsächlich indexiert werden, hängt davon ab, welche Sitemap Google an diesem Tag zuerst liest. Die Lösung ist mechanisch:

• Das Frontend-Framework erzeugt die kanonische Sitemap unter einem bekannten Pfad (wir verwenden /sitemap-index.xml, weil Cloudflare Pages sie sauber ausliefert).
• Die Sitemap des WordPress-Origins wird deaktiviert (Yoast und Rank Math haben beide einen Schalter dafür) oder per 301 auf die Frontend-Sitemap umgeleitet.
• Auch die Core-Sitemap unter /wp-sitemap.xml wird per 301 auf das Frontend-Gegenstück umgeleitet.

Nach der Umstellung antwortet nur noch eine Sitemap mit 200 OK. Der Rest liefert 301 oder 404.

#Wie bauen Sie die Frontend-Sitemap bei headless WordPress?

Für ein Frontend mit Astro oder Next.js gibt es zwei echte Optionen:

Erzeugung zur Build-Zeit. Der Frontend-Build holt während des Builds die URLs aller veröffentlichten Beiträge, Seiten und Terms vom WordPress-Origin, sortiert sie und gibt das XML aus. Das funktioniert für Websites mit planbarem Veröffentlichungsrhythmus (die meisten). Die Cache-Invalidierung erledigt ein Rebuild, der bei jeder Veröffentlichung ausgelöst wird.

Auf Anfrage am Edge. Eine Cloudflare-Worker-Route erzeugt die Sitemap bei jeder Anfrage und liest dazu eine gecachte URL-Liste, die der WordPress-Origin bei jeder Veröffentlichung per Webhook schickt. Das passt zu Websites mit so hoher Veröffentlichungsfrequenz, dass die Rebuild-Dauer zum Problem würde.

Standardmäßig setzen wir auf die Erzeugung zur Build-Zeit. Das Worker-Muster reservieren wir für Websites, die mehr als ein paar Mal pro Stunde veröffentlichen.

#Wie wird die kanonische URL in einem headless Frontend gerendert?

Die kanonische URL muss im HTML-Head stehen, in der ersten Serverantwort, bevor irgendein clientseitiges Skript läuft. Das Muster:

<link rel="canonical" href="https://example.com/headless-wordpress-for-woocommerce/" />

Drei Regeln.

Erstens: serverseitig rendern. Astro rendert sie aus dem Frontmatter der Seite oder aus dem Layout. Next.js rendert sie aus metadata (App Router) oder aus <Head> in Pfaden mit getServerSideProps. Vermeiden Sie es, die kanonische URL in einem Client-Effekt zu aktualisieren: Generative Suchmaschinen und viele AEO-Oberflächen werten nur das initiale HTML aus.

Zweitens: aus WordPress beziehen. Yoast und Rank Math stellen die kanonische URL je Beitrag über REST bereit. Das Frontend holt sie während des Builds (oder pro Anfrage) und rendert sie ins HTML. WordPress bleibt die Quelle der Wahrheit.

Drittens: standardmäßig selbstreferenzierend. Jede URL erklärt sich selbst als kanonisch, außer es gibt einen ausdrücklichen Grund, auf eine andere zu verweisen (paginierte Archive, parametrisierte gefilterte URLs, syndizierte Inhalte). Wenn Sie auf eine andere URL verweisen, zeigt das Canonical des Ziels auf sich selbst.

#Welche Grenzfälle bei Sitemap und Canonical beschädigen headless SEO?

• Uneinheitlicher Schrägstrich am Ende. WordPress-Permalinks enden meist mit /. Das Frontend-Framework arbeitet unter Umständen standardmäßig ohne Schrägstrich. Entscheiden Sie sich für eine Variante, leiten Sie die andere um und lassen Sie nie beide existieren.
• HTTP oder HTTPS, www oder Apex-Domain. Wird meist am CDN gelöst, aber die kanonische URL muss die gewählte Variante deklarieren. Wir deklarieren https:// auf der Apex-Domain; alles andere wird per 301 dorthin umgeleitet.
• Gefilterte URLs (facettierte Katalogsuche). Sie erzeugen oft tausende dünne URL-Varianten. Ihr Canonical zeigt auf die ungefilterte Basis-URL; zusätzlich haben sie noindex, damit sie nicht in die Sitemap gelangen.
• Paginierte Archive. Seite 2, Seite 3 und folgende haben jeweils ein Canonical auf sich selbst, mit rel="prev" und rel="next" zur Klarheit. Manche Teams setzen das Canonical auf Seite 1; damit fallen eigenständige Seiten aus dem Index. Wir raten davon ab.
• Übersetzte Inhalte. Jede Sprachversion hat ein Canonical auf sich selbst, mit <link rel="alternate" hreflang="..."> für die übrigen Versionen. Die hreflang-Zuordnung ist selbstreferenzierend und muss über alle Sprachversionen hinweg übereinstimmen.

#Wie prüfen Sie Sitemap und Canonical vor dem Go-live?

Zwei Prüfungen, die wir bei jedem headless WordPress-Build ausführen:

Sitemap-Abgleich. Erzeugen Sie die neue Sitemap und vergleichen Sie die URL-Menge mit der bisherigen WordPress-Sitemap. Alles, was in der neuen fehlt, ist eine inhaltliche Lücke. Alles Neue ist verdächtig, eine Regression zu sein (oft ein durchgesickerter Entwurf oder privater Beitrag).

Canonical-Stichprobe. Rufen Sie für 50 Seiten mit dem meisten Traffic die URL im neuen Frontend auf und prüfen Sie, ob das Canonical im HTML-Head der URL selbst entspricht (oder dem erwarteten Ziel, wenn es absichtlich auf eine andere Seite verweist). Eine Abweichung ist ein Bug; zehn Abweichungen sind ein Muster, bei dem der Frontend-Build erneut geprüft werden muss.

Beide Prüfungen laufen in der CI. Ein neuer Build, der an einer davon scheitert, wird nicht deployt.

#Weiterführende Artikel zu SEO bei headless WordPress

Verankert in der Checkliste der SEO-Muster für headless WordPress. Ergänzt den Leistungsbereich headless WordPress und die Entscheidungsmatrix Next.js vs Astro für die übergreifenden Entscheidungen zur Build-Zeit.