Vor dem Senden ausfüllen
[Website-URL][Opus-Growth-Hosting oder WordPress]
Überarbeite die robots.txt meiner Website [Website-URL] auf Basis einer bewussten Richtlinie für KI-Crawler. Website-Typ: [Opus-Growth-Hosting oder WordPress]. Meine Präferenz: [A: für alle offen / B: Suche offen, Training gesperrt / C: individuell, bitte erläutern].
1. Ist-Zustand lesen. Lies [Website-URL]/robots.txt mit site_read_url. Wenn die Website auf Opus-Growth-Hosting läuft, lies die robots.txt zusätzlich mit site_read_file und bestätige, dass sie mit der Live-Version übereinstimmt. Bei WordPress finde mit wordpress_seo heraus, welches SEO-Plugin sie ausliefert, und prüfe mit wordpress_snippet action='list', ob bereits ein Snippet die robots.txt verändert. Liste alle vorhandenen Regelgruppen, alle Disallow-Zeilen und alle Sitemap-Zeilen auf.
2. Rollen erklären. Ordne die Crawler drei Gruppen zu und sage mir in je einem Satz, was ich verliere oder gewinne:
1. Suche und Zitierung: OAI-SearchBot, Claude-SearchBot, PerplexityBot, Bingbot, Googlebot, Applebot. Wer diese sperrt, sorgt dafür, dass die Website in den Antworten des jeweiligen Assistenten nicht mehr als Quelle zitiert wird.
2. Live-Abruf im Auftrag eines Nutzers: ChatGPT-User, Claude-User, Perplexity-User. Diese Zugriffe erfolgen, wenn ein Nutzer meinen Link teilt oder der Assistent eine Seite öffnet, um eine Frage zu beantworten. Laut Dokumentation der Anbieter gilt die robots.txt bei solchen nutzerinitiierten Anfragen möglicherweise nicht in jedem Fall. Weise also darauf hin, dass eine Regel hier keine Garantie ist.
3. Modelltraining: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, meta-externalagent. Wer diese sperrt, schränkt die Nutzung der Inhalte für künftiges Training ein, entfernt aber keine Inhalte aus bereits trainierten Modellen. Das Sperren von Google-Extended hat keine Auswirkungen auf die Google-Suche oder AI Overviews.
3. Entwurf schreiben. Erstelle die neue robots.txt für meine Präferenz und beachte dabei diese Regeln:
1. Sobald du eine Gruppe unter dem eigenen Namen eines Crawlers schreibst, liest dieser Crawler die Gruppe `User-agent: *` nicht mehr. Kopiere deshalb jede Disallow-Zeile aus der *-Gruppe (Admin-Bereich, Warenkorb, interne Suchergebnisse usw.) in jede benannte Gruppe, sonst öffnest du unbemerkt private Bereiche.
2. Sperre keine CSS-, JavaScript- oder Bilddateien, da Crawler sie zum Rendern der Seite benötigen.
3. Behalte die vorhandenen Sitemap-Zeilen bei und ergänze die vollständige Sitemap-URL, falls sie fehlt.
4. Sperre keinen Crawler aus der Such-Rolle, es sei denn, ich verlange es ausdrücklich.
5. Lass SEO-Crawler von Wettbewerbern (etwa AhrefsBot und SemrushBot) unangetastet, sofern ich nichts anderes sage, sie liegen außerhalb des Umfangs dieser Aufgabe.
4. Vorschau zeigen. Vergleiche die alte und die neue Datei Zeile für Zeile und zeige eine Tabelle mit der Entscheidung vorher und nachher für jeden Crawler: Crawler, Rolle, alte Entscheidung, neue Entscheidung. Warte auf meine Freigabe.
5. Nach der Freigabe anwenden.
1. Gehostete Website: Schreibe die robots.txt mit site_write_file. Die Plattform legt vor jedem Schreibvorgang einen Versions-Snapshot an. Sage mir daher, zu welcher Version aus site_versions ich zurückkehren kann.
2. WordPress: Existiert auf dem Server keine physische Datei, erzeugt WordPress die robots.txt selbst, und der Filter `robots_txt` kann sie verändern. Erstelle mit wordpress_snippet ein PHP-Snippet, das diesen Filter nutzt, Ort 'everywhere'. Das Snippet wird inaktiv angelegt, also zeige mir den Code und aktiviere es erst nach meiner Freigabe. Ist ein Cache-Plugin aktiv, leere den Cache mit wordpress_purge_cache.
6. Zurücklesen. Lies die robots.txt erneut mit site_read_url und zeige, dass der neue Inhalt live ist. Hat sich bei WordPress der Inhalt nicht geändert, liegt auf dem Server eine physische robots.txt-Datei, die der Filter nicht erreichen kann. Schalte in diesem Fall das Snippet ab und führe mich durch die Änderung der Datei im Dateieditor des SEO-Plugins (Yoast: Werkzeuge, Dateieditor; Rank Math: Allgemeine Einstellungen, robots.txt bearbeiten) oder im Hosting-Panel.
Schließe mit einem Hinweis in zwei Sätzen ab: Die Änderung wird wirksam, sobald die Crawler die Datei neu einlesen (meist innerhalb eines Tages), und wenn eine CDN- oder Firewall-Regel nach Crawler-Namen blockiert, reicht die robots.txt allein nicht aus.
Beispielergebnis
Ein Beispiel für die Ausgabe dieses Prompts. Die Struktur stammt aus der echten Ausgabe der Tools, Zahlen und Namen sind fiktiv.
Beispielausgabe (basierend auf einer fiktiven Website, keine echten Kundendaten)
Die aktuelle Datei enthält zwei Gruppen: User-agent: * (Disallow: /panel/, /cart/) und User-agent: GPTBot (Disallow: /). Ihre Präferenz ist B: Suche offen, Training gesperrt.
| Crawler | Rolle | Alte Entscheidung | Neue Entscheidung |
|---|
| OAI-SearchBot | Suche | Erlaubt | Erlaubt |
| Claude-SearchBot | Suche | Erlaubt | Erlaubt |
| PerplexityBot | Suche | Erlaubt | Erlaubt |
| ChatGPT-User | Nutzerabruf | Erlaubt | Erlaubt |
| GPTBot | Training | Gesperrt | Gesperrt |
| ClaudeBot | Training | Erlaubt | Gesperrt |
| Google-Extended | Training | Erlaubt | Gesperrt |
| CCBot | Training | Erlaubt | Gesperrt |
Hinweis: Die alte GPTBot-Gruppe hat die Zeilen /panel/ und /cart/ nicht wiederholt. Das war dort unproblematisch, weil die Gruppe die gesamte Website gesperrt hat, aber in der neuen Datei werden beide Zeilen in jede benannte Gruppe geschrieben.
Nach Ihrer Freigabe wurde robots.txt mit site_write_file geschrieben. site_read_url hat die Datei live gelesen, sie lieferte 200 und zeigt den neuen Inhalt. Für ein Rollback enthält die Version von 14:02 in site_versions die alte Datei.
Hinweis: Crawler lesen die Datei in der Regel innerhalb eines Tages neu ein. Wenn eine Firewall-Regel nach Crawler-Namen blockiert, reicht robots.txt allein nicht aus.