AI-Suchbereitschaft

---

name: ai-search-readiness description: Was eine kommerzielle Website veröffentlichen muss, damit sie von KI-Suche und Buchungsagenten genutzt werden kann. Einsetzbar auf jeder Kundenseite, die kostenpflichtige Dienstleistungen anbietet oder Buchungen entgegennimmt. Umfasst die drei Schritte: Preisspanne veröffentlichen, Terminplanung agententauglich mit echtem Schema machen und echte Kundenfragen für Inhalte nutzen. Ausgelöst durch Preisseiten, Buchungsseiten, Dienstleistungsseiten, Schema-Arbeit und jede Frage, ob KI die Website finden oder Transaktionen durchführen kann.

KI-Suchbereitschaft (AI Search Readiness)

Drei Schritte. Sie befassen sich nicht mit der Inhaltsqualität, die durch non-commodity-content geregelt wird. Sie befassen sich damit, ob die Website von einer Maschine, die für einen Kunden handelt, gefunden, mit einem Preis zitiert und für Transaktionen genutzt werden kann.

Eine Website kann alle Inhaltsregeln erfüllen und dennoch für einen Agenten unsichtbar sein, weil sie nie eine Zahl veröffentlicht und nie einen Buchungsendpunkt offengelegt hat, den eine Maschine lesen kann.

---

Schritt 1: Preisspanne veröffentlichen

Die Regel. Jede kommerzielle Website veröffentlicht, was ihre Dienstleistung kostet. Kein Preisbuch. Eine Spanne mit den beiden Enden und den Faktoren, die den Betrag zwischen ihnen bewegen.

Leute fragen KI ständig, was Dinge kosten. Eine KI, die nichts zum Zitieren hat, schickt sie zu einem Konkurrenten, der etwas veröffentlicht hat. „Preis auf Anfrage“ ist eine Sackgasse für eine Maschine und zunehmend auch für einen Menschen.

Was mindestens zu veröffentlichen ist:

• das untere Ende und das obere Ende als konkrete Zahlen
• was es bewegt: die zwei bis drei Variablen, die bestimmen, wo in der Spanne ein Auftrag landet
• das Datum, an dem die Spanne gemessen wurde, neben den Zahlen
• jede Pauschalgebühr vollständig: Lieferung, Einrichtung, Anzahlung, Reinigung, Mindestbeträge, Strafen
• ein Link zur Live-Quelle für ein genaues Angebot

Der Einwand und die Antwort. Betreiber sträuben sich, weil Preise schwanken und sie befürchten, an einem veralteten Wert festgehalten zu werden. Dieser Einwand bezieht sich auf einen einzelnen Festpreis, der als der Preis dargestellt wird. Er ist kein Argument gegen eine Spanne. Eine datierte Spanne mit benannten Einflussfaktoren ist genauer als Schweigen, und sie ist das, was der Betreiber als Einziger angeben kann.

Die Regel, die das löst. Veröffentliche niemals einen blanken Tarif. Veröffentliche stattdessen:

Die Übernachtungspreise liegen zwischen 106 € und 175 € je nach Fahrzeug, gemessen am 18. September 2026. Welcher Wohnwagen und welche Daten bestimmen, wo du landest. Prüfe deine Daten für den genauen Preis.

Nicht:

Wohnwagen ab 106 €/Nacht.

Gib einen Preis niemals zweimal ein. Lies ihn aus der Quelle, die das Unternehmen bereits pflegt, zur Build-Zeit: dem Feed der Buchungsplattform, dem POS, der veröffentlichten Gebührentabelle. Ein Preis, der in eine Seite getippt wird, ist ein Preis, der innerhalb eines Monats nicht mehr mit dem Checkout übereinstimmt. Wo die Zahl aus der eigenen Seite des Betreibers geparst wird, können die beiden nie abweichen.

Wo ein Tarif wirklich nicht veröffentlicht werden kann (er wird pro Auftrag angeboten oder von einem Dritten festgelegt), schuldet die Seite dem Leser dennoch alles Angrenzende, das feststeht: die Gebührentabelle, die Mindestbeträge, die Anzahlung, die Strafe für eine Buchungsänderung. Dann sage klar, dass der Tarif selbst erst im Angebot festgelegt wird, und verweise darauf. Eine Seite, die sagt „wir veröffentlichen X nicht, hier ist der Grund, hier ist, wo du es bekommst, und hier ist alles, was sich nicht bewegt“, ist besser als eine Seite, die nichts sagt.

Vor der Veröffentlichung für jede Preisseite prüfen:

• Beide Enden der Spanne sind echte Zahlen, nicht „ab“
• Die Einflussfaktoren, die den Preis bewegen, sind benannt
• Das Messdatum steht neben den Zahlen
• Jede Pauschalgebühr ist vollständig veröffentlicht
• Die Zahlen werden zur Build-Zeit aus einer Quelle gelesen, nicht getippt
• Strukturierte Daten enthalten dieselben Zahlen wie der Fließtext (siehe Schritt 2)
• Wo etwas nicht bepreist werden kann, sagt die Seite das und verweist auf das Angebot

---

Schritt 2: Agententaugliche Terminplanung

Die Regel. Wenn der Agent eines Kunden nicht sehen kann, wie er mit dem Kalender Transaktionen durchführen kann, ist das Unternehmen für ihn unsichtbar. Agentisches Buchen ist Realität: Ein Assistent bucht einen Tisch, einen Serviceanruf, einen Mietwagen. Er greift zuerst nach strukturierten Daten und dann nach dem DOM.

Drei Ebenen, alle erforderlich.

1. Das Angebot, in strukturierten Daten. Jede buchbare Sache trägt ein Offer mit einem echten Preis oder einer priceSpecification-Spanne, einer Währung, einem Verfügbarkeitsstatus und einem priceValidUntil, das dem Messdatum entspricht. Ein priceRange auf dem Unternehmen ist nicht genug; die Maschine will das Angebot auf dem Gegenstand, den sie buchen soll.

"offers": {
  "@type": "Offer",
  "priceCurrency": "EUR",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceCurrency": "EUR",
    "minPrice": 106,
    "maxPrice": 175,
    "unitCode": "DAY",
    "referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
  },
  "availability": "https://schema.org/InStock",
  "priceValidUntil": "2026-12-31",
  "url": "https://example.com/book"
}

2. Die Aktion. Die Entität trägt eine potentialAction, die den Buchungsendpunkt, das HTTP-Ziel und die erforderlichen Eingaben benennt. Dies ist der Teil, den fast niemand veröffentlicht und den ein Agent tatsächlich benötigt.

"potentialAction": {
  "@type": "ReserveAction",
  "name": "Diesen Wohnwagen buchen",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
    "actionPlatform": [
      "https://schema.org/DesktopWebPlatform",
      "https://schema.org/MobileWebPlatform"
    ],
    "httpMethod": "GET"
  },
  "result": { "@type": "Reservation", "name": "Wohnwagen-Mietreservierung" },
  "object": { "@type": "Product", "name": "2023 Jayco Jay Flight" }
}

Wähle den Aktionstyp, der zum Verb passt: ReserveAction für eine Buchung oder Reservierung, ScheduleAction für einen Termin, OrderAction für einen Kauf, RsvpAction für ein Event.

3. Die Einschränkungen, als Daten, nicht als Fließtext. Ein Agent, der einen Aufenthalt bucht, den das Unternehmen nicht einhalten kann, hat die Zeit aller verschwendet. Veröffentliche die Regeln, die eine Buchung scheitern lassen würden:

• Mindest- und Höchstdauer
• Vorlaufzeit und Sperrfrist (availabilityStarts, advanceBookingRequirement)
• Berechtigung (Mindestalter, Führerschein, Anzahlung)
• Servicegebiet (areaServed) und was es kostet, jeden Teil davon zu erreichen
• Öffnungs- oder Lieferfenster, wo die Ankunftszeit durch jemand anderen eingeschränkt ist

Setze jedes davon in Schema, wo eine Eigenschaft existiert, und in klaren Sätzen auf der Seite, wo nicht. Beides, immer: Der Agent liest eines, die Person liest das andere, und sie müssen übereinstimmen.

Agentenlesbare Darstellung. Kritisches Content servergerendert, semantisches HTML, echte Überschriften, Alt-Texte, Tabellen als <table>. Ein Agent liest das DOM und den Accessibility-Baum. Inhalte, die erst nach einem clientseitigen Fetch erscheinen, sind Inhalte, die der Agent nicht gesehen hat.

Gib keine Fähigkeiten vor, die nicht existieren. Veröffentliche nur eine ReserveAction für einen Endpunkt, der tatsächlich eine Buchung entgegennimmt. Eine Aktion, die auf ein Kontaktformular verweist, ist eine Lüge, auf die ein Agent reagieren wird, und der Kunde erfährt es im ungünstigsten Moment. Wo Buchungen tatsächlich telefonisch erfolgen, veröffentliche die Telefonnummer im Schema und keine Reserve-Aktion.

Die Protokollebenen und welche man zuerst umsetzt

Es gibt drei Ebenen. Sie sind keine Alternativen, sie stapeln sich, und die Reihenfolge ist wichtig, weil die unteren heute gelesen werden und die oberen größtenteils noch nicht.

Ebene 1: Strukturierte Daten (diese zuerst bauen, immer). Offer plus potentialAction wie oben. Dies ist das, was heutige Assistenten tatsächlich konsumieren, wenn sie eine Frage zu einem Unternehmen beantworten und wenn sie einem Link zur Aktion folgen. Es kostet eine Seite JSON-LD und funktioniert sofort.

Ebene 2: Ein maschinenlesbarer Feed. Eine stabile JSON-URL, die den Katalog enthält: was gemietet oder verkauft werden kann, der Preis von jedem, die Einschränkungen, die Buchungs-URL und das Datum der Messung. Keine Protokollverpflichtung, kein zu verteidigender Endpunkt, lesbar für jeden Agenten, Crawler oder jede Schwester-Website. Günstig und das, was Ebene 3 später zu einer kleinen Aufgabe macht.

Ebene 3: A2A (Agent2Agent). Das offene Protokoll zur Agent-zu-Agent-Aufgabendelegation: eine Agentenkarte unter einer bekannten URL, die die Identität, Fähigkeiten und Authentifizierung des Agenten beschreibt, und ein Endpunkt, der JSON-RPC über HTTPS spricht und Aufgaben entgegennimmt und Ergebnisse zurückgibt. Es ist die richtige Antwort, wenn der Assistent eines Kunden in der Lage sein sollte, Fragen zu stellen und Antworten zu erhalten, anstatt eine Seite zu lesen.

Sei ehrlich, wo es steht. Ende 2026 gibt es kein Verzeichnis, das Verbraucherassistenten routinemäßig nach Agentenkarten durchsuchen. Eine solche zu veröffentlichen ist daher eine Wette auf die Entdeckung, keine Quelle für Buchungen in diesem Quartal. Baue sie, wenn das Unternehmen etwas hat, das ein Agent wirklich fragen muss, das ein statischer Feed nicht beantworten kann, typischerweise Live-Verfügbarkeit.

Die Ehrlichkeitsregel gilt hier am strengsten. Eine Agentenkarte deklariert Fähigkeiten, und ein anderer Agent wird sie aufrufen. Deklariere nur, was der Endpunkt tatsächlich kann. Die meisten kleinen Betreiber können eine Buchung überhaupt nicht Agent-zu-Agent abschließen, weil Zahlung, Versicherung und der Mietvertrag innerhalb einer Drittanbieterplattform sitzen. Das ist in Ordnung, und die Karte sollte es sagen:

{
  "name": "Example Rentals Buchungsassistent",
  "description": "Beantwortet Verfügbarkeits- und Preisfragen für eine Fahrzeugflotte. Kann keine Zahlungen entgegennehmen.",
  "skills": [
    { "id": "check-availability", "description": "Welche Einheiten sind zwischen zwei Daten frei" },
    { "id": "quote-stay", "description": "Gesamtpreis für eine Einheit und Daten, inklusive Lieferung pro Stadt" }
  ],
  "capabilities": { "streaming": false, "pushNotifications": false }
}

Eine Karte, die eine book-stay-Fähigkeit behauptet, die in einer Weiterleitung endet, ist der gleiche Fehler wie eine ReserveAction, die auf ein Kontaktformular verweist, nur mit einer Maschine auf der anderen Seite statt einer Person.

Zahlungen. Agentische Zahlungsschienen (AP2 als A2A-Erweiterung und die konkurrierenden agentischen-Commerce-Spezifikationen) entwickeln sich schnell und werden von den meisten Buchungsplattformen nicht unterstützt. Gestalte keinen Checkout um sie herum. Übergib an den eigenen Checkout der Plattform und sage das in der Karte.

Vor der Veröffentlichung für jede buchbare Seite prüfen:

• Offer mit Preis oder Preisspanne, Währung, Verfügbarkeit, priceValidUntil
• potentialAction mit einem echten EntryPoint, den ein Agent aufrufen kann
• Die Parameter der URL-Vorlage der Aktion sind die, die das Buchungssystem tatsächlich erwartet
• Mindestbeträge, Vorlaufzeiten, Berechtigung und Servicegebiet sind als Daten und als Fließtext veröffentlicht
• Jede Zahl im Schema stimmt mit der Zahl im Text überein
• Die Seite rendert ihre Buchungsinformationen serverseitig
• Es wird keine Aktion für eine Fähigkeit veröffentlicht, die nicht existiert

---

Schritt 3: Inhalte aus echten Fragen

Die Regel. Die Fragen, die Kunden tatsächlich stellen, sind die Inhalte. Jedes Telefonat, jede E-Mail, jede „vor der Buchung“-Frage ist eine Seite oder ein Abschnitt, der öffentlich beantwortet wird, in den eigenen Worten des Kunden.

Die eigene Anleitung von Google besagt, dass allgemeine Ratschläge („7 Tipps für den Sommer“) nicht gewinnen. Was gewinnt, ist hyperspezifisch und real. Die Frage, die ein Kunde heute Morgen gestellt hat, ist beides, konstruktionsbedingt, weil ein Wettbewerber, der aus öffentlichen Quellen schreibt, nicht weiß, dass sie gestellt wurde.

Die operative Gewohnheit:

1. Halte die Frage wörtlich fest. Die Formulierung des Kunden, nicht Branchenjargon. „Können Sie es bei mir zu Hause abgeben, während sie das Dach reparieren“ ist die Suchanfrage. „Logistik der Wohnortplatzierung“ ist es nicht. Dies ist die gleiche Regel wie das Schreiben des Hauptnomens des Suchenden.
2. Beantworte sie dort, wo der Leser sie hat. Auf der Seite, auf der die Frage aufkommt, nicht in einem Blogbeitrag, den niemand erreicht.
3. Beantworte sie mit einer Quelle. Eine Antwort ohne Quelle ist eine Meinung; es ist die Pauschalgebühr, die veröffentlichte Regel, die gemessene Zahl, die es wert macht, zitiert zu werden.
4. Sage, wenn die Antwort nicht deine ist. Wo die Antwort einem Dritten gehört, einem Rat, einer Versicherung, einem Park, sage das und nenne, wen du fragen sollst. Dieser Satz ist ein Vermögenswert.
5. Führe eine Liste dessen, was nur der Betreiber weiß. Jedes Projekt führt eine Datei mit offenen Fragen. Diese Antworten sind die Inhalte, die niemand kopieren kann, und die Datei ist die Gesprächsagenda für das Interview.

FAQ-Blöcke sind für Leser, mit FAQPage-Auszeichnung, weil sie klar sagen, was die Seite beantwortet. Sie sind nicht der Hebel, der Zitate einbringt. Ersthaftigkeit aus erster Hand ist es.

---

Wie die drei Schritte zusammenspielen

Ein Leser gelangt von einer KI-Antwort, die die Preisspanne zitiert hat. Die Seite bestätigt die Zahl, benennt, was sie bewegt, und beantwortet die Frage, die er tatsächlich hatte. Sein Agent bucht dann, weil das Angebot und die Aktion als Daten veröffentlicht wurden.

Fehlt einer, reißt die Kette. Eine Website mit großartigen Inhalten und keinem veröffentlichten Preis wird nicht zitiert. Eine Website mit einem Preis und keiner Aktion kann nicht für Transaktionen genutzt werden. Eine Website mit beidem und generischen Inhalten ist es nicht wert, überhaupt zitiert zu werden.

Quellen

1. Danny Sullivan Keynote, Google Search Central Live Toronto, April 2026, zu Non-Commodity Content.
2. AI Optimization Guide, Google Search Central, zur Agenten-Lesbarkeit und Query-Fan-Out.
3. schema.org Offer, UnitPriceSpecification, ReserveAction, EntryPoint.
4. A2A (Agent2Agent)-Protokoll, Linux Foundation, für die Agentenkarte und die JSON-RPC-Aufgabenschnittstelle.