ToolPal
Eine Roboterfigur vor einer Laptop-Tastatur

robots.txt Generator: Die richtige Datei für Ihre Website in 2 Minuten erstellen

📷 Prateek Katyal / Pexels

robots.txt Generator: Die richtige Datei für Ihre Website in 2 Minuten erstellen

Ein praktischer Leitfaden zu robots.txt: Was die Datei tut, welche Fehler Entwickler häufig machen und wie Sie die richtige Datei für Ihre Website generieren.

DVon Daniel Park7. April 20269 Min. Lesezeit

robots.txt ist eine jener Dateien, die einmal erstellt und dann vergessen wird. Bei kleinen Inhaltswebsites ist das meist in Ordnung. Für Sites mit Admin-Panels, exponierten Staging-Pfaden, internen Suchergebnisseiten oder doppeltem Content kann eine falsch konfigurierte (oder fehlende) robots.txt monatelang still SEO-Probleme verursachen.

Dieser Leitfaden erklärt, was robots.txt tatsächlich tut, was sie nicht tut (eine häufige Quelle von Verwirrung) und wie man eine korrekte Datei für gängige Website-Typen schreibt. Mit dem robots.txt-Generator können Sie Ihre Datei erstellen, ohne die Syntax auswendig lernen zu müssen.

Was robots.txt tatsächlich tut

robots.txt ist eine einfache Textdatei, die Sie im Stammverzeichnis Ihrer Domain platzieren und Web-Crawlern mitteilt, welche URLs sie crawlen sollen und welche nicht. Das entscheidende Wort ist "crawlen" — nicht "indexieren."

Die Datei liegt unter https://yourdomain.com/robots.txt. Wenn Googlebot, Bingbot oder ein anderer Crawler Ihre Website besucht, ist das Erste, was sie tun, diese Datei abzurufen. Basierend auf dem, was sie finden, entscheiden sie, welchen URLs sie folgen sollen.

Eine minimale robots.txt sieht so aus:

User-agent: *
Allow: /

Das teilt allen Crawlern mit, dass sie alles crawlen dürfen. Funktional identisch damit, keine robots.txt zu haben.

Eine restriktivere könnte so aussehen:

User-agent: *
Disallow: /admin/
Disallow: /internal/
Disallow: /api/

Jede Direktive ist eine Disallow- oder Allow-Zeile, die auf eine oder mehrere User-agent-Gruppen angewendet wird.

Der Unterschied zwischen Crawling und Indexierung (das ist wichtig)

Viele Entwickler nehmen an, dass das Sperren einer URL in robots.txt sie aus Googles Suchergebnissen entfernt. Das stimmt nicht, und dies verursacht echte Probleme.

Was tatsächlich passiert, wenn Sie eine URL blockieren:

  • Googlebot hört auf, sie zu crawlen — er folgt keinen Links von dieser Seite, liest ihren Inhalt nicht
  • Wenn jedoch andere indexierte Seiten auf diese gesperrte URL verlinken, kann Google trotzdem feststellen, dass die URL existiert
  • Google kann diese URL dennoch in den Suchergebnissen mit einer generischen Beschreibung wie "Keine Informationen für diese Seite verfügbar" anzeigen

Wenn Sie also eine Seite vollständig aus den Suchergebnissen ausschließen möchten, reicht Disallow allein nicht aus. Sie benötigen eine noindex-Direktive — aber hier ist das Problem: Wenn die Seite vom Crawling ausgeschlossen ist, kann Googlebot das noindex-Tag nicht lesen.

Das schafft eine frustrierende Situation: Um noindex zu verwenden, müssen Sie die Seite crawlen lassen.

Die Faustregel:

  • Verwenden Sie robots.txt Disallow, um zu verhindern, dass Crawler ihr Crawl-Budget für Seiten verschwenden, die für SEO keine Rolle spielen (Staging-Pfade, interne APIs, doppelte Filterseiten)
  • Verwenden Sie das noindex-Meta-Tag, um zu verhindern, dass bestimmte Seiten in den Suchergebnissen erscheinen
  • Für wirklich sensible Seiten (Admin-Panels, private Inhalte) verwenden Sie echte Authentifizierung — nicht robots.txt

User-Agent: Spezifische Bots ansprechen

Das User-agent-Feld ermöglicht es Ihnen, alle Crawler oder bestimmte anzusprechen.

User-agent: *

Das Sternchen bedeutet "jeder Crawler, der nicht anderweitig angegeben ist." Die meisten robots.txt-Dateien verwenden dies für allgemeine Regeln.

Sie können auch benannte Bots ansprechen:

User-agent: Googlebot
Disallow: /no-google/

User-agent: Bingbot
Disallow: /no-bing/

User-agent: *
Disallow: /admin/

Regeln werden pro User-Agent-Gruppe angewendet. Googlebot folgt dem Googlebot-Block. Wenn es keinen passenden Block gibt, fällt er auf den *-Block zurück.

Einige Crawler, die Sie möglicherweise speziell verwalten möchten:

  • Googlebot — Googles Haupt-Web-Crawler
  • Googlebot-Image — Googles spezifischer Bild-Crawler
  • Bingbot — Microsoft Bing
  • GPTBot — OpenAIs Trainings-Crawler (eine neuere Sorge für Content-Sites)
  • anthropic-ai — Anthropics Trainings-Crawler
  • AhrefsBot, SemrushBot, MJ12bot — SEO- und Analyse-Tools

Wenn Sie KI-Trainings-Crawler speziell blockieren möchten:

User-agent: GPTBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: *
Allow: /

Das wird immer häufiger. Ob es für Ihre Website tatsächlich wichtig ist, ist eine separate Frage, aber die Syntax ist korrekt.

Häufige Disallow-Muster

Hier sind Muster, die für häufige Situationen korrekt sind:

Gesamtes Verzeichnis blockieren

User-agent: *
Disallow: /admin/

Der abschließende Schrägstrich ist wichtig. /admin/ blockiert /admin/settings, /admin/users usw. Ohne den Schrägstrich würde /admin auch eine Seite namens /administrator oder /admin-login blockieren — wahrscheinlich nicht das, was Sie wollen.

Spezifische Datei blockieren

User-agent: *
Disallow: /private-page.html

URL-Abfrageparameter blockieren (Filterseiten)

E-Commerce-Sites haben oft dasselbe Produkt über viele Filterkombinationen zugänglich: /products?color=red&size=L&sort=price. Das erzeugt duplizierten Inhalt. Blockieren Sie diese:

User-agent: *
Disallow: /*?

Das blockiert jede URL mit einem Abfrage-String. Vorsicht — wenn Ihre wichtigen Seiten Abfrage-Strings verwenden (manche SPAs tun das), blockiert das auch diese. Ein gezielter Ansatz:

User-agent: *
Disallow: /products/*?

Das blockiert Abfrage-String-URLs nur unter /products/.

Spezifischen Pfad innerhalb eines gesperrten Verzeichnisses erlauben

Manchmal möchten Sie den größten Teil eines Verzeichnisses blockieren, aber einen Pfad erlauben:

User-agent: *
Disallow: /account/
Allow: /account/signup

Die Reihenfolge innerhalb eines User-Agent-Blocks ist wichtig. Die meisten Crawler wenden die spezifischste passende Regel an.

Die Sitemap-Direktive

Sie können (und sollten) Ihre Sitemap-URL in robots.txt aufnehmen:

User-agent: *
Disallow: /admin/

Sitemap: https://yourdomain.com/sitemap.xml

Die Sitemap-Direktive kommt am Ende, außerhalb aller User-Agent-Blöcke. Das ist nicht nur eine Höflichkeit — Google nutzt dies aktiv, um das Crawling Ihrer wichtigen Seiten zu finden und zu priorisieren.

Wenn Sie mehrere Sitemaps haben (bei großen Sites mit Bild- oder Video-Sitemaps üblich):

Sitemap: https://yourdomain.com/sitemap.xml
Sitemap: https://yourdomain.com/sitemap-images.xml

Sie sollten Ihre Sitemap auch direkt in der Google Search Console einreichen, aber sie in robots.txt aufzunehmen stellt sicher, dass jeder Crawler, der die Datei liest, sie automatisch entdeckt.

Crawl-Delay: Mit Vorsicht verwenden

Einige Crawler unterstützen eine Crawl-delay-Direktive:

User-agent: *
Crawl-delay: 10

Das teilt Bots mit, zwischen Anfragen 10 Sekunden zu warten. Es wurde ursprünglich verwendet, um zu verhindern, dass Crawler kleine Server überlasten.

Das Problem: Googlebot ignoriert es. Google hat ausdrücklich erklärt, dass sie Crawl-delay nicht unterstützen. Wenn Sie die Crawl-Rate von Googlebot reduzieren möchten, tun Sie das in der Google Search Console unter den Crawling-Geschwindigkeit-Einstellungen.

Andere Bots wie Bingbot unterstützen Crawl-delay, also ist es nicht völlig nutzlos — aber für Google ist es wirkungslos. Verlassen Sie sich nicht darauf zur Ratenbegrenzung.

Häufige Fehler, die SEO schaden

CSS- und JavaScript-Dateien blockieren

Das war früher ein häufiger Ratschlag — "Blockieren Sie Bots daran, Skripte und Stylesheets zu crawlen, um Bandbreite zu sparen." Das ist schlechte Praxis. Google muss Ihre Seiten rendern, um sie ordentlich zu bewerten, und das Rendern erfordert CSS und JavaScript. Wenn Sie diese blockieren:

# Tun Sie das nicht
User-agent: *
Disallow: /wp-content/
Disallow: /assets/
Disallow: /*.css$
Disallow: /*.js$

kann Google nicht sehen, wie Ihre Seiten tatsächlich aussehen, was Rankings beeinträchtigen kann. Erlauben Sie Crawlern den Zugriff auf Ihre statischen Assets.

Staging- und Entwicklungsumgebungen vergessen

Wenn Ihre Staging-Umgebung unter staging.yourdomain.com oder yourdomain.com/staging/ zugänglich ist, stellen Sie sicher, dass sie entweder:

  1. Hinter einer Authentifizierung ist (bevorzugt)
  2. In robots.txt blockiert ist

Von Google indexierter Staging-Content erzeugt Probleme mit doppelten Inhalten. Das ist ein häufiges Versehen bei Sites, die schnell entwickelt werden.

robots.txt zum Schutz sensibler Inhalte verwenden

Das ist es wert, wiederholt zu werden. robots.txt ist keine Zugangskontrolle. Die Datei ist öffentlich lesbar — jeder kann yourdomain.com/robots.txt besuchen und genau sehen, welche Pfade Sie versucht haben zu verstecken. Wenn diese Pfade interessant sind, werden die Leute sie direkt besuchen. Verwenden Sie serverseitige Authentifizierung für alles, was wirklich sensibel ist.

Versehentliche Sitemap-Blockierung

# Das blockiert versehentlich die Sitemap
User-agent: *
Disallow: /
Allow: /public/

Sitemap: https://yourdomain.com/sitemap.xml

In diesem Beispiel wird /sitemap.xml durch Disallow: / blockiert, weil es nicht mit der Allow: /public/-Ausnahme übereinstimmt. Die Sitemap-Direktive in der Datei hebt die Sitemap-URL nicht automatisch auf. Sie müssten Allow: /sitemap.xml explizit hinzufügen.

Falsche Position

robots.txt muss im Domain-Stammverzeichnis liegen. yourdomain.com/robots.txt funktioniert. yourdomain.com/blog/robots.txt tut nichts — Crawler schauen nicht dort hin.

Außerdem beeinflusst eine robots.txt bei yourdomain.com nicht subdomain.yourdomain.com. Jede Subdomain benötigt ihre eigene robots.txt, wenn Sie das Crawling dort kontrollieren möchten.

robots.txt-Beispiele für häufige Site-Typen

Standard-Content- oder Marketing-Site

User-agent: *
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

Wenn es nichts zu verbergen gibt und kein Problem mit doppeltem Content besteht, halten Sie es einfach.

WordPress-Site

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://yourdomain.com/sitemap.xml

Allow: /wp-admin/admin-ajax.php ist wichtig — einige Themes und Plugins verwenden diesen Endpunkt für Frontend-Funktionalität, auf die Googlebot für korrekte Darstellung zugreifen muss.

E-Commerce-Site mit Filterseiten

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search?
Disallow: /products/*?sort=
Disallow: /products/*?page=

Sitemap: https://yourdomain.com/sitemap.xml

Warenkorb- und Checkout-Seiten sollten niemals indexiert werden. Account-Seiten sind benutzerspezifischer Content. Filter/Sortier-URL-Kombinationen erzeugen doppelten Content.

Next.js oder SPA mit API-Routen

User-agent: *
Disallow: /api/
Disallow: /_next/
Allow: /_next/static/
Allow: /_next/image

Sitemap: https://yourdomain.com/sitemap.xml

Blockieren Sie API-Routen. Blockieren Sie Next.js-interne Pfade außer den statischen Assets und dem Bildoptimierungs-Endpunkt, den Renderer benötigen.

Ihre robots.txt testen

Nehmen Sie nicht an, dass Ihre Datei korrekt ist — überprüfen Sie es.

Google Search Console hat einen robots.txt-Tester (Einstellungen > robots.txt). Sie geben einen URL-Pfad ein und er teilt Ihnen mit, ob Googlebot basierend auf Ihrer aktuellen Datei erlaubt oder blockiert ist. Er zeigt auch, was Google zuletzt als Datei abgerufen hat.

Das URL-Prüftool in der Search Console ermöglicht es Ihnen, einzelne URLs zu überprüfen und zu sehen, ob Google auf sie zugreifen und sie rendern kann.

Drittanbieter-Tools wie der robots.txt-Check in verschiedenen SEO-Suiten können die Syntax validieren und mehrere User-Agents testen. Der SEO-Meta-Generator und der OG-Bild-Generator sind nützliche Ergänzungen, wenn Sie am allgemeinen SEO-Setup Ihrer Site arbeiten.

Nachdem Sie Änderungen an robots.txt vorgenommen haben, können Sie mit dem URL-Prüftool verlangen, dass Google sie erneut abruft — obwohl Änderungen normalerweise innerhalb weniger Tage ohnehin propagiert werden.

Ihre robots.txt generieren

robots.txt manuell zu schreiben ist nicht kompliziert, aber es ist leicht, die Syntax leicht falsch zu machen — ein fehlender Schrägstrich, eine Direktive an der falschen Stelle, ein User-Agent-Block, der nicht das abdeckt, was Sie dachten.

Der robots.txt-Generator ermöglicht es Ihnen, zu konfigurierenden Bots auszuwählen, zu blockierende Pfade anzugeben, Ihre Sitemap-URL hinzuzufügen und eine saubere, gültige Ausgabe zu erhalten. Das ist schneller als die Syntax nachzuschlagen, und es reduziert die Chance eines Tippfehlers, der Sie Crawl-Abdeckung für Seiten kostet, die Ihnen wichtig sind.

Nach der Generierung platzieren Sie die Datei im Stammverzeichnis Ihres Webservers und überprüfen Sie, ob sie unter yourdomain.com/robots.txt zugänglich ist. Für die meisten Frameworks:

  • Next.js: Fügen Sie public/robots.txt hinzu oder verwenden Sie die robots.ts-Route im App Router
  • Gatsby: Platzieren Sie in static/robots.txt
  • Hugo: Platzieren Sie in static/robots.txt
  • Einfache HTML-Sites: Im Stammverzeichnis des von Ihrem Webserver bereitgestellten Verzeichnisses

Für Next.js App Router-Benutzer können Sie es auch programmatisch generieren:

// app/robots.ts
import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/admin/', '/api/'],
    },
    sitemap: 'https://yourdomain.com/sitemap.xml',
  }
}

Dieser Ansatz ist vorzuziehen für Sites, bei denen die Regeln von Umgebungsvariablen abhängen können (z.B. alle Crawler auf Staging blockieren).


robots.txt ist einfach, aber die Missverständnisse darum herum — besonders die Unterscheidung zwischen Crawling und Indexierung — verursachen echte, manchmal schwer zu debuggende SEO-Probleme. Die Datei einmal richtig konfigurieren, in der Search Console testen, und dann können Sie sie tatsächlich vergessen.

Häufig gestellte Fragen

D

Über den Autor

Daniel Park

Senior frontend engineer based in Seoul. Seven years of experience building web applications at Korean SaaS companies, with a focus on developer tooling, web performance, and privacy-first architecture. Open-source contributor to the JavaScript ecosystem and founder of ToolPal.

Mehr erfahren

Artikel teilen

XLinkedIn

Verwandte Beiträge