Händlerautorisierung im KI-Zeitalter: Schema.org, llms.txt oder security.txt?

Müllermilch bekommst Du in jedem Supermarkt, an jeder Tankstelle und in fast jedem Onlineshop. Einen neuen BMW kaufst Du beim autorisierten Händler. Im Autohaus erkennst Du das am Schild über der Tür. Online gibt es kein solches Schild, und niemand kontrolliert das zentral. Jeder Shop kann “autorisierter Fachhändler” in seinen Footer schreiben.

Deshalb gibt es authorized.by. Dort bestätigen Marken, welche Händler zu ihrem offiziellen Vertriebsnetz gehören. Die Händler bekommen ein Siegel, das sich überprüfen lässt. Gegründet hat das Unternehmen Felix Nottensteiner.

Felix kenne ich auch von der anderen Seite des Tisches: Er ist Kunde bei hosting.de, nutzt verschiedene unserer Technologien und ist damit zufrieden. Aus diesem Kontakt sind über die Zeit viele Gespräche entstanden, die weit über Server und Domains hinausgehen.

In einem dieser Gespräche kamen wir auf eine Frage, die mich seitdem beschäftigt. Wenn künftig ein KI-Assistent für Dich nach einem seriösen Shop sucht, woran erkennt er, dass ein Händler wirklich autorisiert ist? Und wo müsste diese Information technisch liegen? Ich hatte drei Kandidaten im Kopf: Schema.org, llms.txt und security.txt. Felix hat unsere Diskussion anschließend niedergeschrieben. Hier ist sie, leicht gekürzt.

Was ist eine Händlerautorisierung technisch?

Frederick: Fangen wir vorne an. Was ist eine Händlerautorisierung technisch überhaupt?

Felix: Die Frage ist spannender, als sie klingt. Für Verbraucher ist die Aussage einfach: Die Marke bestätigt, dass dieser Händler zu ihrem autorisierten Vertriebsnetz gehört, das ist nachvollziehbar relevant, für alles was potenziell nach dem Kauf wichtig ist: Service, Gewährleistung und Garantie, oder auch Ersatzteile. Technisch ist das eine Beziehung zwischen mehreren Beteiligten.

Ein Punkt ist mir dabei wichtig: authorized.by erteilt keine Händlerautorisierung. Das tut die jeweilige Marke. Wer die Information maschinenlesbar beschreiben will, muss diese Herkunft mitnehmen. Fachlich spricht man von Provenienz.

Passt Schema.org Certification für eine Händlerautorisierung?

Frederick: Dann klingt das für mich nach Schema.org. Dort gibt es inzwischen sogar Certification.

Felix: Das ist der naheliegendste Ausgangspunkt. Mit Certification beschreibt Schema.org eine offizielle Aussage über ein bestimmtes Subjekt, mit hasCertification lässt sie sich unter anderem einer Organisation zuordnen. Eine Certification kann festhalten, worauf sie sich bezieht, wer sie ausgestellt hat, welchen Status sie hat, ab wann sie gilt und wann sie endet.

Wir könnten also ausdrücken: Händler X hat die Bestätigung “Authorized Retailer for Brand Y”, ausgestellt von Brand Y, Status aktiv. Dann steht auf der Website mehr als der Satz “Wir sind autorisierter Händler”. Es steht dort eine strukturierte Aussage darüber, wer wen bestätigt hat.

Frederick: Aber ist eine Händlerautorisierung wirklich eine Zertifizierung?

Felix: Da wird es interessant. Bei Zertifizierungen denken wir an eine unabhängige Instanz, also eine Prüforganisation, eine Behörde oder einen ISO-Zertifizierer. Die Marke ist nicht unabhängig. Sie ist genau die Partei, die entscheidet: Diesen Händler bestätige ich als meinen Vertriebspartner. Semantisch ist das eine Erlaubnis. Schema.org kennt dafür sogar den Typ Permit.

Die Händlerautorisierung liegt zwischen beiden Welten. Sie ist keine unabhängige Prüfung, aber eine offizielle Bestätigung einer klar definierten Organisation. Deshalb meine Einschätzung: Certification ist ein sinnvoller Anknüpfungspunkt, solange eindeutig beschrieben ist, dass es um eine Brand Authorization geht und um keine unabhängige Qualitätszertifizierung.

So könnte das JSON-LD aussehen

Frederick: Wie würdest Du das konkret modellieren?

Felix: Ich würde die Rollen sauber trennen. Die Marke bestätigt die Händlerbeziehung, der Händler ist das Unternehmen, auf das sich die Autorisierung bezieht, und die Autorisierung selbst bekommt eine eigene, dauerhaft referenzierbare URL. Vereinfacht sieht das so aus:

{

 "@context": "https://schema.org",

 "@type": "Certification",

 "@id": "https://www.authorized.by/certificate/ABC123#authorization",

 "name": "Authorized Retailer | Brand XY",

 "description": "Brand XY confirms Shop Example as an authorized retailer.",

 "about": {

 "@type": "Organization",

 "name": "Shop Example GmbH",

 "url": "https://www.shop-example.de/"

 },

 "issuedBy": {

 "@type": "Organization",

 "name": "Brand XY",

 "url": "https://www.brand-xy.com/"

 },

 "certificationStatus": "https://schema.org/CertificationActive",

 "validFrom": "2026-01-01",

 "url": "https://www.authorized.by/certificate/ABC123"

}

Bei issuedBy steht Brand XY. Nicht authorized.by. Die Marke ist die Quelle der Autorisierung. authorized.by stellt die Infrastruktur bereit, über die diese Beziehung bestätigt, dokumentiert, veröffentlicht und maschinenlesbar referenziert wird.

Frederick: Warum schreibt der Händler das JSON-LD nicht einfach selbst auf seine Website?

Felix: Weil wir dann wieder beim Ausgangsproblem wären. Der Händler könnte strukturiert behaupten, er sei autorisiert. Das wäre wunderbar maschinenlesbar, aber eben nicht verifiziert. Maschinenlesbarkeit allein schafft noch kein Vertrauen.

Stärker ist eine Architektur, in der die Autorisierung eine eindeutige externe Referenz hat, das ist im Wesentlich der Kern unserer Lösung. Der Shop verweist darauf, und ein System prüft anschließend: Welcher Händler wird genannt? Welche Domain gehört dazu? Welche Marke hat autorisiert? Ist der Status aktuell? Wo liegt die ursprüngliche Quelle? Im KI-Web muss die Aussage strukturiert sein, und ihre Herkunft muss sich nachvollziehen lassen.

Welche Rolle spielt die llms.txt?

Frederick: Dann könnte man doch sagen: Genau dafür haben wir die llms.txt.

Felix: Ja und nein. Die Idee hinter llms.txt ist, einem Sprachmodell oder Agenten eine kompakte Orientierung über eine Website zu geben. Was ist diese Seite, welche Inhalte sind wichtig, welche Ressourcen sollte eine KI kennen? Für authorized.by könnte das vereinfacht so aussehen:

# authorized.by

> Official directory of brand-confirmed retailer authorizations.

Brands confirm which retailers belong to their official distribution network.

Authorization information is publicly verifiable and machine-readable.

## Authorization data

- [Authorized retailer directory](https://www.authorized.by/)

- [Authorization certificates](https://www.authorized.by/certificates/)

- [API documentation](https://example.com/api)

- [MCP documentation](https://example.com/mcp)

Ein Agent versteht dadurch schnell: Wenn ich wissen will, ob Händler X von Marke Y autorisiert wurde, ist authorized.by eine relevante Quelle. Danach sollte er die konkrete Autorisierungsseite oder die Schnittstelle abrufen.

Frederick: Warum schreibt man die komplette Autorisierung nicht gleich dort hinein?

Felix: Weil die llms.txt vor allem der Orientierung dient. Sie sagt einem Agenten, wo er eine Information findet. Die Information selbst gehört an eine kanonische Quelle. Die llms.txt macht die Autorisierung auffindbar, die Autorisierungsseite oder API liefert den aktuellen Status. Außerdem ist llms.txt bislang eine vorgeschlagene Konvention und kein formaler Internetstandard mit eigener RFC.

Gehört eine Händlerautorisierung in die security.txt?

Frederick: Dann nehme ich die security.txt. Eine autorisierte Bezugsquelle ist schließlich ein Sicherheitsmerkmal.

Felix: Den Gedanken verstehe ich gut. Technisch rate ich klar davon ab. RFC 9116 beschreibt die security.txt als Datei, über die Sicherheitsforscher erfahren, wie sie eine Schwachstelle an eine Organisation melden. Dort stehen Security-Kontakte, Disclosure Policies und Schlüssel für verschlüsselte Meldungen. Eine Händlerautorisierung würde den Standard zweckentfremden.

Frederick: Obwohl sie für Verbraucher durchaus etwas mit Sicherheit zu tun hat?

Felix: Etwas kann für einen sicheren Einkauf relevant sein und trotzdem nicht in die security.txt gehören. Eine bestätigte Autorisierung hilft Verbrauchern und Systemen, eine Bezugsquelle einzuschätzen. Eine Information zur Schwachstellenmeldung ist sie jedoch nicht.

Beim SSL-Zertifikat ist es ähnlich. Es sorgt dafür, dass die Verbindung zum Shop verschlüsselt ist. Ob dieser Händler die Marke offiziell vertreiben darf, beantwortet es nicht. Das sind verschiedene Vertrauensebenen, und die sollten wir technisch nicht vermischen.

Diesen Punkt kenne ich aus unserem Alltag als Hoster gut. Kunden fragen oft, ob ihr Shop mit HTTPS “sicher” sei. Für die Verbindung stimmt das. Über den Server oder Händler dahinter sagt das Schloss im Browser nichts.

Schema.org ist die Sprache, aber nicht die Datenbank

Frederick: Also lautet die Antwort letztlich Schema.org?

Felix: Ich würde es so formulieren: Schema.org ist die Sprache, aber nicht die Datenbank. Damit lässt sich ausdrücken, dass Händler A eine aktive Bestätigung von Marke B hat. Ob die Aussage stimmt und noch aktuell ist, sagt Schema.org dem Agenten nicht. Dafür braucht es eine verlässliche Quelle. Bei authorized.by ist das die öffentlich erreichbare Autorisierungsseite, das Zertifikat, deren Status die jeweilige Marke steuert.

Frederick: Wir hätten also mehrere technische Ebenen.

Felix: Genau. Daraus ergibt sich eine ziemlich klare Architektur:

Kann man Certification heute schon produktiv nutzen?

Frederick: Würdest Du Certification heute schon produktiv verwenden?

Felix: Ja, aber mit Bedacht. Eine Händlerautorisierung darf nicht aussehen wie eine TÜV-, ISO- oder Behördenzertifizierung. Ich würde Bezeichnungen wie “Brand Authorization” oder “Authorized Retailer Confirmation” verwenden, und die Marke muss als issuedBy erkennbar sein.

Auch bei Identifikatoren sollten wir sauber bleiben. Eine authorized.by-ID ist unsere technische ID für die betreffende Autorisierung. Sie darf nicht wirken wie die Registrierungsnummer einer unabhängigen Zertifizierungsbehörde. Für Menschen sind das Kleinigkeiten, für Maschinen entscheiden sie.

Frederick: Und Google oder ein LLM versteht das dann automatisch?

Felix: Automatisch wäre zu viel gesagt. Wir müssen drei Dinge auseinanderhalten: Eine Information lässt sich semantisch beschreiben, ein System kann sie technisch auslesen, und ein System nutzt sie tatsächlich für eine Empfehlung oder ein Ranking. Die ersten beiden Schritte können wir beeinflussen. Wir können nicht garantieren, dass Google daraus ein Rich Result macht oder dass ChatGPT einen Händler deshalb bevorzugt empfiehlt. Wir können aber eine verifizierbare Datengrundlage schaffen. Ohne die kann kein System die Information zuverlässig berücksichtigen.

Wie verändert KI das Vertrauen im Onlinehandel?

Frederick: Ist das der große Unterschied zwischen dem klassischen und dem KI-geprägten Web?

Felix: Ich glaube schon. Im klassischen Web haben wir überlegt, wie wir einem Menschen Vertrauen vermitteln. Daraus sind Gütesiegel, professionelle Designs, Bewertungen, Testimonials und Logos entstanden. Das bleibt wichtig. Ein KI-Agent fragt aber: Welche überprüfbaren Informationen liegen über diesen Anbieter vor? Für einen Menschen kann ein Logo ein Signal sein. Einer Maschine hilft eher so etwas:

Händler: shop.example

Marke: Brand XY

Beziehung: Authorized Retailer

Issuer: Brand XY

Status: Active

Quelle: authorized.by

Wir fragen dann weniger, wie Vertrauen aussieht, und mehr, wie es sich referenzieren und überprüfen lässt. Wie sich der Onlinehandel verändert, wenn KI-Assistenten Produktsuche und Kaufrecherche übernehmen, beschreiben wir ausführlicher in unserem Beitrag Autorisierung im Zeitalter der KI: Warum Vertrauen maschinenlesbar werden muss.

Wohin gehört die Händlerautorisierung also?

Frederick: Dann lass uns zum Schluss festlegen: Wohin gehört sie?

Felix: Nicht in eine einzige Datei. Eine Händlerautorisierung braucht zuerst eine öffentliche, eindeutige und aktuelle Referenz. Diese Referenz lässt sich mit strukturierten Daten beschreiben. Die llms.txt erklärt KI-Systemen, dass es diese Informationen gibt und wo sie liegen. API und MCP liefern den Status für Systeme, die direkt abfragen wollen. Und die security.txt lassen wir bitte bei den Security-Leuten.

Frederick: Damit kann ich leben.

Felix: Dann haben wir ausnahmsweise einen Webstandard nicht zweckentfremdet.

Was ich aus dem Gespräch mitnehme

Ich bin mit der Idee in die Diskussion gegangen, dass eine Händlerautorisierung irgendwo in eine Datei im Webroot gehört. Rausgekommen bin ich mit einer Kette aus Quelle, Beschreibung und Wegweiser. Einen universellen Webstandard speziell für Händlerautorisierungen gibt es bislang nicht. Die vorhandenen Bausteine reichen aber aus, wenn jeder Baustein seine Aufgabe behält.

Wenn Du einen Shop betreibst und von einer Marke autorisiert bist, verweise in Deinen strukturierten Daten auf die externe Autorisierung, statt die Aussage nur selbst zu behaupten. Die beiden Dateien aus unserer Diskussion liegen übrigens an festen Orten auf Deinem Server: die llms.txt im Root Deiner Domain, die security.txt unter /.well-known/security.txt. Auf einem Cloud Server legst Du beide in wenigen Minuten an. Wer sich um den Betrieb nicht selbst kümmern möchte, ist mit einem Managed Cloud Server besser bedient. Und falls Du KI-Agenten nicht nur füttern, sondern selbst betreiben willst, zeigen wir in unserer Anleitung, wie Du lokale KI selbst hostest.

Häufige Fragen

Was ist eine Händlerautorisierung? Eine Händlerautorisierung ist die Bestätigung einer Marke, dass ein bestimmter Händler zu ihrem offiziellen Vertriebsnetz gehört. Ausgestellt wird sie von der Marke selbst, nicht von einer unabhängigen Prüfstelle.

Kann ich eine Händlerautorisierung mit Schema.org auszeichnen? Ja. Der Typ Certification eignet sich als Anknüpfungspunkt, wenn die Marke als issuedBy eingetragen ist und klar erkennbar ist, dass es sich um eine Brand Authorization und keine unabhängige Qualitätszertifizierung handelt.

Was gehört in eine llms.txt? Die llms.txt gibt KI-Systemen eine kompakte Übersicht, was eine Website bietet und wo wichtige Ressourcen liegen. Sie ist ein Wegweiser und sollte nicht selbst als Datenbank für Autorisierungen dienen.

Wofür ist die security.txt gedacht? Die security.txt nach RFC 9116 zeigt Sicherheitsforschern, wie sie Schwachstellen an eine Organisation melden. Händlerautorisierungen gehören dort nicht hinein.

Über die Gesprächspartner

Weiterführende Links

• Schema.org Certification
• Schema.org hasCertification
• Schema.org Permit
• llms.txt: Proposed standard for LLM-friendly websites
• RFC 9116: security.txt
• authorized.by: Offizielles Verzeichnis autorisierter Händler
• authorized.by: Autorisierung im Zeitalter der KI

Artikel von

Frederick Schiwek

Hallo! Ich bin Freddy, Autor und Mitglied des Teams von hosting.de. Mit über 20 Jahren Erfahrung im Hosting-Business schreibe ich über Technologie, das Internet und die Zukunft der digitalen Infrastruktur. Ob Domains, Hosting oder Cloud-Dienste – ich bin hier, um Einblicke und Ideen zu teilen!