JPKCom DB

robots.txt & Sitemap — Tipps & Tricks

Kniffe für robots.txt & Sitemap: typische Stolperfallen, KI-Crawler-Strategie, das Zusammenspiel beider Dateien und die Kombination mit dem SEO & GEO Analyzer.

Zurück zur Übersicht: robots.txt & Sitemap · Tool live öffnen: www.jpkc.com/tools/robots-sitemap/

Das Manual erklärt jede Funktion, die Beispiele zeigen die Arbeitsabläufe. Hier geht es um das, was beides voraussetzt: wo die typischen Fehler lauern, wie du KI-Crawler strategisch behandelst und wie du das Tool sinnvoll mit anderen kombinierst. Die Oberfläche ist auf Englisch — echte Tab- und Button-Namen stehen deshalb im Original.

robots.txt: die gefährlichsten Stolperfallen

  • Disallow: / blockt deine ganze Website. Eine einzige Zeile im falschen Block sperrt alle Crawler komplett aus — und damit deine Site aus Google. Bau die Datei im Generator, prüf sie mit dem Live-Test unter der Vorschau, und kontrollier nach dem Upload im Check robots.txt-Tab, dass Googlebot & Co. wirklich Allowed sind. Steht Disallow: / im *-Block, warnt die Hinweisliste ausdrücklich.
  • Regeln sind Präfixe. Disallow: /admin sperrt auch /administrator und /admin-handbuch/; Disallow: /admin/ nur das Verzeichnis. Für Muster gibt es * und ein abschließendes $ (/*.pdf$) — und weil Crawler Pfad plus Query-String vergleichen, trifft /*?s= auch Suchanfragen auf Unterseiten. Im Zweifel: Pfad in den Live-Test tippen.
  • Eine eigene Gruppe hebelt * aus. Bekommt ein Bot eine eigene Gruppe, gilt für ihn nur diese — alle Sperren aus User-agent: * sind für ihn dann weg. Wer GPTBot gezielt etwas erlauben will, muss die wichtigen Sperren in dessen Gruppe wiederholen.
  • Leerzeilen trennen keine Gruppen. Stehen zwei User-agent-Zeilen mit einer Leerzeile dazwischen untereinander, teilen sie sich trotzdem die Regeln darunter. Erst eine User-agent-Zeile nach einer Regel beginnt eine neue Gruppe. Der Checker weist auf solche Leerzeilen hin; der Generator vermeidet das Problem, indem er einem Block ohne Regel Allow: / mitgibt.
  • Ein Serverfehler sperrt alles. Liefert /robots.txt einen 5xx-Status oder 429, behandeln Crawler die ganze Site als gesperrt — ein 404 dagegen erlaubt alles. Prüf nach Server-Umzügen oder CDN-Änderungen im Check robots.txt-Tab, welchen Status die Datei wirklich liefert, und ob statt der Datei eine HTML-Seite zurückkommt.
  • robots.txt ist keine Security. Die Datei ist öffentlich lesbar und wird von Crawlern nur freiwillig befolgt. Schreib niemals geheime Pfade in Disallow-Regeln — du verrätst sie damit jedem, der deine-domain.de/robots.txt aufruft. Was wirklich geschützt sein muss, gehört hinter eine serverseitige Authentifizierung.
  • Blockieren ist nicht dasselbe wie Deindexieren. Eine in robots.txt blockierte Seite kann trotzdem in den Google-Ergebnissen auftauchen (ohne Snippet), wenn andere Seiten auf sie verlinken. Willst du eine Seite aus dem Index halten, nutz ein noindex-Meta-Tag oder den X-Robots-Tag-HTTP-Header — und blockier sie dann nicht per robots.txt, sonst sieht Google das noindex gar nicht.
  • Blockier nie CSS und JavaScript. Google rendert deine Seiten, um sie zu verstehen. Sperrst du /wp-content/ oder einen Asset-Ordner pauschal, wirken deine Seiten kaputt — schlecht fürs Ranking. Sei spezifisch (siehe die WordPress-Vorlage im Examples-Tab).
  • Crawl-delay ignoriert Google. Die Direktive wird von den meisten Bots, aber nicht von Googlebot unterstützt — die Crawl-Frequenz steuerst du dort über die Search Console. Bing und Yandex halten sich daran, so steht es auch in der Hinweisliste des Tools. Für diese Bots ist ein moderater Wert (z. B. 5–10 Sekunden) sinnvoll; übertreib es nicht, sonst verlangsamst du die Indexierung unnötig.
  • Bot-Namen ohne Version. Crawler vergleichen nur den Produkt-Namen: User-agent: Googlebot/2.1 wirkt wie Googlebot, und ein verkürztes User-agent: google trifft Googlebot gar nicht. Nimm die Namen aus der Autovervollständigung, dann stimmen sie.

KI-Crawler bewusst steuern

Der eigentliche Mehrwert des Tools gegenüber simplen Generatoren ist die Sicht auf die KI-Crawler — sowohl beim Bauen (40 Bot-Vorschläge im Autovervollständigen-Feld, zwei KI-Vorlagen) als auch beim Prüfen (die Per-Bot-Tabelle mit Typ und greifender Gruppe).

  • Entscheide pro Zweck, nicht pauschal. Die Bot-Tabelle im Reference-Tab unterscheidet drei Zwecke: AI training (z. B. GPTBot, ClaudeBot, Google-Extended, CCBot), AI search (z. B. OAI-SearchBot, Claude-SearchBot, PerplexityBot) und AI user request (ChatGPT-User, Claude-User, Perplexity-User — Abrufe, die eine Person im Chat auslöst). Willst du in KI-Antworten zitiert werden, aber nicht im Training landen, nimmst du die Vorlage Block AI Training, Allow AI Search; willst du gar keinen KI-Zugriff, Block All AI Crawlers.
  • Bündel die Bots in einer Gruppe. Ein Block mit GPTBot, ClaudeBot, CCBot ist übersichtlicher als drei gleiche Blöcke — der Generator schreibt daraus eine Gruppe mit drei User-agent-Zeilen. Mehrere Gruppen für denselben Bot führen Crawler ohnehin zusammen; der Checker weist darauf hin.
  • Google-Extended ≠ Googlebot. Google-Extended blockt nur das Gemini-Training, nicht die klassische Google-Suche. Wer aus Angst vor „KI" pauschal alles Google-artige aussperrt, wirft versehentlich seine normale Sichtbarkeit weg.
  • Prüf nach dem Bearbeiten gegen. Schon vor dem Upload zeigt der Live-Test im Generator, ob ein Bot gesperrt ist. Nach dem Upload prüfst du die Datei im Check robots.txt-Tab: Die Per-Bot-Tabelle zeigt dir schwarz auf weiß, welcher KI-Crawler jetzt Allowed und welcher Blocked ist — inklusive Gruppe und greifender Regel.
  • Bedenke die GEO-Folgen. Gesperrte KI-Crawler kosten im GEO-Score des SEO & GEO Analyzers Punkte: Dessen Prüfung AI Crawlers Allowed testet alle 16 KI-Bots aus derselben Bot-Liste und zieht gestaffelt ab — von 3 Punkten bleiben bei 1 bis 3 gesperrten Bots noch 2, bei 4 bis 6 noch 1, ab 7 keiner mehr. Schon ein einziger gesperrter Bot kostet also einen Punkt. Sperren ist eine bewusste Entscheidung gegen KI-Sichtbarkeit — kein Versehen, das nebenbei passieren sollte.

Sitemap: sauber statt vollständig

  • Nur kanonische URLs, die HTTP 200 liefern. Keine Duplikate mit ?utm_*- oder Session-Parametern, keine Weiterleitungen, keine 404er. Jede tote oder doppelte URL verschwendet Crawl-Budget.
  • Keine blockierten oder noindex-Seiten in die Sitemap. Das ist die goldene Regel: Eine URL gehört nie gleichzeitig in ein Disallow der robots.txt und in die Sitemap — dieser Widerspruch verwirrt Crawler. Die Sitemap sagt „bitte indexieren", die robots.txt sagt „nicht abrufen". Der Check Sitemap-Tab gleicht beide Dateien automatisch ab und nennt die URLs, die für Googlebot gesperrt sind.
  • Nur Ziel-URLs, keine Weiterleitungen. Die Stichprobe Do the URLs work? im Checker findet Weiterleitungen und kaputte Seiten. Bei großen Sitemaps prüft sie 20 gleichmäßig über die Liste verteilte URLs — häufen sich darin Treffer, lohnt ein Blick auf die ganze Liste, die du mit Copy all URLs in dein eigenes Werkzeug übernimmst.
  • lastmod nur mit echtem Datum. Ein gefälschtes oder pauschal auf „heute" gesetztes Änderungsdatum untergräbt das Vertrauen der Crawler in dein Signal. Lass das Feld lieber leer, als zu lügen — und nutz den Button Empty lastmod → today nur, wenn die Seiten wirklich heute geändert wurden. Die Metadata-Tabelle im Checker zeigt dir, wie konsequent du lastmod nutzt.
  • changefreq und priority kannst du dir sparen. Google ignoriert beide Felder; das Tool lässt sie deshalb per Default leer und vermerkt sie im Checker als „ignored by Google". Wichtig ist allein ein korrektes lastmod.
  • Sonderzeichen überlässt du dem Generator. Ein & im Query-String muss in XML als & stehen, Umlaute und Leerzeichen gehören prozentkodiert. Der Generator erledigt beides; eine von Hand gebaute Sitemap mit rohem & ist nicht wohlgeformt — und der Checker meldet sie als Fehler, weil Crawler die ganze Datei verwerfen.
  • Große Sites splitten. Ab 50.000 URLs oder 50 MB ist Schluss pro Datei — dann mehrere Sitemaps plus eine Index-Datei, die du im Generator über File type Sitemap index baust. Gzip-komprimierte .xml.gz-Dateien prüft der Checker ebenfalls. Der Check Sitemap-Tab meldet mehr als 50.000 URLs und kann Index-Dateien Kind für Kind aufdröseln. Die 50-MB-Grenze prüft er nur im Expert Mode: Über den Server-Proxy kommt eine so große Datei gar nicht vollständig an, sondern wird vorher gekürzt und als unvollständig gemeldet.

Datenschutz und Betrieb

  • Generatoren bleiben lokal. Die beiden Generator-Tabs erzeugen und prüfen alles im Browser; dein Zwischenstand wird nur in deinem LocalStorage gespeichert, nichts wird hochgeladen. Über Reset (mit Rückfrage) räumst du ihn weg.
  • Die Checker laufen über einen Proxy — das ist gewollt. Eine fremde Datei kann der Browser wegen CORS nicht direkt laden. Der serverseitige Proxy holt sie; die geprüfte Domain sieht dadurch einen Request vom JPKCom-Server, nicht deine IP. Praktisch, wenn du nicht im Crawler-Log einer fremden Seite auftauchen willst.
  • localhost und Intranet gehen nicht. Aus SSRF-Schutz blockiert der Proxy private und interne Adressen. Eine lokale Dev-Instanz prüfst du entweder über eine öffentliche Staging-Domain oder per Expert Mode mit lokalem Proxy.
  • Das Rate-Limit kurz aussitzen. Im Standard-Modus liegen zwischen zwei Prüfungen mindestens 3 Sekunden, serverseitig sind 120 Abrufe pro Minute möglich. Kommt ein Wartehinweis, einfach kurz warten statt nachfeuern.
  • Sehr große Sitemaps werden eventuell abgeschnitten. Der Proxy lädt bis 5 MB und entpackt .xml.gz-Dateien auf höchstens 10 MB; darüber meldet der Checker, dass die Ergebnisse unvollständig sind. Für vollständige Abrufe gibt es den Expert Mode.

Mit anderen JPKCom-Tools kombinieren

  • Bauen hier, prüfen im Kontext. Du baust robots.txt und Sitemap in diesem Tool — die Wirkung auf eine konkrete Seite siehst du im SEO & GEO Analyzer: Dessen Robots Analysis-Tab und die Prüfungen Allowed by robots.txt, Sitemap in robots.txt und AI Crawlers Allowed greifen genau auf das zu, was du hier erzeugst — und nutzen denselben Parser, sodass beide Tools zum selben Ergebnis kommen. Reihenfolge: hier bauen → hochladen → im Analyzer dieselbe URL prüfen → grün ablesen.
  • Den GEO-Teil ergänzen. Die Sitemap ist die Roadmap für klassische Suchmaschinen; das maschinenlesbare Gegenstück für LLMs erzeugst du mit dem llms.txt-Generator.
  • Die gelisteten Seiten optimieren. Jede URL in deiner Sitemap sollte saubere Meta-Daten haben — die baust du mit dem Meta-Tags-Generator.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jede Option und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.