robots.txt

Definition: Die robots.txt ist eine einfache Textdatei, die im Stammverzeichnis einer Website unter der URL example.com/robots.txt abgelegt wird und auf dem Robots Exclusion Protocol (REP) basiert. Sie gibt Suchmaschinen-Crawlern Anweisungen welche Seiten und Verzeichnisse gecrawlt werden dürfen (Allow) und welche nicht (Disallow). Suchmaschinen wie Google und Bing prüfen robots.txt vor dem Crawlen einer Website. Entscheidend: robots.txt kontrolliert ausschließlich das Crawling – nicht die Indexierung. Eine via robots.txt blockierte Seite kann trotzdem indexiert bleiben wenn externe Links auf sie zeigen. Um Indexierung zu verhindern ist noindex (Meta-Tag oder HTTP-Header) notwendig. Für Marketing-Teams ist robots.txt relevant für Crawl-Budget-Optimierung und den Schutz interner Bereiche vor Indexierung.

Erläuterung

Der häufigste robots.txt-Fehler ist das Blockieren von CSS- und JavaScript-Dateien: Googles Crawler braucht diese Ressourcen zum Rendern von Seiten. Wenn GTM, Analytics-Skripte oder Styling-Dateien geblockt sind, sieht Google Ihre Seite möglicherweise ganz anders als ein Nutzer. Das kann zu Rankingproblemen und falschem Mobile-Rendering führen. Zweithäufigster Fehler: versehentliches Blockieren der gesamten Site via «Disallow: /» in Produktion.

robots.txt-Syntax

User-agent: Welcher Crawler ist angesprochen; «User-agent: *» = alle Crawler; «User-agent: Googlebot» = nur Google; «User-agent: GPTBot» = OpenAI-Crawler für KI-Training; mehrere User-agent-Blöcke in einer Datei möglich; jeder Block gilt bis zum nächsten User-agent oder Dateiende
Disallow: Pfade die nicht gecrawlt werden sollen; «Disallow: /admin/» blockiert alles unter /admin/; «Disallow: /» blockiert gesamte Website (Staging-Konfiguration – nie in Produktion!); «Disallow: » (leer) = nichts blockieren; case-sensitiv auf Apache/Linux-Servern
Allow: Ausnahmen von Disallow-Regeln; «Allow: /public/»: erlaubt /public/ auch wenn übergeordnetes Verzeichnis geblockt ist; Allow hat Priorität vor Disallow wenn beide Regeln einen Pfad abdecken; nützlich für facettierte Navigation: Disallow: /search? + Allow: /search?sort=
Sitemap: «Sitemap: https://example.com/sitemap.xml» am Ende der robots.txt; informiert Crawler wo die Sitemap liegt; mehrere Sitemap-Einträge möglich; kein User-agent-Block nötig – gilt für alle; Best Practice: immer angeben

Crawl-Budget-Optimierung

Was blockieren: /admin/, /backend/, /wp-admin/: Backend-Bereiche; URL-Parameter die Duplicate Content erzeugen: «Disallow: /*?sort=» (facettierte Navigation); interne Suchergebnisse: «Disallow: /search»; Datei-Downloads wenn kein SEO-Wert: /downloads/; interne Tracking-URLs; Session-ID-URLs
Was NICHT blockieren: CSS-Dateien (/assets/, /static/): Googlebot rendert Seiten und braucht Styles; JavaScript-Dateien (GTM, Analytics, Frameworks): blockiertes JS = Googlebot sieht ungestylte Seite; wichtige Landingpages auch wenn noindex gesetzt; Bilder die in Google Image Search ranken sollen
Crawl-Rate: Crawl-delay: 1 (Sekunden zwischen Requests) nur für nicht-Google-Crawler sinnvoll; Google ignoriert Crawl-delay in robots.txt; Google-Crawl-Rate in Search Console konfigurieren; robots.txt für Crawl-Budget-Kontrolle primär via Disallow

robots.txt vs. noindex – wichtiger Unterschied

robots.txt Disallow: Verhindert Crawling; Seite kann trotzdem indexiert bleiben (wenn externe Links vorhanden); Google kennt URL aber hat keinen Inhalt gecrawlt; Snippet in SERP leer oder aus externen Quellen; Crawl-Budget-Einsparung
noindex-Meta-Tag: <meta name="robots" content="noindex">; Seite wird gecrawlt aber nicht indexiert; Google muss die Seite crawlen können um noindex zu sehen; deshalb: Seiten mit noindex nie gleichzeitig in robots.txt blockieren – Google kann dann noindex nicht lesen
Kombination: Für Seiten die weder gecrawlt noch indexiert werden sollen: nur noindex + Password-Protection; robots.txt Disallow + noindex ist kontraproduktiv; für Inhalte die gecrawlt aber nicht indexiert werden sollen (CSS, JS): keine robots.txt-Blockierung nötig

Testing und Monitoring

Google Search Console robots.txt-Tester: Einstellungen → robots.txt-Tester; prüft ob eine URL von der robots.txt blockiert wird; zeigt aktuelle gecrawlte robots.txt-Version; simuliert verschiedene User-agents; wichtig nach jeder Änderung
Screaming Frog: crawlt robots.txt und zeigt blockierte URLs; vergleicht Crawl-Ergebnisse mit robots.txt-Regeln; identifiziert wichtige Seiten die versehentlich blockiert sind; im SEO-Audit unverzichtbar
KI-Crawler blockieren: OpenAI GPTBot: «User-agent: GPTBot / Disallow: /»; Anthropic ClaudeBot: «User-agent: ClaudeBot / Disallow: /»; Common Crawl: «User-agent: CCBot / Disallow: /»; verhindert Nutzung der eigenen Inhalte für KI-Training; rechtlich umstritten aber technisch möglich

Praxistipp: Prüfen Sie Ihre aktuelle robots.txt auf drei häufige Fehler: (1) Sind /assets/, /wp-content/, /static/ oder ähnliche Ressourcen-Ordner blockiert? Wenn ja: CSS und JavaScript werden Googlebot nicht angezeigt – Rendering-Probleme sind möglich; (2) Steht «Disallow: /» ohne User-agent-Einschränkung? Das blockiert die gesamte Site für alle Crawler; (3) Ist ein Sitemap-Eintrag vorhanden? Nach Prüfung der robots.txt: Google Search Console → Crawlprotokoll prüfen ob wichtige Seiten gecrawlt werden. Staging-Systeme immer mit robots.txt «Disallow: /» blockieren – aber diese Konfiguration vor dem Produktionslaunch entfernen.