Eine XML-Sitemap für einen Onlineshop ist eine Datei, die die Produkt-, Kategorie- und Content-URLs auflistet, die Suchmaschinen finden sollen: eine kanonische URL pro Seite, mit einem korrekten Datum der letzten Änderung. Eine einzelne Sitemap-Datei fasst höchstens 50.000 URLs oder 50 MB unkomprimiert. Ein großer Katalog verteilt seine URLs deshalb auf mehrere Dateien und listet diese in einem Sitemap-Index, den du einmal in der Google Search Console einreichst.
Das ist die kurze Antwort. Die eigentliche Arbeit im Shop ist die Entscheidung, was hineingehört: Varianten, gefilterte Kategorieseiten, ausverkaufte Produkte, eingestellte Produkte und jede Sprachversion. Liegst du dabei falsch, meldet die Sitemap Google Tausende Seiten, die du gar nicht im Index haben willst, während Produkte fehlen, die dort hingehören. Dieser Leitfaden geht jede Entscheidung durch, zeigt, was Shopify, WooCommerce und Magento standardmäßig erzeugen, und erklärt, wie du eine Sitemap mit dem Katalog abgleichst, den sie abbilden soll.
Welche Shop-URLs in die XML-Sitemap gehören
Eine Sitemap ist eine Liste der URLs, die du bevorzugt in den Suchergebnissen sehen willst. Sie sollte also nur Seiten enthalten, die den Status 200 liefern, indexierbar sind und auf sich selbst kanonisieren. In diesem Leitfaden geht es um die XML-Sitemap für Suchmaschinen; eine HTML-Sitemap als Übersichtsseite für Kundinnen und Kunden ist eine eigene, optionale Seite. Für einen Shop heißt das:
- Rein: Produktseiten (eine URL pro Produkt oder pro Variante, wenn jede Variante eine eigene kanonische Seite hat), Kategorie- und Kollektionsseiten, Markenseiten, Kaufberatungen, Blogartikel und die statischen Seiten, nach denen Leute suchen, etwa Versand und Rückgabe.
- Raus: Filter- und Sortier-URLs (?color=red&sort=price), interne Suchergebnisse, Warenkorb, Checkout und Kundenkonto, URLs mit Weiterleitung, Seiten mit noindex-Tag und jede URL, deren Canonical auf eine andere Seite zeigt.
- Prüfen: paginierte Kategorieseiten. Nimm sie nur auf, wenn sie indexierbar sind und auf sich selbst kanonisieren; viele Shops lassen sie weg und verlassen sich auf interne Links.
Google verlangt in Sitemaps vollständige, absolute URLs (Google Search Central) und dieselbe URL in internen Links, Sitemaps und Canonical-Tags, so Googles Leitfaden zur URL-Struktur für E-Commerce-Websites. Eine Sitemap mit http://-URLs oder mit einem abschließenden Schrägstrich, den das Canonical-Tag nicht hat, sendet für jedes Produkt ein widersprüchliches Signal.
Größenlimits der Sitemap bei großen Katalogen
Die Limits gelten pro Datei, nicht pro Website. Jedes Format ist auf 50.000 URLs oder 50 MB unkomprimiert pro Sitemap begrenzt, und die Datei muss UTF-8-codiert sein, so Google Search Central. Gzip-Komprimierung spart Bandbreite, aber die unkomprimierte Größe zählt trotzdem. Die Plattformen setzen ihre eigenen Standardwerte unterhalb dieser Grenzen.
Sitemap-Limits und Plattform-Standardwerte
| URLs pro Sitemap-Datei | 50.000 | |
|---|---|---|
| Größe pro Sitemap-Datei | 50 MB unkomprimiert | |
| Bildeinträge pro Seiten-URL | 1.000 | |
| WordPress-Core: URLs pro Sitemap | 2.000 (per Filter anpassbar) | WordPress |
| Magento: URLs pro Datei (Standard) | 50.000 | Adobe |
| Magento: Dateigröße (Standard) | 10.485.760 Byte | Adobe |
Einen Katalog mit 120.000 Produkten nach Seitentyp aufteilen
Teile zuerst nach Seitentyp und dann nach Bereich auf. Getrennte Dateien für Produkte, Kategorien, Marken und Content machen Probleme sichtbar: Meldet die Search Console, dass die Hälfte der URLs in einer Produktdatei nicht indexiert ist, weißt du, wo du suchen musst. Ein Beispielshop mit 120.000 Produkt-URLs braucht mindestens drei Produktdateien:
Sitemap-Index für einen Shop mit 120.000 Produkten
Halte die Aufteilung stabil. Rutscht ein Produkt bei jeder neuen SKU von Datei 2 in Datei 3, verlieren die Berichte pro Datei in der Search Console ihre Aussagekraft. Teilst du nach einem festen Schlüssel auf, etwa einem Bereich von Produkt-IDs oder der obersten Kategorieebene, bleibt jede Datei über die Zeit vergleichbar.
Bild-Sitemaps: nur noch zwei Tags
Produktbilder können im url-Eintrag des Produkts selbst stehen. Jede url kann bis zu 1.000 Bildeinträge enthalten, und übrig sind nur noch image:image und image:loc: caption, title, geo_location und license werden nicht mehr unterstützt, so Googles Dokumentation zu Bild-Sitemaps. Bilder auf einer CDN-Domain sind in Ordnung, wenn du diese Domain in der Search Console bestätigst und sie nicht in der robots.txt sperrst.
Manche Plattformen schreiben weiterhin image:title in die Datei. Das schadet nicht, bringt aber auch nichts. Für Bildbeschreibungen bleibt der Alt-Text auf der Seite der richtige Ort. Listet deine Plattform nur das Hauptbild, reicht das meistens; die Galeriebilder findet Google über die Produktseite selbst.
lastmod: das einzige optionale Tag, das Google liest
Google ignoriert priority und changefreq und nutzt lastmod nur, wenn der Wert durchgängig und nachprüfbar stimmt, so Google Search Central. Der Wert sollte die letzte wesentliche Änderung der Seite wiedergeben. Bei einer Produktseite zählen ein neuer Preis, ein geänderter Lagerstatus, überarbeitete Inhalte oder neue Bilder. Eine Änderung im Footer oder ein Template-Deploy, der jede Seite berührt, zählt nicht.
Am häufigsten machen Shops das kaputt, indem ein nächtlicher Job jedes Produkt neu speichert und allen das heutige Datum verpasst. Nach ein paar Wochen trägt lastmod keine Information mehr, und Google vertraut dem Wert nicht mehr. Setzt deine Plattform lastmod aus einem allgemeinen updated_at-Feld, prüfe, was in dieses Feld schreibt: Ein Lagerbestands-Sync, der stündlich jede Zeile anfasst, hat dieselbe Wirkung.
Varianten, kanonische URLs und Parameter
Google verlangt, dass sich jede Variante über eine eigene URL identifizieren lässt, entweder als Pfadsegment (/t-shirt/green) oder als Query-Parameter (/t-shirt?color=green). Ist der Parameter optional, ist die URL ohne ihn die kanonische; hat jede Variante eine eigene URL, steht die kanonische Produkt-URL auf allen Variantenseiten, so Googles Leitfaden zur URL-Struktur für E-Commerce-Websites. Die Sitemap listet dann die kanonische URL, nicht jede Varianten-URL.
Shopify-Themes verlinken eine einzelne Variante mit einem ?variant=-Parameter an der Produkt-URL, und die erzeugte Sitemap verlinkt Produkte. Als kanonisch gilt also die Produkt-URL ohne Parameter. Shops, die pro Farbe eine eigene Seite mit eigenem Inhalt und eigenem Canonical bauen, listen jede dieser Seiten. Was du nie sehen solltest, ist beides zugleich: eine übergeordnete Produkt-URL und ein Dutzend Varianten-URLs, deren Canonical alle auf diese Produkt-URL zeigt.
Ausverkaufte, eingestellte und saisonale Produkte
Der Lagerstatus ändert sich täglich, und eine Sitemap, die Produkte im selben Takt hinzufügt und entfernt, stiftet mehr Verwirrung, als sie hilft. Entscheide je nach Situation, und zwar danach, was die Seite selbst zurückgibt:
Ausverkaufte und eingestellte Produkte in der Sitemap
| Vorübergehend ausverkauft | 200, mit angezeigter Verfügbarkeit | Ja | Lagerstatus, Liefertermin, lastmod |
|---|---|---|---|
| Eine Variante ausverkauft | 200 für das Produkt | Ja (die Produkt-URL) | Verfügbarkeit der Variante auf der Seite |
| Saisonal, kommt nächste Saison wieder | 200, als nicht verfügbar markiert | Ja | Erwarteter Termin, falls bekannt |
| Eingestellt, direkter Nachfolger | 301 zum Nachfolger | Nein, stattdessen den Nachfolger | Interne Links auf die neue URL |
| Eingestellt, kein Ersatz | 404 oder 410 | Nein | Interne Links entfernen |
Ein eingestelltes Produkt auf seine Kategorie oder die Startseite umzuleiten, ist verlockend. Wer aber nach einem bestimmten Modell gesucht hat, landet dann auf einer Seite, auf der es fehlt. Leite nur um, wenn es einen echten Nachfolger gibt; sonst lass die Seite 404 oder 410 liefern und nimm sie im selben Release aus der Sitemap. Ein Produkt, das du vor dem Launch als Vorbestellung verkaufst, ist der umgekehrte Fall: Die Seite ist live und liefert 200, also gehört sie vom ersten Tag an in die Datei.
Facettierte Navigation aus der Sitemap heraushalten
Filterkombinationen vervielfachen sich schnell: 20 Farben, 10 Größen und 5 Marken in einer Kategorie ergeben schon vor jeder Sortierung 1.000 Filterseiten. Keine davon gehört in die Sitemap, es sei denn, du hast einen Filter bewusst zu einer Landingpage gemacht, etwa /shoes/red-running-shoes, mit eigenem Inhalt, selbstreferenzierendem Canonical und internen Links. Solche Seiten kommen in die Kategorie-Datei, der Rest bleibt draußen. Unser Beitrag zu SEO für facettierte Navigation zeigt, wie du verhinderst, dass Crawler dort Zeit verschwenden.
hreflang in der Sitemap für mehrsprachige Shops
Ein Shop mit mehreren Sprach- oder Länderversionen kann sie statt im Seitenkopf in der Sitemap angeben. Jeder url-Eintrag listet dann jede Sprachversion als xhtml:link-Element, sich selbst eingeschlossen, und jede Sprachversion hat ihren eigenen url-Eintrag mit denselben Links. Diese Links machen jeden Eintrag größer, sodass eine Produktdatei bei fünf Sprachen das Limit von 50 MB viel früher erreicht: Teile früher auf.
Die Sitemap-Methode passt zu Shops mit vielen Sprachen, weil der Seitenkopf schlank bleibt und alle Alternativen in einer Datei stehen, die du validieren kannst. Der Haken ist die Vollständigkeit: Ein fehlender Rückverweis in einer Sprache macht das Paar ungültig. Der hreflang-Generator erzeugt die Tags für eine Reihe von URLs, und der Leitfaden zu mehrsprachigem SEO behandelt den Rest der Einrichtung.
Was Shopify, WooCommerce und Magento erzeugen
- Shopify erzeugt die sitemap.xml automatisch. Sie verlinkt alle Produkte mit ihrem Hauptbild, Seiten, Kollektionen und Blogbeiträge und wird aktualisiert, wenn du solche hinzufügst. Bei internationalen Domains bekommt jede Domain eine eigene Sitemap, in die ihre Sprachen aufgenommen werden, so die Shopify-Hilfe. Die Datei verlinkt getrennte Sitemaps für Produkte, Kollektionen, Seiten und Blogs, und Shopify aktualisiert sie selbst, wenn du ein Produkt, eine Kollektion, ein Bild oder einen Beitrag hinzufügst.
- WooCommerce stützt sich auf WordPress. Seit WordPress 5.5 veröffentlicht der Core unter wp-sitemap.xml einen Sitemap-Index für öffentliche Inhaltstypen, zu denen Produkte gehören, mit standardmäßig bis zu 2.000 URLs pro Sitemap, so WordPress. SEO-Plugins wie Yoast SEO ersetzen ihn meist durch ihre eigene Sitemap. Nutze eine Sitemap, nicht beide, und reiche die ein, die live ist.
- Magento (Adobe Commerce) erstellt Sitemaps unter Marketing > SEO & Search > Site Map und konfiguriert sie unter Stores > Configuration > Catalog > XML Sitemap: Häufigkeit und Priorität pro Seitentyp, Produktbilder (None, Base Only oder All), zeitgesteuerte Erstellung und eine Option, die Sitemap in die robots.txt aufzunehmen, so Adobe. Die Erstellung läuft nach Zeitplan, ein Shop mit defektem Cron liefert also eine alte Sitemap aus. Unsere Magento-SEO-Checkliste behandelt die zugehörigen Einstellungen.
Sitemap einreichen und den Bericht lesen
Reiche die Index-URL in der Search Console unter Indexierung, dann Sitemaps ein, und ergänze in der robots.txt eine Sitemap:-Zeile mit der vollständigen URL, damit auch andere Crawler sie finden. Eine Sitemap deckt nur URLs unterhalb ihres eigenen Verzeichnisses ab, sofern du sie nicht über die Search Console einreichst, ein weiterer Grund, sie im Stammverzeichnis abzulegen, so Google Search Central.
Der Bericht zeigt pro Datei, ob Google sie lesen konnte und wie viele URLs gefunden wurden. Der Bericht zur Seitenindexierung zeigt dann, welche eingereichten URLs indexiert sind und warum die anderen nicht. Lies beide zusammen: Eine Produktdatei mit Tausenden URLs im Status „Gecrawlt, zurzeit nicht indexiert“ deutet meist auf dünne oder doppelte Produktinhalte hin, nicht auf die Sitemap. Der Leitfaden zu technischem SEO für Shops geht die übrigen Indexierungsprüfungen durch.
Die Sitemap mit dem Produktkatalog abgleichen
Die Search Console sagt dir, was Google mit den eingereichten URLs gemacht hat. Sie sagt dir nicht, welche Produkte von vornherein in der Sitemap fehlen, weil sie deinen Katalog nicht kennt. Für diesen Vergleich brauchst du beide Listen nebeneinander.
WISEPIM erstellt und hostet die Sitemap deines Shops nicht; das macht deine Shopplattform. Die Analyse Sitemap Coverage (Sitemap-Abdeckung) liest die Sitemaps, die du in den SEO-Einstellungen hinterlegst (oder die Sitemap-Zeilen in der robots.txt, wenn du keine eingetragen hast), folgt Index-Dateien zu ihren untergeordneten Sitemaps, auch gzip-komprimierten, und ordnet jede URL einem Produkt oder einer Kategorie in deinem Katalog zu. Andere URLs werden als Marken-, Blog-, statische oder sonstige Seiten gekennzeichnet. Pro URL siehst du den Typ, das zugeordnete Produkt sowie lastmod und priority, wie die Sitemap sie angibt, und pro Sitemap-Datei, ob der letzte Abruf funktioniert hat.
Die umgekehrte Prüfung, Missing from Sitemap (Fehlt in der Sitemap), geht vom Katalog aus: Für jedes Produkt, das in einem verbundenen Shop gelistet ist, baut sie die erwartete Shop-URL und meldet die Produkte, deren URL nicht in der synchronisierten Sitemap steht, mit Plattformfilter und CSV-Export. Keine der beiden Ansichten sagt, ob Google eine Seite indexiert hat; diese Antwort bleibt in der Search Console. Zusammen finden sie die Fälle, die ein Crawler nie meldet: ein Produkt, das im Shop live ist, aber in der Datei fehlt, und eine Sitemap voller URLs, die zu nichts passen, was du verkaufst.
