Wenn Bots die Regeln umgehen: Warum AI-Crawler zur Governance-Frage werden

Lange galten Web-Crawler als technisches Hintergrundrauschen. Ein Bot meldete sich mit seinem Namen, las die Regeln in der robots.txt und hielt sich daran, oder eben nicht. Das war eine Frage für Administratoren, nicht für Geschäftsführungen.

Das hat sich geändert. Im Sommer 2025 warf der Infrastruktur-Anbieter Cloudflare dem AI-Unternehmen Perplexity öffentlich vor, verdeckte und nicht deklarierte Crawler einzusetzen, um No-Crawl-Vorgaben von Websites zu umgehen. Perplexity widersprach der Darstellung deutlich. Unabhängig davon, wer am Ende recht behält, markiert der Vorfall einen Wendepunkt. Denn er zeigt, dass die Frage, welcher Bot welche Inhalte lesen darf, längst kein reines Technikthema mehr ist. Sie berührt das Verhältnis zwischen Publishern, Infrastruktur-Providern und AI-Firmen. Bots sind politisch geworden.

Was Cloudflare konkret kritisiert

Um den Streit zu verstehen, hilft ein Blick auf die Spielregeln, die das offene Web bisher zusammengehalten haben.

Die robots.txt ist eine einfache Datei, in der ein Betreiber festlegt, welche Bereiche seiner Seite automatisiert abgerufen werden dürfen und welche nicht. Sie ist kein technischer Zwang, sondern eine Konvention. Seriöse Anbieter halten sich daran. Ergänzend gibt es das Konzept verifizierter Bots: Ein Crawler gibt sich über seinen User-Agent zu erkennen, und sein Verhalten lässt sich anhand bekannter Adressbereiche überprüfen. So weiß ein Betreiber, wer da liest.

Cloudflare beschreibt nun ein Verhalten, das diese Konventionen aushebelt. Demnach soll ein Crawler, der über die offizielle Kennung blockiert wurde, seine Identität gewechselt haben: ein generischer User-Agent, der wie ein normaler Browser aussieht, dazu wechselnde IP-Adressen aus verschiedenen Netzen. Getestet habe man das mit eigens angelegten Seiten, die niemand kennen konnte, sogenannten Honeytraps, die per robots.txt ausdrücklich gesperrt waren. Der Inhalt sei trotzdem in AI-Antworten aufgetaucht.

Für Website-Betreiber ist die Konsequenz unbequem. Wer sich darauf verlässt, dass eine Sperre in der robots.txt wirkt, kann sich nicht mehr sicher sein, dass sie das tut. Inhalte, die man bewusst zurückhält, können unter der Oberfläche trotzdem geholt und weiterverarbeitet werden. Die Kontrolle, die man zu haben glaubte, wird zur Annahme.

Was das für Marken und Betreiber heißt

Auf der Business-Ebene hat der Vorfall zwei Seiten, und sie ziehen in entgegengesetzte Richtungen.

Die eine Seite ist ein Governance-Problem. Wenn Bots Inhalte entgegen den eigenen Regeln abrufen, verliert eine Marke die Hoheit darüber, was mit ihren Texten, Preisen und Aussagen geschieht. Das betrifft nicht nur urheberrechtliche Fragen, sondern auch die Kontrolle über die eigene Darstellung. Wer nicht weiß, welche Inhalte ein Agent tatsächlich gelesen hat, weiß auch nicht, worauf dessen Antworten beruhen.

Die andere Seite ist ein Sichtbarkeitsproblem, und es ist häufig das größere. Denn während viel über unerwünschtes Crawling diskutiert wird, ist das umgekehrte Risiko für die meisten Marken realer: Bots, die Inhalte nicht sehen, obwohl sie es sollten. Eine Seite, die technisch schwer lesbar ist, wird von Agenten übergangen. Die Marke fehlt dann nicht, weil sie gesperrt wurde, sondern weil sie unsichtbar blieb.

Beide Seiten führen zu denselben vier Fragen, die heute jede Marke beantworten können sollte. Welche Bots lesen meine Seite? Was sehen sie von meiner Marke? Welche Antworten bauen sie aus meinen Inhalten? Und wie merke ich, wenn sich das ändert? Wer diese Fragen nicht beantworten kann, überlässt die eigene Präsenz in AI-Antworten dem Zufall.

Zwei verschiedene Dinge: Lesbarkeit und Verhalten

An dieser Stelle lohnt eine Unterscheidung, die im Streit um Stealth-Crawler oft verschwimmt. Es gibt zwei getrennte Ebenen, und eine Marke braucht Klarheit über beide.

Die erste Ebene ist die technische Lesbarkeit, oft als AI-Readiness bezeichnet. Sie beantwortet die Frage, ob ein Agent die Inhalte überhaupt sauber erfassen kann. Dazu gehören server-seitiges Rendering, damit Inhalte nicht erst nach dem Ausführen von JavaScript erscheinen, strukturierte Daten, die Aussagen maschinenlesbar machen, saubere Feeds und klare Zugriffsregeln, inklusive neuerer Konventionen wie einer llms.txt, die AI-Systemen den Umgang mit einer Seite erklärt. Das ist die Bringschuld des Betreibers.

Die zweite Ebene ist das Verhalten der Agenten. Sie beantwortet die Frage, welche Bots wann kommen, wie oft sie lesen und ob sie sich an die Regeln halten. Diese Ebene liegt außerhalb der direkten Kontrolle einer Marke, aber sie lässt sich beobachten. Der Cloudflare-Vorfall ist ein Beispiel dafür, warum diese Beobachtung wichtig ist: Wer nur die eigene Lesbarkeit optimiert, aber nie prüft, welche Bots tatsächlich vorbeikommen, sieht nur die Hälfte des Bildes.

Die Kunst besteht darin, beide Ebenen zusammenzudenken. Eine Marke muss wissen, ob ihre Website für AI technisch lesbar ist, und sie muss gleichzeitig verstehen, welche Agenten sich daran bedienen und welche sich tarnen.

Klariton als Infrastruktur für Kontrolle und Sichtbarkeit

Genau hier setzt eine Infrastruktur-Schicht an, wie Klariton sie bereitstellt. Nicht als Werkzeug gegen einzelne Crawler, denn den Wettlauf mit sich tarnenden Bots gewinnt niemand dauerhaft, sondern als Fundament, das beide Ebenen sichtbar und steuerbar macht. Fünf Bausteine zeigen, wie das aussieht.

Technical AI Audit. Der erste Schritt prüft, ob AI-Crawler serverseitig überhaupt verwertbare Antworten sehen, statt nur ein leeres JavaScript-Skelett, das sich erst im Browser füllt. Viele Seiten liefern ihren eigentlichen Inhalt erst nach dem Ausführen von Skripten, die die meisten Bots nicht abwarten. Das Audit deckt diese Lücke auf, bevor sie Sichtbarkeit kostet.

Agentic Reach. Statt sich auf die Annahme zu verlassen, dass eine Regel wirkt, misst Agentic Reach, welche AI-Agenten die Inhalte tatsächlich lesen, aufgeschlüsselt nach Provider, Kategorie und Seite. So entsteht ein reales Bild davon, wer vorbeikommt, und Abweichungen werden sichtbar, auch solche, die man sonst übersehen würde.

LLM Discovery. Diese Ebene zeigt, wo eine Marke in den Antworten der Assistenten auftaucht und in welcher Rolle: als Empfehlung, als zitierte Quelle oder gar nicht. Aus dem diffusen Gefühl, irgendwie präsent zu sein, wird eine belastbare Grundlage für Entscheidungen.

Trust Intelligence und Safe Guard. Beide überwachen, welche veröffentlichten Antworten schwach oder veraltet sind, und verhindern, dass genau diese zum Basis-Material für Agenten werden. Denn was ein Agent einmal aufgreift, wiederholt er.

Compliance Center. Es steuert die Regeln, unter denen Antworten überhaupt in die Welt dürfen: welche Quellen zulässig sind, welche Claims erlaubt sind, welche Policies gelten. So bleibt die Kontrolle über die eigene Darstellung an einer Stelle gebündelt, statt sich in einzelnen Texten zu verlieren.

Der Gedanke dahinter ist nüchtern. Man kann nicht jeden Bot zwingen, sich zu benehmen. Aber man kann dafür sorgen, dass die eigene Marke technisch sauber lesbar ist, dass man sieht, wer liest, und dass die Antworten, die daraus entstehen, stimmen.

Praktische Leitlinien

Für Verantwortliche in Marketing, E-Commerce, Digital und Technik ergeben sich aus dem Vorfall konkrete Konsequenzen.

Nehmen Sie Bots als eigene Kategorie ernst. Führen Sie im Monitoring eine eigene Rubrik für AI-Bots, getrennt vom klassischen Traffic. Nur was sichtbar ist, lässt sich steuern. Agentic Reach liefert diese Sicht nach Provider und Seite.

Behandeln Sie robots.txt und Policies als AI-Governance. Zugriffsregeln sind nicht länger nur ein SEO-Detail, sondern Teil der Frage, wer im Namen Ihrer Marke welche Inhalte nutzen darf. Ein Compliance Center macht diese Regeln zu einer bewussten Entscheidung.

Prüfen Sie die technische AI-Lesbarkeit. Server-seitiges Rendering, strukturierte Daten, saubere Feeds und eine llms.txt entscheiden, ob ein Agent Ihre Inhalte erfassen kann. Ein Audit zeigt die Lücken, bevor sie Umsatz kosten.

Machen Sie sichtbar, wer Sie nutzt und wer nur Ihre Inhalte. Unterscheiden Sie zwischen Bot-Reads und echten AI-Referral-Klicks. Das eine zeigt, wer Ihre Inhalte liest, das andere, wer Ihnen dadurch tatsächlich Kunden schickt. Beides gehört auf dasselbe Dashboard.

Bauen Sie Antworten AI-ready. Verifizierte, zitierbare Einheiten schlagen lose Text-Häppchen. Agenten empfehlen eher, was eindeutig und belegt ist. Buying Answers und ein geführter Advisor liefern genau solche Einheiten.

Planen Sie regelmäßige Safe-Checks. Drift, veraltete Inhalte und neue Richtlinien verändern still, was Agenten aus Ihren Inhalten machen. Safe Guard prüft laufend gegen die aktuelle Quelle und meldet, bevor ein Kunde die falsche Antwort sieht.

Der rote Faden ist derselbe. Der Versuch, einzelne Crawler auszusperren, ist ein Rennen ohne Ziellinie. Die tragfähigere Antwort ist eine Schicht, die Lesbarkeit, Verhalten und Antworten dauerhaft sichtbar und steuerbar hält.

Von der Abwehr zur Kontrolle

Der Streit zwischen Cloudflare und Perplexity wird nicht der letzte seiner Art sein. Je wichtiger AI-Assistenten für Kaufentscheidungen und Recherche werden, desto härter wird um den Zugang zu Inhalten gerungen. Für Marken ist die entscheidende Erkenntnis aber nicht, welche Seite in diesem konkreten Fall recht hat.

Die Erkenntnis ist, dass Kontrolle über die eigene Präsenz in AI-Antworten nicht mehr allein durch Sperren entsteht, sondern durch Wissen. Wer weiß, ob seine Seite lesbar ist, wer liest und was daraus wird, kann handeln. Wer es nicht weiß, ist darauf angewiesen, dass sich alle an Regeln halten, von denen der aktuelle Vorfall zeigt, dass das nicht selbstverständlich ist. Die Kontrolle verlagert sich damit von der Abwehr zur Beobachtung, und von der Annahme zur Messung.