Muss jede Website eine robots.txt-Datei haben?

Nein, eine robots.txt ist optional. Fehlt sie, gehen Suchmaschinen und andere Crawler davon aus, dass sie die komplette Website crawlen dürfen. Für die meisten Handwerker-Websites reicht deshalb eine sehr kurze Datei, die im Kern nur den Pfad zur Sitemap nennt.

Blockiert eine robots.txt auch das Google-Unternehmensprofil oder Google Ads?

Nein. Das Google-Unternehmensprofil und Google Ads laufen über eigene Systeme, die nicht auf robots.txt-Regeln der Website reagieren. Die Datei steuert ausschließlich, welche Crawler welche Bereiche der eigenen Domain besuchen dürfen.

Wie oft sollte man die robots.txt prüfen?

Ein Blick lohnt sich nach jedem Relaunch, jedem Anbieterwechsel und jeder größeren Umstrukturierung der Website, weil dabei am häufigsten versehentlich Sperren stehen bleiben oder neue Pfade fehlen. Ohne solche Anlässe reicht eine Prüfung ein- bis zweimal im Jahr.

Robots.txt für die Firmenwebsite richtig einrichten

Eine robots.txt-Datei legt fest, welche Crawler welche Bereiche einer Website besuchen dürfen, sie liegt als einfache Textdatei unter der-eigenen-domain.de/robots.txt. Für die meisten Handwerksbetriebe braucht es nur wenige Zeilen: einen Verweis auf die Sitemap und im Zweifel gar keine Sperre, denn Google und Bing sollen jede öffentliche Seite finden dürfen. Wichtig zu wissen ist vor allem, was die Datei tatsächlich tut: Sie steuert das Crawlen einzelner Seiten und hat nichts mit dem Google-Unternehmensprofil oder Google Ads zu tun. Ob eine Seite indexiert wird, entscheidet ein anderer Mechanismus.

Was die robots.txt tatsächlich steuert

Google unterscheidet in seiner offiziellen Dokumentation klar zwischen Crawling und Indexierung. Ein Disallow-Eintrag in der robots.txt sagt einem Crawler nur, dass er eine Seite nicht besuchen soll. Verlinken andere Seiten trotzdem auf diese URL, kann Google sie unter Umständen weiterhin mit Titel und URL im Suchergebnis anzeigen, nur ohne Beschreibungstext, weil der Inhalt der Seite selbst nie gelesen wurde. Wer eine Seite wirklich aus dem Suchergebnis heraushalten will, braucht dafür ein noindex per Meta-Tag oder HTTP-Header auf der Seite selbst, nicht in der robots.txt. Für Handwerksbetriebe ist das vor allem bei internen Bereichen relevant: eine Login-Seite für Mitarbeitende gehört eher mit noindex versehen als nur per robots.txt gesperrt, sonst kann die nackte URL trotzdem irgendwo auftauchen.

Die Grundsyntax in vier Zeilen

Eine funktionierende robots.txt kommt für die meisten Firmenwebsites mit wenigen Direktiven aus:

User-agent: *
Disallow:

Sitemap: https://www.beispielbetrieb.de/sitemap-index.xml

User-agent legt fest, für welchen Crawler der folgende Block gilt, der Stern steht für alle. Disallow ohne Pfad dahinter bedeutet, dass nichts gesperrt ist, das ist für eine öffentliche Betriebswebsite meist die richtige Grundeinstellung. Erst wenn es echte interne Bereiche gibt, etwa einen Admin-Zugang des Content-Management-Systems oder eine Vorschau-Umgebung, kommt eine gezielte Zeile wie Disallow: /admin/ dazu. Die Sitemap-Direktive ist laut Google-Dokumentation nicht an einen bestimmten User-Agent gebunden, sie gilt global und darf mehrfach auftauchen, wenn mehrere Sitemaps eingereicht werden. Wichtig ist eine vollständige URL mit https:// und Domain, ein relativer Pfad wird nicht akzeptiert.

Ein Punkt wird dabei oft übersehen: Google und Bing lesen dieselbe Datei, verhalten sich aber nicht identisch. Bing unterstützt laut eigener Dokumentation die Direktive Crawl-delay, mit der sich die Abruffrequenz des Bingbot drosseln lässt, etwa Crawl-delay: 5 für einen langsameren Takt. Google ignoriert dieselbe Zeile vollständig, die Crawl-Frequenz von Googlebot lässt sich stattdessen nur über Server-Antwortzeiten und die Einstellungen in der Search Console beeinflussen. Für eine normale Handwerker-Website mit überschaubarem Traffic braucht es Crawl-delay in aller Regel gar nicht, wichtig ist nur zu wissen, dass eine Zeile, die bei Bing wirkt, bei Google wirkungslos bleibt.

Ein weiterer Punkt, der bei mehreren Domain-Teilen leicht übersehen wird: Eine robots.txt gilt laut Spezifikation nur für genau den Host, unter dem sie liegt. Betreibt ein Betrieb neben der Hauptseite noch einen separaten Shop oder ein Bewerberportal auf einer eigenen Subdomain wie shop.beispielbetrieb.de, braucht diese Subdomain eine eigene robots.txt-Datei, die Regeln der Hauptdomain gelten dort nicht automatisch mit.

Wo die Datei bei modernen Website-Systemen herkommt

Bei statisch generierten Websites liegt die robots.txt meist als einfache Datei im Projektverzeichnis und wird bei jedem Build unverändert mit ausgeliefert, eine nachträgliche Anpassung erfordert also eine neue Veröffentlichung der Seite. Bei klassischen Baukästen und vielen Content-Management-Systemen dagegen wird die Datei dynamisch aus den Einstellungen im Adminbereich erzeugt, oft versteckt unter einem Menüpunkt wie „Sichtbarkeit” oder „SEO-Einstellungen”. Wer die Website wechselt, sollte deshalb nicht automatisch davon ausgehen, dass die neue Plattform dieselbe robots.txt übernimmt, ein Blick nach dem Umzug gehört mit auf die Checkliste, ähnlich wie beim übrigen technischen Abgleich beim Wechsel des Website-Anbieters.

Häufige Fehler bei kleinen Firmenwebsites

Der teuerste Fehler ist eine Zeile wie Disallow: /, die versehentlich stehen bleibt. Sie sperrt die komplette Website für den betroffenen Crawler und wird oft aus einer Staging- oder Testumgebung mit in den Live-Betrieb übernommen, wo sie eigentlich richtig war, um die Vorschauversion aus der Suche herauszuhalten. Nach jedem Wechsel des Website-Anbieters oder jedem größeren Relaunch lohnt sich deshalb ein kurzer Blick auf genau diese Zeile, ähnlich wie beim Prüfen von 301-Weiterleitungen nach einem Umzug. Ein zweiter häufiger Fehler ist eine veraltete oder falsch geschriebene Sitemap-Adresse, etwa nach einem Wechsel des Content-Management-Systems, wodurch neue Sitemap-Formate wie sitemap-index.xml nicht mehr zur alten Angabe passen. Ein dritter Punkt betrifft die Dateigröße: Google verarbeitet laut eigener Spezifikation nur die ersten 500 Kibibyte einer robots.txt, alles danach wird ignoriert, für eine normale Handwerker-Website mit wenigen Dutzend Seiten ist das praktisch nie ein Thema, kann aber bei automatisch generierten, sehr langen Sperrlisten relevant werden.

Der vierte und am leichtesten übersehene Fehler betrifft gesperrte Design- und Funktionsdateien. Sperrt eine zu weit gefasste Regel wie Disallow: /assets/ oder Disallow: /css/ versehentlich die CSS- und JavaScript-Dateien der eigenen Website mit, kann Googlebot die Seite nicht mehr so darstellen, wie ein Besucher sie sieht. Google warnt in seinen Richtlinien für Website-Betreiber ausdrücklich davor, das Crawlen von JavaScript oder CSS zu sperren, weil das direkt schadet, wie gut die eigenen Systeme die Seite rendern und indexieren, mit der Folge schwächerer Platzierungen. Ohne CSS erkennt Google mitunter kein responsives Layout mehr und stuft eine in Wirklichkeit mobilfreundliche Seite als Plain-Text-Dokument ein. Sperrregeln für ganze Verzeichnisse wie /assets/, /static/ oder /wp-includes/ verdienen deshalb einen zweiten Blick, bevor sie live gehen.

KI-Crawler in der robots.txt

Seit 2023 gibt es neben den klassischen Such-Crawlern eine zweite Gruppe von Bots, die Inhalte für das Training oder die Beantwortung von KI-Anfragen sammeln. Wer hier nichts einträgt, lässt sie standardmäßig zu, was für die eigene Sichtbarkeit in KI-Antwortmaschinen in der Regel sinnvoll ist, wie der Artikel zu GEO und KI-Antwortmaschinen genauer beschreibt. Wichtig ist die Unterscheidung, wofür ein Bot überhaupt zuständig ist:

Crawler	Betreiber	Wofür zuständig
GPTBot	OpenAI	Sammelt Inhalte fürs Training generativer Modelle
Google-Extended	Google	Eigener Opt-out-Baustein für Gemini-Training, unabhängig vom normalen Googlebot
ClaudeBot	Anthropic	Sammelt Inhalte fürs Training von Claude-Modellen
PerplexityBot	Perplexity	Crawlt für die Indexierung, die direkt in Perplexity-Antworten einfließt
CCBot	Common Crawl	Sammelt für einen offenen Datensatz, der vielen KI-Trainings als Grundlage dient

Ein Detail lohnt besondere Aufmerksamkeit: Google-Extended blockieren zu lassen, hat laut Google keinen Einfluss auf das normale Ranking in der Google-Suche, denn es ist ein eigenständiger Baustein getrennt vom regulären Googlebot. Wer also aus Vorsicht Trainings-Crawler aussperrt, muss nicht befürchten, dadurch schlechter gefunden zu werden, sollte aber bei PerplexityBot genauer hinschauen, weil dieser Bot direkt mit der Sichtbarkeit in Perplexity-Antworten verknüpft ist. Für die meisten Handwerksbetriebe, die zusätzliche Anfragen über KI-Suchen gewinnen wollen, ist es deshalb sinnvoller, alle diese Bots zuzulassen, statt sie pauschal zu sperren.

Die eigene robots.txt prüfen

Der schnellste Test ist ein Aufruf der eigenen Adresse mit angehängtem /robots.txt im Browser, das zeigt sofort, ob die Datei existiert und was drinsteht. Wer es genauer wissen will, prüft mit curl -I https://www.beispielbetrieb.de/robots.txt, ob der Server tatsächlich mit Statuscode 200 antwortet und nicht etwa eine Weiterleitung oder Fehlerseite ausliefert. Den früheren robots.txt-Tester in der Google Search Console gibt es seit Ende 2023 nicht mehr, Google hat ihn durch einen robots.txt-Bericht ersetzt, der zeigt, wann die Datei zuletzt abgerufen wurde und ob es Parsing-Warnungen gibt, aber keine einzelnen URLs mehr gegen die Regeln testet. Für die konkrete Frage, ob eine bestimmte Seite gerade durch eine Sperre blockiert wird, hilft die URL-Prüfung im Live-Test, direkt erreichbar über dieselbe Search Console, über die auch die Sitemap eingereicht wird.

Nächster Schritt

Für die meisten Betriebe reicht eine robots.txt mit offener Grundeinstellung und korrektem Sitemap-Verweis völlig aus, technisch kompliziert wird es erst bei mehreren Umgebungen oder einem Anbieterwechsel. Mr.Site prüft diese Datei im Rahmen der Website-Betreuung bei jedem Relaunch und jeder größeren technischen Änderung mit, damit keine versehentliche Sperre unbemerkt live bleibt.