Robots.txt-Generator

Erstellen Sie eine standardkonforme robots.txt visuell, statt die Syntax auswendig zu lernen. Fügen Sie eine Regelgruppe pro Crawler hinzu, sperren oder erlauben Sie bestimmte Pfade, hängen Sie eine Crawl-Verzögerung an und weisen Sie Bots auf Ihre XML-Sitemap hin. Der Generator validiert während der Eingabe und läuft vollständig in Ihrem Browser — die Konfiguration wird nie hochgeladen, sodass Sie Regeln für einen privaten Staging-Host entwerfen können, ohne die URLs offenzulegen.

Verwendung

Starten Sie mit einer Voreinstellung oder der Standard-Wildcard-Gruppe. Alles erlauben erzeugt User-agent: * mit einem leeren Disallow:; Alles blockieren erzeugt Disallow: /. Klicken Sie auf Agent hinzufügen, um weitere Crawler-Gruppen anzulegen. Das User-Agent-Feld bietet Vorschläge für gängige Bots wie Googlebot, Bingbot, GPTBot und CCBot, Sie können aber jedes beliebige Token eintippen.

Jede Gruppe hat zwei Textbereiche: einen für Disallow-Pfade und einen für Allow-Pfade, mit einem Pfad pro Zeile. Pfade müssen mit einem Schrägstrich beginnen. Optionale globale Einstellungen stehen unter den Gruppen: eine Crawl-Verzögerung in ganzen Sekunden und eine einzelne Sitemap-URL. Die erzeugte Ausgabe aktualisiert sich live, und die Validierung meldet leere User-Agents, doppelte Gruppen, Pfade ohne führenden /, eine negative Crawl-Verzögerung und Sitemap-Werte, die keine gültigen http(s)-URLs sind. Wenn die Ausgabe sauber ist, kopieren Sie sie oder laden Sie sie als robots.txt herunter und legen Sie sie ins Wurzelverzeichnis Ihrer Website.

Praxisbeispiel: Staging-Site sperren und Sitemap behalten

Angenommen, Sie wollen einen Staging-Server aus jeder Suchmaschine heraushalten und trotzdem die Sitemap anmelden. Fügen Sie eine Wildcard-Gruppe hinzu, tragen Sie / bei Disallow ein, lassen Allow leer und setzen Sie die Sitemap auf https://staging.example.com/sitemap.xml. Die Ausgabe lautet:

User-agent: *
Disallow: /

Sitemap: https://staging.example.com/sitemap.xml

Wenn Sie stattdessen alles außer einer öffentlichen Hinweisseite sperren wollen, tragen Sie / bei Disallow und /public-notice.html bei Allow ein. Da Allow die längere, spezifischere Übereinstimmung ist, bleibt diese eine Seite crawlbar, während der Rest der Website gesperrt ist.

Wie der Regelabgleich funktioniert

Crawler vergleichen eine angeforderte URL mit den Regeln der passenden User-Agent-Gruppe. Der Abgleich erfolgt nach Präfix, nicht nach exakter Gleichheit, sodass Disallow: /admin sowohl /admin als auch /admin/users und auch /administrator sperrt — eine häufige Überraschung. Ein abschließender Schrägstrich verengt die Übereinstimmung: Disallow: /admin/ sperrt das Verzeichnis, lässt aber /administrator unberührt.

* passt auf jede Zeichenfolge, und $ verankert das URL-Ende, sodass Disallow: /*.pdf$ PDFs überall auf der Website sperrt. Der Platzhalter * als User-Agent passt auf jeden Crawler, der keine eigene benannte Gruppe hat. Ein Crawler befolgt nur eine Gruppe: die spezifisch benannte, falls sie existiert, sonst die Wildcard-Gruppe. Deshalb stört eine eigene GPTBot-Gruppe Ihre Googlebot-Regeln nicht.

Blockieren, noindex oder Authentifizierung?

Die richtige Kontrolle hängt davon ab, was Sie erreichen wollen, und diese Werkzeuge sind nicht austauschbar. Die folgende Tabelle ist die Faustregel, die die meisten Unfälle mit der Sichtbarkeit in Suchmaschinen verhindert.

Ziel	Mittel	Warum
Crawl-Budget bei Facetten- oder internen Such-URLs sparen	Disallow	Die Seite bleibt aus der Warteschlange des Crawlers, ist aber weiterhin über Links indexierbar
Eine Seite ganz aus den Suchergebnissen heraushalten	noindex-Meta-Tag oder X-Robots-Tag	Der Bot muss die Seite crawlen, um die Direktive zu sehen, also nicht per Disallow sperren
Private Daten schützen	Authentifizierung oder Passwortschranke	robots.txt ist öffentlich und kann keinen Zugriff erzwingen
Eine ganze Staging-Umgebung vom Crawlen abhalten	Disallow: / für *	Der schnellste Weg, einen Nicht-Produktions-Host aus dem Index zu halten

Ein häufiges Muster ist, Facetten-URLs in robots.txt zu sperren, während die kanonischen Produktseiten crawlbar bleiben. Wenn eine Seite weder gecrawlt noch indexiert werden soll, ist Disallow in Ordnung, weil Sie entschieden haben, dass sie nie sichtbar sein soll.

Häufige Fehler

• robots.txt als Zugriffskontrolle behandeln. Die Datei ist öffentlich; jeder kann die aufgeführten Pfade lesen. Legen Sie niemals Admin-Panels, API-Schlüssel oder private Dokumente hinter eine Disallow-Regel in der Hoffnung auf Geheimhaltung. Nutzen Sie Authentifizierung.
• noindex-Verhalten erwarten. Das Sperren einer URL verhindert das Crawlen, sodass ein Crawler das noindex-Tag der Seite nie sieht. Blockieren und Deindexieren sind getrennte Vorgänge.
• Den führenden Schrägstrich vergessen. Disallow: admin ist kein gültiger Pfad. Jede Regel muss mit / beginnen.
• Zwei Gruppen für denselben Bot anlegen. Doppelte User-agent-Zeilen für einen Crawler werden mehrdeutig zusammengeführt. Halten Sie eine Gruppe pro Agent.
• Crawl-delay in einer Google-orientierten Datei lassen und annehmen, es wirke. Google ignoriert es; nutzen Sie die Crawling-Rate-Einstellungen in der Search Console.
• CSS und JavaScript blockieren. Wenn Sie Ihre Asset-Verzeichnisse per Disallow sperren, können Crawler Seiten nicht richtig rendern und schätzen Mobiltauglichkeit und Inhalt falsch ein.

Randfälle und Stolperfallen

Die Crawl-delay-Direktive wird nur in die erste Gruppe geschrieben, passend zu den üblichen Crawler-Erwartungen; ist Ihre erste Gruppe ein bestimmter Bot, gilt die Verzögerung dort. Eine fehlende robots.txt (HTTP 404) wird als „alles erlauben“ behandelt, während ein Serverfehler (5xx) Crawler dazu bringen kann, ganz zurückzuweichen — halten Sie die Datei also erreichbar. Verwenden Sie UTF-8 ohne Byte-Order-Mark; ein verirrtes BOM vor User-agent kann die erste Zeile unlesbar machen. Schließlich ist der User-Agent-Abgleich für das Token selbst groß-/kleinschreibungsunabhängig, sodass Googlebot und googlebot denselben Crawler meinen.

Ein leeres Disallow: und Disallow: / sind Gegensätze und beim manuellen Bearbeiten leicht zu verwechseln. Das erste erlaubt die ganze Website, das zweite sperrt sie. Kommentare, die mit # beginnen, werden ignoriert, kommentieren Sie also gerne — aber halten Sie sie auf einer eigenen Zeile statt hinter einer Regel, da manche älteren Parser Inline-Kommentare falsch behandeln.

Die Validierung in diesem Tool fängt strukturelle Probleme ab, bevor sie in Produktion gelangen, doch einige Prüfungen lohnen sich weiterhin manuell. Bestätigen Sie, dass die Datei unter https://yourdomain.com/robots.txt HTTP 200 liefert — eine Weiterleitung dort wird von Google befolgt, von manchen Crawlern aber ignoriert. Öffnen Sie die URL in einem privaten Fenster, um sicherzustellen, dass Ihr Server keine HTML-Fehlerseite vor den Text setzt. Rufen Sie dann https://yourdomain.com/robots.txt ab und prüfen Sie, dass die erste Zeile User-agent lautet und kein verirrtes Zeichen ist.

Sobald die Datei live ist, nutzen Sie den robots.txt-Bericht in der Google Search Console und das Gegenstück in den Bing Webmaster Tools, um blockierte Ressourcen zu finden, die Sie nicht blockieren wollten. Wenn Sie viele Hosts verwalten, halten Sie Staging-Dateien strikt und Produktionsdateien freizügig, und prüfen Sie die Datei immer, wenn Sie einen neuen Top-Level-Bereich wie /shop/ oder /api/ hinzufügen.

Verwandte Tools

• Meta-Tag-Generator
• HTTP-Status-Referenz
• URL-Encoder/Decoder
• XML-Formatierer