Warum dieses Thema jetzt konkreter wird
KI-Agenten sind kein rein theoretisches Thema mehr. Google beschreibt inzwischen konkret, wie Websites gebaut sein sollten, damit Agenten sie besser verstehen und bedienen können. In der web.dev-Dokumentation zu agentenfreundlichen Websites geht es nicht um geheime KI-Tricks, sondern um robuste Web-Grundlagen: semantisches HTML, klare Beschriftungen, zugängliche Formulare, stabile Layouts und eindeutige Interaktionen.
Das ist für Unternehmen relevant, weil eine Website zunehmend mehrere Zielgruppen gleichzeitig bedienen muss. Menschen lesen die Seite im Browser. Suchmaschinen crawlen und indexieren sie. Sprachmodelle fassen Inhalte zusammen. Browser-Agenten oder toolnutzende KI-Systeme versuchen, Aufgaben auszuführen. Je klarer eine Website strukturiert ist, desto weniger muss jedes dieser Systeme raten.
Der neue KI-Agenten Website Auditor ist ein bescheidener Versuch, diese Hinweise in ein praktisches Prüfwerkzeug zu übersetzen. Die deutsche Cloudflare-Oberfläche ist bewusst als eigenständiges KI-Radar-Tool angelegt.
Was Google mit agentenfreundlichen Websites meint
Die wichtigste Aussage der Google-Dokumentation ist aus meiner Sicht: Agenten nutzen nicht nur den sichtbaren Text. Sie können mit Screenshots, HTML, der Accessibility-Struktur und sichtbaren Interaktionselementen arbeiten. Dadurch werden klassische Frontend- und Accessibility-Entscheidungen auch für agentische Systeme relevant.
Ein Button sollte ein echter Button sein. Ein Link sollte ein echter Link sein. Ein Formularfeld sollte ein Label haben. Eine Navigation sollte nicht nur optisch sichtbar, sondern im Markup nachvollziehbar sein. Ein Dialog oder Cookie-Banner sollte nicht unklar über dem eigentlichen Inhalt liegen. Solche Dinge sind keine neuen AI-SEO-Kniffe. Sie sind gutes Web-Handwerk.
Google Cloud beschreibt KI-Agenten allgemein als Systeme, die Ziele verfolgen, planen, Werkzeuge nutzen und in mehreren Schritten handeln können. IBM beschreibt ähnliche Komponenten wie Planung, Tools, Speicher, Kommunikation und Aktion. Übertragen auf Websites heißt das: Die Seite ist nicht nur ein Dokument, sondern auch eine Arbeitsoberfläche.
Was der Auditor konkret prüft
Der Auditor crawlt bis zu 100 Seiten einer Domain und bleibt dabei auf demselben Host. Er nutzt auf Wunsch zuerst die Sitemap und respektiert robots.txt. Die Ergebnisse werden in Dimensionen gruppiert: beobachten, handeln, planen und maschinenlesbar machen.
Beobachten bedeutet: Kann ein Agent die Seite sinnvoll erfassen? Gibt es eine klare Überschriftenstruktur, Hauptinhalte, Navigation, Bildbeschreibungen, Tabellenstrukturen und Metadaten? Handeln bedeutet: Sind Buttons, Links, Formulare und Eingaben so beschriftet, dass ein Agent sie nicht nur visuell, sondern auch strukturell versteht?
Planen bedeutet: Sind interne Links, Canonicals, Sitemaps, Statuscodes und Seitenbeziehungen nachvollziehbar? Maschinenlesbarkeit umfasst strukturierte Daten, Open Graph, robots.txt, llms.txt, Sitemap, Feeds und mögliche API-Hinweise. Nicht jede fehlende Datei ist kritisch. Das Tool unterscheidet zwischen wichtigen, empfohlenen, optionalen und eher historischen Ressourcen.
Warum Accessibility hier nicht nur Compliance ist
Viele Signale, die KI-Agenten helfen, sind dieselben Signale, die Menschen mit assistiven Technologien helfen. Accessible Names, Labels, Landmark-Rollen, semantische Buttons und saubere Formularbeziehungen verbessern die Bedienbarkeit für Menschen und reduzieren gleichzeitig Mehrdeutigkeit für automatische Systeme.
Wenn ein Formularfeld nur einen Placeholder hat, sieht es für viele Nutzer vielleicht ausreichend aus. Für robuste Maschinenlesbarkeit ist das schwächer als ein echtes Label. Wenn eine wichtige Aktion als klickbarer div gebaut wird, kann ein Agent sie möglicherweise über Koordinaten erkennen, aber die strukturelle Bedeutung bleibt unsauber.
Der Auditor wertet solche Muster nicht als moralische Anklage, sondern als technische Hinweise. Besonders interessant sind wiederholte Fehler, die aus Templates kommen. Ein korrigiertes Button- oder Formular-Pattern kann viele Seiten auf einmal verbessern.
robots.txt und LLM-Crawler bewusst einordnen
Ein Schwerpunkt des Tools ist robots.txt. Wichtig ist nicht nur, ob der Crawler die Datei respektiert. Wichtig ist auch, was die Datei über KI- und LLM-Crawler aussagt. Viele robots.txt-Dateien wurden für klassische Suchmaschinen, alte Verzeichnisse oder technische Pfade geschrieben und nie auf neuere User Agents geprüft.
Der Auditor betrachtet unter anderem GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, Claude-User, Google-Extended, PerplexityBot, YouBot, CCBot, Meta-ExternalAgent, Bytespider und Applebot-Extended. Die Frage lautet nicht, ob alle erlaubt sein müssen. Die Frage lautet, ob die Entscheidung bewusst und nachvollziehbar ist.
Für Unternehmen ist diese Differenzierung wichtig. Ein Bot für nutzerinitiierte Abfragen, ein Suchbot und ein möglicher Trainingsbot können unterschiedliche Funktionen haben. Wer pauschal blockiert oder erlaubt, trifft möglicherweise eine Entscheidung, die gar nicht zur eigenen Strategie passt.
Wie wichtig ist llms.txt wirklich?
Der Auditor prüft auch, ob eine llms.txt vorhanden ist. Ich würde das aber nicht als Pflichtsignal überhöhen. Eine fehlende llms.txt ist aktuell weniger kritisch als unklare Navigation, kaputte Formularlabels, blockierte wichtige Crawler oder eine Sitemap, die zentrale Seiten nicht auffindbar macht.
llms.txt kann als zusätzliche Orientierung hilfreich sein, vor allem für Experimente und Dokumentationsseiten. Aber sie ersetzt nicht die Grundlagen. Eine Website, die im HTML unklar, in robots.txt widersprüchlich und in der Navigation schwer crawlbar ist, wird nicht durch eine einzelne Zusatzdatei agentenfreundlich.
Deshalb bewertet das Tool llms.txt als empfohlene Ressource, nicht als harte Voraussetzung. Für die meisten Teams ist die bessere Reihenfolge: erst Semantik, Accessibility, Crawl-Pfade und robots.txt prüfen, danach ergänzende Agentenressourcen planen.
Wie man den Report praktisch liest
Der Score ist nur ein Einstieg. Wichtiger sind die konkreten Findings. Ein hoher Score kann trotzdem eine kritische Journey enthalten, die für Agenten schwer bedienbar ist. Ein niedrigerer Score kann dagegen aus wiederholten Template-Problemen entstehen, die sich relativ schnell beheben lassen.
Ich würde den Report in vier Schritten lesen. Erstens: kritische Interaktionsprobleme prüfen, vor allem Buttons ohne klare Namen, Formulare ohne Labels und nicht-semantische Klickflächen. Zweitens: robots.txt und LLM-Crawler-Regeln ansehen. Drittens: Sitemap, Canonicals, Statuscodes und interne Linkpfade kontrollieren. Viertens: strukturierte Daten, Metadaten und optionale Agentenressourcen einordnen.
Wer das direkt ausprobieren möchte, kann den deutschen KI-Agenten Website Auditor nutzen. Für den ersten Lauf reichen meist 25 bis 50 Seiten, aktivierte Sitemap-Nutzung und respektierte robots.txt-Regeln.
Was das Tool nicht behauptet
Der Auditor sagt nicht voraus, ob eine Website in ChatGPT, Gemini, Claude, Perplexity oder Google AI Overviews zitiert wird. Er bewertet auch nicht, ob ein Inhalt fachlich besser ist als ein anderer. Er simuliert keine Login-Bereiche, keine komplexen Checkout-Strecken und keine vollständigen Browser-Agenten mit visueller Steuerung.
Das ist bewusst so. Das Tool ist eine technische Eingangskontrolle. Es beantwortet die Frage: Gibt die Website einem Agenten genug klare Signale, um Inhalte, Aktionen und Zugriffsregeln zu verstehen? Diese Frage ist kleiner als AI-Search-Sichtbarkeit, aber sie ist praktisch und überprüfbar.
Gerade deshalb kann der Audit nützlich sein. Bevor Teams über große KI-Sichtbarkeit spekulieren, können sie zuerst prüfen, ob die Grundlagen stimmen: semantisches Markup, lesbare Inhalte, zugängliche Bedienelemente, stabile Crawl-Pfade und bewusste Bot-Regeln.
Vergleich
Audit-Bereiche und typische Maßnahmen
Praxisfälle
Drei sinnvolle Einsatzszenarien
Relaunch oder Template-Update
Vor einem Relaunch kann der Auditor prüfen, ob neue Komponenten semantisch sauber sind, ob Formulare Labels behalten und ob robots.txt oder Sitemaps versehentlich wichtige Pfade ausschließen.
Content- und SEO-Audit
Bei größeren Websites hilft der Crawl, wiederkehrende Muster zu finden: fehlende Alt-Texte, unklare Buttontexte, schwache Metadaten oder Seiten, die strukturell schwer einzuordnen sind.
AI-Search-Readiness
Für Teams, die sich mit GEO und AI Search beschäftigen, liefert der Auditor eine technische Basisprüfung, bevor Prompt-Monitoring, Citations und externe Markensignale bewertet werden.
FAQ
Häufige Fragen
Ist der KI-Agenten Website Auditor ein offizielles Google-Tool?
Nein. Es ist ein unabhängiges Beta-Tool. Es orientiert sich an öffentlich zugänglichen Google-Dokumentationen zu agentenfreundlichen Websites und KI-Agenten, ist aber kein offizieller Standard.
Verbessert ein hoher Score automatisch die Sichtbarkeit in KI-Antworten?
Nein. Der Score bewertet technische Signale, nicht die spätere Auswahl in ChatGPT, Gemini, Claude, Perplexity oder Google AI Overviews. Er kann aber helfen, technische Unklarheiten zu beseitigen.
Sollte jede Website eine llms.txt haben?
llms.txt kann sinnvoll sein, ist aber derzeit nicht wichtiger als crawlbare Inhalte, gute interne Links, sauberes HTML, Accessibility und bewusste robots.txt-Regeln.
Warum prüft das Tool LLM-Crawler in robots.txt?
Viele Websites haben keine bewusste Strategie für KI-Crawler. Der Auditor zeigt, ob bekannte User Agents erlaubt, blockiert oder nur indirekt über Wildcard-Regeln betroffen sind.
Wie viele Seiten sollte man crawlen?
Für einen schnellen ersten Eindruck reichen 25 bis 50 Seiten. Für größere Websites oder wichtige Templates sind bis zu 100 Seiten sinnvoll.
Was ist der wichtigste erste Fix?
Meistens sind es klare Interaktionen: echte Buttons, echte Links, Labels für Formulare, sinnvolle Überschriften und eine robots.txt, deren Regeln bewusst gesetzt sind.
Quellen und Herstellerseiten