Ein Kunde rief mich letzten Oktober an, in Panik. Seine E-Commerce-Website bekam ein Riesiges Aufkommen an Traffic von dem, was sein Analytics als „direkter" Besuch zeigte, aber Conversions waren gesunken. Nach etwa einer Stunde Analyse der Server-Logs erkannte ich, dass ein großer Teil dieses Traffics überhaupt keine Menschen waren. Es waren KI-Agenten, speziell Einkaufsassistenten und LLM-gestützte Vergleichstools, die seine Produktseiten crawlten und absprangen, weil sie die Inhalte nicht richtig analysieren konnten. Die strukturierten Daten waren ein Durcheinander. Preise waren in JavaScript vergraben. Produktnamen waren in <h3>-Tags, die wie <h2>-Tags gestaltet waren. Die Agenten kamen an, fanden Chaos vor und verließen die Seite.
Das ist, wo wir jetzt sind. KI-Agenten kommen nicht. Sie sind bereits hier, lesen bereits Ihre Websites, treffen bereits Entscheidungen basierend auf dem, was sie extrahieren können oder nicht. Und die meisten der 12.000+ Websites, die ich im Laufe der Jahre bei Seahawk gebaut oder bearbeitet habe, wurden mit diesem Gedanken nicht entwickelt. Ihre wahrscheinlich auch nicht.
Was „Agent-freundlich" wirklich bedeutet
Lassen Sie mich etwas klipp und klar sagen. Agent-freundlich bedeutet nicht „KI-freundlich" im vagen Marketing-Sinne. Es bedeutet, dass eine Maschine bei einer URL ankommen kann, den Inhalt parsen kann, ohne drei Ebenen von JavaScript auszuführen, das gesuchte Element extrahieren kann und darauf reagieren kann. Das ist alles.
Menschen sind nachsichtig. Wir scannen. Wir schlussfolgern. Wir sehen eine große Zahl auf einer Pricing-Seite und wir wissen, dass es der Preis ist, auch wenn er in einem <div class="fancy-number"> eingewickelt ist. Ein KI-Agent, der einen strukturierten Workflow befolgt? Nicht so nachsichtig. Er benötigt Signale, Hierarchie und Vorhersagbarkeit.
Die Agenten, die diese Arbeit gerade ausführen, sind unter anderem OpenAIs Browsing-Tool, Perplexitys Online-Modus und Dutzende von Custom-Agenten, die mit Frameworks wie LangChain und AutoGen gebaut werden. Sie alle haben einen gemeinsamen Bedarf: sauberes, parsbares, semantisch aussagekräftiges HTML mit unterstützten strukturierten Daten.
Das eigentliche Problem: JavaScript-First-Architektur
Das sehe ich am häufigsten. Agenturen und Freelancer bauen Websites auf React oder Next.js (oder Vue oder Svelte, meinetwegen), sie machen Client-Side-Rendering und sehen die Arbeit als erledigt an. Die Website sieht wunderschön aus. Google kann sie mehr oder weniger crawlen, weil Googlebot jetzt einen Headless-Chrome-Renderer eingebaut hat.
Aber die meisten KI-Agenten führen keinen Headless Chrome aus. Sie rufen rohes HTML über HTTP ab. Wenn dein Inhalt erst nach der Ausführung von JavaScript vorhanden ist, bekommen diese Agenten eine leere Seite oder einen Lade-Spinner, der als Text serialisiert ist.
Zurück 2022 hatte Seahawk einen Fintech-Client, der seinen gesamten Kurse- und Produktvergleichsbereich in einer React-SPA gebaut hatte. Kein SSR, kein Static Fallback. Wir führten einen einfachen curl gegen ihre URL aus und bekamen buchstäblich 14 Zeilen HTML: ein <div id="root"> und einige Script-Tags. Das ist das, was ein Agent sieht. Vierzehn Zeilen.
Die Lösung ist nicht unbedingt, dein JS-Framework aufzugeben. Es ist Server-Side-Rendering (SSR) oder Static-Site-Generation (SSG). Next.js mit getServerSideProps oder getStaticProps. Nuxt für Vue. SvelteKit. Oder einfach wichtige Seiten mit etwas wie Prerender.io vorab rendern, wenn du in einem Legacy-Setup steckst. Der Inhalt muss in der initialen HTML-Payload vorhanden sein.
Semantisches HTML ist nicht mehr optional
Ich weiß. Du hörst seit 2009 „nutze semantisches HTML". Aber ich sage das nicht aus SEO-Gründen. Ich sage es, weil Agenten semantische Tags nutzen, um zu verstehen, welche Art von Ding sie sich anschauen.
<article>, <nav>, <main>, <aside>, <header>, <footer> – das sind nicht dekorativ. Das sind Signale. Ein Agent, der den Hauptinhalt einer Seite extrahieren versucht, wird zuerst nach <main> suchen. Wenn du dein Layout mit verschachtelten <div>s und sonst nichts gebaut hast, muss der Agent raten. Agenten, die schlecht raten, geben Benutzer falsche Antworten zurück.
Das prüfe ich jetzt auf jeder Website:
- Gibt es genau ein <main>-Element pro Seite?
- Folgen Überschriften einer logischen Hierarchie (<h1> zu <h2> zu <h3>) ohne Ebenen zu überspringen?
- Befinden sich Navigationsmenüs in <nav>-Elementen?
- Befindet sich ergänzender Inhalt (Sidebars, verwandte Beiträge) in <aside>?
- Sind Listen von Elementen tatsächlich <ul> oder <ol>, nicht eine Reihe von <div class="item">s?
Das klingt nach grundlegenden Dingen. Und doch würde ich sagen, dass 60% der WordPress-Seiten, die ich überprüfe, mindestens drei davon nicht erfüllen. Die Überschriftenhierarchie ist fast überall das Problem – Designer stylen <h3>s groß und <h2>s klein und niemand repariert das Markup darunter.
Schema Markup: Leisten Sie hier die echte Arbeit
Hier werden die meisten Leitfäden generisch. Ich versuche es besser zu machen.
Schema.org strukturierte Daten teilen Agenten nicht nur mit, was auf der Seite steht, sondern auch, um welche Art von Ding es sich handelt. Ein Produkt. Ein Rezept. Ein lokales Unternehmen. Eine FAQ. Ein Event. Und sie liefern diese Daten in einem Format, das Agenten konsumieren können, ohne Prosa zu analysieren.
Die Typen, die gerade am meisten zählen, nach meiner Erfahrung:
- Produkt (mit Angeboten, Preis, Verfügbarkeit – alle drei, immer)
- LocalBusiness (mit openingHoursSpecification und Geokoordinaten, nicht nur eine Adresszeichenkette)
- Article (mit datePublished, dateModified und author als Person-Typ, nicht als einfache Textzeichenkette)
- FAQPage (mehr dazu weiter unten)
- BreadcrumbList (unterschätzt, gibt Agenten eine Karte deiner Website-Hierarchie)
- HowTo (wenn du Tutorials oder Prozessdokumentation veröffentlichst)
Für WordPress-Websites nutze ich Yoast SEO oder Rank Math für die Grundlagen, dann erweitere ich manuell mit Custom-Schema in einem <script type="application/ld+json"> Block für alles, das diese nicht abdecken. JSON-LD ist das Format, das man verwenden sollte. Nicht RDFa, nicht Microdata. JSON-LD. Es hält das Markup sauber und Agenten können es greifen, ohne deine Präsentationsschicht zu berühren.
Ein Fehler, den ich 2021 machte: Ich platzierte Schema auf den Produktseiten eines Kunden, ließ aber das price-Feld leer, weil ihre Preise „auf Anfrage" waren. Der Schema-Validator akzeptierte es. Aber Agenten extrahierten einen leeren Preis und gaben ihn Nutzern als „price: unknown" zurück, was Vertrauen zerstörte. Die Lösung war entweder eine realistische Preisspanne mit minPrice / maxPrice einzufügen oder den offers-Block vollständig zu entfernen. Teilweise Daten können schlimmer sein als gar keine Daten.
Content-Struktur: Schreib scanbar für die Extraktion
Hier ist die Sache mit der Art, wie Agenten Prosa lesen. Sie lesen sie nicht wie du. Sie suchen nach Antworten auf Fragen, Fakten, die herausgegriffen werden können, und klare Beziehungen zwischen Aussagen.
Das bedeutet, dass deine Inhaltsstruktur die Antwort an den Anfang stellen sollte. Wenn jemand (oder etwas) fragt „wie lange dauert die Lieferung?", sollte deine Seite eine Überschrift haben, die etwa „Lieferzeiten" lautet, und der erste Satz darunter sollte die tatsächliche Zahl angeben. Nicht einen Absatz Kontext über deine Lagerverwaltung. Die Zahl zuerst, dann der Kontext.
Ich habe angefangen, Inhalte auf Client-Seiten auf diese Weise zu strukturieren, fast wie eine umgekehrte Pyramide für jeden Unterabschnitt:
- Gib die Tatsache oder Antwort direkt im ersten Satz unter der Überschrift an
- Füge ein oder zwei Sätze unterstützendes Kontext hinzu
- Verlinke auf eine tiefergehende Ressource, wenn das Thema das rechtfertigt
Das war's. Keine einleitenden Absätze. Kein „großartige Frage, lassen Sie uns dieses Thema gemeinsam erforschen." Agenten überspringen diesen Lärm und identifizieren manchmal falsch, wo die echte Antwort beginnt.
Bei einer Reiseseite, die wir letzten Frühling umgebaut haben, haben wir über etwa sechs Wochen 80 Artikel auf diese Weise umstrukturiert. Perplexity-Zitierungen für diese Seiten sind deutlich gestiegen. Wichtiger noch: Die Antworten, auf die diese Zitierungen hinwiesen, waren tatsächlich korrekt, weil die relevante Tatsache auffindbar war.
Robots.txt, llms.txt und Zugriffskontrolle
Das ist neu. Es gibt eine wachsende Konvention, noch kein Standard, für eine Datei namens llms.txt, die im Root-Verzeichnis deiner Domain platziert wird. Die Idee, von Jeremy Howard vorgeschlagen, besteht darin, LLMs eine Klartextkarte der wichtigsten Inhalte deiner Seite und eventueller Zugriffspräferenzen zu geben. Stell dir das wie eine robots.txt vor, aber in einfachem Englisch für Language-Model-Agenten statt für Crawl-Bots geschrieben.
Solltest du sie implementieren? Ehrlich gesagt, ja. Es dauert 20 Minuten, eine zu schreiben. Es signalisiert, dass deine Seite agent-aware ist, und je mehr Agenten trainiert werden, danach zu suchen, desto mehr wird es zu einem aussagekräftigen Signal.
Bei robots.txt speziell: sei bewusst vorgehen. Manche Website-Betreiber blockieren reflexartig jetzt alle KI-Crawler. Das ist deine Entscheidung, aber pauschales Blockieren bedeutet, dass dein Content auch nicht in KI-generierten Antworten erscheint – das ist ein Verteilkanal, auf den du verzichtest. Denk daran genauso, wie du 2005 über das Blockieren von Googlebot nachgedacht hast. Wahrscheinlich keine gute Idee.
Interne Verlinkung und Crawl-Architektur
Ein Agent, der einen Workflow befolgt, landet nicht einfach auf einer Seite. Er folgt Links. Die Qualität deiner internen Verlinkungsstruktur bestimmt, wie viel deiner Website ein Agent tatsächlich durchsuchen und verstehen kann.
Schlechte interne Verlinkung bedeutet, dass Agents eine oder zwei Seiten deiner Website indexieren und dann aufhören. Sie bekommen kein vollständiges Bild davon, was du anbietest.
Gute interne Verlinkung bedeutet:
- Jede wichtige Seite ist von der Startseite aus innerhalb von drei Klicks erreichbar
- Anchor-Text ist aussagekräftig, nicht „hier klicken" oder „weiterlesen"
- Verwandte Inhalte sind kontextuell im Text verlinkt, nicht nur in einem Widget in der Seitenleiste
- Verwaiste Seiten existieren nicht (oder falls doch, weißt du davon und hast dich bewusst dafür entschieden, sie so zu lassen)
Ich führe Screaming Frog Crawls auf Kunden-Websites durch, bevor ich mit der Agent-Readability-Arbeit beginne. Der Bericht über verwaiste Seiten allein offenbart normalerweise Content, den Kunden für veröffentlicht und auffindbar halten, aber nicht. Ein Kunde hatte 34 verwaiste Seiten, einschließlich seiner Hauptcase Studies. Niemand verlinkte darauf. Nicht Agents, nicht Menschen.
FAQ
Muss ich meine gesamte Website umstrukturieren, damit sie von Agenten lesbar ist?
Nein. Beginnen Sie mit Ihren Seiten mit dem höchsten Traffic und Ihren konversions-kritischen Seiten. Das sind normalerweise Ihre Homepage, Ihre Haupt-Service- oder Produktseiten und alle Inhalte, die derzeit ranken und Leads generieren. Machen Sie diese zunächst richtig. Ein vollständiges Website-Audit ist irgendwann sinnvoll, aber es ist nicht der Anfang.
Hilft Schema-Markup tatsächlich bei den Antworten von KI-Agenten?
Nach dem, was ich auf Client-Websites beobachtet habe, ja. Agenten, die strukturierte Daten extrahieren, geben genauere Antworten und führen Quellen zuverlässiger an, wenn Schema vorhanden ist. Allerdings ist das kein magischer Schalter. Der zugrunde liegende Inhalt muss dennoch genau und gut strukturiert sein. Schema hilft Agenten, die Daten zu finden und zu vertrauen; es behebt keine fehlerhaften Daten.
Was ist mit Websites mit bezahlten Inhalten?
Verwenden Sie die isAccessibleForFree-Schema-Eigenschaft auf Ihrem Article-Typ und das hasPart/isPartOf-Muster, um zu kennzeichnen, welche Abschnitte bezahlt sind. Dies teilt Agenten mit, was sie verwenden dürfen. Googles Dokumentation zu strukturierten Daten für bezahlte Inhalte behandelt dies klar, und die gleiche Logik gilt für Nicht-Google-Agenten.
Wird llms.txt bereits weit verbreitet unterstützt?
Nicht universell. Aber die Implementierung kostet fast nichts, und frühzeitige Adoption solcher Konventionen zahlt sich normalerweise aus. Ich habe es seit Anfang 2024 zu Seahawk-Client-Sites hinzugefügt. Es ist jetzt ein kleines Signal. Es wird in 12 Monaten wichtiger.
Wie teste ich, ob ein Agent meine Website lesen kann?
Starten Sie mit curl -A "Mozilla/5.0" [your URL] in einem Terminal und schauen Sie, was zurückkommt. Wenn Ihr Hauptinhalt nicht in dieser Ausgabe vorhanden ist, haben Sie ein Rendering-Problem. Führen Sie dann Ihre Seiten durch Google's Rich Results Test durch, um das Schema zu validieren. Und überprüfen Sie die Chrome Lighthouse Accessibility-Prüfung, denn Agent-Lesbarkeit und Barrierefreiheit überlappen sich stärker als die meisten Menschen realisieren.
---
Das Web wurde für Menschen gebaut und dann für Suchmaschinen nachgerüstet. Jetzt braucht es eine weitere Umrüstung – diesmal für Agenten, die nicht so browsen wie irgendein Mensch. Das ist keine Krise. Es ist einfach die nächste Runde Arbeit. Und ehrlich gesagt ist das meiste gute Praxis, die Websites auch für Menschen besser macht. Sauberes Markup, klarerer Inhalt, weniger JavaScript-Wildwuchs. Sie hätten es wahrscheinlich ohnehin tun sollen.