Robots.txt-Fallstricke bei Headless- und JAMstack-Websites

Die robots.txt ist bei einem klassischen CMS meist unkompliziert. Bei einem JAMstack- oder Headless-Setup dagegen liefern Teams regelmäßig subtile Fehler aus, weil der Build-Prozess die Datei so erzeugt, dass kaum noch erkennbar ist, was wirklich darin steht. Dieser Artikel behandelt die typischen robots.txt-Fallstricke bei statischen und Headless-Deployments, mit den richtigen Mustern für jedes Framework.

Das Muster „Staging versehentlich indexiert“

Der häufigste und folgenreichste Fehler: Dieselbe Codebasis wird sowohl auf Staging als auch auf Produktion ausgerollt. Die Logik der robots.txt hängt von einer Umgebungsvariable ab, die beim Produktions-Build nicht gesetzt ist. Also landet auf Produktion versehentlich ein User-agent: * Disallow: / aus den Staging-Standardwerten. Innerhalb weniger Tage ist die gesamte Produktions-Website aus dem Index verschwunden. Die Lösung: Der Produktions-Build setzt die Produktions-robots.txt ausdrücklich und bricht ab, wenn die Variable fehlt.

Next.js: der public-Ordner gegenüber der API-Route

Next.js unterstützt die robots.txt als statische Datei in /public/robots.txt oder als dynamische API-Route unter /pages/api/robots.txt (oder app/robots.txt). Wer beides mischt, erzeugt ein Rennen bei der Dateiauflösung, das von der Next.js-Version abhängt. Entscheiden Sie sich für einen Ansatz und bleiben Sie dabei. Für die meisten Websites ist die statische Datei einfacher und zuverlässig.

Nuxt: das Modul gegenüber der generierten Datei

Nuxt hat ein Robots-Modul, das die robots.txt beim Build erzeugt. Um es richtig zu konfigurieren, müssen Sie wissen, in welcher Umgebung der Build läuft. Der häufige Fehler: Die Robots-Konfiguration gilt in der Entwicklung, aber nicht in der Produktion, und die Entwicklungs-robots.txt landet auf der Produktions-Website.

Headless WordPress: wer liefert was

Bei Headless WordPress hat das API-Backend eine eigene robots.txt und das Frontend ebenfalls. Beide sind erreichbar. Achten Sie darauf, dass das API-Backend alles sperrt (der GraphQL-Endpunkt soll nicht indexiert werden) und das Frontend die eigentliche Produktions-robots.txt ausliefert. Die Standard-robots.txt von WordPress ist für ein Headless-Setup mit ziemlicher Sicherheit nicht das, was Sie wollen.

robots.txt pro Umgebung

Das Muster, das über Frameworks hinweg zuverlässig funktioniert, sind robots.txt-Dateien pro Umgebung im Repository, wobei der Build-Prozess anhand eines expliziten Umgebungs-Flags auswählt, welche ausgerollt wird. Namen wie robots.production.txt, robots.staging.txt und robots.preview.txt machen die Absicht offensichtlich. Verzichten Sie auf clevere Generierung zur Laufzeit, wenn eine statische Datei pro Umgebung genügt.

Sitemap-Verweise

Die robots.txt sollte Ihre Sitemap mit einer absoluten URL referenzieren. Viele robots.txt-Dateien verweisen relativ auf /sitemap.xml. Google kommt damit zurecht, es ist aber anfälliger. Verwenden Sie die vollständige URL inklusive Protokoll und Domain und prüfen Sie im Browser, dass sie lädt, bevor Sie committen.

User-Agent-spezifische Regeln

Die meisten Websites brauchen keine User-Agent-spezifischen Regeln. Die Versuchung, bestimmte Bots wie AhrefsBot oder SemrushBot zu blockieren, ist real, bringt aber selten echten Nutzen: Die Bots halten sich an die robots.txt, und das Blockieren verrät Ihren Wettbewerbern vor allem, welche Tools Sie verwenden. Bleiben Sie für fast alles bei User-agent: *, es sei denn, es gibt einen konkreten Grund für Unterscheidungen.

Crawl-delay und andere veraltete Direktiven

Google ignoriert Crawl-delay. Bing berücksichtigt es teilweise. Die meisten anderen Bots ignorieren es. Bei Problemen mit der Serverlast liegt die Lösung nicht in der robots.txt, sondern in Ratenbegrenzung oder einem skalierten Server. Entfernen Sie Crawl-delay-Einträge aus jeder robots.txt, die welche enthält: Sie erwecken den falschen Eindruck, Sie hätten etwas Sinnvolles konfiguriert.

Allow vor Disallow bei widersprüchlichen Pfaden

Standardmäßig gewinnt die längere Regel. Bei Disallow: /api/ und Allow: /api/public/ gilt für /api/public/ das Allow und überall sonst unter /api/ das Disallow. Testen Sie konkrete Pfade im robots.txt-Tester von Google, bevor Sie davon ausgehen, dass ein komplizierter Regelsatz funktioniert.

Validierung in der CI

Der zuverlässigste Schutz vor robots.txt-Fehlern ist eine CI-Prüfung, die den Build abbrechen lässt, wenn die robots.txt nicht dem erwarteten Produktionsmuster entspricht. Zwanzig Zeilen Testcode verhindern die gesamte Kategorie der Deployment-Fehler. Die meisten Teams haben diese Prüfung nicht, sie sollten sie haben.

Der Audit-Rhythmus

Die robots.txt gehört unabhängig vom Framework auf jede vierteljährliche Audit-Checkliste, weil sich Änderungen unbemerkt einschleichen. Ein Tool für kontinuierliche Audits, das Änderungen an der robots.txt meldet, findet Probleme wenige Stunden nach dem Deploy statt Wochen später.

Bei JAMstack- und Headless-Websites ist die robots.txt eine der riskantesten Dateien im Build, denn eine einzige geänderte Zeichenfolge kann eine ganze Website aus Googles Sicht offline nehmen. Wer in explizite, umgebungsabhängige Konfiguration und CI-Validierung investiert, hat das beim ersten abgewendeten Beinahe-Unfall sofort wieder drin. UtilitySEO und ähnliche Audit-Tools verfolgen Änderungen an der robots.txt über die Zeit, genau die richtige Form der Überwachung für eine Datei, die sich selten ändern sollte und dann drastisch.