Website für KI‑Agenten optimieren: Warum sauberes HTML mehr bringt als jede KI‑Datei

Ihre Website hat eine neue Sorte Besucher, und dieser Besucher schaut nicht hin. Er liest. Wenn ein Kunde ChatGPT bittet, einen Termin zu buchen oder einen Anbieter zu vergleichen, kommt kein Mensch auf Ihre Seite, sondern ein Agent, der im Auftrag handelt. Er sieht Ihr Layout nicht so, wie Sie es entworfen haben. Er bekommt eine maschinenlesbare Fassung, und deren Qualität entscheidet, ob er Sie versteht oder abbricht.

Für diese Aufgabe kursiert gerade ein Akronym: AEO, mal als „Answer Engine Optimization”, mal als „Agent Engine Optimization” ausbuchstabiert. Ich halte mich an einen Begriff und nenne die Sache GEO, Generative Engine Optimization. Das Etikett ist ohnehin zweitrangig. Die Frage dahinter ist konkret: Was muss an Ihrer Website anders sein, damit ein autonomer Agent sie lesen und bedienen kann? Die verbreitete Antwort lautet „eine llms.txt anlegen”. Sie ist falsch, oder genauer: Sie fängt am kleinsten Hebel an. Der große Hebel ist unspektakulär. Es ist sauberes HTML.

Was ein KI‑Agent von Ihrer Website sieht

Stellen Sie sich Ihre Website als Gebäude vor. Ein menschlicher Besucher sieht die eingerichteten Räume: Farben, Möbel, die große Schaltfläche, den Hover‑Effekt. Ein Agent bekommt davon fast nichts mit. Er arbeitet mit dem Grundriss, also der reinen Struktur dahinter. Wer nur die Möbel schön stellt, aber keinen sauberen Grundriss hinterlegt, den findet der Agent nicht. Anders als ein echter Grundriss entsteht dieser aber nicht einmalig beim Bau, sondern bei jedem Aufruf neu aus Ihrem Code. Genau da können Sie eingreifen.

Konkret sieht ein Agent Ihre Seite auf drei Wegen, wie Googles Chrome‑Team im April 2026 beschrieben hat. Erstens den Screenshot: Ein Vision‑Modell interpretiert das gerenderte Bild. Das ist langsam und teuer: Ein Vision-Modell braucht dafür Sekunden und verbraucht Tokens, während das Auslesen des DOM in Millisekunden erledigt ist. Der Screenshot bleibt die Notlösung, wenn die Struktur unklar ist. Zweitens das HTML und den DOM‑Baum: Verschachtelung, Attribute, Datenfelder. Daraus liest der Agent, was zusammengehört, etwa dass ein „Kaufen”‑Knopf zu genau diesem Produkt zählt. Drittens den Accessibility Tree, die browsereigene Barrierefreiheits‑Ansicht. Sie reduziert die Seite auf das Wesentliche: Rolle, Name und Zustand jedes bedienbaren Elements, ohne das visuelle Rauschen von CSS. Für einen Agenten ist das die genaueste Karte, die Sie ihm geben können.

Moderne Agenten kombinieren diese Kanäle. Das Prinzip ist alt und heißt sonst Barrierefreiheit. Was einem Screenreader hilft, hilft auch der Maschine. Der Satz, mit dem Google den eigenen Leitfaden schließt, trifft es: Fast alles, was eine Seite für Agenten besser macht, macht sie auch für Menschen besser.

Warum das ein Architektur‑ und kein Content‑Problem ist

Die meisten reagieren auf „KI‑Sichtbarkeit” mit mehr Text. Neue Ratgeber, längere Seiten, noch ein Blogartikel. Beim Optimieren für Agenten hilft das wenig. Wenn Ihr „Termin buchen”‑Button in Wahrheit ein <div> ist, das per JavaScript klickbar gemacht wurde, dann erkennt der Agent keinen Button. Er sieht einen bedeutungslosen Kasten. Kein zusätzlicher Absatz ändert das. Es ist ein Struktur‑, kein Inhaltsproblem, und es wird an der falschen Stelle gelöst.

Deshalb sortiere ich die fünf Hebel unten nicht nach Aufwand, sondern nach Wirkung. Der teuerste Fehler ist, mit der Wunderdatei anzufangen und das Fundament zu überspringen.

Fünf Schritte zur agentenfähigen Website

<!-- So nicht: der Agent sieht nur einen bedeutungslosen Kasten -->
<div class="btn" onclick="buchen()">Termin buchen</div>

<!-- So: der Agent erkennt eine bedienbare Schaltfläche mit klarer Aktion -->
<button type="submit">Termin buchen</button>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Muster GmbH",
  "url": "https://www.muster.de",
  "sameAs": [
    "https://de.wikipedia.org/wiki/Muster_GmbH",
    "https://www.linkedin.com/company/muster-gmbh"
  ]
}
</script>

# Zitationsrelevante Abrufer zur Laufzeit zulassen
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: PerplexityBot
User-agent: Claude-User
Allow: /

# Trainings-Crawler bewusst und getrennt entscheiden
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
Disallow: /interner-bereich/

Die gemeinsame Rettungsleine ist das JSON-LD. Was eine Seite nicht server-rendert, kann sie darüber trotzdem an einen Agenten übergeben, aber nur die Fakten, die im Schema modelliert sind. Ein Crawler, der weder JavaScript ausführt noch JSON-LD liest, sieht bei Crocs ein Produkt ohne Preis. Die Lehre: Prüfen Sie jede Schicht einzeln. Gerendertes HTML, JSON-LD und der JavaScript-Blob sind drei verschiedene Dinge, und nur das Erste sieht ein einfacher Agent sicher.

Fünf Muster bremsen Agenten besonders zuverlässig aus:

Wann sich der volle Ausbau lohnt und wann nicht

Nicht jede Website braucht alle fünf Schritte. Die Schritte 1, 2 und 5, also sauberes HTML, geregelter Crawler‑Zugriff und ein Rendering ohne JavaScript‑Blockaden, sind das Fundament und lohnen sich immer. Sie kosten wenig und zahlen doppelt ein, für Menschen wie für Maschinen.

Schritt 4, die API für Aktionen, rechnet sich nur dort, wo Agenten tatsächlich transagieren sollen: Shops, Buchungsplattformen, Portale. Eine fünfseitige Broschüren‑Website braucht keine OpenAPI‑Spezifikation, und ein Berater, dessen Kunden ihn per E‑Mail kontaktieren, auch nicht. Und Schritt 3, die llms.txt, ist ein Sonderfall für dokumentationslastige Sites, kein Pflichtprogramm. Wer knappe Zeit hat, investiert sie zuerst ins Fundament, nicht in die Datei, die auf LinkedIn am meisten Aufmerksamkeit bekommt.

Ob sich die Arbeit auszahlt, sehen Sie nicht in Google Analytics, denn Agenten erzeugen keine klassischen Seitenaufrufe. Der Nachweis läuft über Server‑Logs, in denen Sie die KI‑Bots zählen, und über die Frage, ob die Modelle Sie am Ende zitieren. In Nginx- oder Apache-Logs suchen Sie dafür nach dem User-Agent, etwa nach einer Zeile wie dieser:

203.0.113.7 - - [28/Jul/2026:10:14:22 +0000] "GET /leistungen HTTP/1.1" 200 8123 "-" "Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)"

Ohne so eine Messung bleibt die Optimierung eine Vermutung, und Vermutungen sind kein Fundament.

Welcher Hebel zuerst zählt, hängt vom Geschäftsmodell ab

Das Fundament aus den Schritten 1, 2 und 5 gilt für jede Website. Welcher Hebel danach an erster Stelle steht, entscheidet das Geschäftsmodell. Wer für einen lokalen Handwerksbetrieb dieselbe Reihenfolge wählt wie für ein SaaS-Produkt, investiert an der falschen Stelle.

Die Regel dahinter ist simpel: Beginnen Sie mit der Schicht, in der Ihr Geschäft entsteht. Beim Dienstleister ist das die Auffindbarkeit, beim Shop der Preis, beim SaaS die Aktion, beim Publisher der Text. Alles andere folgt danach.

Häufige Fragen

Was ist der Unterschied zwischen SEO und der Optimierung für KI‑Agenten? Klassisches SEO zielt auf eine Position in einer Trefferliste. Die Optimierung für Agenten zielt darauf, dass eine Maschine Ihre Inhalte fehlerfrei liest und Aktionen ausführt. Das Fundament ist dasselbe: erreichbares HTML, saubere Struktur, klare Entitäten. Neu ist die Ebene der bedienbaren Elemente und der maschinenlesbaren Aktionen. GEO ersetzt SEO nicht, es baut darauf auf.

Muss ich eine llms.txt anlegen, um in KI‑Antworten zitiert zu werden? Nein. Google ignoriert die Datei für die Suche ausdrücklich, und die meisten llms.txt‑Dateien werden von keinem Bot abgerufen. Für dokumentationslastige Sites kann sie ein sinnvoller Wegweiser sein, für die meisten Websites bringt sauberes HTML und geregelter Crawler‑Zugriff deutlich mehr.

Reicht reines HTML, damit Agenten Formulare und Buchungen ausführen? Zum Lesen ja, zum zuverlässigen Handeln oft nicht. Sobald ein Agent eine Transaktion auslösen soll, ist eine dokumentierte API stabiler als das Parsen der Oberfläche. Für rein informative Seiten genügt sauberes, semantisches HTML.

Wie verhindere ich, dass Agenten meine öffentlichen Funktionen missbrauchen? Nicht über die robots.txt, die ist nur eine Bitte. Schützen Sie transaktionale Endpunkte mit Authentifizierung, API‑Schlüsseln und Rate‑Limits. Trennen Sie öffentlich lesbare Inhalte klar von Funktionen, die Kosten oder Buchungen auslösen.

Wie messe ich, ob KI‑Engines meine Seite tatsächlich nutzen? Über zwei Wege. In den Server‑Logs zählen Sie die Zugriffe der KI‑Bots wie OAI‑SearchBot, PerplexityBot oder ClaudeBot. Und Sie prüfen die Zitate direkt, indem Sie ChatGPT, Perplexity und Gemini die wichtigsten Kundenfragen stellen und mitzählen, wie oft Ihre Marke als Quelle auftaucht. Der Weg von „abgerufen” zu „zitiert” ist nicht garantiert, das eine folgt nicht automatisch aus dem anderen.

Fazit

Am Anfang stand das Bild vom Grundriss: Ein Agent sieht nicht Ihre Einrichtung, sondern die Struktur dahinter. Die gute Nachricht ist, dass der wirksamste Teil der Arbeit der unspektakulärste ist. Kein Trick, keine Wunderdatei, sondern <button> statt <div>, ein stabiler Zugriff über die robots.txt und ein Rendering, das ohne JavaScript auskommt. Eine Faustregel fasst es zusammen: Was ein Screenreader mühelos vorlesen und bedienen kann, kann auch der Agent. Prüfen Sie es selbst, heute noch: Öffnen Sie Ihre wichtigste Seite mit deaktiviertem JavaScript. Was jetzt noch zu lesen ist, sieht auch der Agent. Der Rest ist Ihr Grundriss, an dem Sie arbeiten sollten.

Quellen und Stand

• Google Chrome‑Team, „Agent‑freundliche Websites erstellen”, web.dev, Stand 1. April 2026: web.dev/articles/ai-agent-site-ux
• Google, Leitfaden zur Optimierung für generative KI‑Funktionen, mit dem Hinweis zu llms.txt vom 15. Juni 2026: developers.google.com/search/docs/fundamentals/ai-optimization-guide
• Google Search Central, Abschaffung der HowTo‑ und FAQ‑Rich‑Results, August 2023: developers.google.com/search/blog/2023/08/howto-faq-changes
• Ahrefs, Auswertung von rund 137.000 Websites mit llms.txt (97 Prozent ohne Bot‑Abruf): ahrefs.com/blog/llmstxt-study
• Jeremy Howard, llms.txt‑Spezifikation, September 2024: llmstxt.org
• Google Chrome, WebMCP (Early‑Preview‑Programm): developer.chrome.com/blog/webmcp-epp

Stand der Recherche: 28. Juli 2026.