AI Crawler steuern: LLM-Bots blocken oder zulassen?

Redaktionell bereinigtes Transkript des oben eingebundenen Videos von SEOPRESSO Podcast. Grundlage sind die automatisch erzeugten Untertitel; Formulierungen wurden zur Lesbarkeit behutsam geglättet, offensichtliche Erkennungsfehler korrigiert und Sprecherzuordnungen in eckigen Klammern ergänzt. Einzelne Passagen können vom gesprochenen Wort abweichen.

Einstieg: AI Crawler blocken oder nicht?

[Björn] Wir sitzen heute auf der CAMPIXX in der Lobby und wollen uns über das Thema AI Crawling unterhalten. Das ist ein wichtiges Thema, inhouse wie im Agenturalltag. Die Frage ist immer: Blocken wir AI Crawler oder blocken wir sie nicht? Geben wir ihnen unsere Daten oder nicht? Was ist deine Meinung dazu, AI Bots blocken oder nicht?

[Juliane] Generell würde ich die Frage nie schwarz-weiß beantworten. Viele denken sofort in Disallow oder Allow, aber man kann das sehr viel dezidierter angehen. Zuerst sollte man sich anschauen, welche AI-Bot-Typen es gibt und wie man mit ihnen jeweils umgeht. Stichwort: Lasse ich Training zu? Will ich, dass meine Daten in die Trainingsdaten einfließen? Und wie gehe ich mit dem Crawling für die Suche um? Beim Crawling würde ich in der Regel empfehlen, es zuzulassen. Es gibt Edge Cases, über die man nachdenken muss, etwa exklusive Inhalte oder bestimmte Studienergebnisse, bei denen man vielleicht will, dass eine Conversion auf der eigenen Seite stattfindet. Aber grundsätzlich würde ich das Crawling zulassen, beim Training genauer hinschauen und natürlich auch überlegen, wie ich mit bestimmten Verzeichnissen und wirklich exklusiven Inhalten umgehe. Da muss man über Strategien nachdenken. Das wird aktuell noch viel zu wenig diskutiert und in den Unternehmen zu selten aktiv besprochen.

robots.txt, serverseitiges Blocken und Google-Extended

[Björn] Das ist im Prinzip wie bei den Google-Bots: Man hat eine robots.txt und legt fest, wo der Bot hin darf und wo nicht. Siehst du das auch so, dass man dediziert darüber nachdenken muss, was man freigibt und was nicht, und dass man das über die robots.txt steuert?

[Juliane] Absolut. Über die robots.txt, und du kannst natürlich auch serverseitig blockieren. Dabei muss man aber beachten, dass bestimmte Bots wie Google-Extended, also das, was alles in Gemini einfließt, nicht separat serverseitig blockierbar sind, weil es serverseitig nur den Googlebot gibt. Das heißt, dann müsste ich alles komplett für Google sperren. Deshalb kommt man um die robots.txt meistens nicht herum, wenn man an alle AI-Modelle denkt, auch in Richtung Copilot ist es dasselbe. Die robots.txt ist also schon eine gute Maßnahme, aber flankiert eventuell durch ein serverseitiges Setup, weil man serverseitig natürlich viel dezidierter rangehen kann, etwa über Reverse-IP-Lookups, um spezielle Bots gezielt zuzulassen oder zu blockieren. Meines Erachtens muss man beides in Betracht ziehen.

AI-Bots identifizieren: User Agents, Agenten und Headless Browser

[Björn] Wie identifiziert man die AI-Bots? Ist das klassisch wie bei den anderen User Agents, oder gibt es speziellere Fälle?

[Juliane] Die AI-Trainer und AI-Assistenten, die für das Crawling zuständig sind, kann man ziemlich gut über die User-Agent-Strings identifizieren; die zeichnen sich entsprechend aus. In Richtung AI-Agents ist es aktuell dagegen sehr schwer, weil die einfach einen Headless Browser und eine normale Browser-Kennung nutzen. Es gibt Initiativen, dass die sich kennzeichnen, Google hat zum Beispiel einen neuen User-Agent-String für einen AI-Agenten auf den Markt gebracht, aber generell ist diese Gruppe über die Server-Logs sehr schwer zu fassen. Ich kann mich ja auch selbst einfach als ein bestimmter Bot ausgeben. Wenn man es also hundertprozentig sauber haben will, muss man die IPs abgleichen, und das geht nur serverseitig. Das macht man nicht mal eben mit einer WordPress-Seite, in die man ein Plugin reinhaut.

[Björn] Interessant. Wenn die Agents sich als Mensch ausgeben und über einen Headless Browser kommen, wird es richtig schwierig herauszufiltern, wie viel Agent-Traffic überhaupt auf die Seite kommt.

[Juliane] Absolut, das ist gar nicht trivial. Cloudflare hat mittlerweile eine ziemlich gute Detection, da geht es um Fingerprinting, also um bestimmte Muster, die AI-Agents befolgen, etwa wie schnell sie auf Inhalte zugreifen. Es gibt viele Maßnahmen, aber genauso viele Gegenmaßnahmen, um diese Muster wieder zu durchbrechen. Das ist ein kleines Katz-und-Maus-Spiel. Möglich ist es, aber nichts davon zu hundert Prozent.

Gute und schlechte Bots: Scraping-Missbrauch

[Björn] Ich hatte letzten Monat mit unserer IT- und Security-Abteilung ein Meeting, in dem wir uns genau diese Frage gestellt haben: Welche Bots lassen wir rein und welche nicht? Und ich habe naiv gefragt, warum wir das eigentlich machen wollen. Unser CTO hat erklärt, dass auch Spammer oder Blackhats ein ChatGPT oder ein Claude nutzen können, um Inhalte zu scrapen, ohne dass du das herausfindest. Man muss also zwischen guten und schlechten Bots unterscheiden. Hast du Ideen, wie man das heute schon analysieren kann?

[Juliane] Das selbst zu analysieren ist wirklich sehr schwer. Meine Empfehlung wäre, auf Services zurückzugreifen, die solche Crawl-Aktivitäten im großen Maßstab verfolgen und sie am ehesten über Fingerprinting herausbekommen. Ansonsten ist es aktuell wirklich schwer, gerade bei den AI-Agents, die über normale Browser-Kennungen kommen. Wie willst du Inhalte blocken, wenn das gut aufgesetzt ist? Es wird immer schwieriger, seine Inhalte wirklich zu schützen.

Monitoring: Welche Inhalte lösen LLM-Requests aus?

[Björn] Dazu kommt, dass du gar nicht herausfindest, wohin der Bot geht. Bei einem normalen User wissen wir genau, auf welche Seite er gegangen ist, wie lange er da war, was er gelesen hat, wann er abgebrochen hat. Durch den AI-Bot wird das schnell undurchsichtig.

[Juliane] Ich habe dir vorhin gezeigt, dass wir ein Monitoring gebaut haben, mit dem wir uns genau anschauen können, was user-getriggerte LLM-Requests sind. Wenn ein User einem LLM einen Prompt gibt, rattert das LLM los und schaut sich verschiedene Webseiten an. Das heißt nicht, dass du auch erwähnt oder zitiert wirst, aber es heißt erstmal, dass der Bot da war und nach Inhalten gesucht hat. Die Insights daraus sind super spannend. Wir sehen zum Beispiel, dass bestimmte APIs in sehr hohem Maß frequentiert werden, und dass wir eine Menge expired Product-Detail-Seiten haben, die stark abgefragt werden. Wenn man so etwas sieht, ist die nächste Frage: Macht diese API Sinn, und wie geht man mit den expired PDPs um?

APIs, expired Products und 404-Seiten als Crawl-Fallen

[Juliane] Da lohnt es sich, im Detail zu analysieren: Welche Bots greifen hier wirklich zu? Wir haben viele Bots, die uns keinen echten Mehrwert bringen, sei es ein Byte-Spider oder der Meta-ExternalAgent, das muss man je nach eigener Strategie bewerten. Es gibt viele Bots, die ein extremes Crawl-Volumen erzeugen, und allein da zu schauen, welcher Bot es ist, hilft: Oft gibt es Muster. Und bei einer API, über die ihr eigentlich keine Informationen liefern wollt, sollte man über Blockierung nachdenken. Bei den expired PDPs kann man das Spiel spielen und wieder Inhalte einstellen oder einen Redirect setzen; man muss aber prüfen, wie sinnvoll das langfristig ist. Eigentlich will man erstmal diese sinnlose Crawl-Aktivität auf 404-Seiten verhindern. Auch da lohnt der Blick: Welcher Bot ist es? Die OpenAI-Crawler prüfen 404-Seiten in der Regel eigentlich schon, eine so starke Aktivität finde ich deshalb ungewöhnlich. Man muss mittlerweile wirklich tiefer reingehen, auch wenn das klassisch nicht zum Berufsbild des SEOs gehörte. Server-Admins können das oft weniger beurteilen, und wir müssen das SEO-Know-how dorthin transferieren.

[Björn] Wir filtern über Cloudflare schon eine Menge Bots raus. Der Bot-Traffic summiert sich bei uns auf etwa drei bis vier Prozent des Gesamt-Traffics.

Halten sich AI-Bots an die robots.txt?

[Björn] Wir hatten vorhin über die robots.txt gesprochen. Sie ist ja ein Gentlemen's Agreement für Bots im Web. Jetzt hat sich alles so verändert, und ich bin mir nicht sicher, ob eine robots.txt von diesen neuen Bots wirklich respektiert wird.

[Juliane] Meine Erfahrung ist, dass das bei OpenAI und Anthropic definitiv berücksichtigt wird. Ich habe das analysiert und bei den Domains, die aktiv blockieren, über einen längeren Zeitraum keine Crawl-Aktivität gefunden. Aber bei Perplexity zum Beispiel ist bekannt, dass sie über andere User-Agent-Strings und andere IP-Kreise trotzdem auf die Daten zugreifen. Das ist der eine Fall, bei dem man genauer hinschauen muss. Bei allen anderen, die vielleicht unter dem Radar laufen, würde ich meine Hand auch nicht ins Feuer legen. Bei OpenAI und Anthropic kann man sich gut darauf verlassen, Google-Extended natürlich auch. Darüber hinaus würde ich eher an das serverseitige Setup gehen, um das wirklich sicherzustellen.

[Björn] Also über Cloudflare?

[Juliane] Ganz genau. Das ist die sicherste Maßnahme, wenn man merkt, dass man hier wirklich ein Thema hat. Man muss sich die Verhältnisse zwischen den Crawl-Aktivitäten der AI-Crawler und der klassischen Suchmaschinen-Crawler anschauen, und es ist teilweise echt erschreckend, welchen Anteil die AI-Bots mittlerweile haben.

Wenn ChatGPT der zweithäufigste Bot ist

[Juliane] Ich habe vor kurzem ein Projekt analysiert, da war der ChatGPT-User-Bot, also der für das Crawling von OpenAI zuständige, der zweithäufigste Bot-Typ, direkt nach Google. Da merkt man, wie viel Bewegung gerade herrscht und was allein an Aktivität in den LLMs stattfindet, wo Crawling ausgelöst wird.

Training-Bots und Grounding-Bots

[Björn] Siehst du auch, ob es Crawls sind, die durch einen Nutzer-Prompt getriggert werden, oder ob das LLM wie ein Google-Crawler den ganzen Tag das Web crawlt?

[Juliane] Das kommt auf den Typ an. Die AI-Trainer sind sehr konstant unterwegs und haben ihre Peaks, das ist generell ein Thema bei diesen AI-Bots, sie sind sehr volatil. Aber sie crawlen permanent. Die Grounding-Bots dagegen sind wirklich user-getriggert, und das ist sehr spannend, wenn man seine eigene Sichtbarkeit analysieren will und überlegt, welche Prompts für mich relevant sind. Damit habe ich schon ein Abbild des tatsächlichen Nutzerinteresses: Ich weiß, wo Leute suchen und ob meine Inhalte zumindest schon fürs Crawling genutzt werden. Das ist nicht gleichbedeutend mit einer Erwähnung oder Citation, aber ich sehe, wo meine Interessenslagen liegen und wie ich das ausbauen kann.

Server-Logs als Basis für AI-Search-Tracking

[Juliane] Für mich wäre immer der erste Schritt, bevor ich ein Prompt-Tracking aufsetze, in die Logfiles zu schauen, um auf dieser Basis meine Prompts zu entwickeln. Es ist ähnlich wie im SEO: Logfiles werden immer noch viel zu wenig genutzt, weil es manchmal schwierig ist, an die Dateien zu kommen, und weil sie riesig sind. Aber gerade bei den expired Domains sieht man sehr stark, was für eine schlechte User Experience für deine Brand entsteht, wenn das LLM deine PDPs auflistet, der User darauf klickt und die Seite gar nicht existiert. Deshalb ist es umso wichtiger, genau dort reinzuschauen. Und ich sage in meinem Team immer: Prompt-Tracking zum Sichtbarkeits-Messen ist ein bisschen bias, eine Self-Fulfilling Prophecy, eine selbsterfüllende Prophezeiung. Denn du haust die Prompts rein, bei denen du denkst, dass du sichtbar bist, und dann bist du auch sichtbarer. Bei den Log-Daten siehst du dagegen genau, wo das LLM hingeht und welche Relevanz das zum Userprompt hat. Auf dieser Basis kannst du anfangen, die Seiten zu optimieren. Aktuell haben wir nicht eine Quelle, die uns sagt, wie sichtbar wir sind, wir müssen verschiedene Datenpunkte kombinieren, und die Server-Logs sind für mich ein ganz wichtiger Bestandteil, der sogar an erster Stelle steht.

Gibt es ein Crawl-Budget bei LLM-Bots?

[Björn] Kannst du etwas zum Crawl-Budget-Mythos sagen? Gibt es das bei LLM-Bots auch?

[Juliane] Nicht im ganz klassischen Sinne, wie wir es von Google kennen. Bei Google bemühen wir uns darum, den Googlebot möglichst auf der Seite zu haben. Bei den AI-Bots habe ich aktuell nicht das Gefühl, dass wir uns bemühen müssen, weil sie in der Regel sehr stark frequentieren. Aber wenn ich ein unstrukturiertes URL-Inventar habe, keine klaren Navigationsstrukturen, tiefe Crawl-Pfade oder Millionen schlecht gekennzeichneter Parameter-URLs, dann haben natürlich auch die AI-Bots ihre Schwierigkeiten. Alles, was wir im klassischen SEO in Richtung Crawling und Indexing tun, zahlt also auch hier ein. Nur müssen wir uns beim AI-Crawl-Budget weniger Sorgen machen als beim Google-Crawl-Budget.

Performance-Probleme durch Bot-Peaks

[Björn] Du hast gesagt, dass die LLM-Bots die zweithöchste Crawl-Aktivität ausmachen. Gibt es da auch Performance-Schwierigkeiten für den Server? Sieht man Unterschiede zum Google-Crawler?

[Juliane] Von der Qualität eines einzelnen Requests würde ich das gar nicht groß differenzieren. Es geht mehr um die Häufigkeit, die Spitzen und die Volatilität. Der Googlebot ist relativ konstant, es gibt mal Peaks vor Core-Updates. Bei den AI-Bots ist das teilweise sehr viel gravierender, und da muss man entsprechende Serverkapazitäten für Peaks vorhalten. Ich habe in den letzten Monaten sehr oft erlebt, dass die Serverkapazitäten einfach nicht ausgereicht haben und diese AI-Crawl-Aktivitäten die Server so an die Grenzen gebracht haben, dass Seiten down waren oder man als normaler User dreißig Sekunden warten musste, weil der Server komplett überlastet war. Das ist ein Thema, auf das man aktuell auf jeden Fall schauen sollte, wenn man es nicht in guten Händen weiß.

Hoster, Default-Blockierung und Pay-per-Crawl

[Juliane] Viele Server-Admins und Hoster berichten, dass das echt ein Thema ist und dass sie gerade selbst damit struggeln. Einige Hoster blockieren AI-Bots deshalb schon per Default, und da muss man kritisch draufschauen, gerade wenn man eine kleine Website bei einem günstigen Hoster hat.

[Björn] War es nicht Cloudflare, die so weit geblockt und ein Zahlungsmodell entwickelt haben, bei dem ein Bot für den Zugriff Token zahlen muss?

[Juliane] Das sind zwei Punkte. Erstens haben sie für alle neuen User eine AI-Bot-Detection per Default aktiviert. Wenn du als neuer Kunde bei Cloudflare ein Projekt anlegst, ist sie erstmal aktiv, und du musst sie bewusst deaktivieren. Zweitens hatten sie eine Initiative, Pay-per-Crawl, bei der Zugriffe mit einem bestimmten Statuscode gekennzeichnet werden. Aber wenn das nicht von einem LLM akzeptiert wird, bringt dir dieser Statuscode leider nichts, außer dass die Bots blockiert werden.

JavaScript, initiales HTML und Codequalität

[Björn] Haben wir noch etwas Wichtiges vergessen?

[Juliane] Ja, ein paar Aspekte. Thema JavaScript: Wir wissen inzwischen alle, dass gerade AI-Trainer JavaScript nicht ausführen können. Das muss man prüfen: Sind alle wichtigen Inhalte im initialen HTML enthalten? Dann die Semantik des Quellcodes, also die Code-Qualität. Gerade in Richtung Agentic Browsing wird es wichtiger denn je, sprechende Attribute und Text zu verwenden. All das, was wir seit vielen Jahren in Richtung Barrierefreiheit kommunizieren, wird jetzt für das AI-Crawling noch einmal wichtig.

Bing, NoArchive und Copilot

[Juliane] Zu guter Letzt, das haben vielleicht noch nicht alle auf dem Schirm: Es gab im Februar ein Update von Bing rund um das Meta-Tag NoArchive. Das gibt es eigentlich schon lange, es wurde früher genutzt, um Google zu sagen, bitte nutze keine gecachten Inhalte für die Ausspielung in den Suchergebnissen. Google unterstützt das seit etwa 2019 nicht mehr, aber man findet es in vielen Projekten noch. Das ist interessant, denn mit diesem Meta-Tag verhindere ich, dass Bing im Copilot und der ganze KI-Kram drumherum die Inhalte fürs Crawling und für Trainingszwecke nutzt. Auch das ist noch einmal wichtig in Richtung dieser neuen Barrieren.