WC-Sitemap für Web-Component-Detailseiten
Diese Anleitung richtet sich an Agenturen und Entwicklungsteams, die destination.one Web Components einbinden und deren Detailseiten über eine XML-Sitemap für Suchmaschinen auffindbar machen möchten.
Die WC-Sitemap wird zentral von destination.one bereitgestellt. Sie muss nicht auf dem Server der Agentur erzeugt oder gespeichert werden. Die Agentur trägt die passende URL lediglich in die robots.txt ihrer Website ein.
Voraussetzungen
Vor der Einrichtung müssen folgende Bedingungen erfüllt sein:
- Die Detailseiten sind öffentlich und ohne Anmeldung erreichbar.
- Jeder Detail-Deep-Link liefert direkt den HTTP-Status 200.
- Die Web Components verwenden für indexierbare Detailseiten den Router-Modus history.
- Der Webserver beziehungsweise das CMS liefert auch bei einem direkten Aufruf einer Detail-URL die Seite aus, auf der die Web Components eingebunden sind.
- language, experience und der Einhängepfad stimmen mit der Web-Component-Konfiguration überein.
- Die Detailseiten sind nicht durch robots.txt oder ein Robots-Meta-Tag mit noindex gesperrt.
- Die Canonical-URL einer Detailseite entspricht der URL, die in der Sitemap ausgegeben wird.
Eine passende Web-Component-Konfiguration sieht beispielsweise so aus:
- <script
- type="module"
- src="https://newpages.destination.one/web-components.js"
- data-language="de"
- data-experience="destination-one"
- data-template="wlan"
- data-router-mode="history"
- data-base-path="/erleben"
- ></script>
API-Endpunkt
Die Schnittstelle ist öffentlich und benötigt keine Authentifizierung.
Ein vollständiger Aufruf hat folgende Form:
Parameter
Parameter | Pflicht | Beschreibung |
baseUrl | ja | Öffentliche Basis-URL der Detailseiten inklusive Sprache und Einhängepfad. Der Wert muss als Query-Parameter URL-kodiert werden. |
dataType | ja | Datentyp, dessen Detailseiten ausgegeben werden sollen. |
experience | ja | Experience der Web-Component-Konfiguration. |
language | ja | Sprache der Meta-Daten und der erzeugten Slugs. |
page | nein | Interner Parameter für paginierte Unter-Sitemaps. Nicht manuell in die robots.txt eintragen. |
baseUrl
baseUrl muss eine absolute HTTP- oder HTTPS-URL sein und darf maximal 1.024 Zeichen lang sein. Ein Pfad ist erlaubt, Zugangsdaten, Query-Parameter und Fragmente sind nicht erlaubt. Abschließende Schrägstriche werden automatisch entfernt.
Empfohlen:
Nicht erlaubt:
Der Host und das Protokoll müssen der kanonischen Website entsprechen. Wenn die Website ihre Inhalte beispielsweise kanonisch unter
https://www.agentur.de ausliefert, darf nicht
https://agentur.de als
baseUrl verwendet werden.
Unterstützte Datentypen
- Area
- Article
- City
- Event
- Gastro
- Hotel
- Package
- POI
- Tour
Die Eingabe ist nicht von Groß- und Kleinschreibung abhängig. In den erzeugten URLs wird die oben aufgeführte kanonische Schreibweise verwendet.
Unterstützte Sprachen
- cs, da, de, en, es, fr, it, ja, nl, pl, ru, zh
Die Sprache beeinflusst die von Meta gelieferten Daten, Titel und damit die Slugs der Detail-URLs.
Experience
Die Experience muss mit dem Wert data-experience der Web-Component-Einbindung übereinstimmen.
Sie darf maximal 200 Zeichen lang sein.
Erzeugte Detail-URLs
Die Sitemap erzeugt URLs nach folgendem Schema:
- {baseUrl}/detail/{dataType}/{global_id}/{slug}
Beispiel:
Alle Pfadsegmente werden URL-kodiert. Der Slug wird aus dem sprachabhängigen Meta-Titel erzeugt:
- Umwandlung in Kleinbuchstaben
- Entfernen von Akzenten und diakritischen Zeichen
- Ersetzen anderer Zeichenfolgen durch `-`
- Entfernen führender und abschließender Bindestriche
- Begrenzung auf 120 Zeichen
Fehlt ein Titel oder ergibt sich daraus kein Slug, endet die URL nach der global_id.
Der Agentur-Webserver muss diese Deep-Links auf die Einbindungsseite der Web Components routen, ohne die URL im Browser auf die baseUrl zurückzuleiten. Bei einer Single-Page-Anwendung ist dafür typischerweise eine History-Fallback-Regel erforderlich. Bei einem CMS muss eine entsprechende Catch-all- beziehungsweise Rewrite-Regel für den Einhängepfad eingerichtet werden.
Einbindung in die robots.txt
Für jeden verwendeten Datentyp wird eine eigene Sitemap:-Zeile eingetragen. Mehrere Sitemap-Angaben in einer `robots.txt` sind zulässig.
Beispiel für https://www.agentur.de/robots.txt:
In der robots.txt werden normale & verwendet. Nur innerhalb einer XML-Ausgabe werden diese als & dargestellt.
Bei mehreren Sprachen oder unterschiedlichen Einhängepfaden wird pro Kombination aus baseUrl, dataType, experience und language eine eigene Sitemap:-Zeile benötigt.
Die Sitemap darf zentral auf api-prod-pages.neusta-ds.de liegen. Durch die Referenz in der robots.txt bestätigt die Agentur gegenüber unterstützenden Suchmaschinen die Zuordnung zu ihrer Website. Jede Sitemap darf dabei nur URLs der Website enthalten, in deren robots.txt sie eingetragen ist. Deshalb darf dieselbe Sitemap-URL nicht für verschiedene Agentur-Domains verwendet werden.
Paginierung und Sitemap-Index
Die Paginierung erfolgt automatisch:
- Bei 0 bis 1.000 Treffern liefert der API-Aufruf direkt ein <urlset>.
- Bei mehr als 1.000 Treffern liefert der API-Aufruf einen <sitemapindex>.
- Der Index verweist auf Unter-Sitemaps mit page=1, page=2 und so weiter.
- Jede Unter-Sitemap enthält maximal 1.000 Detail-URLs.
- Die Reihenfolge ist anhand der global_id stabil.
Beispiel eines Indexeintrags:
Die Agentur trägt nur den ursprünglichen Aufruf ohne page in die robots.txt ein. Die Unter-Sitemaps werden von Suchmaschinen über den Sitemap-Index gefunden.
Events
Für dataType=Event enthält die Sitemap nur Events im Zeitraum vom Zeitpunkt des API-Aufrufs bis zwei Jahre in die Zukunft. Count, Sitemap-Index und Unter-Sitemaps verwenden denselben Zeitraum.
lastmod
Wenn Meta ein gültiges Änderungsdatum im Feld changed liefert, wird es als <lastmod> ausgegeben:
Unterstützt werden ein gültiges Datum im Format YYYY-MM-DD oder ein gültiger W3C-/ISO-Zeitstempel mit Zeitzone. Fehlt ein zuverlässiges Änderungsdatum, wird <lastmod> weggelassen.
changefreq und priority werden bewusst nicht ausgegeben und sind keine unterstützten API-Parameter.
Berücksichtigung von seoNoindex
Die WC-Sitemap berücksichtigt die zentralen seoNoindex-Regeln aller Pages-Konfigurationen, die zur angegebenen Experience gehören:
- Eine Regel nur mit Datentyp entfernt den gesamten Datentyp aus der Sitemap.
- Eine Regel mit Datentyp und Kategorie entfernt nur Einträge dieser Kategorie.
- Bei mehreren passenden Pages-Konfigurationen werden die Ausschlüsse zusammengeführt.
Bei einem vollständig ausgeschlossenen Datentyp liefert der Hauptaufruf ein gültiges leeres <urlset>.
Antworten und Fehlercodes
Status | Bedeutung |
200 | Sitemap oder Sitemap-Index wurde erfolgreich erzeugt. |
400 | Pflichtparameter fehlt oder ein Parameter ist ungültig beziehungsweise unbekannt. |
404 | Eine explizit angeforderte page enthält keine Treffer. |
502 | Pages- oder Meta-Daten konnten vorübergehend nicht zuverlässig geladen werden. |
Erfolgreiche Antworten haben den Content-Type application/xml; charset=utf-8 und dürfen durch Browser, Proxies oder CDNs für fünf Minuten gecacht werden. Bei 502 sollte der Aufruf später erneut versucht werden.
Unbekannte Parameter werden abgelehnt.
SEO-Anforderungen an die Zielseiten
Eine Sitemap unterstützt Suchmaschinen beim Auffinden von URLs, garantiert aber keine Indexierung. Für jede ausgegebene Detailseite sollte zusätzlich geprüft werden:
- Die URL liefert ohne Cookies oder Anmeldung den Status 200.
- Googlebot und andere gewünschte Crawler werden nicht durch `robots.txt` blockiert.
- Die Seite enthält keinen unbeabsichtigten noindex-Robots-Meta-Tag.
- Die Canonical-URL entspricht exakt der URL aus der Sitemap.
- Seitentitel, Meta-Description, Überschriften und sichtbarer Detailinhalt sind vorhanden.
- Die Inhalte der Web Components können von Suchmaschinen gerendert werden.
- Interne Links verwenden dieselben Detail-URLs wie die Sitemap.
- Fehlerhafte oder nicht mehr vorhandene Inhalte liefern einen passenden Fehlerstatus und werden nicht dauerhaft als leere 200-Seite ausgeliefert.
Wenn
data-detail-link-mode="canonical" verwendet wird, können interne Links von dem hier beschriebenen URL-Schema abweichen. In diesem Fall muss vor der Sitemap-Einbindung sichergestellt werden, dass die Canonical-Links und die von der WC-Sitemap erzeugten URLs identisch sind (
Dokumentation).
Inbetriebnahme-Checkliste
- Web Components mit der richtigen Experience und Sprache einbinden.
- Für SEO-Detailseiten data-router-mode="history" und den passenden data-base-path verwenden.
- History-Fallback beziehungsweise CMS-Rewrite für direkte Detail-Aufrufe einrichten.
- Einen WC-Sitemap-Aufruf mit der endgültigen baseUrl im Browser testen.
- Eine ausgegebene Detail-URL in einem privaten Browserfenster direkt öffnen und Status 200, Inhalt sowie Canonical prüfen.
- Prüfen, dass Sitemap und Detailseiten öffentlich ohne Authentifizierung erreichbar sind.
- Pro Datentyp und Sprache eine Sitemap:-Zeile in der robots.txt ergänzen.
- Die veröffentlichte robots.txt direkt aufrufen und die Sitemap-Links testen.
- Sitemap beziehungsweise Sitemap-Index optional in Google Search Console und Bing Webmaster Tools kontrollieren.
- Nach der ersten Verarbeitung die gemeldeten Sitemap- und Indexierungsfehler beobachten.