Sitemap und Canonical bei headless WordPress: eine Quelle der Wahrheit, ausgeliefert vom Frontend
Die Aufnahme in eine Sitemap ist ein schwaches Canonical-Signal; Weiterleitungen und rel=canonical sind stärker. Weitere Hinweise zur Umsetzung: SEO-Muster für headless WordPress, lautlos brechen.
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
Erzeugen Sie die Sitemap aus einem vollständigen Inventar öffentlicher Routen und geben Sie einen Canonical im HTML-Head aus. Das Inventar kann vom Frontend oder einem korrekt konfigurierten Backend stammen. Mehrere konsistente untergeordnete Sitemaps sind zulässig.
Warum haben headless WordPress-Websites am Ende zwei Sitemaps
WordPress bietet Core-Sitemaps seit Version 5.5. Die Verfügbarkeit hängt von Konfiguration und Filtern ab; SEO-Plugins können den Core-Anbieter deaktivieren. Prüfen Sie tatsächliche Endpunkte. Drei gleichzeitige Generatoren sind nicht unvermeidlich.
/wp-sitemap.xmlaus dem WordPress-Core./sitemap_index.xmlaus Yoast oder Rank Math./sitemap.xmlaus dem Frontend-Framework.
Mehrere Sitemaps können korrekt nebeneinander bestehen. Widersprüchliche öffentliche URL-Inventare benötigen Korrekturen. Google wählt indexierte Seiten nicht allein anhand der Reihenfolge des Sitemap-Abrufs.
Alle aktiven Sitemaps sollten ein konsistentes Inventar öffentlicher Routen verwenden. Deaktivieren Sie unnötige Origin-Generatoren oder leiten Sie deren XML passend weiter. Mehrere untergeordnete Sitemaps können innerhalb eines Index mit 200 antworten.
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.
Geben Sie den Canonical im ursprünglichen HTML-Head über Layout oder Metadaten-API aus. Google unterstützt per JavaScript erzeugte Canonicals, empfiehlt aber eindeutige Signale ohne spätere Änderungen. Die ursprüngliche Ausgabe erleichtert reproduzierbare Release-Tests.
Gleichen Sie SEO-Metadaten mit dem öffentlichen Routenplan ab. Yoast hat eine dokumentierte REST API; andere Plugins benötigen eine eigene unterstützte Integration. Canonical-Ausgaben verwenden nicht automatisch die öffentlichen Headless-Adressen.
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
Filter brauchen eine ausdrückliche Indexierungsrichtlinie. Canonical gilt für echte Duplikate, noindex für einen gewünschten Ausschluss. Setzen Sie beides nicht pauschal auf sämtliche Filter.
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.
Öffentliche URLs vor dem Metadatenabruf festlegen
WordPress speichert Beitragskennungen und eigene Permalinks. Ein Headless-Frontend kann andere Sprachpräfixe, Kategoriepfade und Regeln für abschließende Schrägstriche verwenden. Definieren Sie daher zuerst die Zuordnung von Beitrags-ID und Sprache zur öffentlichen URL. Diese Zuordnung gehört zur Anwendungskonfiguration. Ein Austausch des Hostnamens reicht nicht aus, wenn sich auch der Pfad ändert. Eine hierarchische WordPress-Seite kann im Frontend eine flache Route erhalten, während ein Produkt einen übersetzten Kategorieabschnitt benötigt.
Verwenden Sie denselben Resolver für interne Links, Sitemap-Einträge, Canonical-Tags, hreflang-Verweise und Kennungen in strukturierten Daten. Damit verhindern Sie, dass mehrere Funktionen für denselben Inhalt unterschiedliche Adressen erzeugen. Redaktionelle Canonical-Ausnahmen bleiben ausdrücklich erhalten. Bei syndizierten Beiträgen kann das gewünschte Ziel auf der Website eines Partners liegen. Eine pauschale Ersetzung aller Hostnamen würde diese Entscheidung überschreiben. Prüfen Sie externe Ziele getrennt von der normalen Zuordnung eigener Seiten und schließen Sie Vorschau- sowie Entwicklungsdomains aus.
Die REST API von Yoast liefert SEO-Ausgaben für WordPress-Adressen. Diese Ausgabe passt nicht automatisch zu einer abweichenden Routenstruktur. Entscheiden Sie, ob das Frontend strukturierte Felder verarbeitet oder geprüfte HTML-Ausgabe aus einer Integration übernimmt. Geben Sie nicht einen vollständigen SEO-Head aus und ergänzen daneben einen zweiten Canonical im Layout. Prüfen Sie die tatsächliche Antwort, denn ein korrektes Datenobjekt kann durch zwei Komponenten doppelt ausgegeben werden.
Ein vollständiges Inhaltsinventar erzeugen
Der Generator muss sämtliche benötigten API-Seiten abrufen. Die erste Antwort einer Beitragsliste ist kein vollständiges Inventar. Taxonomien benötigen eine eigene Erfassung, wenn das Frontend dafür brauchbare Archivseiten bereitstellt. Protokollieren Sie die Zahl der eingelesenen Datensätze und vergleichen Sie diese mit dem letzten erfolgreichen Build. Bricht die Verbindung während der Pagination ab, stoppen Sie die Veröffentlichung oder behalten Sie das vorherige vollständige Artefakt. Eine verkürzte Sitemap als erfolgreichen Abruf zu veröffentlichen verdeckt den Integrationsfehler.
Das Inventar darf nur öffentliche Routen enthalten, die tatsächlich existieren. Ein veröffentlichtes WordPress-Medium, ein Autor oder ein Begriff erzeugt nicht automatisch eine Seite im Headless-Frontend. Nehmen Sie die URL erst nach Festlegung von Template und Indexierungsrichtlinie auf. Entwürfe, angemeldete Bereiche, interne Suchergebnisse, Weiterleitungsquellen und absichtlich ausgeschlossene Seiten gehören nicht hinein. Speichern Sie für ausgeschlossene Datensätze einen Grund. Damit kann die Redaktion eine bewusste Entscheidung von einem fehlenden API-Ergebnis unterscheiden.
Die Sitemap-Dokumentation von Google nennt eine Grenze von 50.000 URLs oder 50 MB unkomprimiert pro Datei. Größere Inventare werden aufgeteilt und über einen Sitemap-Index veröffentlicht. Mehrere untergeordnete Dateien sind normale Organisation und erleichtern die Auswertung verschiedener Sammlungen. Verwenden Sie vollständige öffentliche URLs und korrektes XML-Escaping. Ein unmaskiertes kaufmännisches Und kann XML ungültig machen, obwohl der Browser die entsprechende Adresse aufruft.
Lastmod sollte eine relevante Änderung am Inhalt oder an den Metadaten wiedergeben, sofern ein zuverlässiger Zeitpunkt verfügbar ist. Der Build-Zeitpunkt beschreibt die Veröffentlichung des Artefakts und beweist keine Änderung jedes Beitrags. Wenn jeder Deploy sämtliche Werte ersetzt, verlieren sie ihren Informationswert. Legen Sie auch fest, ob eine technische Aktualisierung durch einen Importer tatsächlich sichtbare Inhalte geändert hat. Dieselbe Entscheidung sollte in Sitemap und Artikelmetadaten gelten.
Löschung, Canonical und Crawling unterscheiden
Ein Canonical benennt die bevorzugte Adresse unter identischen oder sehr ähnlichen Seiten. Er leitet Besucher nicht weiter und garantiert keine Auswahl durch Google. Eine dauerhafte Weiterleitung passt, wenn eine alte öffentliche URL durch einen entsprechenden Inhalt ersetzt wurde. Eine echte Löschung ohne Ersatz kann 404 oder 410 zurückgeben. Alle entfernten Beiträge auf die Startseite weiterzuleiten erschwert die Feststellung, welche Inhalte bei einer Migration verloren gingen.
Noindex eignet sich für öffentlich erreichbare Seiten, die nicht in Suchergebnissen erscheinen sollen. Google muss die Seite abrufen können, um die Anweisung zu lesen. Das erläutert die Noindex-Dokumentation. Eine gleichzeitige Sperre in robots.txt kann diesen Abruf verhindern. Disallow steuert Crawling und ersetzt keine Zugriffskontrolle. Schützen Sie private Verwaltung und Vorschauinhalte durch Authentifizierung, denn Crawler-Anweisungen verhindern keinen Zugriff durch Menschen.
Hat der Origin zuvor öffentliche Beiträge ausgeliefert, wählen Sie Weiterleitungen zu den entsprechenden Frontend-Adressen oder eine klare Canonical-Regel für weiterhin erreichbare Seiten. Eine Weiterleitung der XML-Datei leitet deren frühere Artikel nicht weiter. Prüfen Sie einzelne alte URLs und interne Links. Dient WordPress ausschließlich als Inhalts-API, beschränken Sie unnötige öffentliche Templates, ohne die benötigten API-Endpunkte zu sperren.
Pagination und Sprachfassungen vollständig verbinden
Jede brauchbare Archivseite enthält andere Einträge und erhält normalerweise einen eigenen Canonical. Google nutzt rel=prev und rel=next nicht mehr zur Erkennung von Pagination, wie die Pagination-Dokumentation erklärt. Bieten Sie anklickbare HTML-Links zu Folgeseiten an. Ein Button, der Ergebnisse nur per JavaScript anhängt, eröffnet dem Crawler keinen gleichwertigen Weg. Testen Sie die letzte gültige Seite und Anfragen außerhalb des Bereichs, damit leere Listen nicht unbegrenzt mit 200 antworten.
Die Sprachzuordnung muss sich gemeinsam mit den Veröffentlichungen ändern. Ein deutscher Artikel sollte nicht allein deshalb auf die englische Fassung kanonisieren, weil diese als Ausgangstext diente. Hreflang-Verweise gelten für tatsächlich veröffentlichte Entsprechungen. Jede Sprache verweist auf die kanonische öffentliche Adresse ihres Artikels. Entfernen Sie eine Übersetzung, aktualisieren Sie auch die übrigen Fassungen und die Sprach-Sitemap. Die deutsche Startseite ist keine gleichwertige Ersatzfassung eines entfernten technischen Beitrags.
Filter brauchen eine Entscheidung für den konkreten Katalog. Eine dauerhafte Kategorienseite mit eigenem Text und sinnvoller Produktauswahl kann eigenständig indexierbar sein. Eine andere Sortierung derselben Liste kann auf die Hauptansicht verweisen. Interne Suchergebnisse lassen sich ausschließen. Eine pauschale Kombination aus Canonical und noindex ignoriert diese Unterschiede. Dokumentieren Sie erlaubte Parameter, Normalisierung und Indexierungsabsicht, bevor Sie zusätzliche Filter in den Router aufnehmen.
Artefakt und Produktionsantwort prüfen
Ein Routenmanifest enthält angefragte URL, erwarteten Status, Canonical-Ziel und Indexierbarkeit. Vergleichen Sie es mit dem generierten XML und dem HTML-Artefakt. Für jeden Sitemap-Eintrag prüfen Sie eine nutzbare Seite ohne noindex und mit dem erwarteten Canonical. Für entfernte Routen prüfen Sie Weiterleitung oder Löschstatus. Nehmen Sie Umlaute, kodierte Pfade und verschachtelte Seiten in die Stichprobe auf. Ein Test nur mit der Startseite übersieht Fehler in der Slug-Zuordnung.
Wiederholen Sie die Kontrollen nach dem Deploy auf der Produktionsdomain. Ein Vorschauartefakt kann korrekt sein, während das CDN Schrägstriche umschreibt, älteres HTML liefert oder einen unerwarteten X-Robots-Tag setzt. Vergleichen Sie HTTP-Header und ursprüngliches HTML. Verändern Clientskripte Metadaten, prüfen Sie zusätzlich den gerenderten Zustand. Speichern Sie die Release-Kennung im Betriebsbericht, damit die SEO-Prüfung neue Dateien von zwischengespeicherten früheren Antworten unterscheiden kann.
Search Console zeigt den angegebenen Canonical und nach der Indexierung auch die Auswahl von Google. Eine Abweichung verlangt die Prüfung von Duplikaten, Weiterleitungsketten, interner Verlinkung und Erreichbarkeit des Zielartikels. Sie beweist keine Konkurrenz zwischen zwei XML-Dateien. Beginnen Sie mit der betroffenen Adresse und ihren Varianten. Nach Korrekturen braucht Google Zeit zum erneuten Abruf. Ein erfolgreicher Deploy aktualisiert die gespeicherte Interpretation der Suchmaschine nicht sofort.
Bei der Migration eines deutschen Katalogs verdienen historische Umlautvarianten eine eigene Prüfung. Prüfen Sie Adressen aus alten Importen gegen die aktuelle Router-Normalisierung. Zwei optisch ähnliche Slugs können unterschiedliche kodierte Zeichen enthalten. Behalten Sie das vorherige Manifest für den nächsten Import, damit eine veränderte URL-Aufbereitung nicht unbemerkt den Umfang öffentlicher Seiten verändert.
Abhängigkeiten bei einer Slug-Änderung
Eine geänderte Slug betrifft auch Kategoriearchive, Empfehlungen und Sprachverweise. Aktualisieren Sie diese Abhängigkeiten zusammen mit dem Artikel. Werden Sitemap und HTML getrennt erzeugt, muss der Webhook beide Aufgaben anstoßen oder dieselbe Inhaltsversion veröffentlichen. Andernfalls kann XML eine neue Route nennen, die das aktive Frontend noch nicht bereitstellt.
Speichern Sie alte und neue Adresse im Änderungsereignis. Die Beitrags-ID findet den neuen Datensatz, rekonstruiert nach dessen Überschreibung aber nicht zuverlässig den früheren Pfad. Wiederholte Zustellung muss dieselbe Weiterleitung erzeugen. Prüfen Sie außerdem den Fall, dass die Redaktion den Slug erneut ändert, bevor der vorherige Build abgeschlossen ist. Das Ziel sollte die endgültige öffentliche Adresse sein.
Prüfen Sie bei PDF-Dateien zusätzlich den HTTP-Link-Header mit rel=canonical. Eine PDF hat keinen HTML-Head, deshalb bestätigt ein Test für Artikel diesen Hinweis nicht. Entscheiden Sie getrennt, ob das Dokument in die Sitemap gehört und welche öffentliche Adresse seine bevorzugte Version ist.
