Das agentische Web: Wie sich Websites auf generative Suche und autonome KI-Agenten vorbereiten

Das World Wide Web wurde historisch primär für die menschliche Wahrnehmung und visuelle Interaktion gestaltet. HTML strukturiert die Inhalte, CSS steuert die ästhetische Präsentation, und JavaScript ermöglicht dynamische Effekte im Browser. Mit der zunehmenden Verbreitung von Systemen der Künstlichen Intelligenz wird diskutiert, inwieweit diese traditionelle Strukturierung ergänzt oder angepasst werden könnte. Neben menschlichen Nutzern greifen zunehmend auch automatisierte Programme wie Web-Crawler, Suchsysteme und Software-Agenten auf Webseiten zu, um Informationen zu verarbeiten oder Interaktionen vorzunehmen.

Dieser informationelle Wandel wirft grundlegende Fragen auf, wie Webinhalte strukturiert sein sollten, um sowohl für Menschen als auch für maschinelle Systeme optimal nutzbar zu sein. In diesem Blog wurde bereits über WebMCP als Schnittstelle für KI-Agenten berichtet. Im größeren Kontext wird dieses Thema unter dem Begriff „Agentic Readiness“ diskutiert, wobei sich die Entwicklung in zwei wesentliche Nutzungsbereiche aufteilt: die passive Wissenserfassung durch generative Suchmaschinen auf der einen Seite und die aktive Steuerung durch autonome Agenten im Browser auf der anderen Seite.

1. Die Perspektive der Suche: Googles offizielle Leitlinien

Im Zuge der Diskussionen um die Optimierung für generative Systeme – in der Marketingbranche oft als AI Engine Optimization (AEO) bezeichnet – äußern sich die Betreiber von Suchmaschinen zurückhaltend. Im offiziellen Leitfaden von Google zur Optimierung für generative Funktionen (wie die AI Overviews in der Google-Suche) wird betont, dass diese Features auf den bestehenden Kernsystemen für Ranking und Qualität aufbauen. In den Richtlinien zur Generative AI Optimization auf Google Search wird darauf hingewiesen, dass die Optimierung für generative Funktionen im Wesentlichen der klassischen Suchmaschinenoptimierung (SEO) entspricht. Google gibt an, dass keine separaten Frameworks oder gesonderten KI-Strategien erforderlich sind, da die Systeme auf den etablierten Kriterien zur Qualitätsbewertung fußen.

„The best practices for SEO continue to be relevant because our generative AI features on Google Search are rooted in our core Search ranking and quality systems. [...] From Google Search's perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO.“

Quelle: Google Search Central, Optimizing your website for generative AI features on Google Search

Da sich diese Richtlinien und technischen Dokumentationen im Zuge der rasanten technologischen Entwicklung kontinuierlich verändern, stellen solche Angaben stets nur eine Momentaufnahme der aktuellen Praxis dar (Stand: Mai 2026). Google weist in seinen Leitfäden darauf hin, dass für die Ausspielung in den AI Overviews keine gesonderten, maschinenspezifischen Dateien wie die llms.txt herangezogen werden. Auch eine künstliche Fragmentierung von Texten, das sogenannte „Chunking“, wird als nicht erforderlich beschrieben, da moderne Sprachmodelle in der Lage seien, zusammenhängende Inhalte selbstständig im Kontext zu analysieren. Ebenso wird das Umschreiben von Texten in eine vermeintlich maschinenfreundliche Sprache kritisch beurteilt. Stattdessen verweisen die Richtlinien auf das etablierte E-E-A-T-Prinzip (Experience, Expertise, Authoritativeness, Trustworthiness), wie es in den Leitlinien für hilfreiche Inhalte detailliert ist, um qualitativ hochwertige, nutzerzentrierte Beiträge zu fördern. Auch spezifische, vom Standard abweichende Auszeichnungen werden für generative Suchfunktionen nicht verlangt: strukturierte Daten nach Schema.org bleiben zwar wichtig, dienen jedoch dem allgemeinen semantischen Verständnis, wie im Google-Leitfaden für strukturierte Daten erläutert wird.

2. Das AEO-Paradoxon: Training, Inferenz und das agentische Web

Aus dieser Perspektive lässt sich ein scheinbares Paradoxon beobachten: Während das Suchteam von Google feststellt, dass spezifische KI-Dateien wie die llms.txt für die Websuche bedeutungslos sind, führt das Chrome-Team in seinem Entwickler-Tool Lighthouse ein experimentelles Audit namens „Agentic Browsing“ ein, welches genau nach diesen Dateien und Optimierungen sucht. Ein möglicher Erklärungsansatz für diese unterschiedlichen Signale liegt in der Differenzierung der technischen Nutzungsweisen von Webinhalten durch KI-Systeme. Um dieses unübersichtliche Feld besser zu strukturieren, kann ein hypothetisches Modell mit drei verschiedenen Dimensionen herangezogen werden, wie Modelle und Agenten mit dem Web interagieren.

Die erste Dimension betrifft das 'Offline-Training' von Basismodellen. Große Web-Crawler sammeln im Vorfeld enorme Textmengen, um Sprachmodelle grundlegend zu trainieren und sprachliche Muster zu erlernen. In diesem Blog wurde bereits mehrfach über den enormen Hunger der Entwickler nach Webdaten sowie über die genaue Herkunft dieser Trainingsdaten berichtet, bei der unter anderem OpenAIs Crawler GPTBot und der Common-Crawl-Datensatz eine Rolle spielen. In dieser Phase werden Webinhalte dauerhaft in den Parametern des Modells gespeichert, was auch die rechtlichen und moralischen Grenzen der Datennutzung herausfordert, worüber im Netz eine fortlaufende Urheberrechtsdebatte um KI-Systeme geführt wird. So zeigt sich am Beispiel von Google, wie Technologiekonzerne versuchen, durch eine Anpassung der Datenschutzerklärung das gesamte öffentliche Web als freie Trainingsdatenbasis zu deklarieren. Webseitenbetreiber, die diese Datensammlung verwalten oder einschränken möchten, greifen häufig auf Direktiven in der robots.txt zurück – beispielsweise über das von Google bereitgestellte Steuerungs-Token Google-Extended, welches die Nutzung von Inhalten sowohl für das Training zukünftiger Modellgenerationen (wie Gemini) als auch für Grounding-Anwendungen in KI-Produkten steuert, laut Google jedoch keinen Einfluss auf die reguläre Indexierung oder das Ranking in der Websuche hat. Doch da robots.txt-Einträge von Crawlern ignoriert werden können, gewinnen technologische Sperren an Bedeutung. So bietet beispielsweise Cloudflare mittlerweile eine standardmäßige Blockierung von KI-Bots an, was insbesondere öffentliche Institutionen vor die grundlegende Frage stellt, wie sie die Hoheit über ihre Daten wahren und gleichzeitig ihrem Bildungs- oder Informationsauftrag gerecht werden können. Diese technischen Schutzmaßnahmen entwickeln sich rasant weiter: Über defensive Blockaden hinaus ermöglichen fortgeschrittene Schutzschilde das aktive Ausbremsen unerwünschter Scraper durch sogenannte „AI Labyrinths“ – dynamische Tarpits, die Bots in eine Endlosschleife aus künstlich generierten, synthetischen Inhalten lenken.

Die zweite Dimension umfasst die 'generative Websuche' – ein Verfahren, bei dem Sprachmodelle während der Interaktion in Echtzeit auf aktuelle Webinhalte zugreifen, um ihre Antworten abzusichern (oft als Search Grounding oder Websuche-Tool bezeichnet). In der Praxis greifen Systeme bei einer konkreten Benutzeranfrage direkt auf Suchmaschinen-Indizes zu. Dies wird beispielsweise über das Google-Search-Tool der Gemini-API, die integrierten Suchwerkzeuge von OpenAI oder über die LLM-Schnittstelle der Brave-Search-API realisiert. Aus der ursprünglichen Benutzeranfrage werden dabei Suchanfragen erzeugt und bereinigte Textfragmente abgerufen, die speziell auf das begrenzte Verarbeitungsfenster des Modells zugeschnitten sind. Entwickler können diese Prozesse über bestimmte Parameter steuern – etwa durch Relevanzfilter oder begrenzte Textbudgets – und strukturierte Metadaten eine transparente Zitation ermöglichen. Dennoch bleibt der eigentliche Filterprozess eine Blackbox: Die genauen Heuristiken zur Bewertung der Relevanz, das konkrete Auslesen von Drittwebseiten sowie die anschließende Gewichtung der Ergebnisse entziehen sich einer externen Überprüfung.

Die dritte Dimension ist die 'autonome Interaktion durch Browser-Agenten'. In diesem Szenario liest ein System Webinhalte nicht nur passiv für eine Zusammenfassung, sondern agiert aktiv im Auftrag des Nutzers direkt im Browser. Ein solcher Software-Agent soll beispielsweise Formulare ausfüllen, durch Menüs navigieren oder Transaktionen ausführen. Für diese interaktiven Systeme ist ein rein visuell ausgerichtetes, mit CSS-Effekten und Werbeelementen überladenes HTML ineffizient und fehleranfällig. Sie benötigen eine hohe strukturelle Stabilität und maschinenlesbare Schnittstellen.

Das experimentelle Lighthouse-Audit für „Agentic Browsing“ lässt sich daher so interpretieren, dass es nicht die Eignung für das klassische Suchmaschinen-Ranking bewertet, sondern die Gebrauchstauglichkeit und Bedienbarkeit einer Website für aktiv handelnde Software-Agenten untersucht. Dies bildet den Kern der Diskussion um die „Agentic Readiness“.

3. Die technischen Kriterien der Agentic Readiness im Test

Ein Blick in die offizielle Dokumentation zum Lighthouse Agentic Browsing Scoring zeigt, dass diese experimentelle Kategorie keinen gewichteten Score von 0 bis 100 besitzt. Da sich die Standards in einer frühen, experimentellen Phase befinden, wird stattdessen ein Verhältnis bestandener Prüfungen (fractional score) ausgewiesen. Die Bewertung stützt sich im Wesentlichen auf verschiedene technische Kriterien, die als potenzielle Säulen für die maschinelle Interaktion diskutiert werden.

A. llms.txt und llms-full.txt als experimentelle Verzeichnisse

Ein in Entwicklerkreisen viel diskutierter Vorschlag zur Strukturierung von Web-Inhalten für Sprachmodelle ist die von Projekten wie llmstxt.org vorgeschlagene llms.txt-Spezifikation. Es handelt sich dabei um eine einfache Textdatei im Markdown-Format, die im Root-Verzeichnis einer Domain abgelegt wird. Die Idee hinter diesem Entwurf ist es, eine Art kuratiertes, maschinenlesbares Inhaltsverzeichnis anzubieten, das den Zweck und die Struktur der Webpräsenz kurz zusammenfasst. Ergänzend dazu wird über eine optionale Datei namens llms-full.txt nachgedacht, die den bereinigten Volltextinhalt der wichtigsten Seiten in einem einzigen Dokument bündelt.

In der Lighthouse-Dokumentation zu llms.txt wird geprüft, ob diese Dateien vorhanden und syntaktisch korrekt strukturiert sind. Befürworter argumentieren, dass KI-Agenten dadurch mit einer einzigen Anfrage das wesentliche Wissen einer Domain erfassen könnten, wodurch zahlreiche Einzelabrufe vermieden würden. Da große Suchmaschinen wie Google diese Dateien für ihre Suchfunktionen derzeit explizit ignorieren, bleibt die langfristige Etablierung und praktische Relevanz dieser Spezifikationen eine offene Frage.

B. Barrierefreiheit als maschinelle Schnittstelle

Ein zentraler Aspekt der Diskussion ist die Hypothese, dass autonome Agenten Webseiten oft nicht visuell analysieren, sondern sich auf denselben Datenstrom stützen können wie menschliche Nutzer mit Seheinschränkungen: den 'Accessibility Tree (Barrierefreiheitsbaum)' des Browsers. Dies würde bedeuten, dass klassische Barrierefreiheit (Accessibility) eine zusätzliche Funktion als maschinelle Schnittstelle erhält.

Gemäß den Richtlinien zur Accessibility für Agenten in Lighthouse konzentriert sich die Bewertung vor allem auf die semantische Struktur des DOM. Dazu gehört die präzise Vergabe von programmatischen Namen und Beschriftungen (Names and Labels), damit interaktive Elemente wie Buttons oder Eingabefelder im Barrierefreiheitsbaum eindeutig identifizierbar sind. Zudem wird die strukturelle Integrität des DOM (Tree Integrity) bewertet, um einen fehlerfreien Aufbau des Accessibility-Trees zu gewährleisten. Interaktive Steuerelemente müssen zudem im Baum als sichtbar deklariert sein, um von automatisierten Systemen erfasst werden zu können. Ob sich dieser vermutete Synergieeffekt zwischen Barrierefreiheit für Menschen und Lesbarkeit für Maschinen in der Praxis flächendeckend bestätigt, wird sich im Zuge der weiteren Entwicklung autonomer Systeme weisen müssen.

C. Layout-Stabilität und CLS

Ein weiteres Kriterium, das in der Lighthouse-Dokumentation zur Layout-Stabilität untersucht wird, ist die Vermeidung von unerwarteten Layout-Verschiebungen (Cumulative Layout Shift). Es wird vermutet, dass plötzliche Verschiebungen von Elementen während des Ladevorgangs – beispielsweise durch nachträglich geladene Bilder oder Schriften – die Navigation von KI-Agenten erschweren können. Da sich automatisierte Systeme bei Interaktionen häufig auf ermittelte Positionsdaten oder DOM-Koordinaten stützen, könnten Verschiebungen zu Fehlklicks oder Abbruchfehlern führen. Layout-Stabilität wird daher als ein potenzielles Kriterium für die funktionale Zuverlässigkeit von Interaktionen diskutiert.

D. Deklarative Schnittstellen mit WebMCP

Einen weiteren, in der WebMCP-Spezifikation beschriebenen Ansatz stellt das Zusammenspiel mit dem Model Context Protocol dar. Hierbei wird die Möglichkeit erörtert, Formulare und Skripte so deklarativ auszuzeichnen, dass Browser-Agenten sie direkt als strukturierte Werkzeuge interpretieren und ansteuern können. Befürworter betonen, dass durch die Ausführung der Aktionen im geschützten Kontext des Benutzer-Browsers der Grundsatz der menschlichen Kontrolle gewahrt bleibt und die Sicherheit erhöht werden könnte.

4. Fazit: Perspektiven einer offenen Entwicklung

Die Auseinandersetzung mit den Konzepten des agentischen Webs verdeutlicht, dass bewährte Webstandards im Kern weiterhin die verlässlichste Orientierung bieten. Spezifische technische Hilfskonstruktionen oder das vorschnelle Anpassen von Texten an ein vermeintlich maschinenfreundliches Format erweisen sich nach aktuellem Erkenntnisstand als wenig zielführend.

Während die passive Auffindbarkeit in generativen Suchsystemen in erster Linie auf der Relevanz und Struktur menschlich kuratierter Inhalte aufbaut, erfordert die Interaktion mit autonom agierenden Browser-Agenten strukturelle Präzision – von semantischem HTML über Barrierefreiheit bis hin zu experimentellen Protokollen. Da sich viele der technischen Richtlinien noch in einer frühen Entwicklungsphase befinden, bleibt die konkrete Ausgestaltung zukünftiger Standards eine offene, im Fluss befindliche Entwicklung.