Logfile-Analyse für SEO und AI Search: AI-Bots erkennen und KI-Sichtbarkeit messen

Redaktionell bereinigtes und gekürztes Transkript des oben eingebundenen Videos von Bloofusion Germany (Search Camp). Grundlage sind die automatisch erzeugten Untertitel; Formulierungen wurden zur Lesbarkeit geglättet, offensichtliche Erkennungsfehler korrigiert und Sprecherzuordnungen in eckigen Klammern ergänzt. Um Begrüßungs-, Vorstellungs- und Verabschiedungspassagen wurde gekürzt, die fachlichen Aussagen sind vollständig erhalten. Einzelne Passagen können vom gesprochenen Wort abweichen.

Worum es geht: Crawling und AI

[Markus] Willkommen zu Search Camp, zu einem Thema, mit dem sich viele SEOs und GEOs in den letzten Monaten beschäftigt haben: Crawling und AI. Ich habe heute Unterstützung durch Juliane Bettinga, SEO-Expertin und Mitgründerin von SEOSOON, technisches SEO ist eines ihrer Themen. Ähnlich wie es bei Google klassisch wichtig war, dass man gecrawlt wird, ist das bei den neuen KI-Suchmaschinen auch ein großes Thema. Und die erste Frage, die man vielleicht gar nicht erwartet, ist: Kann ein AI Crawler überhaupt auf die eigene Website zugreifen? Was kann da alles schiefgehen?

Barriere 1: serverseitiges Blocken (oft unbewusst)

[Juliane] Da gibt es verschiedene Faktoren. Spannend ist, dass sich zuerst sehr viel auf das Thema Content gestürzt hat, wie mache ich meinen Content fit für LLMs, ohne die technischen Barrieren zu diskutieren. Der erste Punkt, den die wenigsten auf dem Schirm haben, ist das serverseitige Blocken. Können AI-Bots meine Seite überhaupt crawlen? Das hat nichts mit der robots.txt zu tun, sondern mit serverseitigen Blockaden: über ein CDN, über Firewalls oder über den Hoster kann es Barrieren geben. Man merkt es daran, dass ein Rate Limit ausgespielt wird oder die Bots einen Status 403 bekommen. Das ist oft problematisch, weil gerade kleinere und mittlere Websites diese Entscheidung gar nicht bewusst getroffen haben. Sie haben sich für einen Hoster entschieden, und der Hoster hat für sie entschieden, dass bestimmte AI-Bots blockiert werden. Es fehlt Transparenz, es wird nicht darüber aufgeklärt. Größere Domains steuern das sehr bewusst, auch serverseitig über IP-Ranges. Aber bei kleineren und mittleren ist es eher ein unbewusstes Blocking.

[Markus] Du hast Rate Limit gesagt. Heißt das, ich bin zu einem Zeitpunkt zugreifbar und zu einem anderen nicht mehr, oder wird man immer beziehungsweise nie geblockt?

[Juliane] In der Regel sehe ich, dass es schon direkt bei den ersten Crawl-Aktivitäten ein Rate Limit gibt. Es ist ein künstliches Rate Limit, ab dem ersten Zugriff, meines Erachtens fast schon ein Missbrauch dieses Statuscodes. Das haben wir schon öfter festgestellt.

Barriere 2: robots.txt (bewusste Steuerung)

[Juliane] Neben dem serverseitigen Blocken können wir mit der robots.txt arbeiten. Das ist in der Regel eine sehr bewusste Steuerung, weil ich sie aktiv einpflegen muss. Habe ich bestimmte Bots blockiert, ist meine Seite für die gängigsten nicht zugänglich. Es gibt Ausnahmen: Perplexity und AI-Agents halten sich nicht immer an die robots.txt, weil sie eine normale Browser-Kennung nutzen. Insgesamt ist die robots.txt aber der bewusste Mechanismus, um AI-Bots zu blockieren. Interessant: Wenn ich mich sehr bewusst für eine Blockierung entscheide, darf ich mich trotzdem nicht wundern, wenn ich noch in AI-Antworten auftauche. Die robots.txt ist keine rückwirkende Maßnahme. Ich bin oft schon in den Trainingsdaten enthalten und werde von anderen Domains referenziert. Das heißt aber nicht zwingend, dass ich komplett in AI sichtbar bin. Das sollte man sich bewusst halten.

Barriere 3: das NoArchive-Meta-Tag

[Juliane] Daneben gibt es noch ein paar Faktoren, und das ist relativ neu, da muss man den Wingman-Kollegen Credits geben, die hatten das in der Dokumentation gefunden: Wenn man noch so ein historisches NoArchive im Meta-Robots-Tag im Quellcode hat, dann wird das in Richtung Bing, also Copilot, so gewertet: bitte nicht in den KI-Antworten nutzen. Man ist dann weder fürs Training noch für die Chats in diesem Bing-Kosmos verfügbar. Das kann man leicht testen: die Bing Webmaster Tools aufmachen, dort wird ein NoArchive-Tag als Recommendation reported. Das ist neu, das muss man beachten.

Barriere 4: JavaScript

[Juliane] Und dann das Thema JavaScript. Das kann man in beide Richtungen nutzen. Wenn ich möchte, dass meine Inhalte für LLMs verfügbar sind, sollte ich wichtige Inhalte nicht in JavaScript packen. Habe ich dagegen sensible Daten, kann ich sie bewusst in JavaScript packen, dann werden sie von LLMs nicht genutzt. Die Bots, gerade beim Grounding, extrahieren erstmal reinen Text.

[Markus] Wie verbreitet ist das Problem, dass relevante Inhalte per JavaScript generiert oder nachgeladen werden?

[Juliane] Relevante Inhalte per JavaScript sehe ich immer weniger. Oft sind es einzelne Widgets oder Elemente, die per JavaScript geladen werden. Bei größeren, interaktiven Plattformen kommt es häufiger vor, da habe ich bei komplexeren Projekten öfter mit JavaScript zu tun. Eine kleine bis mittlere Website hat eher einzelne Elemente, etwa bei WordPress oder TYPO3 einen Slider, aber das sind in der Regel nicht die wichtigsten Inhalte. Für die Standardwebsite ist das meist nicht der größte Hebel.

[Markus] Wie würdest du das prüfen? Mit welchen Tools gehst du ran?

[Juliane] Für das serverseitige Blocking gibt es mittlerweile verschiedene Tools, die alle AI-Bot-Typen im Bulk durchchecken, sogenannte KI-Bot-Checker. Wir haben da auch ein kleines Tool gebaut. Man kann es auch händisch mit dem Screaming Frog machen, da lässt sich der User Agent schön wechseln, die AI-Bots sind dort per Default hinterlegt. Man muss aber jeden Bot einzeln prüfen, das ist etwas aufwendiger, deshalb die Bulk-Checker. Für die robots.txt ist den meisten bekannt, wie man sie aufruft, sie liegt im Root, es gibt auch robots.txt-Checker. Und für JavaScript ist der Screaming Frog eine gute Option: Was wird per JavaScript nachgeladen? Oder verschiedene Chrome-Plugins, mit denen man JavaScript im Browser deaktiviert. Man muss trotzdem in den Code schauen, denn nur weil man eine weiße Seite sieht, heißt das nicht, dass alles per JavaScript geladen wird, oft fehlt einfach das CSS-Styling.

[Markus] Wenn man Probleme mit JavaScript hat, es kann ein kleines Thema sein oder ein Riesenthema, weil die Website komplett auf JavaScript gebaut ist. Was sind Lösungswege, um das für KI lesbar zu machen?

[Juliane] Relativ einfach ist Server-Side Rendering. Gerade bei größeren Websites, die ich nicht komplett umbauen will, ist Server-Side Rendering the way to go. Alternativ die wichtigen Elemente, die wichtigsten Beschreibungstexte, wirklich ins Raw-HTML bringen. Das ist ohnehin sinnvoll, nicht nur für LLMs: Google kommt mit JavaScript zwar gut zurecht, aber die Welt wird komplexer, Google ist vielleicht nicht mehr der Standard-Crawler. Also gehören die wichtigsten Inhalte ins Raw-HTML.

[Markus] Ketzerische Frage: Wenn die Systeme ihre Quellen oft aus dem Google- oder Bing-Index holen, könnte ich die JavaScript-Thematik dann nicht vernachlässigen, weil Google und Bing mit JavaScript umgehen können?

[Juliane] Der Index ist ja nur der Zwischenschritt. Aus dem Index bekommen die LLMs erstmal nur die URL und die Metadaten, also Title und Description. Die URL müssen sie trotzdem noch scrapen. Das nehmen Bing und Google ihnen nicht ab. Es ist also nur ein Zwischenschritt.

Server-Performance: grüne Core Web Vitals reichen nicht

[Markus] Ein weiteres Thema ist die Server-Performance, dass mein Server zu langsam ist. Ich könnte sagen, ich schaue mir meine Core Web Vitals an, in der Search Console ist alles grün, also ist alles gut. Ist das so?

[Juliane] Die Core Web Vitals sind schon ein guter Indikator. Trotzdem kann ich mit sehr guten Core Web Vitals Serverprobleme bekommen, weil die Crawl-Aktivität durch die AI-Bots extrem zugenommen hat. Die Serverbelastung, gerade bei Shared Hosting, habe ich im letzten Jahr vermehrt bei mehreren Projekten gesehen: Sie hatten teilweise Downzeiten oder Reaktionszeiten von bis zu 20 Sekunden, obwohl an der Seite selbst nichts geändert wurde, nur der Server hatte eine extreme Auslastung durch die sprunghaften Crawl-Aktivitäten der AI-Bots. Selbst mit guten Core Web Vitals muss ich also schauen, wie der Server dahinter performt, nicht nur meine Ressourcenstruktur.

[Markus] Helfen da nicht die Crawling-Statistiken in der Search Console? Da sehe ich ja, wie viele Millisekunden bis zur ersten Antwort vergehen.

[Juliane] Ich liebe die Crawling-Statistiken, aber sie haben einen dreitägigen Verzug. Was ich dort sehe, merke ich in der Realität schon vorher, wenn ich die Seite selbst im Browser öffne. Sie sind für kurzfristiges Monitoring zu träge. Für eine Trendentwicklung der Server-Reaktionszeit schaue ich schon rein, aber fürs kurzfristige Monitoring ist die Time to First Byte eine gute Metrik, um die Server-Health zu beobachten. Dafür gibt es verschiedene Server-Monitoring-Tools.

Logfiles: die wichtigste Datenquelle

[Markus] Du hast ein Faible für das Thema Logfiles. Lass uns das aufziehen. Was sind Logfiles?

[Juliane] Server-Logs sind Protokolldateien, die jeden Request an den Server dokumentieren. Ein Request kann vom User kommen oder von verschiedenen Bots. Sie protokollieren hart alles, wo von außen eine Anfrage kommt. Ich bezeichne sie gerne als GA4 für Bots. Während wir mit GA4 die User tracken, können wir mit den Server-Logs sehr schön schauen, was Bots mit unserer Seite machen, und das lässt sich super für LLMs nutzen.

[Markus] Woher bekomme ich die Logfiles?

[Juliane] Die stellt mir typischerweise mein Hoster zur Verfügung. Es kommt auf die Umgebung an, aber bei einer kleinen bis mittleren Website kann ich sie normalerweise über einen SFTP-Zugang ziehen und exportieren. In der Regel bekomme ich sie also immer irgendwo als Export.

[Markus] Dafür brauche ich Tools, um mir die Dateien anzuschauen. Gibt es da etwas Feines von Screaming Frog, oder was benutzt du?

[Juliane] Viele haben eine kleine Hemmschwelle, mit Server-Logs zu arbeiten, meines Erachtens vollkommen zu Unrecht. Der Zugang ist relativ leicht, man muss sich nur einmal initial damit beschäftigen, wo man sie findet. Das zweite ist die Auswertung, weil man mit riesigen Datenmengen zu tun hat, dafür braucht man ein Tool. Der Screaming Frog Log File Analyser ist eine schöne, günstige und faire Lösung. Für die ganzen AI-Geschichten ist er vielleicht nicht hundertprozentig, aber für jeden, der einfach loslegen will, ein sehr günstiges und einfaches Setup. Ansonsten kann man sich eigene Auswertungen bauen, denn es sind einfache Dateien, die einer einheitlichen Struktur folgen und sich leicht parsen lassen, gerade mittlerweile auch mit AI-Tools.

[Markus] Und wenn ich das Setup habe, was kann ich aus den Logfiles lernen?

[Juliane] Sehr viel. Die Logfiles waren für mich schon vor diesen ganzen AI-Bot-Aktivitäten super, weil sie einen echten Blick unter die Haube geben. Und hier ist es genauso: Mit den Server-Logs ist das für mich das einzige Mittel, um die eigene Sichtbarkeit in LLMs überhaupt zu beziffern. Wir können feststellen, welche URLs vom Trainingsbot genutzt wurden und welche im Grounding zur Beantwortung von Fragen. Das identifiziert man anhand der User Agents in den Server-Logs. Wenn man da in die Analyse geht und sich ein kleines Setup entwickelt, kann man eine Art Reverse Prompt Engineering betreiben: Ich stelle fest, welche URLs ganz oft fürs Grounding genutzt werden, also wo wirklich ein Nutzerinteresse dahintersteht. Das ist wertvoll, weil wir momentan wenig Möglichkeiten haben, die Sichtbarkeit in LLMs zu quantifizieren. Wir fangen oft mit Prompts an, die wir tracken, aber die haben kein Suchvolumen dahinter, und es gibt keine Tools, die das zuverlässig beziffern. Mit den Server-Logs bekomme ich zumindest einen Indikator, wo wirklich Nutzerinteresse besteht.

[Juliane] Der zweite Schritt ist, diese Daten zu aggregieren: Welche meiner Themen, Produktgruppen oder Verzeichnisse werden am häufigsten von LLMs wie ChatGPT genutzt? Damit bekomme ich ein Gefühl dafür, wo ich relevant bin, wo nicht und wo ich gerne relevant wäre. Das kann ich alles schon in den Server-Logs sehen.

[Markus] Die konkreten Prompts der Leute sehe ich aber nicht?

[Juliane] Nein, leider nicht. Man sieht nur, welche URLs zur Beantwortung von Prompts genutzt wurden, aber nicht, welcher Prompt es war. Man kann sich Hilfstools bauen: Zu den URLs, die besonders häufig im Grounding genutzt wurden, schaue ich in der Search Console nach den Longtail-Suchbegriffen, die einen Hinweis auf relevante Fragestellungen geben. Ich habe mir zum Beispiel einen eigenen AI-Agenten gebaut, dem ich die auffälligen URLs aus den Server-Logs übergebe, der dann relevante Prompts entlang der Customer Journey entwickelt, die Seite scrapt und die Suchintention analysiert. Man kann sich dem nähern, aber die Prompts bekommt man nicht wirklich angezeigt, das ist der Nachteil.

[Markus] Kann es passieren, dass ich sehe, ChatGPT hat im Rahmen des Groundings auf meine Seite zugegriffen, sie aber später wieder verworfen?

[Juliane] In den Server-Logs sieht man das nicht. Man sieht nur, dass man in die engere Auswahl gekommen ist. Bei ChatGPT wird ein Prompt eingegeben, es startet ein Query-Fan-out, meine Seite kommt ins Relevanzset zur Beantwortung. Das heißt aber nicht, dass ich als Quelle erwähnt werde oder dass Inhalte von mir in der Antwort genutzt werden. Das können wir nicht mit hundertprozentiger Sicherheit sagen.

Bing AI Performance Report versus Logfiles

[Markus] Wie findest du unter diesem Aspekt den AI Performance Report in den Bing Webmaster Tools?

[Juliane] Den habe ich mir mit großem Interesse angeschaut, weil er erstmals überhaupt Daten zur Verfügung stellt. Ich habe ihn mit den Server-Logs abgeglichen und festgestellt, dass Bing uns nur etwa 10 Prozent der Daten liefert, die wir aus den Server-Logs bekommen, wenn ich die reinen URLs vergleiche. Man kann aber Brücken schlagen: schauen, welche URLs in den Server-Logs oft genutzt werden und parallel in den Bing Webmaster Tools, welche Grounding-Queries mit diesen Seiten verbunden sind. Bei Bing ist die Copilot-Nutzung insgesamt geringer, kein Wunder, dass es nur 10 Prozent der ChatGPT-Werte aus den Logs sind. Trotzdem ist es eine sehr gute Ergänzung. In der Analyse fehlt aber viel, das muss man ehrlich sagen, auch weil die Zielgruppe von Copilot eine andere ist, eher B2B.

Was tun, wenn Inhalte in der KI nicht ankommen?

[Markus] Wenn ich das Setup habe und sehe, dass bestimmte Inhalte bei der KI nicht gut ankommen, wie gehst du dann vor?

[Juliane] Das muss man abwägen und auf Ursachenforschung gehen. Es kann sein, dass diese Inhalte schon vom internen KI-Wissen beantwortet werden. Wir hatten zum Beispiel einen Konzertveranstalter mit verschiedenen Seiten-Templates nach Ticketing, Veranstaltungsort und Artists. Anhand der Server-Logs sahen wir, dass der Bereich Artists oft von den Trainingsbots gescrapt wurde, aber nie von denen, die fürs Grounding zuständig sind. Im Umkehrschluss: Diese Inhalte sind für die Sichtbarkeit in LLMs unwichtig. Das ist nicht schlimm, wir müssen an alle Kanäle denken, die Artists haben in anderen Bereichen ihre Berechtigung. Ich versuche immer, anhand der Server-Logs an den Fällen zu lernen, die gut funktionieren und mir Conversions bringen. Was gut funktioniert und Klicks oder Conversions bringt, kann ich überlegen zu adaptieren, auf wichtige Produktgruppen und Themenbereiche. Ein Patentrezept gibt es nicht, man muss die Daten anschauen und anhand des eigenen Geschäftsmodells bewerten.

Cloudflare und der Blick nach vorn

[Markus] Die AI-Bots crawlen zum Teil viel, und Cloudflare hat sich zum Anwalt der Websites erhoben und will dieses massive Crawling steuern. Wo geht die Reise hin, kommt ein Crawling War?

[Juliane] Wenn man sich die Crawl-Aktivität anschaut, sieht man, dass es ein Thema ist, gerade für die Server und Cloudflares dieser Welt. Sie machen das aber nicht uneigennützig: Netzlast und Ressourcenkosten wollen sie einsparen. Perspektivisch kann man das Crawling nicht verhindern. Es wird Modelle geben, für die man sich aktiv entscheiden kann, aber ich glaube nicht, dass die Lösung ist, alles per Default für alle zu sperren. Es muss eine gesunde Abwägung geben, vielleicht mit einem richtigen Rate Limit, gerade bei AI-Trainern, wo man den Anteil herunterreguliert. Ich glaube, die Crawl-Aktivitäten der AI-Bots werden perspektivisch etwas strukturierter und ressourcenorientierter. Und nicht jedes LLM wird künftig die Relevanz haben, die es heute hat, das wird sich durch Marktregularien vielleicht auch auflösen.

[Markus] Von Google soll es bald auch Kontrollen geben, dass man sich aus den AI Overviews herausnehmen kann, aber im normalen Index bleibt. Und Cloudflare hatte diese Content Signals, mit denen man das Trainieren erlauben oder verbieten konnte.

[Juliane] Die Content Signals gab es, aber sie haben keinen Eingang in die Praxis gefunden.

Der Appell: schau in deine Logfiles

[Markus] Haben wir ein wichtiges Thema vergessen, hast du noch einen Tipp?

[Juliane] Ich kann wirklich jedem empfehlen, sich einfach mal die Server-Logs anzuschauen, 14 Tage, ohne großen Aufwand, und zu schauen, was wie häufig gecrawlt wird. Das sind wirklich schöne Einblicke. Das und die strukturellen Barrieren sind für mich die zwei wichtigsten Punkte, die jeder mal checken sollte. Damit ist man in diesem Bereich einfach einen Schritt weiter.