GEO und Agentisches Browsing Warum KI-Agenten eure Hotel-Website anders sehen als Menschen

Während Menschen eure Website mit den Augen betrachten, lesen KI-Agenten den Quellcode. Sie klicken nicht auf schöne Buttons, sondern suchen nach strukturierten Daten. Sie buchen nicht spontan, sondern vergleichen systematisch. Reines SEO reicht dafür nicht mehr aus: Während SEO euch bisher Klicks über Suchmaschinen brachte, entscheidet jetzt GEO (Generative Engine Optimization), ob KI-Systeme eure Inhalte verstehen. Moderne Plattformen wie Google Gemini messen bereits, wie gut eure Website für diese neue Besucherklasse zugänglich ist. Genau das entscheidet, ob ihr in KI-gesteuerten Empfehlungen auftaucht oder unsichtbar bleibt.

Was ist agentisches Browsing und wie unterscheidet es sich vom klassischen Browser?

Die meisten von euch arbeiten täglich mit Browsern: Chrome, Firefox, Safari. Ihr wisst, wie sie funktionieren. Ihr gebt eine URL ein, der Browser lädt HTML, CSS und JavaScript herunter, interpretiert den Code und zeigt euch das Ergebnis visuell auf dem Bildschirm. Der Browser ist ein passives Anzeigeprogramm. ¹ Er wartet auf eure Klicks, führt aus, was ihr ihm sagt, und merkt sich bestenfalls ein paar Cookies. Sobald ihr das Fenster schließt, ist der Vorgang vergessen.

Agentisches Browsing funktioniert komplett anders. Ein agentischer Browser ist mit künstlicher Intelligenz ausgestattet – mit Large Language Models (LLMs) oder Small Language Models (SLMs) – und kann komplexe Aufgaben eigenständig planen und ausführen. ² Er agiert nicht reaktiv, sondern proaktiv . Er versteht die Struktur eurer Website, kann sich in Systeme einloggen, navigiert über mehrere Domains hinweg, füllt Formulare aus und schließt Transaktionen ab, ohne dass ein Mensch jeden einzelnen Schritt klicken muss. ²

Der entscheidende Unterschied liegt im Arbeitsmodus. Während klassische Crawler stateless arbeiten, also jede Seite isoliert betrachten und keine Verbindung zwischen den Schritten herstellen, operieren agentische Browser stateful, also zustandsbehaftet. ² Sie merken sich, was sie bereits getan haben, passen ihre nächsten Schritte daran an und verfolgen ein konkretes Ziel über mehrere Interaktionen hinweg.

Das Herzstück dieser Technologie ist der sogenannte Observe-Plan-Act-Zyklus. Der Agent beobachtet zunächst die Website-Struktur und vorhandene Informationen, plant daraufhin die nötigen Schritte zur Zielerreichung und handelt anschließend autonom – Schritt für Schritt, bis die Aufgabe erledigt ist. ³ Dieser Zyklus wiederholt sich kontinuierlich, bis das Ziel erreicht ist oder der Agent an eine Grenze stößt.

Nicht jeder agentische Browser kann gleich viel. Die Branche arbeitet mit einer vierstufigen Taxonomie.

• Generator Agents: reine Textgenerierung ohne eigenständige Aktionen
• Tool-calling Agents: können APIs nutzen und Daten aus verschiedenen Quellen abrufen
• Planning Agents: führen einfache Workflows mit mehreren Schritten aus
• Autonomous Agents: bewältigen hunderte von Schritten autonom, über mehrere Websites und Domänen hinweg

Besonders leistungsfähige Vertreter wie Perplexity Comet, ChatGPT Atlas von OpenAI, Sigma Browser, Fellou, Opera Neon oder BrowserOS gehören meist zu den letzten beiden Kategorien. ⁴ Sie können komplexe Recherchen durchführen, Preise vergleichen, Verfügbarkeiten prüfen und im Prinzip auch Buchungen vornehmen. Das alles geschieht ohne menschliches Eingreifen nach der initialen Anfrage.

Was diese Systeme noch mächtiger macht, sind ihre vier Gedächtnisebenen. Das Kurzzeitgedächtnis speichert Informationen für die aktuelle Sitzung, das Langzeitgedächtnis erkennt wiederkehrende Muster und Präferenzen, das episodische Gedächtnis ruft vergangene Interaktionen ab, und das Konsens-Gedächtnis führt Erkenntnisse mehrerer Agenten zusammen. ⁵ Ein agentischer Browser lernt also nicht nur während einer einzelnen Session – er baut über die Zeit hinweg ein immer präziseres Verständnis von Websites, Nutzerverhalten und Zielerreichung auf.

Auf eurer Website habt ihr es nicht mehr nur mit menschlichen Gästen zu tun, die Bilder anschauen und Texte lesen. Ihr empfangt intelligente Agenten, die strukturierte Informationen extrahieren, eure Verfügbarkeit maschinell prüfen und eure Inhalte in Antworten auf Nutzerfragen umwandeln, ohne dass ihr es in eurem Tracking überhaupt bemerkt.

Wie funktioniert agentisches Browsing technisch?

Wenn ein KI-Agent eure Website besucht, läuft im Hintergrund ein technischer Prozess ab, der sich fundamental von allem unterscheidet, was ihr von klassischen Besuchern kennt. Vier aufeinanderfolgende Phasen bestimmen, wie der Agent eure Inhalte verarbeitet, welche Daten er extrahiert und ob er am Ende zum Ziel kommt – oder an euren technischen Hürden scheitert. Ihr müsst verstehen, was in jeder dieser Phasen passiert. Nur so könnt ihr nachvollziehen, wie eure Analytics-Daten zustande kommen und warum euer Conversion-Tracking plötzlich andere Zahlen liefert.

Phase 1: Intent Interpretation

Alles beginnt mit einer natürlichsprachlichen Anfrage. „Finde mir ein familienfreundliches Hotel an der Ostsee mit Meerblick für vier Nächte im Juli." Der KI-Agent analysiert diese Eingabe und übersetzt sie in ausführbare Teilaufgaben. ¹ Er identifiziert die Schlüsselbegriffe (familienfreundlich, Ostsee, Meerblick, Verfügbarkeit), extrahiert die Parameter (vier Nächte, Zeitraum Juli) und leitet daraus ab, welche Websites er aufrufen, welche Filter er setzen und welche Datenfelder er prüfen muss.

Diese Phase läuft vollständig im Hintergrund ab, bevor der Agent überhaupt eure Website betritt. Was für Menschen eine einfache Suchanfrage ist, wird hier zu einem strukturierten Handlungsplan – und der Agent erwartet, dass eure Website die notwendigen Informationen maschinenlesbar zur Verfügung stellt.

Phase 2: Task Decomposition

Der Agent zerlegt das übergeordnete Ziel jetzt in logische Einzelschritte. ¹ Aus „Finde ein Hotel" werden konkrete Sub-Tasks. Website aufrufen, Suchmaske identifizieren, Reisezeitraum eingeben, Filter „familienfreundlich" aktivieren, Ergebnisliste analysieren, Zimmerkategorien mit Meerblick identifizieren, Verfügbarkeit prüfen, Preisinformationen extrahieren.

Besonders leistungsfähige Systeme arbeiten hier bereits mit Multi-Agenten-Architekturen. Ein übergeordneter Manager-Agent orchestriert mehrere spezialisierte Sub-Agenten, die jeweils einen Teilschritt übernehmen. ⁶ Das hat zwei Vorteile. Die Last wird verteilt, und für triviale Aufgaben wie das Auslesen von Preisen können schnellere, kostengünstigere Small Language Models (SLMs) eingesetzt werden, während komplexe Entscheidungen den leistungsfähigeren Large Language Models vorbehalten bleiben. ⁵

Was das für eure Website bedeutet? Der Agent arbeitet nicht linear wie ein menschlicher Gast, sondern verteilt die Anfrage möglicherweise über mehrere parallele Prozesse. Eure Server sehen nicht einen Besucher, sondern eine orchestrierte Abfrage-Kaskade.

Phase 3: Website Analysis

Hier passiert der entscheidende Unterschied. Während menschliche Gäste eure Website visuell wahrnehmen – Bilder, Schriften, Layout –, analysiert der Agent ausschließlich euren Quellcode und den sogenannten Accessibility Tree. ⁷ Er interessiert sich nicht für Farben oder Schriftgrößen. Er sucht nach strukturierten Daten, semantisch korrekt ausgezeichnetem HTML, maschinenlesbaren Metadaten und logisch aufgebauten Formularen.

Der Accessibility Tree ist dabei die technische Schnittstelle, die ursprünglich für Screenreader entwickelt wurde. Eine hierarchische Darstellung aller interaktiven Elemente, Labels und Inhalte einer Website. Agentische Browser nutzen genau diese Struktur, um sich zu orientieren. Wenn eure „Jetzt buchen"-Buttons nur als dekorative <div>-Elemente ohne semantische Auszeichnung existieren, kann der Agent sie nicht als Buchungs-Call-to-Action erkennen. Wenn eure Verfügbarkeitsanzeige nur visuell über CSS-Klassen gesteuert wird, bleibt sie für den Agent unsichtbar.

Phase 4: Execution with Adaptation

Jetzt wird der Agent aktiv. Er führt die geplanten Schritte aus – und passt seine Strategie kontinuierlich an das an, was er vorfindet. ⁷ Taucht ein Cookie-Banner auf, erkennt er es und klickt es weg. Blockiert ein Pop-up den Zugriff auf das Buchungsformular, sucht er nach alternativen Navigationswegen. Ändert sich die Seitenstruktur nach einem Filter-Klick, analysiert er die neue DOM-Struktur und passt seinen nächsten Schritt an.

Diese Anpassungsfähigkeit unterscheidet agentische Browser von klassischen Crawlern, die stur vordefinierte Skripte abarbeiten. Der Agent lernt während der Ausführung – und kann dabei auch scheitern, wenn eure Website technische Barrieren aufbaut. Fehlerhafte ARIA-Labels, JavaScript-abhängige Navigation ohne Fallback, fehlende strukturierte Daten für Verfügbarkeit oder Preise.

Agentisches Browsing testet eure Website auf eine Weise, die weit über klassische SEO-Audits hinausgeht. Es deckt auf, ob eure digitale Infrastruktur nicht nur für menschliche Augen, sondern auch für intelligente Systeme zugänglich ist – und diese Zugänglichkeit wird künftig darüber entscheiden, ob eure Angebote überhaupt in KI-generierten Empfehlungen auftauchen.

Was Google PageSpeed jetzt prüft

Google hat reagiert – und zwar schneller, als die meisten Hoteliers es bemerkt haben. Mit Lighthouse 13.3 wurde eine komplett neue Hauptkategorie in PageSpeed Insights integriert – 'Agentic Browsing'. ⁸ Sie steht jetzt gleichberechtigt neben Performance, Accessibility, Best Practices und SEO als fünfte Säule. Das ist kein experimentelles Feature in den Developer Tools – es ist eine offizielle Bewertungsdimension, die Google euren Websites zuordnet. Wer künftig in KI-gesteuerten Empfehlungs-Ökosystemen sichtbar bleiben will, muss maschinenlesbar werden.

Aber diese neue Kategorie funktioniert grundlegend anders als die vier bisherigen Metriken. Während Performance einen Score von 0 bis 100 vergibt, arbeitet Agentic Browsing mit einem Pass/Fail-System. Ihr seht Brüche wie 3/3, 2/2 oder 4/9 – die erste Zahl zeigt, wie viele Checks bestanden wurden, die zweite die Gesamtzahl der geprüften Kriterien. ⁹ Besteht ihr nur zwei von neun Checks, habt ihr ein Problem. Hier kommt die gute Nachricht. Eine schlechte Agentic-Browsing-Ratio verändert eure bestehenden Performance- oder SEO-Scores nicht. ⁸ Google bestraft euch nicht nachträglich – noch nicht. Die Metrik ist Stand Mitte 2025 experimentell und kein direkter Ranking-Faktor für klassische blaue Links in der Suche. ¹⁰

Cumulative Layout Shift

Agenten klicken anhand von X- und Y-Koordinaten im Viewport – exakt wie ein Mensch, der mit der Maus auf ein Element zielt. ⁹ Wenn euer Layout nach dem ersten Rendering asynchron nachlädt – Bilder ohne Dimensionen, Werbebanner, Web Fonts –, verschiebt sich die Position aller Elemente. ⁸ Der Agent zielt auf den Button „Verfügbarkeit prüfen", aber in dem Moment, in dem er klickt, ist der Button drei Zeilen nach unten gerutscht. Der Klick geht ins Leere, die Aktion schlägt fehl, der Agent bricht ab.

Deshalb ist ein CLS-Wert nahe null jetzt kritisch für Agent Safety. ¹¹ Nicht nur aus Performance-Gründen, sondern weil Layout-Instabilität Agenten technisch daran hindert, eure Seite korrekt zu bedienen. Wenn eure Zimmerkategorien erst nach zwei Sekunden vollständig geladen sind und dabei euren Buchungsbutton nach unten schieben, sieht das für Menschen nur unschön aus – für Agenten ist es ein Blocker.

llms.txt und WebMCP

PageSpeed prüft jetzt zwei neue Dateien in eurem Stammverzeichnis. llms.txt und WebMCP-Implementierungen. ⁹ Die llms.txt-Datei ist das Äquivalent zur robots.txt – aber für KI-Agenten. Sie erklärt maschinenlesbar, welche Funktionen eure Website bietet, welche URLs relevant sind und welche Bereiche Agenten nutzen dürfen. Fehlt sie, müssen Agenten eure gesamte Seitenstruktur erraten – ineffizient und fehleranfällig. ¹²

WebMCP geht noch einen Schritt weiter. Es ermöglicht eurer Website, interne Funktionen strukturiert und maschinenlesbar an KI-Agenten zu melden. ⁹ PageSpeed prüft WebMCP-Implementierungen über den offiziellen WebMCP Origin Trial von Google. ⁹ Statt dass ein Agent eure Verfügbarkeitssuche durch Trial-and-Error herausfinden muss, meldet eure Website von sich aus, wo die Funktion „Verfügbarkeit prüfen" liegt, welche Parameter sie erwartet und wie die Antwort aussieht. Das ist der Unterschied zwischen einem Agenten, der zehn Minuten lang eure Seite analysiert – und einem, der in zehn Sekunden die richtige Funktion findet.

Lighthouse 13.3 ist euer Frühwarnsystem. Die Metrik bestraft euch heute noch nicht im Ranking – aber sie zeigt euch schwarz auf weiß, ob eure Website für die nächste Traffic-Welle bereit ist. Wenn ihr jetzt reagiert, habt ihr einen Vorsprung. Wenn ihr wartet, bis Google Agentic Browsing zum Ranking-Faktor macht, seid ihr zu spät dran.

Wie optimiert man eine Hotel-Website für KI-Agenten?

Die gute Nachricht zuerst: ihr müsst eure Website nicht komplett neu bauen. Die meisten Optimierungen sind gezielte technische Eingriffe, die ihr sukzessive umsetzen könnt – oder die eure Agentur für euch übernimmt, wenn euch die Ressourcen fehlen. Wir zeigen euch die vier Hebel, die den größten Unterschied machen.

Mit diesen Maßnahmen erreicht ihr einen Agentic-Browsing-Score von über 80 %. Lighthouse 13.3 bestraft euch heute noch nicht im Ranking – aber es zeigt euch schwarz auf weiß, ob eure Website für die nächste Traffic-Welle bereit ist.

llms.txt: Die strukturierte Landkarte für Large Language Models

Beginnen wir mit der llms.txt-Datei – sie ist technisch am einfachsten umzusetzen und liefert sofort Wirkung. llms.txt ist eine hochkuratierte, strukturierte Landkarte der wichtigsten Website-Informationen für Large Language Models. ¹³ Ihr legt sie im Root-Verzeichnis eurer Domain ab, genau wie die robots.txt – also unter https://euerhotel.de/llms.txt. Die Datei ist Plain-Text und nutzt Markdown-Syntax. ¹⁴ Markdown ist die „Muttersprache" von LLMs, weil es Hierarchien ohne HTML-Overhead liefert. ¹⁴ Agenten können Markdown-Strukturen direkt verarbeiten, ohne CSS oder JavaScript interpretieren zu müssen.

Die Struktur der Datei ist bewusst einfach gehalten und folgt vier Elementen. Der H1-Titel ist verpflichtend und besteht aus einem # gefolgt von eurem Website-Namen. Direkt darunter folgt eine Blockquote Summary – eingeleitet mit > – die euer Hotel in zwei bis drei Sätzen verdichtet beschreibt. Dann kommen Section Headers als H2-Überschriften (##) für logische Inhalts-Blöcke wie „Zimmerkategorien", „Restaurants" oder „Buchungsprozess". Unter jeder Sektion listet ihr relevante Links im Format - (/pfad): Kurzbeschreibung auf. ¹⁵ Ein Beispiel. - (/zimmer/suite-meerblick): Suite mit 42 qm, direktem Meerblick und privater Terrasse. Agenten verstehen sofort, was sich hinter diesem Link verbirgt – ohne die Seite erst aufrufen zu müssen.

Für größere Hotels oder solche mit viel Content gibt es eine Ergänzung – die /llms-full.txt-Datei. Sie enthält euren gesamten relevanten Inhalt als fortlaufenden Text in einer einzigen Datei und reduziert den Fetch-Overhead auf einen HTTP-Request. ¹⁶ Das ist besonders wertvoll, wenn Agenten umfassende Informationen benötigen – etwa für komplexe Anfragen wie „Welches Zimmer eignet sich für eine Familie mit zwei Kindern und Hund?" Die llms.txt-Datei solltet ihr vierteljährlich überprüfen, optimal unter 10 KB Größe halten und mit einer Response Time von unter 200 Millisekunden ausliefern. ¹⁵ Das sind technische Bagatellen – aber sie signalisieren Agenten, dass eure Website professionell aufgesetzt ist.

WebMCP: Von Dokumenten zu Tool Surfaces

WebMCP geht deutlich weiter als llms.txt. Es verwandelt Webseiten von Dokumenten in „Tool Surfaces". ¹¹ Eure Website registriert Kernfunktionen als strukturierte API-Schnittstellen direkt im Browser-Kontext. ⁹ Statt dass ein Agent eure Verfügbarkeitssuche durch Trial-and-Error nachvollziehen muss, meldet eure Website proaktiv, wo die Funktion „Verfügbarkeit prüfen" liegt, welche Parameter sie benötigt (Check-in, Check-out, Personenzahl) und wie das Ergebnis aussieht.

Es gibt zwei technische Wege, WebMCP zu implementieren. Der deklarative Ansatz nutzt <tool>-Tags direkt im HTML – ideal für statische Seiten oder wenn eure Funktionen sich nicht dynamisch ändern. Der imperative Ansatz nutzt die navigator.webMCP-API in JavaScript und eignet sich für Single-Page Applications, bei denen Funktionen zur Laufzeit registriert werden. ⁹ Für die meisten Hotel-Websites mit klassischem CMS ist der deklarative Weg der richtige. Ihr definiert eure Buchungsfunktion, Kontaktformulare oder Tischreservierungen einmal sauber – und Agenten können sie ab sofort direkt ansprechen.

WebMCP-Registrierungen müssen schnell verfügbar sein. Wenn eure JavaScript-Initialisierung drei Sekunden braucht, um die Tools zu registrieren, scheitert der Lighthouse-Snapshot – und euer Agentic-Browsing-Score bricht ein. ⁹ Kritische Funktionen müsst ihr so früh wie möglich im Rendering-Prozess verfügbar machen.

Performance als Agent Safety: Latenz eliminieren

Latenz ist der größte Feind von KI-Agenten. ⁶ Jeder LLM-API-Aufruf kostet Geld und Rechenzeit, und Time-outs führen zu kompletten Task-Abbrüchen. ⁶ Wenn euer Server drei Sekunden braucht, um auf eine Anfrage zu antworten, bricht der Agent ab und geht zur nächsten Website. Deshalb sind die Core Web Vitals jetzt kritisch für Agentic Browsing – nicht nur als Performance-Metrik, sondern als Betriebssicherheit für Maschinen.

Drei Metriken sind unverzichtbar. LCP (Largest Contentful Paint) muss unter 2,5 Sekunden liegen, damit euer Hauptinhalt sofort verfügbar ist. INP (Interaction to Next Paint) sollte unter 200 Millisekunden bleiben – Agenten erwarten Reaktionen auf Input in Echtzeit. Und CLS (Cumulative Layout Shift) sollte bei 0,1 oder idealerweise 0,0 liegen, damit Agenten nicht ins Leere klicken. ¹⁷ Diese Zahlen sind keine Empfehlungen – sie sind technische Voraussetzungen, damit Agenten eure Seite überhaupt bedienen können.

Drei Maßnahmen machen den größten Unterschied. Bildoptimierung mit modernen Formaten wie WebP oder AVIF und expliziten Breiten- und Höhenangaben verhindert CLS. Die Eliminierung ungenutzten CSS- und JavaScript-Codes durch Tree Shaking reduziert Ladezeiten drastisch. Und Code-Splitting mit Lazy Loading für nicht-kritisches Rendering sorgt dafür, dass nur die wirklich benötigten Ressourcen geladen werden. ¹⁸ Das sind technische Standard-Maßnahmen, die jede moderne Agentur beherrscht – aber sie müssen konsequent umgesetzt werden.

Accessibility by Default: Semantisches HTML statt Framework-Noise

Barrierefreiheit ist kein nachträgliches Plugin mehr – es ist der Standard, an dem Agenten eure Website messen. ¹² Viele moderne Hotel-Websites sind JavaScript-lastige Single-Page Applications, die „Framework-Noise" erzeugen – technischen Overhead, der Agenten verwirrt. ¹² Tools wie Astro, die statisches HTML ausliefern, bieten hier deutliche Vorteile gegenüber schweren SPAs. ¹²

Vier Regeln sind zwingend. Jedes Formularfeld benötigt ein explizit verknüpftes <label>-Element. Schaltflächen müssen native <button>-Tags sein, keine klickbaren <div>-Container. Zustandsänderungen kommuniziert ihr über ARIA-Attribute wie aria-expanded. Und dekorative Elemente – Bilder ohne inhaltliche Bedeutung, Spacer-Divs – versetzt ihr mit aria-hidden="true" für maximale Signal-to-Noise Ratio. Diese Maßnahmen kosten euch nichts an visuellem Design, machen eure Website aber für Agenten vollständig lesbar.

Agentic-Browsing-Scores können bei dynamischen Anwendungen fluktuieren. ⁹ Client-Side Rendering mit React oder Vue bedeutet, dass sich der DOM-Zustand ständig ändert – IDs und aria-hidden-Attribute schwanken während der Initialisierung. ⁹ Server-Side Rendering (SSR) oder statische Generierung (SSG) solltet ihr klar bevorzugen, wenn ihr eine agentenfreundliche Website wollt. ⁹ Das bedeutet nicht, dass SPAs unmöglich sind – aber sie erfordern deutlich mehr technische Sorgfalt.

Was sind die nächsten Schritte?

Zwischen Rezeption, Housekeeping und Abrechnungen bleibt keine Zeit, um sich mit llms.txt-Dateien oder WebMCP-Registrierungen zu beschäftigen. Und genau deshalb gibt es uns. Was ihr gerade gelesen habt, ist keine Theorie. Das sind die Maßnahmen, die wir aktuell bei unseren Hotels umsetzen. Ihr müsst diesen Weg also nicht allein gehen. Bucht einfach ein kostenloses Erstgespräch und wir schauen gemeinsam, wie wir euch am besten unterstützen können.