Wissen

Warum Dienstleister und B2B-Unternehmen strukturierte Daten noch dringender brauchen als Shops.

Strukturierte Daten sind nichts Kompliziertes: Fakten in einem Format, das Maschinen lesen können. Die Produkte eines Shops existieren wenigstens so: Feeds, Artikelnummern, Preise. Die Leistungen einer Beratung existieren meist nur als Marketing-Prosa, und Prosa ist das eine Format, das AI-Assistenten nicht verlässlich zitieren können. Das macht Agenturen, Beratungen und SaaS-Unternehmen zu den unsichtbarsten Anbietern in AI-Antworten, und zu denen, die am meisten gewinnen, wenn sie das ändern.

7 Min. Lesezeit·
Abstraktes Knoten-Gitter als Sinnbild für strukturierte Daten

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.

diag-structured-data-for-services-b2b-0.svg

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:

diag-structured-data-for-services-b2b-1.svg

Leistungsseite · im server-seitig ausgelieferten <head>

<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.

diag-structured-data-for-services-b2b-2.svg

Häufige Fragen

Frag Klariton

Stell deine Frage zu Klariton.

Gegroundet in Klaritons eigenem Wissen, belegt statt erfunden.

Oder stell deine eigene Frage:
Nächster Schritt

Wie sichtbar ist deine Marke für AI?

Der kostenlose AI-Visibility-Check zeigt dir in unter einer Minute, wie AI-Assistenten deinen Shop heute sehen.