Shops, Produkte, Websites müssen maschinenlesbar sein. Sonst kauft der Agent woanders.

Die Annahme hinter diesem Beitrag ist einfach: In wenigen Jahren entscheiden Agenten, was gekauft wird und wo. Ein Mensch sagt „Ich brauche bis Freitag zwanzig Steckdosenleisten mit Überspannungsschutz, Lieferung auf Rechnung“, und ein Programm sucht, vergleicht, bestellt. Dieses Programm sieht keine Startseite, kein Banner und keine Hero-Animation. Es liest Daten. Wer keine liefert, ist in diesem Vergleich nicht dabei. Nicht auf Platz zehn, sondern gar nicht.

Der Agent kauft nicht, was er nicht lesen kann

Ein Mensch, der einen Shop besucht, verzeiht viel. Er scrollt, wartet auf nachladende Inhalte, liest den Preis aus einer Grafik ab und findet den Bestellknopf, auch wenn er nur ein Symbol ist. Ein Agent verzeiht nichts davon. Er ruft die Seite ab, meist ohne Maus, häufig ohne JavaScript, immer mit einem Zeitlimit. Dann sucht er nach dem, was er für seine Aufgabe braucht: Produktname, Artikelnummer, Preis mit Währung und Steuer, Verfügbarkeit, Lieferzeit, Versandkosten, Rückgaberegel. Findet er diese Angaben als Text und am besten als strukturierte Daten, nimmt er den Artikel in den Vergleich auf. Findet er sie nicht, nimmt er den nächsten Anbieter.

Das ist keine Zukunftsmusik, sondern laufender Betrieb. ChatGPT bestellt bei angebundenen Händlern direkt im Chat, Perplexity und die KI-Browser kaufen auf Zuruf, Amazon lässt seinen Agenten auf fremden Seiten einkaufen. Die großen Plattformen haben 2025 und 2026 Protokolle veröffentlicht, die genau einen Zweck haben: einem Programm das Einkaufen bei beliebigen Händlern zu ermöglichen. Dazu unten mehr. Vorher die Grundlage, ohne die kein Protokoll etwas nützt.

Vier Ebenen der Maschinenlesbarkeit

Maschinenlesbar ist kein Schalter, den man umlegt, sondern vier Ebenen, die aufeinander aufbauen. Jede fehlende Ebene kostet einen Teil der Agenten, die Sie erreichen könnten.

Was ein Produkt für eine Maschine braucht

Die folgende Tabelle ist die Prüfliste, mit der wir Produktseiten abnehmen. Jede Zeile ist ein Feld, das ein Agent für Vergleich oder Kauf braucht. Die Spalte rechts sagt, wo das Feld stehen muss, damit die Maschine es findet.

So sieht der Datensatz eines Produkts aus, wie ihn ein Agent am liebsten vorfindet. Ein erfundener Artikel, die Felder sind echt:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Steckdosenleiste 8-fach mit Überspannungsschutz",
  "sku": "SL-8-UES",
  "gtin13": "4000000000001",
  "brand": {"@type": "Brand", "name": "Beispielmarke"},
  "image": "https://beispielshop.example/img/sl-8-ues.jpg",
  "offers": {
    "@type": "Offer",
    "price": "34.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "url": "https://beispielshop.example/steckdosenleiste-8-fach",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {"@type": "MonetaryAmount", "value": "4.90", "currency": "EUR"},
      "shippingDestination": {"@type": "DefinedRegion", "addressCountry": "DE"},
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "transitTime": {"@type": "QuantitativeValue", "minValue": 1, "maxValue": 3, "unitCode": "DAY"}
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "DE",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 14
    }
  }
}
</script>

Wer einen Shop auf Shopware, WooCommerce, Shopify oder einem eigenen System betreibt, hat einen Teil davon schon, meist Name, Preis und Verfügbarkeit. Lieferzeit, Versandkosten, Rückgabe und Varianten fehlen in der Praxis fast immer, und genau diese Felder entscheiden bei einem Agenten mit der Vorgabe „bis Freitag, auf Rechnung“ über den Zuschlag. Prüfen lässt sich jede Seite mit dem Schema Markup Validator.

Dieselbe Regel für Leistungen und Unternehmen

Was für ein Produkt gilt, gilt für eine Dienstleistung und für das Unternehmen dahinter. Ein Agent, der für einen Handwerksbetrieb jemanden sucht, der die Kasse an die Buchhaltung anbindet, braucht dieselben Antworten: Was wird gemacht, für wen, in welchem Gebiet, in welcher Zeit, zu welchen Bedingungen, wie wird beauftragt. Eine Leistungsseite, die das in drei Werbesätzen und einem Kontaktformular ohne Beschriftung erledigt, ist für den Agenten leer.

Die technische Form ist dieselbe: Leistungen als Service mit Gebiet, Anbieter und Beschreibung im JSON-LD, das Unternehmen als Organization mit Anschrift, Erreichbarkeit und Rechtsform, dazu eine llms.txt, die beschreibt, was die Seite bietet, und für Agenten eine Langfassung mit dem vollständigen Katalog. Wie wir das auf unserer eigenen Seite umgesetzt haben, steht weiter unten.

Die neuen Einkaufsprotokolle

Bis hierhin ging es ums Lesen. Die Plattformen wollen mehr: Der Agent soll bestellen und bezahlen, ohne die Oberfläche eines Shops zu bedienen. Dafür sind seit Herbst 2025 drei Protokolle entstanden, die Händler kennen sollten, auch wenn sie noch nichts davon einbauen.

• ACP, Agentic Commerce Protocol. Von OpenAI gemeinsam mit Stripe veröffentlicht. Der Händler liefert einen Produktfeed und eine Kassen-Schnittstelle, ChatGPT zeigt das Produkt und schließt den Kauf im Chat ab. Der Händler bleibt Verkäufer, verarbeitet die Zahlung selbst und bekommt die Bestellung wie jede andere.
• AP2, Agent Payments Protocol. Von Google mit Zahlungsdienstleistern vorgestellt. Es regelt die Frage, die alle Händler stellen: Woher weiß ich, dass dieser Agent im Auftrag eines echten Menschen bezahlen darf? Die Antwort sind signierte Mandate, in denen der Mensch vorab festlegt, was der Agent kaufen darf und bis zu welchem Betrag.
• UCP, Universal Commerce Protocol. Von Google mit Shopify, Etsy, Wayfair, Target, Walmart und weiteren Partnern entwickelt, inzwischen auch von Amazon, Microsoft, Meta und Stripe unterstützt. UCP bündelt Suche, Warenkorb, Kasse und Zahlung in einem Standard und setzt auf AP2, A2A und MCP auf. Der Händler bleibt ausdrücklich Vertragspartner und behält die Kundenbeziehung.

llms.txt, robots.txt und die Tür, die versehentlich zu ist

Die llms.txt ist eine Textdatei im Wurzelverzeichnis, die einem Sprachmodell in kurzer Form sagt, was die Seite ist und wo die wichtigen Inhalte liegen, mit Links auf die Langfassungen. Google wertet sie nach eigener Aussage nicht aus. Andere Systeme lesen sie, und für Agenten, die eine Seite zum ersten Mal besuchen, ist sie der schnellste Einstieg. Der Aufwand ist gering, der Nutzen wächst mit der Zahl der Agenten, die vorbeikommen.

Wichtiger als jede neue Datei ist die alte: robots.txt. Viele Shops sperren dort seit Jahren pauschal alles, was nicht Google oder Bing heißt. Das war gegen Kopierer gedacht und trifft jetzt die Einkäufer. Wer von Agenten gefunden werden will, muss die Crawler der KI-Anbieter zulassen, mindestens auf Produkt- und Leistungsseiten. Wer Inhalte verkauft statt Produkte, entscheidet anders. Beides ist legitim, nur versehentlich sollte die Tür nicht zu sein.

Die zweite Tür sitzt im CDN. Bei der Umstellung unserer eigenen Seite im Oktober 2026 blockierte die Browser-Integritätsprüfung des CDN jeden Abruf durch einfache Programme mit dem Fehler 1010, obwohl robots.txt alles erlaubte. Kein Agent hat uns das gemeldet, weil ein ausgesperrter Agent nichts meldet. Aufgefallen ist es nur, weil wir die Abrufe selbst nachgestellt haben. Die Lösung war eine Regel, die die Prüfung für die maschinenlesbaren Pfade abschaltet und für den Rest beibehält. Prüfen Sie Ihre Seite einmal so, wie ein Programm sie abruft, nicht nur im Browser.

Preise für Maschinen

Bei Produkten ist die Sache klar: Ohne Preis in den Daten kein Vergleich, ohne Vergleich kein Kauf. Bei Dienstleistungen stellt sich die Frage anders. Viele Anbieter nennen auf ihren Seiten bewusst keine Festpreise, weil jedes Projekt anders ist. Ein Agent, der für einen Betrieb drei Anbieter vergleichen soll, kommt damit nicht weiter und streicht den Anbieter ohne Angabe.

Der Ausweg ist ein Preisrahmen in den Maschinendateien: eine Spanne je Leistung in llms-full.txt und in einer Leistungsdatei im JSON-Format, die ein Agent abrufen kann. Die Seite für Menschen bleibt, wie sie ist. Eine Regel dabei ist nicht verhandelbar: Was in den strukturierten Daten im Quelltext steht, muss auf der Seite sichtbar sein. Google wertet Abweichungen zwischen JSON-LD und sichtbarem Inhalt als Verstoß. Preisrahmen gehören deshalb in die Agentendateien, nicht in das JSON-LD der Seite.

Selbsttest in zehn Minuten

Sechs Prüfungen, die zeigen, was ein Agent von Ihrer Seite hat. Keine davon braucht besondere Werkzeuge.

• Ohne JavaScript laden. Im Browser Skripte abschalten und die Produktseite aufrufen. Sind Preis, Verfügbarkeit und Bestellknopf noch da? Was fehlt, fehlt für die meisten Agenten.
• Quelltext lesen. Rechtsklick, Seitenquelltext anzeigen, nach application/ld+json suchen. Steht da ein Produkt mit Preis, Verfügbarkeit und Lieferzeit? Dann weiter zum Validator.
• Validator laufen lassen. Die Adresse der Produktseite in den Schema Markup Validator eintragen. Fehlende Pflichtfelder und Warnungen stehen danach schwarz auf weiß.
• robots.txt öffnen. Ihre Domain mit /robots.txt aufrufen. Steht da ein pauschales Disallow: / für alles außer Google? Dann sind die Einkäufer draußen.
• Einstiegsdateien abrufen. /sitemap.xml und /llms.txt aufrufen. Antwortet eine davon mit 404, fehlt dem Agenten die Landkarte.
• Kasse ohne Konto. Eine Testbestellung als Gast bis zur letzten Seite durchspielen, nur mit der Tastatur. Jede Stelle, an der ein Bild erkannt oder ein Rätsel gelöst werden muss, ist für einen Agenten das Ende.

Wie wir es bei uns gemacht haben

Wir haben netzhandwerker.de im Oktober 2026 selbst auf Maschinenlesbarkeit umgestellt, mit Messung vor und nach jedem Schritt. Der Ausgangsbefund war ernüchternd: Die llms-full.txt kannte rund ein Viertel der Seiten, die Leistungsdatei für Agenten listete fünf von über vierhundert Leistungen, die E-Mail-Adressen waren vom CDN verschleiert und für Programme unlesbar, und die Startseite trug ein doppeltes Menü im Quelltext, das jeden Abruf aufblähte.

• llms.txt: Kurzbeschreibung der Seite, die wichtigsten Einstiege, Verweise auf die Langfassung und die Datendateien.
• llms-full.txt: der vollständige Katalog aller 921 Seiten mit Titel und Beschreibung, aus demselben Index erzeugt wie die Sitemap.
• services.json: jede Leistung als Datensatz mit Name, Beschreibung, Adresse und Preisrahmen, abrufbar in einem Aufruf.
• company.json und agent.json: Unternehmensdaten und Angaben darüber, was ein Agent auf dieser Seite darf und wo er die Daten findet.
• JSON-LD auf jeder Leistungsseite als Service, auf jeder Ratgeberseite als Article, dazu Organization und BreadcrumbList ohne Lücken.
• Ein Zähler, der festhält, welche Agenten die Maschinendateien abrufen. Ob und wie oft das passiert, messen wir seit dem 19. Oktober 2026 und werten es Mitte November aus. Vorher gibt es dazu keine Zahl, und wir erfinden keine.

Die Umstellung hat nichts an der Seite für Menschen geändert. Sie hat eine zweite Seite daneben gestellt, die aus denselben Quellen gespeist wird und die ein Programm in Sekunden vollständig lesen kann.

Grenzen und offene Fragen

• Agenten irren. Ein Sprachmodell kann Preise verwechseln, Varianten vertauschen oder eine Rückgaberegel falsch lesen. Je klarer die Daten, desto seltener passiert das, aber ganz verschwinden wird es nicht. Bestellbestätigung und Widerruf müssen deshalb weiter funktionieren wie bei Menschen.
• Die Protokolle sind jung. ACP, AP2 und UCP ändern sich noch, und welcher Standard sich in Europa durchsetzt, ist offen. Wer heute baut, baut die Datengrundlage, nicht die Anbindung an ein bestimmtes Protokoll.
• Recht bleibt Recht. Preisangaben, Button-Lösung, Widerrufsbelehrung und Impressumspflicht gelten auch, wenn ein Agent bestellt. Ein Kauf über ein Protokoll ändert nichts an den Pflichten des Händlers.
• Nicht jeder will gelesen werden. Wer Inhalte verkauft, hat gute Gründe, Agenten zu beschränken. Die Entscheidung muss nur bewusst fallen, nicht durch eine vergessene Regel aus 2019.

Quellen

• schema.org: Product und Offer: Felder für Produkt, Angebot, Versand und Rückgabe
• Google Search Central: Strukturierte Daten für Produkte: Pflichtfelder und die Regel, dass Markup zum sichtbaren Inhalt passen muss
• Google Search Central: KI-Funktionen und Ihre Website: Hinweise zu Agenten, Struktur und llms.txt
• llmstxt.org: Vorschlag und Format der llms.txt
• OpenAI: Agentic Commerce Protocol: Produktfeed, Kassen-Schnittstelle, Ablauf im Chat
• AP2: Agent Payments Protocol: Mandate, Zahlung im Auftrag eines Menschen
• UCP: Universal Commerce Protocol: Partner, Aufbau auf AP2, A2A und MCP, Händler als Vertragspartner
• Cloudflare: Pay per crawl: Zugang für Crawler steuern und bepreisen
• Schema Markup Validator: Prüfwerkzeug für JSON-LD

Stand der Angaben: 21. Oktober 2026. Die Protokolle sind in Entwicklung, Partnerlisten und Spezifikationen ändern sich.

Wir bauen Shops und Websites als Unikate, bei denen die Daten für Agenten von Anfang an aus derselben Quelle kommen wie die Seite für Menschen, und wir rüsten bestehende Shops mit Produktdaten, Einstiegsdateien und einer bedienbaren Kasse nach. Mehr dazu unter Onlineshop erstellen lassen und Webseite erstellen lassen. Die Grundlagen zum Lesen von Websites durch Agenten stehen im Beitrag Webseiten bauen 2026: Ihre nächsten Besucher sind KI-Agenten, die Bezahlung zwischen Maschinen im Beitrag Maschinen bezahlen Maschinen.

Anfrage senden