2021 habe ich eine WooCommerce-Website mit 140.000 Produkt-URLs geerbt, eine einzelne sitemap.xml, die genau bei 50.000 Einträgen endete, und einen Kunden, der nicht verstehen konnte, warum Google Search Console nur einen Bruchteil seiner Seiten als indexiert anzeigte. Die Sitemap-Datei hörte einfach auf. Kein Fehler. Keine Warnung. Nur stille Kürzung. Das ist die Art von Ding, das dir Rankings kostet, ohne je ein sichtbares Signal zu senden, dass etwas nicht stimmt.
Wenn deine Website über 50.000 URLs wächst, ist dieser Beitrag derjenige, den du lesen musst, bevor du auf diese Grenze triffst.
Warum das 50.000-URL-Limit existiert
Das Sitemaps-Protokoll, das gemeinsam von Google, Bing und anderen gepflegt wird, setzt zwei harte Grenzen für eine einzelne Sitemap-Datei: nicht mehr als 50.000 URLs und nicht größer als 50MB unkomprimiert. Das sind keine Vorschläge. Googlebot stoppt das Parsen der Datei bei dem Limit, das zuerst erreicht wird.Sitemaps protocol, maintained jointly by Google, Bing, and others, sets two hard constraints on a single sitemap file: no more than 50,000 URLs, and no larger than 50MB uncompressed. These aren't suggestions. Googlebot will stop parsing the file at whichever limit it hits first.
Ehrlich gesagt, die 50MB-Obergrenze ist selten das Problem. Die meisten URLs sind kurz genug, dass du lächerlich lange Pfade brauchtest, um die Dateigröße-Grenze vor dem URL-Zähler-Limit zu erreichen. Das 50.000-URL-Limit ist dasjenige, das Leute trifft.
Was tust du also, wenn dein Katalog, dein Blog-Archiv, dein Benutzer-generierten Inhalte-Bereich diese Schwelle überschreitet? Du verwendest eine Sitemap-Index-Datei.
Was eine Sitemap-Index-Datei wirklich ist
Einfaches Konzept. Anstatt einer Sitemap mit URLs darin erstellst du eine übergeordnete XML-Datei, die auf mehrere untergeordnete Sitemaps verweist. Jede untergeordnete Sitemap kann bis zu 50.000 URLs enthalten. Die Index-Datei selbst kann bis zu 50.000 untergeordnete Sitemaps referenzieren. Die theoretische Obergrenze liegt also bei 2,5 Milliarden URLs. Du wirst sie nicht erreichen.
Die Struktur sieht so aus:
`` sitemap_index.xml ├── sitemap-posts-1.xml (bis zu 50.000 Blog-Beiträge) ├── sitemap-posts-2.xml (Überlauf-Beiträge) ├── sitemap-products-1.xml (bis zu 50.000 Produkte) ├── sitemap-products-2.xml (Überlauf-Produkte) └── sitemap-pages.xml (statische Seiten) `` sitemap_index.xml ├── sitemap-posts-1.xml (up to 50,000 blog posts) ├── sitemap-posts-2.xml (overflow posts) ├── sitemap-products-1.xml (up to 50,000 products) ├── sitemap-products-2.xml (overflow products) └── sitemap-pages.xml (static pages) ``
Die Index-Datei verwendet <sitemapindex> als Root-Element anstelle von <urlset>. Jedes untergeordnete Element ist in einem <sitemap>-Tag mit einem <loc> verpackt, das auf die untergeordnete Datei verweist, und optional einen <lastmod>-Zeitstempel.<sitemapindex> as the root element instead of <urlset>. Each child is wrapped in a <sitemap> tag with a <loc> pointing to the child file, and optionally a <lastmod> timestamp.
Was du bei Google Search Console einreichst, ist die Index-Datei-URL, nicht jede einzelne untergeordnete Datei. Eine Einreichung, eine Quelle der Wahrheit.
So teilst du deine URLs intelligent auf
Hier machen die meisten Tutorials es falsch. Sie sagen „teile deine URLs einfach in Gruppen von 50.000 auf" und lassen es dabei bewenden. Aber die Chunk-Grenzen sind wichtig für die Wartbarkeit und für die Crawl-Logik von Googlebot.
Ich teile nach Inhaltstyp auf, nicht nach beliebiger Anzahl. Immer. Jedes Mal.
Teilen Sie zuerst nach Inhaltstyp auf
- Produkte in ihrer eigenen Sitemap-Serie (sitemap-products-1.xml, sitemap-products-2.xml)
sitemap-products-1.xml,sitemap-products-2.xml) - Blogbeiträge in ihrer eigenen Serie
- Kategorie- und Tag-Seiten zusammen (sie sind navigational, behandeln Sie sie als eine Gruppe)
- Statische Seiten (Über uns, Kontakt, Landing Pages) in einer einzelnen Datei, normalerweise deutlich unter 1.000 URLs
Warum ist das wichtig? Weil bei einer Massenerneuerung einer Produktdatenbank nur die Produkt-Sitemaps regeneriert werden müssen. Sie invalidieren und regenerieren keine monolithische Datei, die Produkte mit Blogbeiträgen vermischt. Googlebot crawlt Sitemaps auch sequenziell, daher gibt das Gruppieren nach Typ ein klareres Signal darüber, welche Art von Inhalten es finden wird.
Dann paginieren Sie innerhalb jedes Typs
Sobald ein Inhaltstyp 50.000 URLs überschreitet, paginieren Sie ihn. Verwenden Sie von Anfang an eine konsistente Namenskonvention. Ich verwende sitemap-{type}-{page}.xml. Verwenden Sie keine Daten im Dateinamen. Ich habe diesen Fehler 2019 auf einer Nachrichtenseite gemacht und endete mit Dateinamen wie sitemap-articles-2019-march.xml, die völlig bedeutungslos wurden, sobald wir historische Inhalte neu generieren mussten. Bleiben Sie bei nummerierten Seiten.sitemap-{type}-{page}.xml . Don't use dates in the filename. I made that mistake on a news site in 2019 and ended up with filenames like sitemap-articles-2019-march.xml that became completely meaningless the moment we needed to regenerate historical content. Stick to numbered pages.
Halten Sie lastmod ehrlich
Das Element <lastmod> in Ihren untergeordneten Sitemaps sollte widerspiegeln, wann der Inhalt tatsächlich zuletzt geändert wurde, nicht wann Sie die Sitemap regeneriert haben. Ich habe Setups gesehen, bei denen jede Regenerierung jeden URL mit dem heutigen Datum versieht. Das trainiert Googlebot, Ihren lastmod-Wert völlig zu ignorieren, da das Signal Rauschen ist. Verwenden Sie den tatsächlichen geänderten Zeitstempel Ihres CMS. In WordPress ist das post_modified_gmt aus der wp_posts-Tabelle.<lastmod> element in your child sitemaps should reflect when the content was actually last modified, not when you regenerated the sitemap. I've seen setups where every regeneration stamps every URL with today's date. That trains Googlebot to ignore your lastmod entirely because the signal is noise. Use your CMS's actual modified timestamp. In WordPress, that's post_modified_gmt from the wp_posts table.
Tooling: Was tatsächlich im großen Maßstab funktioniert
Für WordPress-Sites (das ist der Großteil dessen, was wir bei Seahawk bauen), sind das die Optionen, die ich tatsächlich nutze:
- Yoast SEO verwaltet Sitemap-Indizes automatisch, sobald du mehr als 1.000 URLs pro Post-Typ hast. Es generiert saubere, segmentierte Dateien. Die Standard-Batch-Größe ist aber 1.000 URLs pro Child-Sitemap, was konservativ ist. Du kannst das mit wpseo_sitemap_entries_per_page hochfahren. Ich schiebe das normalerweise auf 5.000 auf gut gehosteten Servern. handles sitemap indexes automatically once you have more than 1,000 URLs per post type. It generates clean, segmented files. But the default batch size is 1,000 URLs per child sitemap, which is conservative. You can filter that up with
wpseo_sitemap_entries_per_page. I usually push it to 5,000 on well-hosted servers. - Rank Math macht das Gleiche, mit etwas feineren Kontrollen darüber, welche Post-Typen und Taxonomien ihre eigenen Child-Sitemaps bekommen. Auf einer kürzlichen Client-Site mit 80.000 WooCommerce-Produkten war die Segmentierung von Rank Math direkt ab Werk sauberer als die von Yoast. does the same, with slightly more granular control over which post types and taxonomies get their own child sitemaps. On a recent client site with 80,000 WooCommerce products, Rank Math's segmentation out of the box was cleaner than Yoast's.
- Custom Generation mit WP-CLI ist das, zu dem ich greife, wenn die Site ungewöhnliche Content-Typen hat oder die Plugin-generierten Sitemaps zu langsam zu generieren sind. Ich habe Scripts geschrieben, die die Datenbank direkt abfragen, Ergebnisse in Chunks à 10.000 paginieren, das XML auf die Festplatte schreiben und dann die Index-Datei zuletzt schreiben. Läuft in unter 30 Sekunden für 200.000 URLs. Der Schlüssel ist, in eine Temp-Datei zu schreiben und sie dann atomar an die richtige Stelle zu verschieben, damit Googlebot nie auf eine halb geschriebene Datei trifft. is what I reach for when the site has unusual content types or the plugin-generated sitemaps are too slow to generate. I've written scripts that query the database directly, paginate results in chunks of 10,000, write the XML to disk, and then write the index file last. Runs in under 30 seconds for 200,000 URLs. The key is writing to a temp file and atomically moving it into place so Googlebot never hits a half-written file.
Für nicht-WordPress-Stacks kann Screaming Frog SEO Spider deine Site crawlen und einen Sitemap-Index für dich generieren, obwohl es besser als Validierungs-Tool als als Production-Sitemap-Generator funktioniert. Für Production solltest du Sitemaps aus deiner Datenquelle generieren, nicht von einem Crawler. Crawler verpassen Dinge.Screaming Frog SEO Spider can crawl your site and generate a sitemap index for you, though it's better as a validation tool than a production sitemap generator. For production, generate sitemaps from your data source, not from a crawler. Crawlers miss things.
Einreichen und Validieren in Search Console
Gehe zur Google Search Console, öffne den Sitemaps-Report und reiche deine Index-Datei-URL ein. Eine URL. Das ist alles.Google Search Console, open the Sitemaps report, and submit your index file URL. One URL. That's it.
Nach der Einreichung warte 24–48 Stunden und überprüfe dann zwei Dinge:
- Eingereicht vs. Entdeckt. Die Anzahl der „Entdeckten URLs" sollte sich deiner echten URL-Anzahl annähern. Wenn sie seltsam früh stagniert, hast du wahrscheinlich ein Crawl-Budget-Problem oder eine malformed Child-Sitemap. The "Discovered URLs" count should be climbing toward your actual URL count. If it plateaus weirdly early, you likely have a crawl budget issue or a malformed child sitemap.
- Individueller Status der untergeordneten Sitemap. Die Search Console zeigt dir jede untergeordnete Sitemap und ihren Status. Falls eine untergeordnete Sitemap einen Fehler zurückgibt, kannst du sie isolieren, ohne die anderen zu beeinflussen. Das ist der unterschätzte Vorteil der Index-Struktur. Search Console will show you each child sitemap and its status. If one child is returning an error, you can isolate it without touching the others. This is the underrated advantage of the index structure.
Bing Webmaster Tools funktioniert genauso. Reiche die Index-Datei ein, nicht die untergeordneten. Dauert zwei Minuten.
Häufige Fehler, die ich ständig sehe
Seahawk prüft regelmäßig Webseiten für Agenturen. Dieselben Sitemap-Fehler treten immer wieder auf.
URLs mit noindex in der Sitemap. Falls eine URL einen noindex Meta-Tag oder X-Robots Header hat, darf sie nicht in deiner Sitemap stehen. Punkt. Eine Sitemap ist eine Empfehlung zum Crawlen und Indexieren. noindex-URLs in die Sitemap aufzunehmen verschwendet Crawl-Budget und verwirrt das Signal. Ich führe vor jedem größeren Site-Launch einen schnellen Screaming Frog Crawl gegen die Sitemap-URLs durch und filtere nach noindex-Antworten. If a URL has a noindex meta tag or X-Robots header, it should not be in your sitemap. Full stop. A sitemap is a recommendation to crawl and index. Including noindexed URLs wastes crawl budget and confuses the signal. I run a quick Screaming Frog crawl against the sitemap URLs and filter for noindex responses before any major site launch.
Gesperrte URLs in der Sitemap. Noch schlimmer als noindex: URLs, die in robots.txt disallowed sind, aber immer noch in der Sitemap aufgelistet werden. Googlebot sieht den Widerspruch. Es bestraft dich nicht dafür, aber es ist schlampig und verschwendet Zeit. Even worse than noindex: URLs that are disallowed in robots.txt but still listed in the sitemap. Googlebot can see the contradiction. It won't penalise you for it, but it's sloppy and it wastes time.
Die Index-Datei nach dem Hinzufügen einer neuen untergeordneten Sitemap nicht aktualisieren. Das klingt offensichtlich, stolpert aber benutzerdefinierte Implementierungen. Du fügst einen neuen Content-Typ hinzu, generierst eine neue untergeordnete Sitemap-Datei und vergisst, den <sitemap> Eintrag zur Index hinzuzufügen. Die untergeordnete Datei existiert auf der Festplatte, aber nichts verweist darauf. Ich habe das schon monatelang unbemerkt sitzen sehen. This sounds obvious but it trips up custom implementations. You add a new content type, generate a new child sitemap file, and forget to add the <sitemap> entry to the index. The child file exists on disk but nothing points to it. I've seen this sit unnoticed for months.
Untergeordnete Sitemaps einzeln statt der Index einreichen. Falls du 12 untergeordnete Sitemaps hast und alle 12 einzeln in der Search Console einreichst, hast du den organisatorischen Vorteil verspielt. Reiche die Index ein. Lass sie kaskadieren. If you have 12 child sitemaps and you submit all 12 to Search Console separately, you've lost the organisational benefit. Submit the index. Let it cascade.
Crawl-Budget: Das größere Bild
Sitemap-Index-Dateien stehen in direkter Verbindung mit Crawl-Budget-Management. Googles Dokumentation zu Crawl-Budget lohnt sich zu lesen, wenn du in diesem Maßstab arbeitest. Die Kurzfassung: Googlebot hat eine begrenzte Zeit, die es pro Tag auf deiner Webseite verbringt, und eine gut strukturierte Sitemap-Index hilft ihm, diese Zeit zuerst auf deinen hochstpriorisierten Content zu verwenden.Google's documentation on crawl budget is worth reading if you're operating at this scale. The short version: Googlebot has a finite amount of time it'll spend on your site per day, and a well-structured sitemap index helps it spend that time on your highest-priority content first.
Bei großen Websites lege ich neu aktualisierte Inhalte in eigene untergeordnete Sitemaps. Bei einigen meiner Implementierungen nutze ich eine sitemap-recent.xml, die nur URLs enthält, die in den letzten 30 Tagen geändert wurden und stündlich aktualisiert wird. Googlebot durchsucht diese aggressiv. Die älteren historischen Sitemap-Dateien werden weniger häufig durchsucht, was in Ordnung ist, da sich dieser Inhalt nicht ändert.sitemap-recent.xml that only contains URLs modified in the last 30 days, refreshed hourly. Googlebot recrawls that one aggressively. The older historical sitemap files get crawled less frequently, which is fine because that content isn't changing.
Das ist kein Trick. Es geht einfach darum, das Crawl-Signal der Inhaltsrealität anzupassen.
FAQ
Wie viele untergeordnete Sitemaps kann eine Sitemap-Index-Datei enthalten?
Das Protokoll erlaubt bis zu 50.000 untergeordnete Sitemaps in einer einzigen Index-Datei. In der Praxis, wenn Sie sich dieser Anzahl nähern, haben Sie hunderte Millionen URLs und befassen sich mit Problemen, die die meisten Websites nie haben. Für die überwiegende Mehrheit großer Websites haben Sie irgendwo zwischen 5 und 50 untergeordnete Sitemaps.
Muss ich meine Sitemap-Dateien mit gzip komprimieren?
Das müssen Sie nicht, es lohnt sich aber bei großen Dateien. Eine 50MB-Sitemap wird mit gzip auf etwa 3-5MB komprimiert. Googlebot akzeptiert .xml.gz-Dateien ohne zusätzliche Konfiguration. Die meisten modernen Webserver handhaben dies transparent, wenn Sie Gzip-Kompression auf Serverebene aktivieren. Für auf der Festplatte generierte statische Sitemaps komprimiere ich vorher mit gzip und serviere die .xml.gz direkt.need to, but it's worth doing for large files. A 50MB sitemap compresses down to roughly 3-5MB with gzip. Googlebot accepts .xml.gz files without any configuration. Most modern web servers will handle this transparently if you enable gzip compression at the server level. For static-file sitemaps generated to disk, I pre-compress with gzip and serve the .xml.gz directly.
Sollte ich Bild- oder Video-Sitemaps in den Index einbinden?
Ja. Wenn Sie Bild-Sitemap-Erweiterungen oder Video-Sitemaps verwenden, können diese als untergeordnete Sitemaps in derselben Index-Datei enthalten sein. Halten Sie diese in eigenen untergeordneten Dateien, anstatt Bilddaten in Ihre Standard-URL-Sitemaps zu vermischen. Das hält die Dateien kleiner und macht es einfacher, nur die Bild-Sitemap zu regenerieren, wenn sich Ihre Medienbibliothek aktualisiert.
Was passiert, wenn eine untergeordnete Sitemap einen 404-Status zurückgibt?
Search Console wird dieses Kind-Sitemap im Sitemaps-Bericht als fehlerhaft markieren. Googlebot wird die anderen Kind-Sitemaps im Index weiterhin verarbeiten. Der gesamte Index wird nicht invalidiert, aber die URLs, die nur in dieser 404er-Kind-Sitemap aufgelistet sind, werden über die Sitemap nicht entdeckt. Behebe das schnell. Der Fehler bleibt wochenlang im Bericht von Search Console bestehen, auch nachdem du ihn behoben hast, was nervig, aber harmlos ist.
Kann ich einen Sitemap-Index auf einer kleinen Website verwenden?
Technisch ja, aber es gibt keinen Grund dazu. Die zusätzliche Komplexität lohnt sich nicht unter 10.000 URLs. Eine einzelne sitemap.xml ist einfacher zu pflegen, einfacher zu debuggen und leistet genau dieselbe Arbeit. Verwende eine Index-Datei, wenn du sie brauchst, nicht davor.
---
Das 50.000-URL-Limit überrascht Menschen jedes Mal, normalerweise im ungünstigsten Moment, etwa kurz vor einem Product Launch. Die Index-Struktur einmal richtig zu gestalten bedeutet, dass du dir beim Wachstum der Website nie wieder Gedanken darüber machen musst. Das ist eine Stunde Setup wert.