Was die robots.txt tut — und was nicht
Die robots.txt liegt im Root-Verzeichnis einer Domain (z.B. https://example.com/robots.txt) und gibt Crawlern Anweisungen, welche Bereiche der Website gecrawlt werden dürfen und welche nicht. Das Protokoll dahinter heißt Robots Exclusion Protocol und ist seit den 1990er-Jahren etabliert.
Zwei Missverständnisse sind besonders verbreitet:
- Disallow verhindert keine Indexierung. Wenn eine Seite über externe Links erreichbar ist, kann Google sie trotz Disallow-Eintrag in den Index aufnehmen — nur ohne den Seiteninhalt gecrawlt zu haben. Das Ergebnis: eine Indexierung ohne Meta-Daten, ohne Title, ohne Description.
- Robots.txt ist kein Sicherheitsmechanismus. Wer sensible Bereiche schützen möchte, braucht eine Authentifizierung — nicht einen Disallow-Eintrag. Böswillige Bots ignorieren die Datei ohnehin.
Wer diese Grundannahmen verinnerlicht, trifft bessere Entscheidungen bei der Konfiguration. Für Seiten, die nicht indexiert werden sollen, aber gecrawlt werden dürfen, ist ein Canonical Tag oder ein noindex-Meta-Tag die richtige Lösung — nicht robots.txt.
Syntax-Grundlagen: Was Crawler tatsächlich lesen
Eine robots.txt besteht aus sogenannten Records. Jeder Record beginnt mit einem User-agent-Eintrag und enthält anschließend Allow- oder Disallow-Direktiven.
User-agent: *
Disallow: /admin/
Disallow: /intern/
Allow: /
User-agent: Googlebot
Disallow: /staging/
Sitemap: https://example.com/sitemap.xmlWichtige Regeln der Syntax:
- Ein leeres
Disallow:bedeutet: alles erlaubt. Disallow: /bedeutet: alles gesperrt — ein häufiger Fehler bei Staging-Umgebungen, der versehentlich in Produktion landet.- Pfade sind case-sensitiv:
/Admin/und/admin/sind unterschiedliche Einträge. - Wildcards (
*) und das Dollarzeichen ($) werden von Google unterstützt, aber nicht von allen Crawlern. - Kommentare beginnen mit
#und werden ignoriert.
Google dokumentiert die unterstützte Syntax in der Google Search Central ausführlich. Es lohnt sich, diese Referenz einmal vollständig zu lesen.
Die häufigsten Fehler in der robots.txt — und ihre Konsequenzen
1. Versehentlich alles gesperrt
Der gefährlichste Fehler ist gleichzeitig der häufigste: Disallow: / für alle User-Agents. Dieser Eintrag blockiert Googlebot vollständig. Websites, die von einem CMS oder Entwicklungsumgebung auf Produktion migriert werden, tragen diesen Eintrag manchmal aus der Staging-Konfiguration mit. Google Search Console zeigt in solchen Fällen eine Warnung — aber nur, wenn man aktiv nachschaut.
Sofortmaßnahme: robots.txt nach jedem Deployment prüfen. Viele Teams vergessen das, weil die Datei selten angefasst wird.
2. CSS und JavaScript blockiert
Ältere SEO-Empfehlungen rieten dazu, CSS- und JavaScript-Verzeichnisse zu sperren, um Crawl-Budget zu schonen. Das ist heute kontraproduktiv. Google rendert Seiten wie ein Browser — wenn Ressourcen nicht gecrawlt werden können, sieht Googlebot eine unvollständige Seite. Das betrifft besonders JavaScript-lastige Anwendungen. Mehr dazu im Artikel zu JavaScript SEO und Crawler-Problemen.
3. Sitemap-Verweis fehlt
Die robots.txt ist der ideale Ort, um die XML-Sitemap zu referenzieren. Viele Konfigurationen verzichten darauf. Der Eintrag Sitemap: https://example.com/sitemap.xml hilft Crawlern, die Sitemap zuverlässig zu finden — unabhängig davon, ob sie in der Search Console eingetragen ist. Wie eine saubere Sitemap aussieht, beschreibt der Artikel XML Sitemap erstellen — was Google wirklich braucht.
4. Falsche Reihenfolge von Allow und Disallow
Wenn ein Pfad sowohl von einem Allow- als auch einem Disallow-Eintrag erfasst wird, gilt bei Google die spezifischere Regel. Bei gleicher Spezifität gewinnt Allow. Andere Crawler können das anders interpretieren. Wer komplexe Regeln schreibt, sollte sie mit dem robots.txt-Tester in der Google Search Console validieren.
5. URL-Parameter nicht berücksichtigt
Facettierte Navigation, Session-IDs oder Tracking-Parameter erzeugen oft Tausende von URL-Varianten, die gecrawlt, aber nicht indexiert werden sollen. Robots.txt kann helfen, diese Pfade zu sperren — aber nur, wenn die Parameterstruktur konsistent ist. Alternativ bieten sich Canonical Tags an, um Duplicate Content strukturell zu verhindern.
6. Subdomains vergessen
Eine robots.txt gilt nur für die Domain, auf der sie liegt. example.com/robots.txt hat keine Wirkung auf blog.example.com oder shop.example.com. Jede Subdomain braucht eine eigene Datei. Wer internationale Subdomains betreibt, sollte das im Kontext von Hreflang-Konfigurationen für DACH mitdenken.
Crawl-Budget: Wann robots.txt wirklich hilft
Crawl-Budget ist für die meisten mittelgroßen Websites kein kritisches Thema. Google crawlt Seiten basierend auf ihrer Popularität und dem Crawl-Limit, das der Server zulässt. Für Websites mit hunderttausenden URLs — etwa große E-Commerce-Plattformen oder Nachrichtenportale — kann robots.txt jedoch sinnvoll eingesetzt werden, um Crawler von unwichtigen Bereichen fernzuhalten.
Typische Kandidaten für Disallow-Einträge:
- Admin- und Backend-Bereiche (
/wp-admin/,/admin/) - Interne Suchseiten (
/search?) - Druckversionen (
/print/) - Staging- oder Testverzeichnisse, die nicht in Produktion gehören
- Duplicate-Content-Pfade, die nicht per Canonical gelöst werden können
Was nicht gesperrt werden sollte: Seiten, die im Index erscheinen sollen, aber aus irgendeinem Grund als „unwichtig" gelten. Wer Seiten aus dem Index entfernen möchte, nutzt noindex — nicht robots.txt.
Robots.txt bei mehrsprachigen und internationalen Websites
Wer eine Website für den DACH-Markt betreibt und mit Sprachverzeichnissen (/de/, /at/, /ch/) arbeitet, sollte sicherstellen, dass keine dieser Verzeichnisse versehentlich gesperrt ist. Das klingt trivial, passiert aber regelmäßig bei Relaunchs oder CMS-Migrationen.
Gleichzeitig sollte die robots.txt auf alle relevanten Sitemaps verweisen — auch auf sprachspezifische Sitemaps, falls vorhanden. Ein Beispiel:
Sitemap: https://example.com/sitemap-de.xml
Sitemap: https://example.com/sitemap-at.xml
Sitemap: https://example.com/sitemap-ch.xmlDie korrekte Auszeichnung der Sprachvarianten selbst ist Aufgabe der Hreflang-Tags, nicht der robots.txt.
Robots.txt prüfen und dauerhaft monitoren
Eine einmalige Konfiguration reicht nicht. Robots.txt-Einträge können durch CMS-Updates, Plugin-Installationen oder Deployments überschrieben werden. Folgende Maßnahmen helfen, Probleme frühzeitig zu erkennen:
- Google Search Console: Unter „Crawling" → „robots.txt-Tester" lässt sich die aktuelle Datei prüfen und simulieren, welche URLs geblockt werden.
- Screaming Frog: Beim Crawl werden blockierte URLs markiert. So sieht man sofort, ob relevante Seiten betroffen sind.
- Ahrefs / Semrush: Beide Tools warnen in ihren Site-Audits, wenn wichtige Seiten durch robots.txt blockiert sind.
- Monitoring: Die robots.txt sollte in ein regelmäßiges technisches Audit eingebunden sein — idealerweise als Teil einer umfassenden Technical-SEO-Checkliste.
Wer die Performance der Website im Blick hat, sollte auch prüfen, ob blockierte Ressourcen die Ladezeit beeinflussen — etwa wenn Drittanbieter-Skripte oder Schriftarten gesperrt sind. Das hängt eng mit Core Web Vitals zusammen, da Render-Blocking-Ressourcen den LCP-Wert direkt beeinflussen können.
Eine saubere Basis-Konfiguration als Ausgangspunkt
Die folgende Konfiguration eignet sich als Ausgangspunkt für die meisten B2B-Websites. Sie sperrt typische Backend-Bereiche, verweist auf die Sitemap und lässt alle relevanten Inhalte für Googlebot offen:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /search
Disallow: /intern/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xmlDer Allow: /wp-admin/admin-ajax.php-Eintrag ist bei WordPress-Installationen notwendig, weil viele Frontend-Funktionen diese URL nutzen. Ohne diesen Eintrag kann es zu Darstellungsproblemen kommen, die Googlebot beim Rendering sieht.
Jede Konfiguration sollte auf die konkrete Seitenstruktur angepasst werden. Eine generische robots.txt, die blind kopiert wird, kann mehr schaden als nützen.