Sitemap / Robots.txt Cross-Check: Zwei Quellen, eine Wahrheit

Googles Crawler entscheidet anhand von zwei Dateien, ob eine URL indexiert wird: der XML-Sitemap als aktiver Einladungsstapel und der robots.txt als Ausschlussliste. Widersprechen sich beide – eine URL steht in der Sitemap, ist aber in der robots.txt blockiert – wertet Google dies als Crawl-Fehler. In der Search Console tauchen solche URLs unter „Indexiert, obwohl durch robots.txt blockiert“ oder „Durch robots.txt blockiert“ auf.

Dieses Szenario entsteht klassischerweise bei Migrationen: eine neue Disallow: /preview/-Regel wird in die robots.txt aufgenommen, der Sitemap-Generator läuft aber weiter und exportiert Preview-URLs. Oder ein Sitemap:-Eintrag zeigt nach einem Relaunch auf eine Datei, die es nicht mehr gibt – ein 404, den niemand bemerkt.

Unser Cross-Check gibt eine URL oder eine Domäne ein, holt die robots.txt, parst alle Sitemap:-Deklarationen, liest jede Sitemap (inklusive <sitemapindex>-Verzeichnisse) und testet eine Stichprobe der enthaltenen URLs gegen die robots-Regeln. Die verdichtete Punchliste zeigt sofort: was passt, was nicht passt, was fehlt.

So nutzen Sie den Cross-Check

1. Domäne eingeben: Entweder nur example.com oder eine beliebige URL derselben Domäne. Das Tool extrahiert automatisch den Origin und hängt /robots.txt an.
2. Check starten: Ein Klick genügt. Die Prüfung dauert typischerweise 2–5 Sekunden und bleibt dank Transient-Cache beim wiederholten Aufruf derselben Domäne nahezu instant.
3. Summary-Strip lesen: Oben sehen Sie vier Kennzahlen: deklarierte Sitemaps, erreichbare Sitemaps, gezogene Stichprobengröße und davon durch robots.txt blockierte URLs. Letzterer Wert in Rot ist der entscheidende Handlungsindikator.
4. Findings prüfen: Befunde sind nach Schweregrad sortiert (rot > gelb > blau). Rot bedeutet: sofort beheben. Blau: Hinweis, kein Bug.
5. Sitemap-Karten durchklappen: Jede gefundene Sitemap bekommt eine eigene Karte mit Statuscode, Typ (urlset vs. sitemapindex), Stichprobentabelle und – bei Treffern – der konkreten Regel, die eine URL blockiert.

Was die Stichprobe bedeutet

Bei Sitemaps mit vielen Tausend URLs testet der Cross-Check keine vollständige Liste, sondern eine Stichprobe von 25 URLs pro Sitemap. Der Grund ist pragmatisch: 10.000 URLs einzeln gegen robots.txt zu prüfen würde die Auswertung verlangsamen, ohne zusätzliche Erkenntnis zu liefern – wenn auch nur eine URL mit dem typischen Muster /preview/ kollidiert, erscheint der gesamte Regel-Widerspruch im Report. Für ein vollständiges Audit pro URL genügen zusätzlich Google Search Console → Abdeckung.

Bei <sitemapindex>-Dateien

Große Websites packen ihre Sitemaps in eine Sitemap-Index-Datei. Unser Tool folgt maximal eine Ebene tief und prüft die ersten drei Sub-Sitemaps. Das reicht, um typische Kollisionen zu entdecken, ohne 500 Unter-Sitemaps durchzuklopfen.

Warum passieren diese Fehler?

Migration von Staging zu Produktion

Auf Staging-Umgebungen steht oft ein kompaktes Disallow: / in der robots.txt, um eine versehentliche Indexierung der Baustelle zu vermeiden. Beim Go-Live wird die Datei getauscht – aber der Sitemap-Generator exportiert weiterhin Staging-spezifische URLs, die nach dem Relaunch nicht mehr existieren oder via 301 auf Produktion zeigen. Ergebnis: Google holt sich den Redirect aus der Sitemap und folgt ihm – die robots-Regel hingegen greift für die alte URL nicht mehr, aber das falsche Signal ist schon gesendet.

Preview- und Intranet-Pfade

WordPress-Installationen mit Plugins für Page-Preview, Staging-Subdomains oder interne Kundenbereiche deklarieren häufig Disallow: /preview/ oder Disallow: /intern/. Wenn jedoch die XML-Sitemap dieselben URLs ausliefert (weil sie z. B. als „Seite“ im WP-Backend existieren und keine Noindex-Meta-Anweisung tragen), entsteht genau der Widerspruch, den dieses Tool aufdeckt.

Sitemap-Pfad im Setup vergessen

Ein Klassiker: Die Website liefert /sitemap.xml aus, aber in der robots.txt fehlt die Sitemap:-Zeile. Google findet die Datei zwar trotzdem via Search Console, aber andere Crawler (Bing, Seznam, Baidu, AI-Bots) verlassen sich auf die Deklaration. Wir testen /sitemap.xml, /sitemap_index.xml, /sitemap-index.xml und /wp-sitemap.xml als Fallbacks – wenn einer trifft, erscheint ein blauer Hinweis mit Handlungsempfehlung.

Häufig gestellte Fragen

Was bedeutet der Statuscode an jeder Sitemap-Karte?

Der HTTP-Statuscode der HEAD-Anfrage, mit der wir die Sitemap-URL prüfen. 200 = erreichbar. 301/302 = Redirect (wir folgen automatisch). 403 kombiniert mit einem „Blocked by WAF“-Badge = Cloudflare oder ähnliches hält Crawler ab – das sollten Sie whitelisten, sonst sieht Google die Sitemap auch nicht. 404 = Sitemap-Datei existiert nicht.

Warum steht mein Sitemap-Eintrag trotz grünem Status auf „Disallowed“?

Weil der Statuscode der Sitemap-Datei grün ist (200), eine einzelne URL darin aber von einer Disallow-Regel der robots.txt erfasst wird. Das ist der Haupttreffer des Tools. Die Karte zeigt die Regel und die Zeilennummer in der robots.txt – Sie wissen sofort, wo Sie nachschauen müssen.

Wird der User-Agent * getestet?

Ja, wir testen gegen die Gruppe für *, weil das die Default-Policy für Googlebot und alle anderen Standard-Crawler ist. Für spezifische Bot-Regeln verwenden Sie unseren Robots.txt Validator: dort können Sie eine einzelne URL gegen einen konkreten User-Agent testen und die Entscheidungslogik Zeile für Zeile nachvollziehen.

Warum nur 25 URLs Stichprobe?

Weil das als Frühwarnsystem reicht. Wenn Ihre Sitemap auch nur eine einzige typische „Staging-Leiche“ enthält, liegt sie mit hoher Wahrscheinlichkeit in den ersten 25 Einträgen, da Sitemap-Generatoren überwiegend alphabetisch oder nach lastmod sortieren. Für einen vollständigen Audit Ihrer Indexierung bleibt die Google Search Console das umfassendere Werkzeug.

Prüft das Tool, ob die URLs tatsächlich erreichbar sind?

In dieser Version nicht. Ein Broken-Link-Check pro URL würde pro Audit 25 zusätzliche HEAD-Anfragen bedeuten und die Prüfung stark verlangsamen. Für reine Erreichbarkeit-Tests einzelner Sitemap-URLs nutzen Sie unseren LLMS.txt Validator (auch wenn der eine andere Quelle prüft, greift er auf dieselbe HEAD-Check-Infrastruktur zu) oder den Hreflang Tester (Tier-1-Liveness-Check).

Warum bekomme ich bei vielen Prüfungen hintereinander Fehler?

Bei zahlreichen Cross-Checks in kurzer Folge – etwa wenn Sie mehrere Domänen nacheinander auditieren – kann ein vorgeschalteter Webserver oder eine WAF wie Cloudflare, Imperva, Akamai oder Sucuri die Anfragen temporär als bot-artig einstufen und drosseln oder blockieren. Das äußert sich entweder als 403/503-Statuscode mit WAF-Badge oder als „Unerwarteter Fehler“. Warten Sie in dem Fall 2–5 Minuten und versuchen Sie es erneut. Ergebnisse werden für 5 Minuten gecacht – eine erneute Prüfung derselben Domäne kostet keinen zusätzlichen Netzwerk-Call.

Was bedeutet „sitemapindex“ vs. „urlset“?

Beides sind gültige XML-Sitemap-Formate nach der sitemaps.org-Spezifikation. urlset ist eine flache Liste konkreter URLs. sitemapindex ist eine Liste anderer Sitemaps – typisch für große Sites, die ihre 50.000-URL-Grenze pro Datei überschreiten und die Sitemap auf mehrere Dateien aufteilen. Der Cross-Check folgt einer Index-Datei eine Ebene tief und prüft die ersten drei Sub-Sitemaps.

Änderungsprotokoll

• Erkennt URLs, die in der Sitemap stehen und gleichzeitig durch robots.txt blockiert sind
• Flaggt Sitemap:-Deklarationen, die einen 404 oder WAF-Block liefern
• Sucht bei fehlender Deklaration automatisch die konventionellen Pfade /sitemap.xml, /sitemap_index.xml, /sitemap-index.xml, /wp-sitemap.xml
• Folgt <sitemapindex>-Dateien eine Ebene tief
• Reines Local-Rule-Matching – keine 25 zusätzlichen Netzwerk-Calls pro Audit
• Dreistufiger Schweregrad bei den Findings (hoch / mittel / info)