Das World Wide Web wurde historisch vor allem für menschliche Wahrnehmung und Interaktion gestaltet. HTML strukturiert Inhalte, CSS steuert deren Darstellung, und JavaScript ermöglicht dynamische Funktionen im Browser. Diese Grundarchitektur bleibt weiterhin tragfähig. Zugleich verschiebt sich jedoch die Art, wie Webinhalte genutzt werden. Neben menschlichen Nutzern und klassischen Suchmaschinen-Crawlern greifen zunehmend KI-gestützte Systeme auf Websites zu, um Informationen zu verarbeiten oder einzelne Handlungen vorzubereiten.
Diese Entwicklung wird häufig unter Begriffen wie „Agentic Web“ oder „Agentic Readiness“
diskutiert. Gemeint ist damit nicht ein klar abgegrenzter neuer Webstandard, sondern ein Bündel von
technischen und konzeptionellen Fragen: Wie werden Inhalte von generativen Suchsystemen ausgewertet?
Welche Rolle spielen maschinenlesbare Dateien wie llms.txt? Und in welchem Umfang
könnten Browser-Agenten Websites künftig nicht nur lesen, sondern auch bedienen?
In diesem Blog wurde bereits über WebMCP als Schnittstelle für KI-Agenten berichtet. Der folgende Beitrag ordnet dieses Thema breiter ein. Dabei ist wichtig, verschiedene Ebenen auseinanderzuhalten: das Training von Modellen, die generative Websuche und die aktive Bedienung von Websites durch Agenten.
Generative Suche: Googles offizielle Leitlinien
Im Umfeld generativer Suchsysteme werden seit einiger Zeit Begriffe wie „Answer Engine Optimization“ (AEO) oder „Generative Engine Optimization“ (GEO) verwendet. Sie beschreiben den Versuch, Inhalte so zu gestalten, dass sie in KI-gestützten Such- und Antwortsystemen sichtbar bleiben. Die Betreiber der großen Suchsysteme formulieren dazu allerdings zurückhaltender. Google betont in seinem offiziellen Leitfaden zur Optimierung für generative Funktionen in der Suche, dass AI Overviews und AI Mode auf den bestehenden Kernsystemen für Ranking und Qualität aufbauen.
„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
Für Google Search bedeutet dies nach aktuellem Stand (Mai 2026): Es gibt keine gesonderte
KI-Optimierung, die klassische SEO ersetzt. Google nennt ausdrücklich mehrere Maßnahmen, die für die
Sichtbarkeit in generativen Suchfunktionen nicht erforderlich sind. Dazu gehören spezielle
maschinenlesbare Dateien wie llms.txt, eine künstliche Fragmentierung von Texten in
kleine Abschnitte („Chunking“), das Umschreiben von Inhalten in eine vermeintlich
maschinenfreundliche Sprache sowie ein übermäßiger Fokus auf strukturierte Daten.
Das bedeutet nicht, dass technische Struktur bedeutungslos wäre. Google verweist weiterhin auf crawlbare Inhalte, klare Seitenstrukturen, hilfreiche und nutzerzentrierte Texte sowie nachvollziehbare Angaben zu Autorschaft und Vertrauen. Auch strukturierte Daten nach Schema.org können weiterhin sinnvoll sein, insbesondere für Rich Results und das allgemeine Verständnis von Seiteninhalten. Sie sind aber nach Googles Darstellung keine besondere Eintrittskarte für generative Suchfunktionen.
Maschinelle Webnutzung
Ein Teil der Verwirrung in der Debatte entsteht, weil unterschiedliche technische Vorgänge unter
denselben Schlagworten verhandelt werden. Wenn Google für die Suche keine llms.txt
verlangt, während Chrome Lighthouse experimentelle Prüfungen für llms.txt und
agentische Bedienbarkeit einführt, handelt es sich nicht zwingend um einen Widerspruch. Es geht um
verschiedene Ebenen der Webnutzung.
Training und Datenkontrolle
Die erste Ebene betrifft das Training von Basismodellen. Hier werden große Text- und Datensammlungen verwendet, um Sprachmodelle zu trainieren. Webinhalte können dabei Teil solcher Trainingskorpora werden. Daraus ergeben sich rechtliche, wirtschaftliche und normative Fragen zur Nutzung öffentlich zugänglicher Inhalte. Diese Fragen sind Gegenstand laufender Debatten zwischen Rechteinhabern, Plattformen, Unternehmen und der Öffentlichkeit.
Webseitenbetreiber, die diese Nutzung steuern möchten, greifen unter anderem auf
robots.txt zurück. Google stellt dafür beispielsweise den Produkt-Token
Google-Extended
bereit. Nach Googles Dokumentation kann damit gesteuert werden, ob Inhalte für das Training
zukünftiger Gemini-Modelle sowie für bestimmte Grounding-Anwendungen in Google-KI-Produkten genutzt
werden dürfen. Google betont zugleich, dass Google-Extended keinen Einfluss auf die reguläre
Aufnahme in Google Search und kein Ranking-Signal für die Websuche ist.
robots.txt ist jedoch keine technische Zugriffssperre, sondern eine Konvention, die
von Crawlern beachtet werden muss. Deshalb ergänzen manche Anbieter diese Ebene durch technische
Schutzmaßnahmen. Cloudflare bietet etwa Funktionen zum Blockieren von KI-Bots an. Mit
AI Labyrinth existiert außerdem ein
optionaler Mechanismus, der mutmaßlich unerwünschte Bots in künstlich erzeugte Inhaltsstrukturen
lenken soll. Solche Ansätze zeigen, dass die Kontrolle über Webzugriffe nicht nur eine Frage von
Metadaten, sondern zunehmend auch eine Frage der Infrastruktur ist.
Generative Websuche
Die zweite Ebene betrifft generative Such- und Antwortsysteme. Dabei greifen Sprachmodelle während einer konkreten Anfrage auf aktuelle oder indexierte Webinformationen zurück, um Antworten zu stützen. Dieser Vorgang wird häufig als Grounding oder Retrieval-Augmented Generation (RAG) beschrieben. Beispiele sind das Google-Search-Tool der Gemini-API, die integrierten Websuche-Werkzeuge von OpenAI oder entsprechende Angebote anderer Suchanbieter.
Je nach Anbieter und Produkt werden Suchanfragen erzeugt, Ergebnisse ausgewählt, Inhalte verarbeitet und Quellenhinweise bereitgestellt. Für Entwickler können dabei Parameter wie Suchkontext, Quellenzugriff oder Antwortbudget eine Rolle spielen. Aus Sicht externer Webseitenbetreiber bleibt jedoch nur begrenzt nachvollziehbar, welche Seiten in welchem Moment abgerufen, wie stark gewichtet und wie in die Antwort eingebunden werden. Die Systeme liefern zwar teilweise Zitationsdaten, aber der genaue Auswahl- und Gewichtungsprozess bleibt im Wesentlichen proprietär.
Aktive Bedienung durch Browser-Agenten
Die dritte Ebene betrifft Browser-Agenten. In diesem Szenario liest ein System eine Website nicht nur, um Informationen zusammenzufassen. Es soll im Auftrag eines Nutzers konkrete Schritte ausführen: Formulare ausfüllen, Filter setzen, Menüs bedienen oder eine Transaktion vorbereiten. Hier geht es nicht mehr allein um Sichtbarkeit in einer Antwort, sondern um die Zuverlässigkeit maschineller Interaktion mit einer bestehenden Weboberfläche.
Für solche Systeme können andere Kriterien relevant werden als für die klassische Suche. Dazu gehören semantisch verständliches HTML, eindeutig beschriftete Steuerelemente, ein stabiler Accessibility Tree, geringe Layout-Verschiebungen und, in bestimmten Fällen, explizite Schnittstellen für Agenten. Genau an dieser Stelle setzt die Diskussion um „Agentic Readiness“ an.
Lighthouse Agentic Browsing
Chrome Lighthouse enthält eine experimentelle Kategorie namens „Agentic Browsing“. Laut der offiziellen Dokumentation zum Scoring handelt es sich nicht um einen gewichteten Score von 0 bis 100. Stattdessen werden bestandene Prüfungen als Verhältnis ausgewiesen. Google beschreibt die Kategorie ausdrücklich als experimentell und auf vorgeschlagenen Standards beruhend.
Das ist eine wichtige Einschränkung. Die Lighthouse-Prüfungen sind kein Rankingfaktor für Google Search und auch keine allgemein anerkannte Norm für das Web. Sie sind eher als technisches Signal zu verstehen, welche Eigenschaften eine Website für maschinelle Bedienung besser oder schlechter zugänglich machen könnten.
llms.txt und llms-full.txt
Die von llmstxt.org vorgeschlagene Datei
llms.txt ist ein einfaches Markdown-Dokument im Root-Verzeichnis einer Domain. Sie
soll den Zweck einer Website und wichtige Inhalte in einer kompakten, maschinenlesbaren Form
zusammenfassen. Ergänzend wird häufig eine Datei llms-full.txt erwähnt, die bereinigte
Volltexte wichtiger Seiten bündeln kann.
Lighthouse prüft, ob eine solche Datei vorhanden und technisch abrufbar ist. Zugleich markiert die
Dokumentation die Bereitstellung derzeit als optional. Für Google Search ist llms.txt
nach den offiziellen Search-Leitlinien nicht erforderlich. Die praktische Bedeutung dieser Dateien
hängt daher davon ab, ob relevante Agenten, Werkzeuge oder Plattformen sie tatsächlich nutzen.
Barrierefreiheit als maschinelle Lesestruktur
Ein weiterer Schwerpunkt ist Barrierefreiheit. Browser-Agenten können sich an Informationen orientieren, die auch für assistive Technologien wichtig sind: Rollen, Beschriftungen, programmatische Namen und der Accessibility Tree. Wenn ein Button nur visuell verständlich ist, aber keinen sinnvollen Namen besitzt, kann dies nicht nur für Screenreader problematisch sein, sondern auch für automatisierte Systeme.
Die Lighthouse-Dokumentation zu Accessibility für Agenten hebt deshalb unter anderem Namen und Labels, die Integrität des Accessibility Trees und die Sichtbarkeit interaktiver Elemente hervor. Der naheliegende Schluss ist nicht, dass Barrierefreiheit künftig nur noch als Maschinenoptimierung verstanden werden sollte. Eher zeigt sich umgekehrt, dass robuste, zugängliche Webstrukturen auch maschinelle Nutzung erleichtern können.
Layout-Stabilität
Auch Layout-Stabilität spielt eine Rolle. Unerwartete Verschiebungen von Elementen während des Ladevorgangs können menschliche Nutzer irritieren. Für Agenten können sie zusätzlich problematisch sein, wenn ein System ein Element anhand von Positionen oder aktuellen DOM-Zuständen auswählt und sich die Oberfläche kurz darauf verändert. Die Lighthouse-Dokumentation verweist deshalb auf Cumulative Layout Shift (CLS) als Signal für die Zuverlässigkeit interaktiver Bedienung.
WebMCP und deklarative Schnittstellen
WebMCP geht über reine Lesbarkeit hinaus. Die von Chrome beschriebene WebMCP-Spezifikation soll es Websites ermöglichen, bestimmte Funktionen als strukturierte Werkzeuge für Agenten bereitzustellen. Dazu können JavaScript-basierte Tools oder deklarativ ausgezeichnete Formulare gehören. Ein Agent müsste dann nicht allein aus Button-Texten und visuellen Zuständen schließen, welche Handlung möglich ist, sondern könnte auf eine explizit beschriebene Funktion zugreifen.
Der Ansatz bleibt experimentell. Chrome beschreibt WebMCP als vorgeschlagenen Standard, der für lokale Entwicklung über eine Chrome-Flag verfügbar ist und später in einem Origin Trial erprobt werden soll. Zudem gelten Einschränkungen: Ein Browserkontext ist erforderlich, Werkzeuge müssen entdeckt werden, und komplexe Interfaces können zusätzliche Modellierung erfordern.
Hinzu kommt eine Sicherheitsdimension. Sobald Agenten nicht nur lesen, sondern handeln können, werden Berechtigungen, Bestätigungsschritte, Protokollierung und Missbrauchsschutz zentral. Risiken wie ungewollte Tool-Nutzung, manipulierte Kontexte, zu weit gefasste Berechtigungen oder missverständliche Toolbeschreibungen sind keine Randfragen. Eine agentenfreundliche Website ist daher nicht nur eine Frage der Bedienbarkeit, sondern auch der Begrenzung dessen, was automatisiert ausgelöst werden darf.
Fazit
Die Debatte um das agentische Web zeigt weniger einen vollständigen Bruch mit bisherigen Webstandards als eine Verschiebung ihrer Bedeutung. Für generative Suche bleiben nach offizieller Google-Darstellung klassische Grundlagen entscheidend: crawlbare Inhalte, klare Struktur, hilfreiche Texte und nachvollziehbare Qualität. Spezielle Dateien oder Schreibweisen für KI-Systeme sind dafür derzeit nicht erforderlich.
Anders liegt der Fall bei Browser-Agenten, die Websites aktiv bedienen sollen. Hier werden
Eigenschaften wichtiger, die bereits aus Barrierefreiheit, sauberem HTML und stabiler
Webentwicklung bekannt sind. Ansätze wie llms.txt und WebMCP zeigen, in welche Richtung
sich eine zusätzliche Maschinenschicht des Webs
entwickeln könnte. Ob und in welcher Form sich diese Ansätze durchsetzen, ist offen.
Deshalb erscheint Zurückhaltung angebracht. Weder ist jede Website kurzfristig zu einer agentischen Schnittstelle umzubauen, noch lässt sich die Entwicklung ignorieren. Sinnvoll ist vor allem eine klare Unterscheidung der Ebenen: Datenkontrolle beim Training, Sichtbarkeit in generativen Suchsystemen und Bedienbarkeit durch Agenten sind miteinander verbunden, aber nicht dasselbe.