In Webflow behandeln wir robots.txt als Teil des Publish-Prozesses. Die Einstellungen liegen unter Site settings → SEO → Indexing.
Wir prüfen Production zuerst
Wir öffnen /robots.txt und suchen nach zu breiten Regeln, falschem Host und doppelten Sitemap:-Zeilen.
Wir berücksichtigen die automatische Sitemap
Bevor wir eine Zeile hinzufügen, prüfen wir, ob Webflow sie bereits erzeugt. Bei Reverse-Proxy- oder Multi-Site-Setups beachten wir die dokumentierte Möglichkeit, die automatische Referenz zu ersetzen.
Speichern ist nicht Publish
Wir ändern, speichern, veröffentlichen und rufen die Datei erneut ab. Bleibt sie alt, untersuchen wir Cache und Domain-Routing.
Content-Signal ist eine andere Ebene
Content-Signal beschreibt Präferenzen zur KI-Inhaltsnutzung; robots.txt steuert Crawling. Diese Mechanismen halten wir getrennt.
Wir testen vor dem Release
Wir nutzen Tester und Validator. Private Previews bekommen echten Zugriffsschutz.
Content-Signal ist kein robots.txt-Standard
Webflow dokumentiert den HTTP-Header Content-Signal für Präferenzen wie ai-train=no, search=yes oder ai-input=no, weist aber darauf hin, dass dies auf einer vorgeschlagenen Erweiterung und nicht auf einem akzeptierten Standard basiert. robots.txt beantwortet die Zugriffsfrage; Content-Signal drückt eine Nutzungspräferenz aus, wo sie unterstützt wird.
Sitemap, Publishing und Domain müssen zusammenpassen
Webflow fügt die Sitemap häufig automatisch in robots.txt ein. Vor einer manuellen Zeile prüfen wir, ob sie bereits vorhanden ist und den kanonischen Host nutzt. Bei Reverse Proxy oder Multi-Site klären wir, welche Ebene /robots.txt und /sitemap.xml tatsächlich ausliefert.
Speichern ist nicht Veröffentlichen. Unser finaler Test erfolgt nach dem Publish auf der öffentlichen Custom Domain; Staging-Domain und Produktionsdomain behandeln wir als getrennte Origins.
