Shops haben Feeds. Du hast Adjektive.
Wenn ein AI-Assistent die Frage „was verkauft dieser Shop und zu welchem Preis" beantwortet, hat er Rohmaterial: Produkt-Feeds, also die Datenlisten, die Shops mit jedem Artikel und Preis pflegen, dazu Product-Markup und Preisvergleichsdaten. Markup heißt dabei nichts anderes als zusätzliche Etiketten im Quelltext einer Seite, die Fakten für Maschinen ausbuchstabieren. Die Daten mögen lückenhaft oder veraltet sein, aber sie existieren. Stell demselben Assistenten jetzt die Frage „welche Agentur bei München baut Shopify-Shops für B2B-Marken, und was kostet das". Das Rohmaterial für diese Antwort besteht auf den meisten Agentur-Websites aus einer Hero-Headline über Leidenschaft, einer Leistungsseite mit „wir bieten ganzheitliche Lösungen" und einem Kontaktformular.
Das ist der strukturelle Nachteil: Dienstleistungen haben kein natürliches Datenformat. Niemand zwingt eine Beratung, einen Feed zu pflegen, was sie verkauft, zu welchem Preis, für wen. Also existiert nichts Maschinenlesbares, und der Assistent überspringt das Unternehmen entweder komplett oder verlässt sich darauf, was Dritte darüber sagen. Und das passiert, während der Einkauf selbst agentisch wird: Gartner prognostiziert, dass bis 2028 90% des B2B-Einkaufs über AI-Agenten laufen, bei einem Volumen von über 15 Billionen Dollar. Die Unternehmen, deren Leistungen maschinenlesbar sind, werden die sein, die diese Agenten überhaupt in Betracht ziehen können.
Wie AI-Assistenten eine Dienstleister-Empfehlung bauen
Ein Assistent, der einen Anbieter empfehlen soll, „weiß" nicht, wer gut ist. Er baut eine Antwort aus Belegen, die er parsen, also maschinell auslesen und in verwertbare Fakten zerlegen kann:
- Verzeichnisse und Register, die Anbieter mit Kategorien, Standorten und Spezialisierungen listen.
- Bewertungsplattformen, auf denen Ratings und Bewertungstexte strukturiert und zuordenbar sind.
- Strukturierte Beschreibungen auf der eigenen Website: was genau angeboten wird, für wen, wo, zu welcher Art von Preis.
- Konsistenz über Quellen hinweg: Dieselben Fakten an mehreren Stellen machen eine Aussage zitierfähig.
Halte jetzt eine typische Leistungsseite gegen diese Liste. „Wir liefern ganzheitliche, maßgeschneiderte Lösungen mit Leidenschaft" enthält null parsbare Fakten: keinen Leistungsnamen, kein Zielsegment, keine Region, kein Preissignal. Es ist nicht so, dass der Assistent deinen Text nicht mag. Es ist so, dass in dem Satz nichts steht, was eine Maschine extrahieren, vergleichen oder zitieren kann. Unstrukturierte Selbstbeschreibung ist kein Beleg, sie ist Dekoration.
Die Lösung sind nicht bessere Adjektive. Die Lösung ist eine maschinenlesbare Identität für jedes Angebot.
Eine Leistung als Service-Entity auszeichnen
Schema.org, das gemeinsame Vokabular, mit dem Suchmaschinen und AI-Anbieter Fakten auf Websites auszeichnen, hat genau dafür einen Typ, und er wird so selten genutzt, dass das ein Vorteil ist. Eine Service-Entity ist in diesem Vokabular ein einzelnes, klar beschriebenes Angebot samt seiner Fakten. Du hinterlegst sie als JSON-LD, ein kleines Datenpaket im Quelltext deiner Seite, das Besucher nie sehen, Maschinen aber lesen. Ein Block pro Angebot, auf der Seite, die es beschreibt:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Shop-Migration zu Shopify",
"serviceType": "E-Commerce-Plattform-Migration",
"description": "Komplette Migration eines bestehenden Online-Shops zu Shopify: Datenmigration für Produkte, Kunden und Bestellungen, Theme-Setup, URL-Redirects und Go-Live-Begleitung. Typische Dauer 6 bis 10 Wochen.",
"provider": {
"@type": "Organization",
"name": "Example Agency GmbH",
"url": "https://www.example-agency.de"
},
"areaServed": ["DE", "AT", "CH"],
"offers": {
"@type": "Offer",
"priceCurrency": "EUR",
"priceSpecification": {
"@type": "PriceSpecification",
"minPrice": 9500,
"priceCurrency": "EUR"
}
}
}
</script>Sieh dir an, was dieser Block leistet, was die Prosa-Version nicht kann: Er benennt die Leistung präzise, sagt, wer sie erbringt (der provider-Block ist ein Organization-Eintrag, quasi die maschinenlesbare Visitenkarte deiner Firma), wo, und ab welchem Preis. Ein Assistent, der „Shopify-Migration, DACH-Region, mittleres Budget" matcht, hat jetzt etwas zum Matchen. Die Granularität zählt mehr als der Feinschliff: Ein Service-Block pro klar umrissenem Angebot schlägt einen einzelnen vagen Block für „unsere Leistungen", weil Käufer und ihre Agenten nach konkreten Bedarfen suchen, nicht nach Selbstporträts.
Pricing: Auch „ab X" und „auf Anfrage" lassen sich strukturieren
Der Standard-Einwand: „Unsere Preise sind individuell, wir können nichts veröffentlichen." Du musst keinen Festpreis veröffentlichen, um maschinenlesbar zu sein. Das Beispiel oben nutzt minPrice, ein ehrliches „ab 9.500 Euro", das einen Assistenten dein Angebot in eine Budget-Spanne einordnen lässt, ohne dich auf einen festen Preis festzunageln. Wenn selbst das zu viel ist, benenne das Preismodell in der Beschreibung: projektbasiert, monatlicher Retainer, Tagessatz. Ein Assistent kann mit „projektbasiert, typische Projekte ab mittlerem fünfstelligem Bereich" arbeiten. Mit einer Seite, die den Preis wie ein Staatsgeheimnis behandelt, kann er nur eines tun: dich aus jeder Antwort weglassen, in der Budget Teil der Frage ist. Und Budget ist fast immer Teil der Frage.
Fallstudien: Belege statt Applaus
Fallstudien sind der Ersatz der Dienstleistungswelt für Produktbewertungen, und die meisten sind so geschrieben, dass sie unbrauchbar sind: „signifikante Steigerung", „reibungslose Zusammenarbeit", keine Branche, kein Zeitraum, keine Zahlen. Für eine Maschine, und ehrlich gesagt auch für einen skeptischen Einkäufer, sind sie leer. Eine zitierfähige Fallstudie nennt überprüfbare Fakten: die Branche, den Umfang, die Dauer, was geliefert wurde, was sich messbar verändert hat. Sind die echten Zahlen vertraulich, beschreibe die Art des Ergebnisses, statt eines zu erfinden. Eine erfundene Kennzahl, die zitiert und dann hinterfragt wird, richtet mehr Schaden an als gar keine. Auch hier hilft Struktur: Konsistente Faktenmuster über deine Fallstudien hinweg machen sie als zusammenhängende Beleg-Sammlung lesbar statt als Wand aus Lobzitaten.
Das Ganze bei fünfzehn Angeboten, und dauerhaft wahr
Alles oben lässt sich für eine Firma mit drei Leistungen von Hand bauen. Bei fünfzehn Angeboten in zwei Sprachen wird es mühsam, und richtig schwer wird es, wenn Beschreibungen, Preise und Team-Fakten sich laufend weiterentwickeln. Denn Markup, das von der Realität wegdriftet, wird still zur Belastung. Es ist dasselbe Skalierungsproblem wie bei Shops, nur im Anzug. Der Schema-Export von Klariton behandelt Dienstleistungen genauso wie Produkte: Deine Angebote werden einmal als strukturierte Entities gepflegt und als Service-Markup veröffentlicht, das Crawler, also die Programme, mit denen AI-Systeme Websites einlesen, direkt aufgreifen können. Safe Guard prüft währenddessen laufend, dass das Ausgelieferte noch zu den Quellen passt, aus denen es stammt. So können Website und Markup nicht unbemerkt auseinanderdriften. Und auch hier gilt die Basis von überall: Das Markup muss im server-seitig ausgelieferten HTML stehen, also in der Version der Seite, die dein Server verschickt, bevor irgendein Script läuft. Denn die meisten AI-Crawler führen kein JavaScript aus. Diese Kombination, maschinenlesbar und nachweisbar aktuell, ist das, was Agentic Reach für ein Dienstleistungsunternehmen bedeutet.
Häufige Fragen
Welcher Schema-Typ passt zu einer Beratung oder Agentur?
Nutze einmal Organization-Markup für das Unternehmen selbst und eine eigene Service-Entity für jedes einzelne Angebot. LocalBusiness oder ProfessionalService können für standortgebundene Anbieter sinnvoll sein. Der entscheidende Hebel ist Granularität: Ein präziser Service-Block pro Angebot schlägt einen vagen Block für die ganze Firma, weil Assistenten gegen konkrete Bedarfe matchen, nicht gegen Unternehmensbeschreibungen.
Unsere Preise sind individuell. Können wir Pricing trotzdem strukturieren?
Ja, und du solltest. Ein Einstiegspreis lässt sich mit einer PriceSpecification und minPrice ausdrücken, und selbst ein Modell auf Anfrage wird maschinenlesbarer, wenn du die Preisstruktur benennst, etwa projektbasiert oder monatliche Retainer, direkt in der Leistungsbeschreibung. Ein Assistent kann mit einem Ab-Preis oder einem benannten Modell arbeiten. Mit Schweigen kann er nichts anfangen.
Nutzen AI-Assistenten Service-Markup heute wirklich?
Assistenten bauen Empfehlungen aus den maschinenlesbaren Belegen, die existieren: Verzeichnisse, Bewertungsplattformen, strukturierte Beschreibungen und konsistente Fakten über Quellen hinweg. Service-Markup ist eines der stärksten Signale, das du direkt kontrollierst. Es garantiert keine Empfehlung, aber es entscheidet, ob dein Angebot überhaupt geparst, verglichen und zitiert werden kann, und das ist die Qualifikationsrunde.
Was macht eine Fallstudie für AI verwertbar?
Überprüfbare Konkretheit. Branche, Projektumfang, Dauer, was geliefert wurde und was sich messbar verändert hat, in schlichten Faktensätzen, die eine Maschine übernehmen und zuordnen kann. Superlative ohne Beleg werden ignoriert, und erfundene Zahlen sind schlimmer als keine. Ist ein Ergebnis vertraulich, beschreibe ehrlich die Art des Resultats, statt eine Kennzahl zu erfinden.
Der kostenlose Klariton-Check liest deine Website so, wie AI-Crawler es tun, und zeigt, was an deinen Angeboten heute maschinenlesbar ist: welche Fakten existieren, welche nur als Prosa vorliegen, und wo die Lücken sind, die dich aus AI-Antworten heraushalten.