Die perfekte robots.txt für 2026: eine Frage der Strategie, nicht der Syntax

Wie wir bei Elbnetz unsere robots.txt aufgebaut haben, welche KI-Crawler wir hereinlassen und welche nicht – und warum die schwierigste Entscheidung keine technische ist. Mit fertigen Vorlagen für klassische Websites, Shops und schützenswerte Inhalte.

Die Wichtigste zur robots.txt 2026 in Kürze

• Die robots.txt lebt von freiwilliger Befolgung (RFC 9309, 2022) und steuert das Crawling, nicht das Indexieren – wer eine Seite zuverlässig draußen halten will, braucht noindex, nicht Disallow.
• Sie ist eine Bitte, kein Schloss: Seriöse Anbieter halten sich daran, aggressive Scraper nicht – sensible Pfade gehören deshalb nie in die robots.txt, sondern hinter Authentifizierung.
• 2026 zählen vier Bot-Kategorien: klassische Suche (durchlassen), KI-Suche/Zitation (Vertriebsweg mit Rücklink), KI-Training (der eigentliche Zielkonflikt) und aggressive Scraper (blocken).
• Die entscheidende technische Regel: Ein Crawler befolgt nur eine Gruppe – die spezifischste; eine benannte Gruppe und * werden nie kombiniert. Ein benannter Bot mit nacktem Allow: / umgeht damit unbemerkt alle *-Sperren (z. B. wp-admin).
• Faustregel: Einen Bot nur benennen, wenn er anders behandelt werden soll – und dann mit vollständiger Regelmenge oder Vollsperre (Disallow: /), nie mit nacktem Allow: /.
• Drei häufige Fehleinordnungen: Applebot-Extended ist ein Trainings-Opt-out (crawlt nicht), Google-Extended kostet keine Suchsichtbarkeit, und CCBot ist eine Trainings-Entscheidung – kein Lastproblem.
• Die einzige Frage, die wirklich zählt, ist geschäftlich, nicht technisch: Sichtbarkeit in KI-Modellen gegen Trainingsschutz – die Antwort hängt vom Geschäftsmodell ab.
• Elbnetz fährt maximal offen mit selektivem Scraper-Block (CCBot bewusst erlaubt), weil Auffindbarkeit das Geschäft ist; für schützenswerte Inhalte gibt es eine Vorlage mit Trainings-Vollsperre.
• robots.txt ist nur ein Schritt: Durchsetzung gegen unkooperative Bots erfolgt auf Edge-/WAF-Ebene, die Datei gehört quartalsweise geprüft, und die llms.txt ergänzt sie als nächster Baustein.

Warum eine alte Textdatei plötzlich wieder strategisch ist

Die robots.txt stammt aus dem Jahr 1994, lebt von freiwilliger Befolgung und wurde erst 2022 als RFC 9309 standardisiert. Jahrelang war sie Routine: Googlebot durchlassen, ein paar Verzeichnisse sperren, fertig.

2026 ist das vorbei – nicht wegen des klassischen SEO, sondern wegen der KI-Crawler. Wo früher eine Handvoll Suchmaschinen-Bots vorbeikam, sind es heute über ein Dutzend, mit grundverschiedenen Absichten. Auf Cloudflares Netzwerk zählen Googlebot, Meta-ExternalAgent, GPTBot, ClaudeBot und Applebot inzwischen zu den verkehrsstärksten Crawlern überhaupt – und der Großteil dieses Bot-Verkehrs dient dem Training von KI-Modellen. Gleichzeitig ist KI zu einer echten Traffic-Quelle geworden: Wer in den Antworten von ChatGPT, Perplexity oder Google AI Mode auftaucht, bekommt Besucher, die zunehmend besser konvertieren als klassischer Suchverkehr.

Daraus folgt der zentrale Punkt: Jeder dieser Bots fragt beim Besuch dasselbe – Darf ich diese Inhalte lesen, und wofür darf ich sie verwenden? Die Antwort gibt die robots.txt. Und wer keine bewusste Antwort hinterlegt, gibt trotzdem eine: Schweigen liest sich für einen Crawler als „Ja“.

Genau deshalb haben wir unsere eigene Datei überarbeitet und dokumentieren hier offen, wie wir entschieden haben.

Zwei Dinge, die die robots.txt nicht kann

Bevor wir Regeln aufstellen, müssen zwei hartnäckige Missverständnisse weg, weil fast alle Fehler aus ihnen entstehen.

Sie steuert das Crawling, nicht das Indexieren. Google sagt das selbst deutlich: Zweck der Datei ist es, die Crawl-Last zu steuern – nicht, eine Seite aus den Suchergebnissen herauszuhalten. Eine per robots.txt gesperrte, aber extern verlinkte URL kann trotzdem im Index landen (nur ohne sauberes Snippet). Wer eine Seite zuverlässig draußen halten will, nutzt noindex per Meta-Tag oder X-Robots-Tag. Wichtig: Dafür muss die Seite crawlbar sein – wer sie gleichzeitig per robots.txt sperrt, verhindert, dass Google das noindex überhaupt sieht.

Sie ist eine Bitte, kein Schloss. Seriöse Anbieter – Google, Microsoft, OpenAI, Anthropic, Apple – halten sich daran. Aggressive Scraper nicht zuverlässig. Wer Inhalte technisch schützen muss, braucht zusätzlich serverseitige Mittel (WAF, Rate-Limiting, Bot-Management). Daraus folgt eine Regel, die wir konsequent einhalten: Sensible Pfade gehören nicht in die robots.txt. Wer dort Disallow: /geheim/ schreibt, weist neugierige Menschen sogar erst auf den Ordner hin. Die Datei ist Crawl-Steuerung, kein Datenschutzkonzept.

Die Bot-Landschaft 2026: vier Kategorien

Der entscheidende Schritt ist, Crawler nicht mehr als eine Gruppe zu behandeln. Die saubere Einteilung in Training, Suche/Zitation und Agenten stammt aus der WCEU-2026-Session „Crawler to Citation“ von Alain Schlesser – wir übernehmen sie und ergänzen sie um die aggressiven Scraper als vierte Kategorie:

1. Klassische Suchmaschinen. Googlebot, Bingbot, Applebot. Bauen den Suchindex. Blockieren = aus der organischen Suche verschwinden. Hier gibt es nichts abzuwägen.

2. KI-Suche und Zitation. OAI-SearchBot (ChatGPT Search), ChatGPT-User (nutzerausgelöste Abrufe), PerplexityBot, DuckAssistBot. Diese Bots beantworten Live-Anfragen und verlinken auf die Quelle zurück. Sie sind der Kanal, über den man in KI-Antworten auftaucht und Referral-Traffic bekommt. Für eine Agentur, die Sichtbarkeit verkauft, sind sie kein Risiko, sondern der Vertriebsweg.

3. KI-Training. GPTBot, ClaudeBot, CCBot (Common Crawl), Google-Extended, Applebot-Extended. Diese sammeln Inhalte, um sie dauerhaft in Modelle einzubacken. Kein Referral, kein Rücklink – aber Präsenz im „Gedächtnis“ der Modelle. Hier liegt der eigentliche Zielkonflikt.

4. Aggressive Scraper. Bytespider, PetalBot, Diffbot, ImagesiftBot, MJ12bot und ähnliche. Hohe Last, fragwürdiger Gegenwert, teils schlechte Befolgungs-Historie. Diese Kategorie blockiert man – im Wissen, dass die Sperre nur bei den kooperativen greift.

Drei Bot-Details, die oft falsch eingeordnet werden

Hier lohnt Präzision, weil schon gute Quellen hier ungenau sind:

• Applebot-Extended ist kein Zitations-Bot. Es ist Apples Trainings-Opt-out-Token und crawlt selbst gar nicht. Die Sichtbarkeit in Siri, Spotlight und Safari liefert der reguläre Applebot. Wer „Apple-Sichtbarkeit will, aber kein Training“ möchte, erlaubt Applebot und sperrt nur Applebot-Extended. Beide mit derselben Regel zu blocken kostet die Apple-Suchsichtbarkeit, die man eigentlich behalten wollte.
• Google-Extended kostet keine Suchsichtbarkeit. Google stellt ausdrücklich klar: Das Token hat keinen Einfluss auf die Google-Suche oder die AI Overviews. Es steuert nur das Training bzw. Grounding von Gemini. Man kann es also bedenkenlos sperren, ohne in der Suche etwas zu verlieren – die AI Overviews speisen sich aus dem normalen Googlebot-Index und lassen sich über die robots.txt ohnehin nicht von der Suche trennen.
• CCBot ist kein „unhöflicher“ Scraper, sondern eine Trainings-Entscheidung. Common Crawl befolgt die robots.txt und ist Grundlage vieler Trainingsdatensätze. Es zu blocken ist ein Opt-out aus dem Modell-Training – kein Lastschutz. Wer maximale KI-Präsenz will, lässt CCBot bewusst zu; wer Inhalte schützen will, sperrt es. Es gehört in Kategorie 3, nicht 4.

Und eine generelle Einschränkung: Ob ein Bot die robots.txt respektiert, ist eine Eigenschaft des Anbieters, nicht der Kategorie. Manche nutzerausgelösten Abruf-Tools ignorieren die Datei, während die Pendants anderer Anbieter sie befolgen. Die robots.txt ist deshalb notwendig, aber nie ausreichend.

Die technische Tatsache, die alles entscheidet

Jetzt zum Kern – und zu der Stelle, an der viele Vorlagen (auch professionelle Konferenz-Folien) eine stille Falle eingebaut haben.

Ein Crawler befolgt immer nur genau eine Gruppe: die spezifischste, die auf seinen Namen passt. Eine benannte Gruppe und die *-Gruppe werden niemals kombiniert.

Das steht so in RFC 9309 und in Googles Dokumentation. Die Konsequenz ist drastisch und kontraintuitiv. Diese Datei tut nicht, was sie auf den ersten Blick verspricht:

User-agent: *
Disallow: /wp-admin/

User-agent: GPTBot
Allow: /

GPTBot findet hier seinen eigenen Block, befolgt nur diesen – und die *-Gruppe wird für ihn komplett ignoriert. Das Disallow: /wp-admin/ gilt für GPTBot also nicht. Man hat GPTBot, ohne es zu merken, den Admin-Bereich geöffnet.

Daraus folgt die wichtigste Faustregel überhaupt:

Benenne einen Bot nur dann, wenn seine Behandlung von der Standard-Regel abweichen soll. Und wenn du ihn benennst, gib ihm entweder eine vollständige Regelmenge (alle Schutz-Disallows wiederholt) oder eine vollständige Sperre (Disallow: /) – niemals ein nacktes Allow: /.

Damit lösen sich die scheinbaren Widersprüche zwischen den gängigen Empfehlungen auf:

• Wer empfiehlt, jeden erlaubten KI-Bot mit Allow: / aufzulisten, baut – kombiniert mit der WordPress-Standarddatei – genau die obige Falle ein. Für reine „Erlauben“-Bots ist das Benennen im besten Fall wirkungslos (Standard ist ohnehin „erlaubt“) und im schlechtesten Fall schädlich.
• Wer empfiehlt, KI-Bots gar nicht zu nennen und die Offenheit nur per Kommentar zu dokumentieren, hat für eine offene Strategie recht: funktional ändert das Benennen nichts, also lässt man es weg und hält die Datei schlank.
• Wer Training blocken will, muss die Trainings-Bots benennen – aber jeweils mit Disallow: / (Vollsperre). Das ist die einzige Situation, in der das Benennen zwingend ist, und sie ist dank Vollsperre unkritisch.

Für und Wider: einzelne KI-Bots benennen?

Weil dies die meistdiskutierte Frage ist, hier die Abwägung kompakt.

Dafür spricht: Es ist die einzige Möglichkeit, eine differenzierte Haltung auszudrücken (z. B. Training sperren, Suche erlauben) – die robots.txt kennt keinen anderen Hebel. Manche KI-Crawler suchen außerdem zuerst nach ihrem eigenen Namen. Und ein benannter Block dokumentiert eine bewusste, prüfbare Entscheidung statt eines stillschweigenden „Ja“.

Dagegen spricht: Die Nicht-Kombinations-Regel macht ein nacktes Allow: / aktiv gefährlich (siehe oben). Für eine offene Haltung ist das Benennen reine Redundanz, weil der Standard ohnehin „erlaubt“ lautet. Und die Bot-Namen ändern sich etwa quartalsweise – Listen veralten, während ein nicht gelisteter Bot ohnehin unter * läuft. Mehr Zeilen bedeuten hier mehr Wartung und mehr falsche Sicherheit, nicht mehr Kontrolle.

Unsere Synthese: Die robots.txt schlank halten. Benannt wird nur, was anders behandelt werden soll – also bei offener Strategie nur die zu sperrenden Scraper, bei restriktiver Strategie zusätzlich die Trainings-Bots als Vollsperre. Alles andere läuft sauber unter *. Die strategische Aussage gehört als Kommentar in die Datei, nicht als wirkungslose Allow-Zeilen.

Der eigentliche Kompromiss: Sichtbarkeit gegen Trainingsschutz

Damit ist die Syntax geklärt – und es bleibt die einzige Frage, die wirklich zählt, und sie ist geschäftlich, nicht technisch:

Sind wir damit einverstanden, dass unsere öffentlichen Inhalte KI-Modelle mittrainieren – im Tausch gegen maximale Auffindbarkeit in genau diesen Modellen?

Es gibt kein universelles Richtig. Die Antwort hängt vom Geschäftsmodell ab:

• Inhalts-getriebene Anbieter (Verlage, originäre Forschung, Bezahl- oder Mitgliederinhalte) haben gute Gründe, das Training abzulehnen: Einmal im Modell, ist der Inhalt dort dauerhaft, das Crawling kostet Bandbreite, und die Rechtslage entwickelt sich tendenziell in Richtung mehr Kontrolle. Ein sauberes Opt-out heute ist günstige Vorsorge.
• Reichweiten-getriebene Anbieter (Marken, Dienstleister, Agenturen) profitieren davon, in den Modellen präsent zu sein. Markennennungen und Empfehlungen in KI-Antworten entstehen auch dadurch, dass man Teil der Wissensbasis ist.

Unsere Entscheidung bei Elbnetz – und ihre Begründung

Wir verkaufen Sichtbarkeit, klassisch und in KI-Systemen. Eine Agentur, die selbst aus den Modellen verschwindet, wäre dabei wenig glaubwürdig. Deshalb ist unsere Haltung maximal offen, mit selektivem Scraper-Block: alle seriösen Such-, KI-Such- und KI-Trainings-Crawler dürfen lesen, geblockt werden nur kommerzielle Massen-Scraper ohne Gegenwert.

Das ist ein bewusster Tausch: Unsere öffentlichen Marketing-Inhalte dürfen Modelle mittrainieren. Für uns ist das kein Verlust, sondern Teil des Produkts. Schützenswertes gehört ohnehin nicht auf eine öffentliche Marketing-Website, sondern hinter Authentifizierung – außerhalb der Reichweite jeder robots.txt.

Daraus ergibt sich diese bewusst schlanke Datei:

# robots.txt · elbnetz.com
# Strategie: offen für alle seriösen Crawler – klassische Suche,
# KI-Suche/Zitation und KI-Training. Auffindbarkeit ist unser Geschäft;
# wir wollen gelesen, verstanden und zitiert werden.
# KI-Bots werden daher bewusst NICHT einzeln gelistet – sie laufen unter "*".
# Geblockt werden nur kommerzielle Massen-Scraper ohne Gegenwert.
# Letzte Prüfung: 2026-06 · nächste Prüfung: 2026-09

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=
Disallow: /*?attachment_id=

# Kommerzielle Massen-Scraper ohne Gegenwert.
# (Eine Vollsperre ist hier korrekt: Da der Bot komplett ausgeschlossen
#  wird, spielt die Nicht-Kombination mit "*" keine Rolle.)
User-agent: Bytespider
Disallow: /

User-agent: PetalBot
Disallow: /

User-agent: ImagesiftBot
Disallow: /

User-agent: Diffbot
Disallow: /

User-agent: MJ12bot
Disallow: /

Sitemap: https://elbnetz.com/sitemap_index.xml

Zeile für Zeile begründet:

• Disallow: /wp-admin/ mit Ausnahme admin-ajax.php – Standard für jede WordPress-Installation. Der Admin-Bereich hat im Crawl nichts verloren; der AJAX-Endpunkt muss aber offen bleiben, weil viele Themes und Plugins darüber Front-End-Inhalte nachladen.
• /?s= und /search/ – interne Suchergebnisse erzeugen Dünn- und Duplicate-Content und können für beliebig viele Suchbegriffe entstehen. Draußen halten schont das Crawl-Budget.
• /*?replytocom= und /*?attachment_id= – zwei WordPress-Klassiker (Kommentar-Antwort-Links und Anhang-Seiten), die endlose Parameter-URLs ohne Mehrwert erzeugen.
• Keine KI-Bots gelistet – bewusst. Sie laufen unter * (= erlaubt). Die Offenheit dokumentieren wir im Kommentarkopf, nicht in wirkungslosen Allow-Zeilen.
• Scraper-Block als Vollsperre – jeweils Disallow: /. Sauber, weil eine Vollsperre die Nicht-Kombinations-Falle nicht auslöst.
• Sitemap – erspart kooperativen Bots die Suche und verbessert die Crawl-Effizienz.

Was wir bewusst weggelassen haben

Drei Dinge, die in vielen Vorlagen stehen und bei uns fehlen – mit Absicht:

• Kein Disallow: /wp-includes/, /wp-content/plugins/ oder /wp-content/uploads/. Google rendert Seiten wie ein Browser und braucht dafür CSS, JS, Schriften und Bilder. Diese Ordner pauschal zu sperren ist heute purer SEO-Schaden – die häufigste Altlast in kopierten Vorlagen. Wer keine Sperre setzt, braucht auch keine kompensierenden Allow-Zeilen für Rendering-Ressourcen: Ein Allow ohne konkurrierendes Disallow ist ein No-op.
• Kein Disallow: /xmlrpc.php. Das ist Kosmetik, keine Sicherheit: XML-RPC-Angriffe lesen keine robots.txt. Wer XML-RPC einschränken will, tut das serverseitig oder per Plugin.
• CCBot nicht geblockt. Eine bewusste Korrektur gegenüber gängigen Vorlagen: CCBot ist ein Trainings-Sammler, kein unhöflicher Scraper. Es zu sperren wäre ein Opt-out aus dem Modell-Training – und damit ein Widerspruch zu unserer offenen GEO-Strategie. Wer Training ablehnen will, gehört in die nächste Vorlage.

Vorlagen für unterschiedliche Kundentypen

Die richtige robots.txt hängt vom Geschäftsmodell ab. Wir nutzen vier Fragen als Entscheidungsrahmen, bevor wir eine Datei schreiben: Bringt uns die jeweilige KI-Plattform Wert? Sind wir mit Training einverstanden? Was muss öffentlich sein, was geschützt? Belohnt unser Geschäftsmodell Reichweite oder Exklusivität? Daraus ergeben sich drei Standard-Profile.

Vorlage A – klassische Unternehmenswebsite

Für Dienstleister, Kanzleien, lokale Marken, Portfolios – der häufigste Fall. Identische Logik wie unsere eigene Datei: offen für alle seriösen Bots, Scraper-Block, Sitemap.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/

User-agent: Bytespider
Disallow: /
User-agent: PetalBot
Disallow: /
User-agent: MJ12bot
Disallow: /

Sitemap: https://www.beispiel.de/sitemap_index.xml

Hinweis: Schleust ein Security-Plugin pauschale Ordner-Sperren ein (z. B. Disallow: /wp-content/), ist die saubere Lösung, diese zu entfernen – nicht, sie mit Allow-Zeilen zu überschreiben.

Vorlage B – WooCommerce-Shop

Shops erzeugen Bereiche, die für Suchmaschinen wertlos sind (Warenkorb, Kasse, Konto) sowie Filter- und Sortier-Parameter. Produkte, Kategorien und Bilder bleiben crawlbar. KI bleibt offen – Produktsichtbarkeit in KI-Antworten ist Upside.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /*add-to-cart=
Disallow: /*?orderby=
Disallow: /?s=
Disallow: /search/

User-agent: Bytespider
Disallow: /
User-agent: PetalBot
Disallow: /

Sitemap: https://www.beispielshop.de/sitemap_index.xml

Die Filter-/Sortier-Sperren je nach Shop prüfen – es dürfen keine kanonischen Produkt- oder Kategorieseiten versehentlich mitgesperrt werden.

Vorlage C – schützenswerte Inhalte (Training ablehnen)

Für Verlage, originäre Forschung, Bezahl- oder Mitgliederinhalte. Hier nutzen wir den einzigen Fall, in dem das Benennen zwingend ist: Trainings-Bots werden per Vollsperre ausgeschlossen, während Suche und Zitation unter * erlaubt bleiben. Das ist das saubere „Suche behalten, Training ablehnen“ – bei Apple und Google sogar ausdrücklich über die -Extended-Token vorgesehen.

# Standard: alles Legitime erlaubt (klassische Suche + KI-Suche/Zitation).
# Googlebot, Bingbot, Applebot, OAI-SearchBot, PerplexityBot, ChatGPT-User
# laufen unter "*" und bleiben damit erlaubt.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/

# KI-TRAINING ausgeschlossen – Inhalte sollen nicht dauerhaft ins Modell.
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /

# Aggressive Scraper
User-agent: Bytespider
Disallow: /
User-agent: PetalBot
Disallow: /

Sitemap: https://www.beispiel.de/sitemap_index.xml

Zwei Hinweise: Der Roster der Trainings-Bots verschiebt sich laufend und gehört quartalsweise geprüft – manche Anbieter trennen Trainings- und Abruf-Bots in eigene Namen. Und: Diese Sperre wirkt nur bei Anbietern, die die robots.txt befolgen. Wer Inhalte wirklich schützen muss, sichert sie zusätzlich auf Server-/Edge-Ebene ab.

Was die robots.txt nicht leistet – und was dazugehört

Drei Ergänzungen, ohne die jedes Setup unvollständig ist:

Durchsetzung auf Edge-/Server-Ebene. Die robots.txt regelt nur die Kooperativen. Wer aggressive Scraper wirklich stoppen will, nutzt Bot-Management bzw. AI-Crawler-Controls auf CDN-Ebene, Rate-Limiting oder eine WAF. Die robots.txt ist die Absichtserklärung, die Firewall die Durchsetzung.

Quartalsweise Überprüfung. KI-Crawler-Namen ändern sich häufig: Bots starten, werden umbenannt oder aufgeteilt. „Einmal einrichten und vergessen“ funktioniert nicht mehr. Wir setzen das Prüfdatum bewusst in den Kommentarkopf und legen einen festen Monatstermin in den Kalender.

Die llms.txt als nächster Baustein. Parallel etabliert sich die llms.txt – ein optionaler Markdown-Index der wichtigsten Inhalte für KI-Systeme. Sie ist kein offizieller Standard und ersetzt die robots.txt nicht, sondern ergänzt sie: Die robots.txt sagt, wer rein darf, die llms.txt sagt, was am wichtigsten ist. Für eine GEO-Strategie ist sie günstige Vorarbeit – ganz gleich, welches der konkurrierenden Folge-Protokolle (NLWeb, MCP-für-Web, Agent-Manifeste) sich am Ende durchsetzt.

Damit ordnet sich die robots.txt in eine größere Kette ein: Crawler verstehen → Zugriff steuern (robots.txt) → maschinenlesbar strukturieren (Schema) → zitierfähig schreiben (Quellen, Zitate, Zahlen) → messen (KI-Referrer, Crawler-Anteil im Log). Die robots.txt ist der zweite Schritt, nicht der einzige.

Fazit

Eine gute robots.txt für 2026 ist nicht möglichst lang, sondern möglichst bewusst. Die Technik ist in einer halben Stunde geschrieben; die eigentliche Arbeit liegt in einer einzigen Entscheidung: Sichtbarkeit gegen Trainingsschutz – und die hängt am Geschäftsmodell, nicht am Code.

Unsere Datei ist offen, weil Auffindbarkeit unser Geschäft ist. Das ist kein Naturgesetz, sondern eine Entscheidung, die zu uns passt. Der wichtigste Rat ist deshalb kein Copy-&-Paste-Block, sondern eine Haltung: Verstehen Sie Ihre vier Bot-Kategorien, treffen Sie Ihren Kompromiss bewusst, benennen Sie nur, was anders behandelt werden soll – und schreiben Sie auf, warum. Genau das ist dieser Beitrag.