Sprachen

Ecommerce-XML-Sitemaps

Allgemeine Sitemap-Empfehlungen greifen bei großen Katalogen zu kurz. So segmentieren Sie eine Ecommerce-Sitemap nach Seitentyp, halten die Grenzen von 50 000 URLs und 50 MB mit einem Sitemap-Index ein, behandeln nicht verfügbare und eingestellte Produkt-URLs, pflegen lastmod ehrlich und kombinieren Sitemaps mit IndexNow.

Erstveröffentlicht: 3. Juli 2026 · Zuletzt aktualisiert: 11. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Eine Ecommerce-XML-Sitemap listet kanonische, indexierbare URLs nach Typ unter einem Sitemap-Index. Pro Datei gelten 50 000 URLs und 50 MB; Segmentierung dient dem Monitoring, nicht dem Crawl-Budget. Nur kanonische 200-URLs aufnehmen, lastmod ehrlich pflegen und für nicht verfügbare Produkte eine dokumentierte Entscheidung verwenden.

TL;DR — Segmentieren Sie eine Ecommerce-Sitemap nach Typ (Produkte, Kategorien, Marken, statische Seiten) unter einem Sitemap-Index. Der Zweck ist Monitoring in der Search Console und den Bing Webmaster Tools, nicht mehr Crawl-Budget oder ein Rankingvorteil (Mueller). Planen Sie mit 50 000 URLs beziehungsweise 50 MB pro Datei und bis zu 50 000 Dateien pro Index; für sehr große Systeme akzeptiert die GSC bis zu 500 Sitemaps, während Bings Indexmodell Milliarden URLs unterstützt. Nehmen Sie nur kanonische, indexierbare URLs mit Status 200 auf. Schließen Sie Facetten, Trackingparameter, dünne Varianten, Weiterleitungen, 4xx und noindex aus. lastmod ist das einzige von beiden Suchmaschinen verwendete optionale Attribut: Halten Sie es beim letzten wesentlichen Änderungszeitpunkt ehrlich und ignorieren Sie priority und changefreq. Automatisieren Sie die Erzeugung und kombinieren Sie lastmod bei schnellen Preis- oder Bestandsänderungen mit IndexNow. Besonders wichtig ist ein dokumentierter Entscheidungsbaum für nicht verfügbare und eingestellte Produkte (dauerhaft, vorübergehend oder unbekannt), bei dem das Entfernen aus der Sitemap mit der Bereinigung interner Links zusammenfällt — statt pauschal 404 auszuliefern.

Warum allgemeine Sitemap-Ratschläge bei Katalogmaßstab versagen

Jeder Artikel darüber, wie man eine Sitemap erstellt, behandelt dieselben Punkte: die Grenze von 50 000 URLs, die Aufteilung über einen Index, den Ausschluss ungeeigneter URLs und ein korrektes lastmod. Das stimmt alles, beschreibt aber nicht die eigentlichen Schwierigkeiten eines Ecommerce-Shops. Im Betrieb geht es um einen täglich wechselnden Katalog, Tausende nicht verfügbare oder eingestellte SKUs, nahezu identische Größen- und Farbvarianten sowie Automatisierungen, die unbemerkt ausfallen. Dieser Artikel setzt voraus, dass bereits eine Sitemap existiert, und erklärt den Umgang mit diesen Fällen.

Warum Sitemaps mit wachsender Shopgröße wichtiger werden, ist leicht erklärt. Google: “Generally, on large sites it’s more difficult to make sure that every page is linked by at least one other page on the site.” (Übersetzung) „Bei großen Websites ist es im Allgemeinen schwieriger sicherzustellen, dass jede Seite von mindestens einer anderen Seite der Website verlinkt wird.“ Eine Sitemap sorgt dafür, dass auch intern schwach verlinkte Produkte entdeckt werden. John Mueller bezeichnete XML-Sitemaps als “a minimal baseline for any serious website.” (Übersetzung) „eine Mindestgrundlage für jede ernst zu nehmende Website.“ Die Aussage von Mueller zur „Mindestgrundlage“ wird über die Berichterstattung von Search Engine Roundtable zu einer Antwort auf X/Twitter wiedergegeben. Sie ist daher als berichtetes und nicht als selbst abgerufenes Primärzitat zu behandeln.

Die harten Grenzen, für die Sie planen

Das Sitemap-Protokoll begrenzt einzelne Dateien und stellt für größere Bestände den Sitemap-Index bereit:

  • Pro Datei: Google — “All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs. If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps.” (Übersetzung) „Alle Formate begrenzen eine einzelne Für jedes Sitemap-Format gelten höchstens 50 MB (unkomprimiert) oder 50 000 URLs. Ist eine Datei größer oder enthält sie mehr URLs, muss sie auf mehrere Sitemaps verteilt werden.“ Evidence for this claim Each Google sitemap file is limited to 50,000 URLs or 50 MB uncompressed. Scope: Protocol and Search Console submission limits are separate constraints. Confidence: high · Verified: Google: Large sitemaps
  • Sitemap-Index: “A sitemap index file may have up to 50,000 loc tags” (Übersetzung) „Eine Sitemap-Indexdatei darf höchstens 50 000 loc-Tags enthalten“ — sie kann also auf bis zu 50 000 untergeordnete Sitemaps verweisen. Außerdem können Sie “submit up to 500 sitemap index files for each site in your Search Console account.” (Übersetzung) „für jede Website in Ihrem Search-Console-Konto bis zu 500 Sitemap-Indexdateien einreichen.“
  • Bings angegebene Obergrenze ist noch großzügiger: 50 000 URLs pro Datei und 50 000 untergeordnete Dateien pro Index. Daher gilt: “a single sitemap index file can reference up to 2.5 billion URLs. At scale, multiple index files can support up to 2.5 trillion URLs across a domain, making this approach ideal for large, complex sites.” (Übersetzung) „Eine einzelne Sitemap-Indexdatei kann auf bis zu 2,5 Milliarden URLs verweisen. In großem Maßstab können mehrere Indexdateien bis zu 2,5 Billionen URLs einer Domain unterstützen, sodass sich dieser Ansatz für große, komplexe Websites eignet.“

Für nahezu jeden Shop lautet die praktische Konsequenz: 50 000 URLs pro Datei, nach Typ aufteilen und in einem Index bündeln. Die Milliarden- und Billionenwerte sind nur für Architekturen mit vielen Millionen SKUs relevant. Sie zeigen aber, dass das Protokoll nicht zum Engpass wird.

Segmentierungsstrategie — und wofür sie wirklich dient

Teilen Sie den Katalog in logische Sitemap-Dateien für Produkte, Kategorien beziehungsweise Collections, Marken und statische beziehungsweise CMS-Seiten auf, auf die ein einziger Index verweist. Viele Leitfäden erwecken fälschlich den Eindruck, eine Aufteilung nach Typ verbessere das Crawl-Budget oder führe zur Indexierung weiterer Seiten. Das stimmt nicht. Mueller beschreibt die Aufteilung ausdrücklich als diagnostische Entscheidung, nicht als Crawling-Hebel:

  • “The size & number of sitemap files generally won’t affect the crawling, unless your server is so bogged down that even fetching a handful of sitemap files would slow it down…” (Übersetzung) „Größe und Anzahl der Sitemap-Dateien wirken sich normalerweise nicht auf das Crawling aus, es sei denn, Ihr Server ist so überlastet, dass schon das Abrufen einiger Sitemap-Dateien ihn verlangsamen würde …“
  • “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually…” (Übersetzung) „Ich empfehle im Allgemeinen, eine Sitemap-Datei in logische Bereiche Ihrer Website aufzuteilen, damit Sie diese Bereiche einzeln überwachen können …“ Beide Aussagen werden über den Bericht des Search Engine Journal zu einem Reddit AMA wiedergegeben; entscheidend ist hier die Aufteilung für das Monitoring.

Der Nutzen einer separaten Produkt- und Kategorie-Sitemap besteht darin, dass der Sitemaps-Bericht der GSC und die Bing Webmaster Tools das Verhältnis von eingereichten zu indexierten URLs pro Segment zeigen. Werden beispielsweise 40 % der Produktseiten, aber 95 % der Kategorieseiten indexiert, wissen Sie sofort, wo Sie suchen müssen. Die Segmentierung macht das Problem sichtbar; sie löst es nicht und verschafft kein zusätzliches Crawl-Budget.

Was in die Sitemap gehört — und was nicht

Googles Regel ist der vollständige Filter: “Include the URLs in your sitemap that you want to see in Google’s search results. Google generally shows the canonical URLs in its search results, which you can influence with sitemaps.” (Übersetzung) „Listen Sie die URLs in Ihrer Sitemap, die Google als Suchergebnisse zeigen soll. In der Regel präsentiert Google dort kanonische URLs; mit Sitemaps können Sie diese Auswahl beeinflussen.“ Eine Sitemap-URL sollte daher kanonisch und indexierbar sein und den Status 200 zurückgeben. Evidence for this claim Google recommends listing the canonical URLs that a site wants shown in Search. Scope: Sitemap inclusion is a canonicalization hint and does not override noindex or response status. Confidence: high · Verified: Google: Build and submit a sitemap

Aufnehmen: kanonische Produktdetailseiten (PDPs), rankende Kategorie- beziehungsweise Collection-Seiten, Markenseiten und indexierbare statische Seiten.

Ausschließen:

  • Facetten-, Filter- und Sortier-URLs — ?sort=, ?color= und Filterkombinationen. Sie gehören in Ihre Facettenstrategie (blockieren oder kanonisieren), nicht in die Sitemap. Joshua Hardwicks Sitemap-Leitfaden bei Ahrefs weist auf die Ecommerce-Variante dieses Problems hin: Es sei “worth checking for duplicate and near-duplicate pages on ecommerce sites as these often slip through the net.” (Übersetzung) „sinnvoll, Ecommerce-Websites auf doppelte und nahezu doppelte Seiten zu prüfen, weil diese oft durchs Raster fallen.“
  • Session-IDs und Trackingparameter.
  • Weiterleitungen (3xx) und Fehler (4xx / 410) — eine Sitemap mit Weiterleitungs-URLs enthält URLs, die Google gerade nicht anzeigen soll.
  • noindex-Seiten — die widersprüchlichen Signale „einreichen“ und „nicht indexieren“ verschwenden nur Crawls.
  • Inhaltsarme, nahezu identische Varianten. Eine separate Größen- oder Farb-URL ohne eigenen Inhalt sollte keinen eigenen Sitemap-Eintrag erhalten. Listen Sie die kanonische Produkt-URL. Googles 2024 eingeführte strukturierte Daten für Produktvarianten (ProductGroup / hasVariant / variesBy) drücken modern aus, dass Größen oder Farben Varianten eines Produkts und nicht N nahezu doppelte Seiten sind. Diese Beziehung gehört dorthin und nicht in die Sitemap.

Produktbilder gehören in den Eintrag der zugehörigen Seite und nicht in eine separate Liste. Erstellen Sie keine eigenständige Sitemap mit Bild-URLs. Ergänzen Sie stattdessen den <url>-Eintrag der kanonischen Produkt-URL mithilfe der Bild-Sitemap-Erweiterung um einen <image:image>-Block. Google: “Each <url> tag can contain up to 1,000 <image:image> tags” (Übersetzung) „Jedes <url>-Tag kann bis zu 1 000 <image:image>-Tags enthalten“ — für die Galerie einer PDP mehr als genug. Evidence for this claim Product images can be added to an existing product URL entry with the image sitemap extension instead of a separate image sitemap. Scope: Each <url> entry can carry up to 1,000 <image:image> tags, and the images still have to be crawlable (not blocked by robots.txt) and, if served from another domain, verified in Search Console. Confidence: high · Verified: Google: Image sitemaps Zwei Anforderungen an die Crawlbarkeit werden bei großen Katalogen leicht übersehen: Sperren Sie die Bildpfade nicht in robots.txt. Werden Produktbilder von einer anderen Domain oder einem CDN ausgeliefert, verifizieren Sie diesen Host in der Search Console, sonst werden die Bilder nicht erfasst. Welche Variantenbilder aufgenommen werden, richtet sich nach derselben kanonischen Architektur wie die URL: Hängen Sie Bilder an den kanonischen Produkteintrag und nicht an jede bereits ausgeschlossene dünne Variante.

Entscheidungsbaum für nicht verfügbare und eingestellte Produkte

Hier kann ein Artikel über Ecommerce-Sitemaps echten Mehrwert bieten: Fast kein Leitfaden behandelt diese Frage differenziert, obwohl genau diese Entscheidung bestimmt, ob eine URL in die Sitemap gehört. Das vollständige Modell habe ich im Ahrefs-Blog beschrieben (Wie sollten Sie mit nicht verfügbaren Produkten umgehen? Es kommt darauf an). Der Titel ist bewusst gewählt. Es gibt keine perfekte Lösung. Entscheidend sind einheitliche, an Ihren Geschäftszielen ausgerichtete Regeln, nicht eine auswendig gelernte Pauschalantwort.

Die Entscheidung folgt zwei Achsen: Ist das Produkt dauerhaft oder vorübergehend nicht verfügbar, und hat die Seite weiterhin Wert (Traffic, Rezensionen oder nützliche Informationen)?

  • Vorübergehend nicht verfügbar, Rückkehr bestätigt → Seite online und in der Sitemap lassen. Nennen Sie ein voraussichtliches Datum, bieten Sie eine Warteliste oder eine Benachrichtigung an. Verschieben Sie die URL nicht bei jedem Bestandswechsel in die Sitemap hinein und wieder hinaus — das erzeugt nur Rauschen.
  • Vorübergehend nicht verfügbar, Status unbekannt → Produkt in Oberfläche und interner Verlinkung niedriger priorisieren (nach hinten sortieren oder ausblenden), statt es sofort aus der Sitemap zu entfernen. Eine verfrühte Entfernung kann Google die Seite als aufgegeben deuten lassen und schwer zurückzugewinnende Rankings kosten.
  • Dauerhaft eingestellt, guter Ersatz vorhanden → per 301 auf ein ähnliches Produkt weiterleiten, Linkkraft erhalten und die alte URL aus der Sitemap entfernen.
  • Dauerhaft eingestellt, kein Ersatz, aber weiterhin Traffic oder nützlicher Inhalt (Rezensionen, Kaufratgeber) → Seite online und in der Sitemap lassen.
  • Dauerhaft eingestellt, kein Wert → Seite löschen, 404/410 zurückgeben und aus der Sitemap entfernen.

Ein zentraler betrieblicher Punkt: Eine Entfernung ist eine koordinierte Bereinigung, keine einzelne Sitemap-Änderung. Wie ich es in dem Artikel formuliere: “when redirecting a page, many systems will automatically remove internal links from categories, facets, sitemaps, and internal search pages” (Übersetzung) „Wenn eine Seite weitergeleitet wird, entfernen viele Systeme automatisch interne Links aus Kategorien, Facetten, Sitemaps und internen Suchseiten.“ Entfernen Sie die URL daher aus der Sitemap und bereinigen Sie im selben Workflow die internen Links darauf (Kategorienmodule, Widgets für verwandte Produkte, interne Suche). Eine tote URL, die nicht mehr in der Sitemap steht, aber noch von zwanzig Kategorieseiten verlinkt wird, ist nicht wirklich bereinigt.

Und vermeiden Sie genau das, wovor Googles eigene Hinweise warnen: Antworten Sie nicht reflexartig für jedes eingestellte Produkt mit 404. Google bevorzugt es, die URL mit Alternativen online zu lassen oder auf eine relevante Kategorie weiterzuleiten, statt pauschal 404 auszuliefern. Außerdem warnt Google vor vielen Soft-404-Seiten. Eine Wand neu entstandener 404-Produktseiten erzeugt genau dieses Muster.

Aktualisierungsfrequenz, lastmod und Automatisierung

Automatisieren Sie die Erzeugung. Bei einem täglich wechselnden Katalog ist das unverzichtbar. Mein ständiger Rat für große Websites lautet: “Add sitemaps. I would make sure this is automated. If you are asked to manually create them, you can do it, but just know that if it’s manual these will rarely be kept up-to-date.” (Übersetzung) „Fügen Sie Sitemaps hinzu und stellen Sie sicher, dass dies automatisiert ist. Wenn Sie Sitemaps manuell erstellen sollen, können Sie das tun; bedenken Sie aber, manuelle Sitemaps nur selten aktuell gehalten werden.“ Bing hat den typischen Fehler dokumentiert: “Too often, Bing discovers stalled sitemaps which have the same URLs listed for months – sometimes years” (Übersetzung) „Zu oft findet Bing nicht mehr aktualisierte Sitemaps, die über Monate — manchmal Jahre — dieselben URLs enthalten“ und empfiehlt, die Sitemap “should ideally be automatically generated at least once a day.” (Übersetzung) „sollte idealerweise mindestens einmal täglich automatisch erzeugt werden.“

lastmod ist das einzige relevante Attribut. Google und Bing verwenden es aktiv; die anderen optionalen Attribute nicht. Halten Sie den Wert ehrlich:

  • Google: “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” (Übersetzung) „Google verwendet den <lastmod>-Wert, wenn er dauerhaft und nachprüfbar korrekt ist, beispielsweise im Vergleich zur letzten Änderung der Seite.“ Er soll “reflect the date and time of the last significant update to the page… an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.” (Übersetzung) „Datum und Uhrzeit der letzten wesentlichen Aktualisierung der Seite abbilden … Eine Änderung am Hauptinhalt, an strukturierten Daten oder an Links gilt im Allgemeinen als wesentlich, eine Änderung des Copyright-Datums dagegen nicht.“
  • Bing benennt das Gegenbeispiel klar: “Do not set the <lastmod> value set to the time you generate the sitemap. <lastmod> should be the date of the last modification of the content.” (Übersetzung) „Verwenden Sie als <lastmod> nicht die Uhrzeit der Sitemap-Erzeugung. Der Wert muss dem Datum entsprechen, an dem der Inhalt zuletzt geändert wurde.“ Verwenden Sie ISO 8601 einschließlich Uhrzeit.

Eine echte Grauzone ist die Frage, ob eine Preisänderung oder ein Wechsel des Bestandsstatus eine „wesentliche“ Aktualisierung darstellt. Nach Googles Definition (Hauptinhalt, strukturierte Daten, Links) ist eine reine Preisänderung möglicherweise nicht wesentlich. Ändert sie jedoch die strukturierten Product-Daten (availability, price), kommt sie dem näher. Meine Einschätzung: Versuchen Sie nicht, das System auszutricksen. Erhöhen Sie lastmod nicht bei jedem belanglosen Wechsel — das erzeugt nur Rauschen — und verlassen Sie sich bei einem zeitkritischen Preisnachlass nicht allein auf lastmod.

Kombinieren Sie lastmod bei schnellen Änderungen mit IndexNow. Bing beschreibt beide als Ergänzung, nicht als Entweder-oder: “While real-time URL submission protocols such as IndexNow help notify search engines of immediate content changes, sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site.” (Übersetzung) „Während Echtzeit-Protokolle zur URL-Übermittlung wie IndexNow Suchmaschinen über unmittelbare Inhaltsänderungen informieren, bleiben Sitemaps ein grundlegendes Signal für eine umfassende URL-Abdeckung der Website.“ Für KI-gestützte Oberflächen gilt außerdem: “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn’t changed since the last crawl.” (Übersetzung) „Das lastmod-Feld Ihrer Sitemap bleibt ein wichtiges Signal, mit dem Bing URLs für erneutes Crawling und Indexieren priorisiert oder vollständig überspringt, wenn sich der Inhalt seit dem letzten Crawl nicht geändert hat.“ Die Sitemap liefert also Abdeckung und tägliche Aktualität; IndexNow (Bing, Yandex und weitere — nicht Google) übermittelt einzelne Preis- oder Bestandsänderungen, ohne auf den nächsten Crawl-Zyklus zu warten.

priority und changefreq ignorieren

Investieren Sie keine Entwicklungszeit in die Pflege dieser Werte. Google formuliert es eindeutig: “Google ignores <priority> and <changefreq> values.” (Übersetzung) „Google ignoriert die Werte von <priority> und <changefreq>.“ Gary Illyes bezeichnete das priority-Feld laut Berichten als “essentially a bag of noise.” (Übersetzung) „im Grunde einen Sack voller Rauschen.“ Die Aussage von Illyes wird über die Berichterstattung von Search Engine Roundtable zur SMX Advanced 2017 wiedergegeben und ist keine selbst abgerufene Primärquelle. Der Punkt bleibt bestehen, weil Googles Dokumentation inzwischen unabhängig davon bestätigt, dass beide Felder ignoriert werden. Automatisch von Ihrer Plattform gesetzte Werte sind harmlos. Entwickeln Sie nur keine eigene Logik für ihre Berechnung.

Monitoring und Diagnose

Dafür ist die Segmentierung gedacht:

  • GSC-Sitemaps-Bericht — zeigt pro Segment das Verhältnis von eingereichten zu indexierten URLs. Ist es bei der Produkt-Sitemap deutlich schlechter als bei der Kategorie-Sitemap, liegt wahrscheinlich ein Problem mit Produktseiten vor (inhaltsarme Seiten, blockierte Varianten, kanonische Signale).
  • Bing Webmaster Tools — bieten dieselbe Segmentansicht für Bing sowie den Übermittlungsstatus von IndexNow.
  • GSC-Bericht zur Seitenindexierung — beobachten Sie wachsende Ausschlussgruppen für Facetten- und Parameter-URLs; sie zeigen, dass Ihre Facettenstrategie URLs in die Entdeckung durchsickern lässt.
  • Website-Crawl beziehungsweise Audit (Ahrefs Site Audit, Screaming Frog) — findet Produkte mit fortbestehender Nicht-verfügbar-Meldung, verwaiste Produkte ohne interne Links und defekte interne Links nach einer Weiterleitung oder Entfernung.

Architektur im Enterprise-Maßstab — ein konkretes Beispiel

Planen Sie bei einem Katalog mit Millionen SKUs die Hierarchie anhand des tatsächlichen Volumens und der Einreichungsgrenzen, statt später reaktiv Dateien anzuhängen:

/sitemap-index.xml            ← the one index you submit to GSC + BWT
  ├── /sitemaps/products-1.xml      (URLs 1–50,000)
  ├── /sitemaps/products-2.xml      (50,001–100,000)
  ├── … products-N.xml              (chunk every 50,000 canonical PDPs)
  ├── /sitemaps/categories.xml      (all category / collection pages)
  ├── /sitemaps/brands.xml          (all brand pages)
  └── /sitemaps/static.xml          (homepage, guides, policy pages)

Bei fünf Millionen Produkten entstehen ungefähr 100 Produkt-Sitemap-Dateien plus einige weitere — deutlich unter der Grenze von 50 000 Dateien pro Index und den 500 von der GSC akzeptierten Sitemaps. Überschreiten Sie tatsächlich einen einzelnen Index (50 000 × 50 000 = 2,5 Milliarden URLs), teilen Sie ihn auf mehrere Indexdateien auf und reichen jede davon ein. Legen Sie die Größe der Blöcke von Anfang an fest, damit die tägliche Erzeugung nur die Inhalte jeder Datei neu schreibt und Sie die Baumstruktur nicht wegen einer zu kleinen Schätzung neu entwerfen müssen.

Einordnung

Ecommerce-Sitemaps überschneiden sich stark mit den Seiten, die sie auflisten. Welche URLs in die Sitemap gehören, bestimmt Ihre Strategie für Kategorieseiten und Facettennavigation, also welche gefilterten URLs kanonisch und indexierbar sind. Was bei einem ausverkauften Produkt mit seiner URL geschieht, entscheidet die Regel für nicht verfügbare und eingestellte Produkte. Die Sitemap ist außerdem nur einer von mehreren Wegen, auf denen Crawler einen Shop entdecken — neben internen Links, IndexNow und, für Google Shopping, einem Produktfeed im Merchant Center. Sie ersetzt keinen davon, sondern dient als Absicherung der Abdeckung, damit keine URL verwaist.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.