Vortrag Wir haben zum Beispiel im letzten Jahr entdeckt, dass IONOS alle Websites im Shared-Hosting-Paket erst mal prinzipiell blockiert hat. Also nicht alle Bots, aber die GPT- und die Claude-Bots. Das waren die AI-Trainer. Das heißt, auch wenn ich die Optimierung vorangetrieben habe, haben die vielleicht gar keine Früchte getragen, weil diese Bots komplett blockiert wurden und ich gar keine Chance hatte, quasi in die Knowledge Base der LLMs reinzukommen. Wer crawlt eigentlich gerade eure Webseite? Und warum? Diese Frage klingt nach SEO-Grundlagen, aber die Antwort hat sich in den letzten Monaten radikal verändert. Neben dem Google-Bot tauchen in euren Logfiles plötzlich ganz neue Namen auf. GPT-Bot, Claude-Bot, Perplexity-Bot und weitere. Manche davon trainieren Sprachmodelle, andere recherchieren in Echtzeit für KI-Antworten. Und die entscheidende Frage ist: Wisst ihr, welcher eurer Inhalte diese Bots tatsächlich abholen und was sie damit machen? Mit KI ändert sich nicht nur die Suche, sondern auch die Anforderungen an das technische SEO. Die neuen Bot-Typen bieten uns aber gleichzeitig eine Chance. Wir können ermitteln, welche unserer Inhalte in LLMs tatsächlich genutzt werden und daraus Rückschlüsse für Content und Prompt-Recherche ziehen. Meine nächste Speakerin hier beim Spotlight SEO für KI ist Juliane Bettinger. Sie ist Co-Founderin und Technical SEO Consultant bei der Jenaer SEO-Agentur SEOSOON. Seit 2018 berät sie vor allem Publisher und Medienhäuser, also genau die Branche, die von den Veränderungen durch KI-Systeme besonders betroffen ist. Gemeinsam mit ihrem Team setzt sie SEO- und KI-Strategien nicht nur beratend, sondern auch operativ um, schult Inhouse-Teams und entwickelt maßgeschneiderte Dashboards und ist auf tollen Konferenzen wie dieser hier auch als Speakerin dabei. Ich freue mich sehr, dass du heute hier bist, liebe Juliane. Hallo Hendrik, vielen lieben Dank für die Anmoderation. Sehr, sehr gerne. Ja, wir haben ja wie gesagt keine Zeit und der Markus und ich, wir sammeln im Hintergrund natürlich auch wieder fleißig eure Fragen. Deshalb Juliane, die Bühne gehört dir. Am Ende gibt es eine kleine Fragerunde und ja, ich freue mich jetzt auf einen spannenden Vortrag. Ja, wir sprechen ja momentan aktuell alle sehr viel über Optimierung für AI Search, also wie wir Mentions und Citations gewinnen können, wie wir vielleicht auch den Sentiment beeinflussen, aber wir sprechen meines Erachtens viel zu wenig über die technischen und infrastrukturellen Voraussetzungen. Wenn ich jetzt mal eine ziemlich abgedroschene Baumetapher heranziehe, ist es so ein bisschen, als wenn wir uns um den Dachbau kümmern, um den Innenausbau, aber eigentlich keine Gedanken an die Wände und an das Fundament verschwenden. Und gerade halt auch in diesem Bereich der Basics, der technischen SEO-Basics, hat sich halt viel geändert. Die Rahmenbedingungen haben sich geändert. Denn wir haben aktuell zwei prinzipielle Herausforderungen, mit denen wir uns auseinandersetzen müssen. Wir haben zum einen, auf der einen Seite, eine extreme Zunahme an verfügbaren Dokumenten. Und das ist natürlich getrieben durch den ganzen AI-Content, der produziert und massenhaft veröffentlicht wird. Und der Google-CEO hat erst vor ein paar Monaten das schön quantifiziert, hat gesagt, dass sich die Anzahl der verfügbaren Inhalte in den letzten zwei Jahren um 45 Prozent erhöht hat. Also 45 Prozent mehr Inhalte, die Google ja auch irgendwie erst mal verarbeiten muss. Das heißt, wir haben in diesem Bereich eigentlich eine zunehmende Wettbewerbssituation, weil sich die Crawl-Kapazitäten nicht wirklich anpassen. Das heißt, wir müssen uns eigentlich hier die Frage stellen: Wie kriegen wir eigentlich noch unsere wichtigen und relevanten Inhalte gecrawlt und indexiert? Und auf der anderen Seite wiederum haben wir einen komplett neuen Typus an Crawlern, die AI-Bots. Und die fluten quasi unsere Server, also die scrapen unsere Inhalte im ganz großen Stil. Und hier müssen wir uns eigentlich die Frage stellen: Wie gehen wir denn mit dieser Flut an Anfragen um, ohne dass wir im Gegenzug noch wirklich nennenswerten, relevanten Traffic bekommen? Und diese beiden Entwicklungen machen das Thema Crawling wichtiger als je zuvor, weil da vielleicht noch mal ein ganz basic Schritt, den wir uns vor Augen halten sollten: Wenn wir das Crawling von unseren wichtigen Inhalten nicht sicherstellen können, dann werden sie nicht indexiert, in der Folge können sie nicht ranken und damit habe ich halt auch keine Sichtbarkeit in Google, Bing und allen anderen klassischen Suchindizes. Soweit ist das, glaube ich, ganz klar, aber jetzt müssen wir uns ja auch noch einen Schritt weiterdenken. Weil wenn wir das nicht sicherstellen, dann haben wir aber auch mittlerweile keine Sichtbarkeit oder eine verringerte Chance auf Sichtbarkeit in LLM-Antworten. Weil die nutzen in diesem Retrieval-Prozess, im Grounding, die Indexdaten der klassischen Suchmaschinen. Und wenn ich dort nicht stattfinde, kann ich auch mit sehr geringer Wahrscheinlichkeit nur in den LLMs stattfinden. Das heißt: Crawling ist mittlerweile wichtig für zwei Suchsysteme. Und das bedeutet halt auch, dass wir uns um unsere technischen SEO-Basics Gedanken machen müssen. Das sollten wir schon immer eigentlich, aber es wird immer noch wichtiger. Und das bedeutet: Wir sollten uns um ein gutes URL-Inventar kümmern. Wir brauchen eine saubere und schnelle Server-Performance und eine gute Website-Struktur. Und das sind eigentlich Themen, wie gesagt, um die hätten wir uns schon lange kümmern sollen und um die kümmern wir uns in der Regel auch. Aber jetzt gibt es noch mal eine neue Anspruchsgruppe, nämlich die KI-Crawler. Und während wir halt bei den Search-Crawlern mittlerweile diese Herausforderung haben, dass wir um Crawl-Kapazitäten kämpfen müssen, dass es eine Wettbewerbssituation ist, haben wir nun bei den AI-Bots oftmals die Situation, dass sie teilweise mehr crawlen, als uns lieb ist. Man sieht, sie haben mittlerweile in den letzten zwei Jahren massiv aufgeholt. Also sie stellen mittlerweile 21 Prozent der gesamten Bot-Aktivitäten dar. Plus noch mal die ganzen AI Searches. Das ist halt extrem. Und wir sehen halt auch, wenn wir uns noch mal andere Charts anschauen, wie exponentiell das gewachsen ist. Der GPT-Bot zum Beispiel hatte letztes Jahr von einem Monat auf den anderen die Crawl-Aktivität verdreifacht. Also das ist höchst volatil und unvorhersehbar, wie diese Crawl-Aktivitäten der AI-Bots sich gestalten. Und wenn wir jetzt halt von diesen ganzen verschiedenen AI-Bots sprechen, ist es noch mal auch sehr wichtig, die zu klassifizieren. Weil es ist wichtig zu verstehen, wie die funktionieren, was die für einen Sinn und Zweck haben, damit wir auch wissen, wie wir mit denen umgehen und wie wir die vielleicht auch sogar für uns nutzen können. Dafür würde ich die in vier Kategorien packen, die sich nach Zweck ein bisschen unterscheiden. Die erste Kategorie, das sind die AI-Trainer. Das ist zum Beispiel ganz klassisch von OpenAI der GPT-Bot. Und die sind dazu da, die Daten zu scrapen. Und mit diesen Daten werden dann die entsprechenden Modelle trainiert. Also das sind die ganz klassischen großen Datensammler zum Trainieren der LLMs. Die nächste Kategorie, und die sind tatsächlich für die SEOs sehr spannend, das sind die AI-Assistants. Und jedes Modell, also OpenAI hat neben dem GPT-Bot zum Beispiel noch den ChatGPT-User-Bot und andere Modelle halt auch. Also jeder hat eigentlich neben dem AI-Trainer auch einen AI-Assistant. Und diese AI-Assistants, das sind nun diese Echtzeitabrufe. Das heißt, wenn ich in ChatGPT eine Frage stelle und ein Crawling-Prozess ausgelöst wird, dann Subqueries entstehen und da ein Relevanzset an URLs dazu zur Beantwortung der Fragen genutzt werden, dann werden diese URLs in dieser Zeit gecrawlt durch diesen AI-Assistant. Das heißt, wir haben hier wirklich eine 1:1-Relation. Die dritte Kategorie, das sind die AI-Search-Crawler. Und im Gegensatz zu diesem Echtzeitabruf sind die eher asynchron unterwegs. Das heißt, ganz oft kommen die halt auch nach den AI-Assistants und crawlen noch mal im großen Stil die ganzen verbundenen Ressourcen, die robots.txt. Also das sind die ganz großen Datensammler. Und die sind offiziell dafür da, um die Such- und Indexdaten zu verbessern. Was das ganz genau im Detail heißt, da kann man jetzt nur aus den Crawl-Mustern ein bisschen Rückschlüsse ziehen. Also sehr wahrscheinlich sind sie dazu da, um halt auch ein Caching mit zu unterstützen, einen eigenen Index mit aufzubauen. Eventuell werden auch im Hintergrund natürlich die Daten für Trainingszwecke genutzt. Man kann es nicht hundertprozentig sagen. Die Informationen sind hier tatsächlich relativ dünn. Die vierte Kategorie, und ich glaube, die sind auch in den letzten Wochen noch sehr viel prominenter geworden, das sind die AI-Agents. Das haben wir zum Beispiel ganz prominent in ChatGPT als Operator mit integriert oder halt auch sehr viele eigenständige Agents, die es mittlerweile gibt. Und wie die AI-Assistants haben die quasi so eine 1:1-Relation. Auch hier wird durch einen User eine Interaktion getriggert. Aber das ist wirklich hier kein Abruf, sondern eine Interaktion mit einer Seite. Und diese vier verschiedenen AI-Bot-Typen, die bringen jetzt nun, ja, ich würde sagen, geänderte Anforderungen mit sich. Es sind nicht unbedingt neue, aber wir müssen andere Fragen stellen. Und wir müssen hier erst mal Grundlagen schaffen, die wir bis jetzt nicht hatten. Deswegen die Frage: Was ist eigentlich wichtig, wenn wir über KI-Crawler sprechen und um Basics und um bestmögliche Sichtbarkeit in LLMs zu gewährleisten? Und die erste, für mich auch wirklich wichtigste Frage, die oft viel zu kurz kommt, ist: Können denn die KI-Crawler überhaupt zugreifen? Weil oftmals werden Optimierungsmaßnahmen ergriffen, ohne zu prüfen, ob es überhaupt strukturelle Barrieren gibt. Also es gibt viele Optionen über den CDN, Firewall, direkt durch den Hoster, also alles, was serverseitig irgendwie diese ganzen Bot-Anfragen blockiert. Und das Problem ist halt, wenn man das bewusst einrichtet, ist das okay. Aber viele wissen gar nicht, dass es diese Barrieren gibt, weil sie sich nicht aktiv dafür entschieden haben. Wir haben zum Beispiel im letzten Jahr entdeckt, dass IONOS alle Websites im Shared-Hosting-Paket erst mal prinzipiell blockiert hat. Also nicht alle Bots, aber die GPT- und die Claude-Bots. Das waren die AI-Trainer. Das heißt, auch wenn ich die Optimierung vorangetrieben habe, haben die vielleicht gar keine Früchte getragen, weil diese Bots komplett blockiert wurden und ich gar keine Chance hatte, quasi in die Knowledge Base der LLMs reinzukommen. Wir haben jetzt ganz frisch auch eine eigene Studie dazu durchgeführt und haben uns 1.600 Domains angeschaut und mal geguckt: Wie weit verbreitet ist eigentlich dieses Problem? Und tatsächlich sind es doch 15 Prozent, wo so eine Blockade stattfindet. Also 15 Prozent aller untersuchten Domains hatten mindestens einen Bot blockiert. Und wir haben hier wirklich nur die relevantesten Bots genommen, also die, die für AI-Assistant und AI-Training zuständig sind. Wenn man dazu noch den Meta-External und den Bytespider nimmt, dann liegen wir sogar bei fast 30 Prozent. Das ist schon eine ordentliche Hausnummer. Wenn man sich das dann auch mal anguckt, wie sich das verteilt nach Website-Größe, sieht man, dass vor allem auch die Kleinen und sehr Kleinen davon betroffen sind. Meine Vermutung ist: Das liegt natürlich sehr stark am Hoster. Während die Großen, gehe ich ganz stark davon aus, eher bewusst blockieren, ist es bei den Kleinen und Mittleren unbewusst. Das heißt, hier gilt es halt wirklich, das zu testen, ob ich überhaupt erst mal für KI-Bots erreichbar bin. Und das kann ich entweder manuell machen über einen User-Agent-Switcher, da gibt es ganz viele Optionen. Kann man auch im Screaming Frog theoretisch machen, aber dann immer nur einzeln pro Bot. Oder es gibt auch schon verschiedene Tools. Wir haben auch schon für uns einen kleinen KI-Bot-Checker gebaut, wo wir das halt einfach domainweit checken können. Die zweite Frage in diesem Bereich „Können die KI-Crawler zugreifen?“ ist jetzt auch relativ neu. Denn erst vor wenigen Wochen hat Bing die Dokumentation angepasst, oder es ist jedenfalls erst mal bekannt geworden, dass Bing diesen Meta-Tag noarchive jetzt anders interpretiert. Der wird historisch gesehen schon lange von Google nicht mehr genutzt. Der war ursprünglich dazu da, dass gecachte Versionen nicht in den SERPs angezeigt werden. Bing hat jetzt einfach gesagt: Okay, wir nehmen jetzt diesen Tag und geben dem noch mal eine neue Bedeutung. Das heißt: Wenn du diesen Meta-Robots-Tag noch irgendwo im Quelltext hast, dann werden diese Inhalte nicht für Copilot und den Bing Chat genutzt und auch nicht als Trainingsdaten für Copilot. Das heißt, auch das sollte man einfach noch mal prüfen. Gerade im Publishing-Bereich wurde das historisch doch gerne genutzt. Und da habe ich es tatsächlich bei mehreren Publishern gefunden. Also auch das ist ein Thema: Wenn man Sichtbarkeit in Bing-Systemen wie Copilot haben möchte, sollte man prüfen, ob man noch diesen Meta-Tag irgendwo integriert hat. Jetzt kommen wir zur zweiten Frage. Jetzt haben wir erst mal Barrieren abgebaut, also alles, was uns vielleicht nicht wirklich bewusst war. Und jetzt kommt eher die Frage: Dürfen, sollen denn die KI-Crawler überhaupt zugreifen? Und da kann ich neben diesen serverseitigen Blockaden auch mit der robots.txt arbeiten. Also hier kann ich prinzipiell Scraping verhindern. Und in dem Zusammenhang wird viel zu selten die Frage diskutiert: Wie gehen wir denn überhaupt mit unseren vielleicht exklusiven Inhalten um oder mit unseren Inhalten, die momentan schon auf noindex stehen? Das hat ja bestimmt einen Grund, warum die auf noindex stehen. Und auch diese Fragen sollte ich mir eigentlich sehr explizit stellen. Wenn ich dann jetzt aber über die robots.txt nachdenke und die gerne einsetzen möchte, muss ich mir bewusst sein, dass die robots.txt nicht global funktioniert. Zum Beispiel Perplexity versteht sie eher als nett gemeinten Hinweis und nicht als wirkliche Direktive. Aber auch die AI-Agents halten sich nicht daran. Und das hat einfach damit zu tun, dass die einen Headless-Browser nutzen und damit eine ganz normale Browser-Erkennung und da auch nicht die robots.txt noch mal abfragen. Dessen muss man sich bewusst sein. Und als letzten Punkt: Wenn ich die robots.txt einsetze, muss ich mir auch bewusst sein, dass es keine rückwirkende Maßnahme ist. Das heißt, meine Inhalte sind meistens schon in der Knowledge Base auch zum Teil enthalten. Das wird damit also nicht entfernt. Und ich bin natürlich auch durch andere Websites irgendwo verlinkt, erwähnt. Auch das wird sich damit natürlich nicht auflösen. Die nächste Frage, die ich auch sehr wichtig finde, ist das Thema: Wie reagiert mein Server? Wie performt mein Server? Wir müssen uns ja mal vorstellen: Wir haben jetzt eigentlich neben diesen ganz normalen User-Hits und den ganzen Search-Bots und allen anderen Bot-Typen, die es da schon gab, noch mal so eine riesengroße neue Gruppe an Crawlern, die auch massiv crawlen. Und das belastet die Server. Deswegen reagieren die Hoster auch teilweise so, dass sie einzelne Bot-Typen blockieren. Und wir müssen das wirklich im Blick behalten. Wir müssen stabile Serverantworten sicherstellen und es muss vor allem Spielraum da sein. Denn die AI-Bots crawlen teilweise sehr volatil. Das heißt, ich brauche hier auch ein bisschen Kapazitäten nach oben. Ich habe es in den letzten Monaten wirklich mehrfach erlebt, dass Server immense Probleme hatten, teilweise Downtimes hatten. Und hier gilt es, Time to First Byte zu monitoren, die Page Performance im Blick zu haben. Ich habe jetzt hier mal einen Screenshot von der Google Search Console, von den Crawling-Statistiken. Das ist für eine Trendentwicklung ganz spannend, aber nicht für ein kurzfristiges Monitoring, weil die einen dreitägigen Verzug haben. Bis dahin hat das jeder selber gemerkt, dass er Probleme mit dem Server hat. Aber für eine Trendentwicklung auf jeden Fall super spannend. Die nächste Frage, die ich mir stellen sollte in Richtung „Können LLMs meine Inhalte lesen?“, ist: Wie ist denn mein ganzer Quelltext aufgebaut? Und ich denke, viele haben das mittlerweile schon gehört, dass AI-Bots nicht rendern. Sie führen JavaScript nicht aus. Das heißt, alles, was irgendwie über JavaScript nachgeladen wird, ist nicht sichtbar. Wenn ich etwas habe, was ich verstecken will, kann ich es schön in JavaScript packen. Das ist wahrscheinlich super. Aber ansonsten gilt: Alles, was relevant ist, sollte im initialen HTML sein. Dann bilderlastige Seiten oder Seiten mit viel Video- und Audiocontent. Auch das hat Nachteile. KI-Bots können die verarbeiten, aber wenn wir an das Grounding denken, dann werden Text-HTMLs bevorzugt. Da werden keine Video- und Audio-Inhalte für das Grounding verarbeitet. Das heißt, auch dahingehend müssen wir prüfen, wie wir diese Inhalte vielleicht in unseren Content-Bereich bekommen. Und in dem Zusammenhang finde ich auch strukturierte Daten auf jeden Fall immer noch sinnvoll und hilfreich. Ich weiß, das wird viel diskutiert. Sind strukturierte Daten in Richtung LLMs relevant? Haben die einen Impact? Können die gelesen werden? Aber unabhängig davon: Wir brauchen sie trotzdem auch für das klassische SEO, für die AIOs, für den KI-Modus von Google. Und gerade für erklärungswürdige Inhalte, wie es zum Beispiel Videos und Audios sind, die für Crawler doch schwerer zu verarbeiten sind, ist es auf jeden Fall hilfreich, hier über strukturierte Daten Semantik anzureichern. Und zu guter Letzt, Stichwort Semantik: Auch unser ganzer Code sollte semantisch gut aufbereitet sein. Weil wir sprechen hier von Large Language Models. Das heißt, die können mit Sprache sehr gut umgehen, also sollten wir ihnen auch Sprache geben – auch in unserem Code. Das heißt, sie sollten Absätze gut erkennen können. Sie sollten zum Beispiel, wenn ich eine Tabelle habe, diese nicht in einen Div-Container packen und mit CSS stylen, sondern das Tag table verwenden. Das hilft den LLMs. Das ist sehr basic, aber auch das ist ein Schritt dahin. Wenn wir all diese Ebenen jetzt mal zusammennehmen, dann ist das für mich so das Framework, womit man gute Basics für KI und für SEO schafft. Die unteren Ebenen, also die Crawling- und Zugriffssteuerung und die Serverkapazitäten, hatten wir gerade besprochen. Die orange Ebene ist nun alles das, was wir eigentlich im klassischen SEO machen. Also hier müssen wir das Crawling sicherstellen durch eine gute URL-Struktur und durch ein gutes URL-Inventar. Denn wir müssen uns vorstellen: Wenn wir Millionen dynamischer Parameter haben, eine schlechte interne Verlinkung, wo schon die normalen Search-Crawler nicht gut durchkommen, dann werden die AI-Bots sicherlich auch scheitern. Auch das ist noch ein Punkt, den wir in dem Zusammenhang mit Basics diskutieren und im Blick behalten müssen. Und wenn wir diese ganzen Ebenen sichergestellt haben, dann haben wir eigentlich erst mal ein gutes Setup geschaffen. Dann sind wir so weit, dass wir sagen: Okay, wir haben jetzt erst mal die Basics erfüllt. Jetzt können wir in Optimierungsmaßnahmen investieren und weiterdenken. Und das tun wir jetzt nämlich auch. Denn wir können auch im Bereich des technischen SEOs schon gewisse Inputs liefern und Monitoring aufzeigen, wie LLMs unsere Seite sehen und verstehen. Und das können wir wunderbar über Logfiles tun. Logfiles sind Protokolldateien, die jeden Request an diesem Webserver protokollieren. Und wir müssen uns vorstellen: Logfiles sind quasi unsere Analytics für Crawler. Wir können damit großartige Analysen machen. Wir haben hier bestimmte Informationen und können zum Beispiel herausfinden: Welche KI-Bots dominieren bei mir auf der Domain das Crawling? Welche URLs rufen die KI-Bots auf? Wie schnell wird eine komplett neue URL durch welchen KI-Bot gefunden? Also wir können damit ziemlich viele großartige Analysen machen. Und für alle, die vielleicht noch nicht mit Serverlogs gearbeitet haben, noch keine Logfile-Analyse gemacht haben, fragen sich jetzt vielleicht: Okay, wo finde ich denn eigentlich meine Serverlogs? Das ist wiederum ein bisschen abhängig davon, auf welcher Umgebung eure Seite läuft. Ich würde mal sagen, der Klassiker für eine mittelgroße Seite ist vielleicht ein Managed Hoster, eventuell noch in Kombination mit einem CDN. Und je größer die Website-Strukturen werden, umso eher ist es wahrscheinlich eine Cloud-Lösung oder eine eigene Server-Konfiguration. Aber eigentlich egal, welche dieser Optionen ihr vorfindet: Ihr solltet in der Regel immer die Möglichkeit haben, die Logs zu exportieren oder zu transferieren. Also theoretisch gibt es immer die Option, auf die Serverlogs zuzugreifen. Und wenn ihr damit arbeiten wollt, dann kann ich euch nur empfehlen: Sprecht mit dem Server-Admin oder dem technischen Betrieb, wie das bei euch heißt, und sagt, dass ihr diese Logfiles für KI-Analysen braucht. Denn damit könnt ihr eure Sichtbarkeit in Large Language Models sichtbar machen. Und mit diesem Argument bekommt man die Serverlogs mittlerweile auch. In der Vergangenheit war es erfahrungsgemäß immer relativ schwer, daran zu kommen. Da waren Themen wie Datenschutz oder der Aufwand oft ein Hindernis. Aber mit dem Thema KI-Analyse bekomme ich die mittlerweile in zwei bis drei Tagen. So, wie sieht denn jetzt so ein Logfile-Eintrag überhaupt aus? Das ist jetzt auf den ersten Blick vielleicht ein bisschen kryptisch, aber wir brauchen davon gar nicht viel. Insgesamt ist es auch relativ leicht zu verstehen. Wir haben eigentlich vier Komponenten, die wir daraus insbesondere brauchen. Einmal den Zeitstempel. Der sagt uns ganz genau: Wann wurde überhaupt gecrawlt? Dann haben wir den URL-Pfad. Der sagt uns: Was wurde überhaupt gecrawlt? Dann gibt es noch den Status-Code. Der sagt wiederum: Wie hat unser Server auf diesen Request reagiert? Und zu guter Letzt haben wir noch den User-Agent-String. Das ist immer das, was am kryptischsten aussieht. Er sagt uns aber: Wer hat denn hier überhaupt gecrawlt? Und das ist jetzt das Spannende. Denn wir erinnern uns noch einmal an unsere vier AI-Bot-Typen. Die können wir anhand des User-Agent-Strings identifizieren. Mit einer Ausnahme: Die AI-Agents benutzen eine normale Browser-Kennung. Damit sind sie in den Logfiles nicht ohne Weiteres zu identifizieren. Deswegen: Wenn ihr Logfile-Analysen macht und Sichtbarkeit analysieren wollt, dann konzentriert euch auf die AI-Trainer und die AI-Assistants. Denn die haben einfach den höchsten Informationsgehalt. Das hat wiederum mit den Antwortprozessen der LLMs zu tun. Man kann ganz grob sagen, dass es einen Bereich gibt, in dem Grounding ausgelöst wird, also eine Websuche im Hintergrund. Und dann gibt es wiederum Fragen, die kein Grounding auslösen. Die Fragen, die Grounding auslösen, sind meistens sehr zeitkritische oder sehr aktuelle Informationen. Fragen nach Produkten, Preisen – all das löst in der Regel eine Websuche aus. Dagegen: Wenn ich eher kreative Aufgaben stelle, Mathematik, Code-Geschichten oder sehr stabile Wissensfragen – das hatten wir vorhin auch schon mal –, dann wird in der Regel kein Grounding ausgeführt. Und wenn wir uns das jetzt mal gegenüberstellen, dann ist das schon eigentlich sehr wichtig. Denn die Fragen, bei denen Grounding ausgeführt wird, sind für uns wahrscheinlich eher conversionrelevant. Das sind die Sachen, in die wir auch reinwollen. Und wenn wir diese Unterscheidung der Antwort-Typen jetzt auf unsere AI-Bots übertragen, dann sehen wir schon, dass es hier einen Unterschied zwischen diesen Antwortprozessen gibt. Allein schon beim Crawl-Zeitpunkt. Im Grounding findet das Crawling nämlich im Antwortprozess statt. Also: Jemand stellt eine Frage, es wird eine Websuche ausgelöst, ein Relevanzset wird gebildet aufgrund der Subqueries, dieses Relevanzset wird gecrawlt und dann wird auf Basis dieser Inhalte eine Antwort generiert. Bei dem anderen Prozess, bei dem die Knowledge Base zum Tragen kommt, also kein Grounding stattfindet, ist das Crawling bereits vorgelagert. Das sind unsere zwei unterschiedlichen Bot-Typen, nämlich die AI-Assistants und die AI-Trainer. Und besonders spannend ist der Prozess im Grounding. Denn wir können anhand der AI-Assistants Rückschlüsse auf Nutzeranfragen ziehen. Wir können anhand der AI-Assistants eigentlich wahres Nutzerinteresse identifizieren und damit eine Art Reverse-Prompt-Recherche machen. Ich habe meinen Prozess mitgebracht und ein paar Beispiele, wie das aussehen kann. Als Allererstes würde ich in dieser Identifikation des Nutzerinteresses die einzelnen Bot-Hits analysieren. Und das am besten je nach Modell, weil es hier Unterschiede gibt. Man schaut sich also erst mal ganz stupide an: Wie viele Hits hat welche Seite durch welchen Bot? Das allein ist schon interessant. Aber noch spannender wird es, wenn man die Daten aggregiert. Also nach Verzeichnis, Produktgruppen oder Themen. Dann sieht man schon: Welche Themenschwerpunkte sind denn am meisten gefragt? Und daraus kann man natürlich ableiten, wo man später vielleicht mehr investieren möchte – in Richtung weiterer GEO-Maßnahmen. Wenn ich mich jetzt diesem Punkt Reverse-Prompt-Engineering nähern will, würde ich mich jetzt halt durch die einzelnen URLs auch durcharbeiten. Das heißt, man kann hier sehr gut die Kombination mit den GSC-Daten nehmen. Man schaut sich die einzelnen URLs an und guckt dann zu diesen URLs: Was habe ich denn hier gerade im Long-Tail-Bereich in den GSC-Daten? Habe ich hier Fragen, die mir auffällig sind? Das ist schon mal der erste Indikator. Das könnten aggregierte Daten sein, die auch so in einem längeren Prompt, in einem individuellen Prompt natürlich, in den LLMs gestellt werden. Und neben diesem Zugang über die GSC würde ich immer noch parallel mit einem KI-Agenten arbeiten. Das heißt, diese Top-URLs dann einem KI-Agenten übergeben, Themen und Entitäten extrahieren lassen und durch den KI-Agenten mögliche Fragen entwickeln lassen. Und das am besten schon entlang der Customer Journey und des Such-Intents. Sodass ich diese ganzen Fragen, die eher diese informationellen Bereiche abdecken, schon mal außen vor lasse und wirklich meine wichtigsten Fragestellungen herausziehe, die weiter unten im Funnel liegen. Und mit diesen Fragen kann ich dann sehr gezielt ein Tracking beziehungsweise Monitoring aufsetzen. Denn ich kann es anhand des wahren Nutzerinteresses ableiten. Ich muss mir nicht überlegen, was mögliche Fragen sein könnten, die irgendjemand gestellt hat, sondern ich habe bereits klare Hinweise, an denen ich mich abarbeiten kann. Aber wir können mit Logfiles sogar noch mehr machen, außer dieses Nutzerinteresse zu identifizieren. Wir können auch schon etwas über unsere eigene AI-Performance sagen. Und da lohnt es sich auf jeden Fall, die Serverlogs noch mit weiteren Datenquellen anzureichern. Also GA4, GSC. Und daraus können wir dann sehr viele interessante Schlüsse ziehen. Ich mache im ersten Schritt immer so eine Art Quantifizierung. Das heißt, ich schaue mir erst mal ganz simpel an: Wie viele URLs werden denn überhaupt von einem AI-Assistant genutzt? Also: Wie viele meiner URLs werden überhaupt schon im Grounding genutzt? Und das stelle ich den GSC-Daten gegenüber. Also: Wie viele URLs habe ich dort mit einer Impression? Dann habe ich schon eine Art AI-Score. Hier in dem Fall sind es 79 Prozent. Das ist tatsächlich schon relativ viel. Oftmals sehe ich Anteile von 50 bis 60 Prozent. Da hat man natürlich noch sehr viel Raum für Entwicklung und Optimierung. Neben dieser Quantifizierung ist auch eine Qualifizierung spannend. Also wirklich zu gucken: Führen diese Hits denn auch wirklich zu Klicks? Das könnte ich jetzt auch schon anhand der Serverlogs machen. Dafür bräuchte ich theoretisch die GA4-Daten nicht. Spannend ist aber zusätzlich, Conversions mit dazuzunehmen. Also nicht nur die Klicks, die auf meine Seite kommen, sondern auch: Hat der Klick konvertiert? Man kann die Daten unglaublich stark anreichern und sehr viele Erkenntnisse daraus ziehen. Ein Ansatz ist zum Beispiel zu schauen, ob ich sogenannte Hidden Champions habe. Also URLs, die für das Grounding genutzt werden, in einem relativ geringen Ausmaß, aber einen übermäßigen Anteil an Klicks bringen. Und die ich in den normalen Search-Daten der GSC möglicherweise gar nicht finden würde, weil sie dort nur wenige Klicks bringen. Aber sie scheinen besonders relevant in LLMs zu sein. Daneben ist auch hier eine Aggregation wieder spannend. Ihr seht hier fast 50 Prozent für den Bereich Gesundheit und Ernährung. Ich hatte eben eine Grafik, bei der Gesundheit und Ernährung 25 Prozent hatte, also die reinen Hits. Das heißt: Von den reinen Hits zu den URLs, die auch einen Klick bekommen, haben wir hier einen großen Sprung. Diese Inhalte performen also überdurchschnittlich gut. Gesundheit und Ernährung scheint hier richtig gut zu funktionieren. Da sollte ich schauen, ob ich die Erfolgsrezepte dieser Seiten übertragen kann. Ob ich diese Seiten für Conversion weiter optimiere, interne Verlinkungen ausbaue. Es gibt viele Ideen, wie man mit diesen Daten weiterarbeiten kann. Und dann ist natürlich auch die Frage: Welche Inhalte werden denn nicht genutzt oder führen zu keinen Klicks? Denn auch das kann spannend sein. Man kann daraus ableiten, wo man vielleicht in Zukunft weniger investieren sollte. Man sieht hier, dass teilweise unter den Top-URLs mit den Top-Hits im Grounding einige dabei sind, die gar keine Klicks bekommen. Wenn man sich das ansieht, dann sind das oft diese rein informationellen Inhalte. Dort lohnt es sich wahrscheinlich weniger, weiter zu investieren. Auch das sind mögliche Schlussfolgerungen. Der dritte Bereich, über den wir durch die Logfiles Aufschluss bekommen können, ist die Knowledge-Phase. Also: Was ist eigentlich schon von meinen Inhalten in den internen KI-Wissenssystemen abgelegt? Das geht, indem ich mir die Klicks anschaue, die ich aus diesen einzelnen Systemen bekomme, und gleichzeitig prüfe, ob ich in den Serverlogs einen AI-Assistant-Eintrag dazu finde. Wenn ich den nicht finde, bedeutet das im Umkehrschluss, dass meine Inhalte bereits im Foundation Model vorhanden sein müssen. Und man sieht das eigentlich sehr gut. Das sind meistens Informationen wie Checkout, Account-Bereiche, Kontaktdaten zu Unternehmen oder Informationen über Unternehmen. Also Dinge, die nicht so volatil sind. Ich habe hier mal ein schönes Beispiel gehabt, das uns wirklich ein bisschen die Augen geöffnet hat. Wir hatten die Daten aggregiert und gesehen, dass der Anteil bei den Artists bei 26 Prozent lag. Also beim GPT-Bot waren 26 Prozent aller Hits auf Artists verteilt. Und wir haben daneben noch die AI-Assistants gelegt, also die URLs, die im Grounding genutzt werden. Dort machten die Artists nur zwei Prozent aus. Das heißt: Sie werden unterdurchschnittlich oft in Grounding-Suchen genutzt. Was wiederum bedeutet: Wahrscheinlich werden diese Inhalte direkt aus der internen Knowledge Base beantwortet. Was auch Sinn macht, wenn man sich Artists vorstellt. Das sind nicht unbedingt brandaktuelle Informationen – außer wenn es um Konzerte geht. Das heißt auch hier: Eigentlich sollten wir darauf nicht noch zusätzliche GEO-Maßnahmen setzen. Zu guter Letzt kann ich mit den Serverlogs auch die Erreichbarkeit analysieren. Also: Wie bin ich überhaupt für alle AI-Bots erreichbar? Indem ich einfach schaue: Finde ich überhaupt alle wesentlichen AI-Bots in meinen Serverlogs? Und natürlich prüfe ich auch, ob sie alle einen Statuscode 200 bekommen. Auch die Verteilung ist teilweise schon spannend. Ich sehe in mehreren Projekten, dass der AI-Assistant von OpenAI, also der ChatGPT-User-Bot, mittlerweile schon den zweitgrößten Anteil ausmacht. Noch vor Bing. Das ist der Wahnsinn. Der ChatGPT-User-Bot crawlt häufiger die Seite als Bing. Auch das ist spannend, sich einfach mal anzuschauen. Zu guter Letzt habe ich noch einen kleinen Vergleich zu den Bing Webmaster Tools gezogen. Vor ein oder zwei Monaten – es ist noch gar nicht so lange her – hat uns Bing einen neuen Bereich zur Verfügung gestellt. AI Performance heißt der. Hier finden wir aggregierte Grounding-Queries und Pages, die für das Grounding genutzt wurden. Wir haben leider keine direkte Querverbindung. Wir wissen also nicht: Welche Grounding-Query passt zu welcher Page? Man kann es natürlich teilweise ableiten, aber das fehlt an dieser Stelle. Ich habe mich gefragt: Wie gut sind diese Daten eigentlich? Vielleicht ersetzen die ja sogar die Serverlogs. Und wir können uns diese Abkürzung nehmen. Ich habe zunächst mit unserer eigenen Domain gestartet. Zugegeben, die ist nicht sehr groß. Aber ich habe dort trotzdem nur eine Page gefunden. Im Vergleich dazu habe ich in den Serverlogs 39 URLs gefunden und über 300 ChatGPT-User-Hits im gleichen Zeitraum. Jeweils 30 Tage. Und wenn man zusätzlich die GSC-Daten dazulegt, findet man noch ein paar mehr URLs. Insgesamt scheint unsere Domain aber schon relativ gut im Grounding genutzt zu werden. Wir haben eine Durchdringung von 86 Prozent. Und dann zu guter Letzt auch noch spannend, sich diese Top-URLs im Vergleich anzuschauen. Also entsprechend die Top-Ten-Logfile-Daten, dann auch die der GSC und der Bing Webmaster Tools. Und da kann man ganz abgekürzt sagen: Es entspricht sich nicht. Es gibt eine Übereinstimmung von circa 50 Prozent, wenn ich mir verschiedene Datensets anschaue. Und das entspricht auch dem, was wir wissen: Ein gutes Ranking in Google und Bing korreliert mit Sichtbarkeit in LLM-Antworten. Aber es ist eben nur eine Korrelation. In den Logfiles finden wir noch sehr viel mehr Inhalte und gerade auch solche Hidden Champions. Von daher lohnt es sich aus meiner Sicht auf jeden Fall, in die Daten zu schauen. Ich habe das auch noch an einem zweiten Beispiel durchgespielt. Auch hier habe ich immerhin 14 URLs gefunden. Im Vergleich zu den Serverlogs habe ich jedoch 113 URLs im Grounding gefunden. Also unter zehn Prozent dessen, was uns Bing hier zur Verfügung stellt. Natürlich muss man dabei anmerken: Die Nutzung von Copilot ist wesentlich geringer als die Nutzung von ChatGPT. Das heißt, man kann es nicht direkt vergleichen. Aber die Daten zeigen auch hier, dass wir mit den Logfiles deutlich mehr Erkenntnisse gewinnen können. Genau, auch das hier noch ein Beispiel. Hier sind es zum Beispiel um die 60 Prozent. Hier besteht noch erhebliches Potenzial. Kommen wir zum Recap. Was sind jetzt die Takeaways, die ihr hier mitnehmen könnt? Als Allererstes: Ein gutes Crawl- und Index-Management ist wichtiger denn je. Die Rahmenbedingungen haben sich verschärft und wir müssen gute Basics schaffen, damit wir in LLMs sichtbar sind. Wenn wir das erledigt haben, dann müssen wir uns um diesen neuen Bot-Typus KI-Crawler kümmern. Denn die haben noch einmal gewisse andere Ansprüche. Wir müssen Barrieren abbauen und ein optimales Setup für sie schaffen. Und zu guter Letzt: Wenn wir das alles erledigt haben und die Basics geschaffen sind, dann können wir die Crawl-Aktivitäten für uns nutzen. Denn wir können mit den Logfiles analysieren: Wie sichtbar sind wir aktuell schon in den einzelnen Large Language Models? Und wo können wir vielleicht sogar noch Optimierungsmaßnahmen ableiten? Ja, damit habe ich nur noch zwei kleine Tool-Tipps. Einmal diesen KI-Bot-Checker, mit dem ihr prüfen könnt, ob ihr irgendwo strukturelle Barrieren habt. Und wenn ihr selber einmal mit Logfiles arbeiten wollt: Das ist alles kostenfrei und datenschutzkonform. Könnt ihr gerne ausprobieren. Es gibt sicherlich auch noch andere Alternativen. Ja, damit bin ich am Ende. Vielen lieben Dank. Ja, super. Vielen, vielen Dank dir, liebe Juliane. Es sind auch tatsächlich einige Fragen eingetrudelt. Wir haben noch ein bisschen Zeit, Markus. Ich würde sagen, du kannst einfach mal loslegen mit deinen Fragen. Ja, hallo auch von mir noch mal. Danke für den guten Vortrag. Ein paar Fragen sind schon da, aber wir hätten durchaus noch Platz. Wenn jemand noch etwas auf dem Herzen hat, ich glaube zwei oder drei gute Fragen könnten wir noch gebrauchen. Aber ich fange mal an. KI-Crawler blocken war ein Thema. Aber die Rückfrage von jemandem: Was für gute Gründe gibt es eigentlich, KI-Crawler zu blocken? Ja, das ist ein sehr gutes Thema. Kommt halt darauf an, wie exklusiv meine Inhalte sind. Zum Beispiel gerade im Publishing-Bereich wird das sehr stark diskutiert. Denn hier wird natürlich Traffic abgezogen – zumindest in großen Teilen. Wenn Informationen von anderen Plattformen einfach gescrapt und angeboten werden, dann hat man da natürlich ein gewisses Missverhältnis. Ich würde auch eigentlich erst mal niemandem aktiv empfehlen, Inhalte zu blocken. Ich würde eher schauen: Habe ich bestimmte exklusive Inhalte? Deswegen bin ich auch kein Fan von globalem Sperren. Gezielte Sperrungen sind eher das Thema. Es kommt viel Lob im Chat. Starker Vortrag. Danke dafür noch mal. Eine interessante Frage, die hätte ich gar nicht so vorhergesehen, aber ich finde sie echt gut: Wäre eine an Barrierefreiheit angepasste und strukturierte Website unterm Strich auch für KI-Systeme besser les- und verarbeitbar? Ja, definitiv. Das kann man mit einem klaren Ja beantworten. Absolut. Weil JavaScript zum Beispiel für die ja auch nicht so gut wäre. Genau. Und auch semantische Tags spielen hier eine Rolle. Also ja: Eine barrierefreie Seite hilft auch für KI-Systeme. Logfile-Analyse. Welchen Zeitraum der Logfiles sollte man sich ansehen, um eine konkrete Aussage treffen zu können? Guter Punkt. Nehmt, was ihr kriegen könnt, würde ich erst mal sagen. In der Regel kann man schon mit vier Wochen sehr gut arbeiten. Ich beschäftige mich schon länger damit und habe gemerkt, dass sich das in den letzten Monaten noch einmal extrem verstärkt hat. Wenn man sich im August zum Beispiel Logfiles angeguckt hat, hat sich die Frequenz gerade von diesen AI-Assistants noch einmal extrem erhöht. Das heißt, es lohnt sich schon, immer mal wieder hineinzuschauen. Denn ich glaube, man kann dadurch auch Trendentwicklungen erkennen. Vier Wochen reichen aber schon aus. Da kann man sehr viel herauslesen. Diese Logfiles können ja relativ gewaltig groß werden. Die guckt man sich wahrscheinlich nicht mehr mit einem Texteditor an. Gibt es Tools für die Auswertung dieser Zugriffe? Genau, die gibt es. Ich hatte zum Schluss eins gezeigt. Wir haben für uns eine Lösung mit Fokus auf AI-Bots. Ansonsten gibt es beispielsweise vom Screaming Frog den Log File Analyser. Der ist relativ günstig. Den kann man, glaube ich, für etwa 150 Euro im Jahr kaufen. Dann gibt es auch größere Tool-Anbieter wie OnCrawl. Es gibt verschiedene Lösungen. Man braucht tatsächlich ein Tool dafür. Anders macht das keinen Sinn. Du hattest auch Time-to-First-Byte-Monitoring genannt. Also wie schnell antwortet mein Server eigentlich? Das kann man sich ja kostenlos in den Crawling-Statistiken der Search Console anschauen. Aber da habe ich diesen Zeitverzug. Wie würdest du das kurzfristig überwachen? Ja, das ist so ein Thema. Dann brauche ich wahrscheinlich schon ein aufwendigeres Monitoring. Entweder direkt ein Server-Monitoring oder andere Tools, die das überwachen. Du kannst dir über PageSpeed Insights zum Beispiel auch den Time to First Byte ausgeben lassen. Aber dafür müsste ich täglich hineinschauen. Das ist schon komplexer. Das sollte man wahrscheinlich eher in Richtung IT und Server-Monitoring geben. Gerade als kleine oder mittlere Website ist das schwieriger. Da braucht man wahrscheinlich kostenpflichtige Tools für ein echtes Monitoring. Du hast ja auch an einigen Stellen Daten aus verschiedenen Quellen zusammengeführt. Search Console, AI Performance Report, andere Datenquellen. Wie geht ihr damit in der Praxis um? Habt ihr da eine Plattform? Ja, wir analysieren die Logfiles im Bulk und binden das momentan einfach in einem Looker-Studio-Dashboard an. Das geht relativ unkompliziert. Man kann über APIs natürlich noch weitere Datenquellen integrieren. Ganz basic: Logfile-Daten aggregieren, als Sheets bereitstellen und an ein Looker-Studio-Dashboard anbinden. Dazu kommen die Konnektoren für GSC und GA4. Das ist erst mal der einfache Weg. So, jetzt kommen noch mehr Fragen rein. Verrückt. Was ist hier heute los? Lesen Bots auch semantisch YouTube-Videos aus, zum Beispiel die Tonspur oder Untertitel? Ja, das ist ein sehr guter Punkt. Da bin ich ehrlich gesagt selbst noch dabei, das zu analysieren und Test-Setups aufzubauen. Bei YouTube kann ich mir das sehr gut vorstellen. Gerade im Google-Umfeld liegt das nahe. Und bei ChatGPT kann ich mir vorstellen, dass solche Daten für Trainingszwecke genutzt werden. Aber wie gut das tatsächlich funktioniert, ist noch offen. Im Retrieval würde ich das eher bezweifeln. In der Knowledge Base eher ja. Wie gesagt: Da laufen bei mir selbst noch Tests. Mein Gefühl ist aber, dass Video- und Audio-Inhalte aktuell noch Nachteile haben. Noch eine Frage: Schadet die Sperrung einzelner Verzeichnisse, beispielsweise für das LLM-Training, der Sichtbarkeit der Domain insgesamt? Also beim Grounding oder bei Inhalten, die nicht gesperrt sind? Nein. Klares Nein. Die LLMs haben nicht so ein ausgeklügeltes Ranking-System wie Google mit einer Sitewide-Bewertung. Die KI-Bots machen das nicht. Sie nutzen das, was im Grounding vorhanden ist oder für Trainingszwecke gefunden wird. Daraus entstehen keine Nachteile für andere Inhalte. Deshalb kann man solche Bereiche sehr unbedenklich sperren. Und darüber sollte man tatsächlich nachdenken: Welche Inhalte möchte ich vielleicht gezielt für Trainingszwecke oder Groundings sperren? Es kommt noch eine etwas Off-Topic-Frage rein. Wie ist deine Meinung zu Grounding-Pages? Wir haben ja gleich den Hans Kronenberg noch da. Ja, tatsächlich. Ich weiß, das ist aktuell ein sehr umstrittenes Thema. Hans hat da wirklich etwas angestoßen. Ich bin tatsächlich eher pro Grounding-Pages. Wir machen dazu gerade selbst Tests. Und ich finde den Grundgedanken sinnvoll: Informationen, die ich einem normalen Nutzer vielleicht gar nicht so präsentieren möchte, die aber für Sprachmodelle hilfreich sind, kann ich dort gezielt und neutral bündeln. Für mich ergibt das durchaus Sinn. Okay, dann würde ich sagen: Schön, dass du da warst. Und ich wünsche mir den Hendrik jetzt herbei. Ja, da bin ich auch schon. Liebe Juliane, ich sage dir auch noch einmal vielen lieben Dank. Es kommen wirklich ganz viele Dankes- und Lobesworte im Chat an. Falls noch Fragen offen geblieben sind: Wir haben nachher noch den Talk mit Hans. Und mit Sicherheit kann man dir auch später noch eine Frage stellen oder dich über LinkedIn kontaktieren. Ich glaube, wir haben heute alle festgestellt: So eine Logfile-Analyse ist ein bisschen wie Brokkoli im SEO-Speiseplan. Jeder weiß, wie gesund und wichtig sie ist. Vielleicht ist sie nicht jedermanns Sache. Aber vielleicht hat dieser Vortrag ja dazu geführt, dass wir alle mehr Brokkoli essen. Gut, diesen Scherz konnte ich mir jetzt nicht verkneifen. Alles klar.
Ep. 01