Strukturierte Daten galten lange als technisches SEO-Extra für Rich Results und ein paar zusätzliche Suchergebnis-Features. 2026 hat sich der Blick darauf deutlich verändert: Schema-Daten helfen Suchmaschinen und KI-Systemen dabei, Inhalte, Entitäten und Beziehungen auf einer Website klar zu erfassen – und bilden damit einen wichtigen ersten Schritt hin zu einem Web, in dem Agenten nicht nur lesen, sondern zunehmend auch gezielt mit digitalen Oberflächen interagieren. Für echte Handlungen von KI-Agenten braucht es mehr als JSON-LD allein, aber ohne saubere semantische Grundlagen wird genau das deutlich schwerer.
Genau deshalb reicht es nicht mehr, einfach irgendein Plugin zu aktivieren oder Standard-Snippets auf jede Seite zu legen. Entscheidend ist, strukturierte Daten strategisch zu denken: passend zum Seitentyp, sauber verknüpft, technisch korrekt und so aufgebaut, dass Inhalte, Services, Unternehmen und Beziehungen für Maschinen wirklich verständlich werden. Denn das führt zu mehr Klarheit und folglich zu mehr Vertrauen (Confidence Score) in deine Brand, deine Produkte oder Services.
In diesem Guide zeigen wir dir, wie du strukturierte Daten mit JSON-LD konkret einsetzt, welche Schema-Typen du wirklich brauchst, welche Fehler du vermeiden solltest und wie du deine Website nicht nur für klassisches SEO, sondern auch für AI Search und das Agentic Web sinnvoll vorbereitest. Und wenn du keine Lust auf die Umsetzung hast – wir von WEVENTURE Performance helfen dir gerne weiter.
In diesem Artikel
Mach deine Website verständlich für Google, KI & Co.
Wir prüfen, welches Schema für deine Website sinnvoll ist und setzen strukturierte Daten so um, dass daraus ein klarer semantischer Vorteil entsteht.
Marketing-Wissen, dem du vertrauen kannst
Sag Google, dass du uns liest und wir tauchen öfter auf, wenn es drauf ankommt.
Wichtige Begriffe, die du kennen solltest
Bevor wir in die praktische Umsetzung von strukturierten Daten einsteigen, lohnt sich ein kurzer Blick auf die wichtigsten Begriffe, die du kennen solltest.
Strukturierte Daten
Maschinenlesbare Informationen, die den Inhalt einer Seite in standardisierter Form beschreiben. Sie helfen Suchmaschinen und anderen Systemen dabei, Inhalte, Entitäten und Beziehungen besser zu verstehen.
Schema.org
Das gemeinsame Vokabular, mit dem strukturierte Daten beschrieben werden. Dort sind die Typen und Eigenschaften definiert, zum Beispiel Person, Organization, Article, Service oder Product.
JSON-LD
JSON-LD ist das von Google bevorzugte Format, um strukturierte Daten einzubinden. Der Code wird meist im Head oder Body der Seite eingebunden, ohne den sichtbaren Inhalt direkt zu verändern. Neben JSON-LD gibt es auch andere Formate wie Microdata und RDFa, bei denen strukturierte Daten direkt stärker im HTML-Markup verankert werden. In der Praxis gilt JSON-LD jedoch meist als Best Practice, weil es sauberer zu pflegen, flexibler einzubinden und weniger fehleranfällig ist.
Rich Results
Erweiterte Suchergebnisse mit zusätzlichen Darstellungen, zum Beispiel FAQs, Sterne, Events oder Produktinformationen. Strukturierte Daten können dafür eine Grundlage sein, garantieren diese Darstellung aber nicht.
Entity
Eine klar erkennbare Einheit, die von Systemen als eigenständiges „Ding“ verstanden werden kann, zum Beispiel ein Unternehmen, eine Person, ein Service, ein Produkt oder ein Artikel. Entity-SEO wird in 2026 immer wichtiger.
Agentic Web
Eine Entwicklung des Webs, in der nicht nur Menschen Websites nutzen, sondern zunehmend auch KI-Systeme und Agenten eigenständig Informationen abrufen, Aufgaben ausführen oder mit Interfaces interagieren.
Warum strukturierte Daten im KI-Zeitalter weit mehr als ein SEO-Bonus sind
Maschinen brauchen Klarheit – und strukturierte Daten liefern genau das
Für uns ist genau das der eigentliche Kern: Strukturierte Daten machen Inhalte nicht schöner, sondern klarer. Sie helfen Maschinen dabei, schneller und eindeutiger zu erkennen, worum es auf einer Seite geht, welche Entität im Mittelpunkt steht und wie Inhalte miteinander zusammenhängen.
Strukturierte Daten sind kein Wundermittel, aber sie liefern ein zusätzliches, sauberes Signal.
Wichtige Informationen sollten mehrfach vorkommen
Ein Punkt, den viele unterschätzen: Strukturierte Daten sind auch deshalb so wertvoll, weil sie die wichtigsten Informationen einer Seite noch einmal in komprimierter, maschinenlesbarer Form wiederholen. Nicht als plumpes Keyword-Stuffing, sondern als saubere Auszeichnung dessen, was auf der Seite ohnehin vorhanden ist. Das kann gerade bei zentralen Informationen einen Unterschied machen.
Aus unserer Sicht ist das einer der größten praktischen Vorteile. Wenn eine Information sowohl für Menschen verständlich im sichtbaren Content steht als auch strukturiert für Maschinen beschrieben wird, entsteht mehr Eindeutigkeit (= höherer Confidence Score bei LLMs). Genau das ist im KI-Zeitalter wichtig: Sowohl der Google-Algorithmus als auch LLMs müssen Muster erkennen, Informationen einordnen und Relevanz ableiten. Sauber wiederholte Kernaussagen in einem standardisierten Format helfen dabei, ohne dass der Text unnatürlich wirkt oder mit Keywords überladen wird.
Strukturierte Daten sind nicht nur für Google da
Strukturierten Daten ist es ziemlich egal, welches System sie ausliest. Und Google unterstützt auch nicht zwingend alle Types und Properties für die Suche. Viele andere schema.org-Typen sind trotzdem semantisch sinnvoll, aber eben eher für allgemeines Maschinenverständnis als für ein direktes Rich Result.
Seiten, die sauber strukturiert und verständlich modelliert sind, geben Maschinen bessere Grundlagen an die Hand. Und wenn diese Systeme deine Seite, Brand und Service besser verstehen, ist es wahrscheinlicher, dass deine Inhalte auch verwendet werden bzw. deine Brand empfohlen wird.
Wichtig dabei: KI-Systeme und Agenten lesen strukturierte Daten nicht isoliert. Sie gleichen Informationen mit anderen Quellen ab, prüfen Aussagen gegen weitere Signale und bilden daraus vereinfacht gesagt eine Art Vertrauensbild (Confidence Score). Sind Angaben widersprüchlich, lückenhaft oder unsauber gepflegt, kann das die Glaubwürdigkeit deiner Inhalte und deiner Marke im maschinellen Verständnis schwächen.
Für echte Agenten-Interaktion reicht JSON-LD allein noch nicht
Wichtig zu wissen: Strukturierte Daten allein machen eine Website noch nicht agentenfähig. Wenn KI-Agenten künftig selbstständig mit Websites interagieren, spielen weitere Faktoren mindestens genauso stark hinein – etwa semantisches HTML, klare Buttons und Formulare, stabile Layouts und ein sauberer Accessibility Tree. Genau das hebt auch web.dev in seiner Guidance für agentenfreundliche Websites hervor.
Trotzdem sind strukturierte Daten ein sinnvoller erster Schritt in diese Richtung. Sie schaffen Orientierung, definieren Entitäten und können sogar mögliche Handlungen modellieren. Schema.org kennt mit potentialAction und verwandten Konzepten bereits eine eigene Logik für potenzielle Aktionen. Das ist noch nicht gleichbedeutend mit vollautomatischer Agenten-Interaktion, zeigt aber die Richtung: erst verstehen, dann verlässlich handeln.
Bereit für SEO, GEO und das Agentic Web?
Wenn Inhalte künftig nicht nur von Menschen, sondern auch von KI-Systemen, Suchmaschinen und Agenten verstanden werden sollen, braucht deine Website eine klare semantische Struktur. Wir unterstützen dich dabei, strukturierte Daten, Entitäten und Inhalte strategisch zusammenzubringen.
Strukturierte Daten richtig denken: nicht als einzelnes Snippet, sondern als Entity Graph
Viele Websites setzen strukturierte Daten noch immer nach dem Baukastenprinzip ein: hier ein Organization-Snippet, dort ein FAQPage-Block, auf dem Blog ein Article-Markup, fertig. Technisch ist das nicht falsch, strategisch aber zu kurz gedacht. Denn strukturierte Daten entfalten ihren eigentlichen Wert erst dann, wenn sie nicht als lose Einzelteile, sondern als zusammenhängendes System verstanden werden. Entscheidend ist also nicht nur, ob Markup vorhanden ist, sondern wie sauber Seiten, Entitäten und Beziehungen miteinander verknüpft sind.
Der eigentliche Hebel von strukturierten Daten liegt in deren Verknüpfung
Eine Website besteht nicht nur aus einzelnen URLs, sondern aus Beziehungen: Ein Unternehmen bietet Leistungen an, veröffentlicht Artikel, beschäftigt Mitarbeitende und Autor:innen, betreibt eine Website, hat Kontaktpunkte, Standorte, Produkte, Referenzen und thematische Schwerpunkte und Expertise. Strukturierte Daten helfen dabei, diese Beziehungen explizit zu machen.
Einzelne Seiten brauchen eine Hauptlogik
Jede URL sollte deshalb zunächst eine klare Hauptfunktion haben. Ist sie eine Startseite, eine Leistungsseite, ein Blogartikel, eine Teamseite, eine Kontaktseite oder eine Produktseite? Davon hängt ab, welcher Schema-Typ im Zentrum steht. Eine Leistungsseite sollte in der Regel nicht nur als WebPage, sondern zusätzlich als Service modelliert werden. Ein Blogbeitrag ist nicht einfach nur eine Seite, sondern ein Article oder BlogPosting. Eine Kontaktseite ist mehr als eine URL mit Formular – sie ist inhaltlich eine ContactPage.
Dazu gibt es eine Reihe weiterer Types und Properties, die man je nach Seitentyp einbauen kann. Diese Elemente sollten nicht lose nebeneinander stehen, sondern miteinander verbunden werden. Dafür sind Eigenschaften wie @id, isPartOf, about, publisher, provider oder mainEntityOfPage wichtig. Sie machen aus einzelnen JSON-LD-Blöcken ein konsistentes semantisches Modell.
Genau hier beginnt auch echtes Entity Building. Wenn du sauber modellierst, wer du bist, was du anbietest, mit welchen Personen, Themen und Quellen du verbunden bist und wie all diese Bausteine zusammenhängen, stärkst du die Eindeutigkeit deiner ganzen Brand.
Der Yoast Schema Visualizer macht Verbindungen sichtbar
Ein hilfreiches Werkzeug in diesem Zusammenhang ist der Yoast Schema Visualizer. Gerade wenn man beginnt, nicht mehr nur in Einzel-Snippets, sondern in vernetzten Entitäten zu denken, ist so ein Visualizer Gold wert. Denn dort sieht man sehr schnell, ob die eigene Struktur wirklich zusammenhängend aufgebaut ist.
SameAs ist nicht mehr nur ein netter Zusatz
Eine Property, die oft unterschätzt wird, ist sameAs. Viele tragen dort einfach ein paar Social-Media-Profile ein und haken das Thema ab. Dabei kann sameAs ein extrem wertvoller Baustein für Entity-SEO sein, weil es externe Signale mit deiner eigenen Website verbindet.
Wenn deine Organisation, deine Autor:innen oder andere wichtige Entitäten auf LinkedIn, Crunchbase, GitHub, Wikipedia, Wikidata oder anderen vertrauenswürdigen Profilen und Plattformen präsent sind, können solche Verweise helfen, diese Identitäten sauber zusammenzuführen. Das heißt nicht, dass man wahllos alles verlinken sollte. Aber dort, wo echte, konsistente und seriöse Verbindungen bestehen, lohnt sich eine saubere Einbindung (vor allem, wenn diese externen Seiten auch wieder auf die eigene Seite zurück verlinken).
Plugins sind ein guter Start – aber selten das Ziel
Für viele Websites sind SEO-Plugins wie Yoast oder Rank Math ein sinnvoller Einstieg. Sie liefern eine solide Basis und nehmen dir gerade bei Standardfällen viel Arbeit ab. Das ist absolut hilfreich, vor allem wenn es um Dinge wie grundlegende Organization-, WebPage-, Article– oder Breadcrumb-Logiken geht.
Das Problem beginnt meistens dann, wenn du über diese Standards hinaus willst. In der Praxis stoßen solche Plugins schnell an Grenzen, sobald du individueller arbeiten möchtest: spezielle Seitentypen, eigene Service-Logiken, gezielte Verknüpfungen zwischen Autor:innen, Leistungen und Unternehmensentitäten oder zusätzliche Typen, die nicht standardmäßig vorgesehen sind.
Deshalb sehen wir Plugins eher als saubere Basis, nicht als vollständige Lösung. Für viele Projekte ist das Grundsetup über ein Plugin sinnvoll, aber spätestens bei strategisch wichtigen Seiten, individuellen Services oder komplexeren Entitäten lohnt sich eine teilweise manuelle Ergänzung.
Warum manuelle JSON-LD-Ergänzungen oft sinnvoll sind
Wer heute mit ChatGPT, Claude etc. arbeitet, kann sich JSON-LD-Code sehr schnell vorbereiten lassen und an die jeweilige Seite anpassen. Der technische Aufwand, eigene strukturierte Daten gezielt zu ergänzen, ist heute um ein Vielfaches kleiner als früher.
Und genau deshalb ist eine teilweise manuelle Einpflege in vielen Fällen sinnvoll. Nicht, weil Plugins schlecht wären, sondern weil man damit deutlich präziser arbeiten kann. Du kannst zusätzliche Verknüpfungen aufbauen, sameAs gezielter einsetzen, spezifischere Typen ergänzen und genau die Informationen auszeichnen, die für dein Geschäftsmodell, deine Themenwelt und deine Sichtbarkeit wirklich relevant sind.
Gerade wenn man strukturierte Daten nicht nur als Rich-Result-Hebel, sondern als Teil einer größeren Entity-Strategie versteht, wird diese Flexibilität extrem wertvoll.
Aus Content wird Kontext. Aus Sichtbarkeit wird Relevanz.
Gute Inhalte allein reichen nicht immer aus. Entscheidend ist, dass Google und KI-Systeme erkennen, wer du bist, was du anbietest und wie deine Inhalte zusammenhängen. Mit strukturierten Daten und Entity-SEO schaffen wir die Grundlage für bessere Auffindbarkeit in klassischen Suchergebnissen und KI-Antworten.
Welche Schema-Typen du brauchst
Gute strukturierte Daten orientieren sich immer zuerst am Seitentyp, dann an der Hauptentität der jeweiligen Seite und erst danach an optionalen Ergänzungen.
Nicht jeder Typ ist auf jeder Seite Pflicht. Aber einige Bausteine tauchen in der Praxis sehr häufig auf und sollten fast immer mitgedacht werden. Dazu gehören vor allem eine saubere WebPage-Logik für die konkrete URL, eine klare Referenz auf die Website bzw. Organisation und eine BreadcrumbList, damit Inhalte besser in die Seitenstruktur eingeordnet werden können.
Eine weitere Idee ist das Einfügen einer “AI-optimized Brand Card”, einem Organization-Schema mit den wichtigsten Services. Dieses kann mit wenigen Klicks auf der gesamten Seite eingebaut werden und sorgt dafür, dass keine Lücken entstehen.
Startseite
Die Startseite ist fast immer der wichtigste Ankerpunkt für deine gesamte Schema-Struktur. Hier sollte das Unternehmen oder die Organisation klar definiert sein, ebenso die Website selbst.
Typische Haupt- und Ergänzungstypen:
- Organization
- WebSite
- WebPage
Sinnvolle Ergänzungen:
- ContactPoint
- optional SearchAction (Wenn eine Website eine funktionierende interne Suche hat, kann SearchAction auf WebSite ein sehr logischer, nützlicher Baustein sein, nicht nur klassisch für Suche, sondern auch als früher strukturierter „Einstiegspunkt“ für maschinelle Interaktion.)
- optional OfferCatalog
Leistungsseiten / Service-Seiten
Für viele Unternehmenswebsites gehören Service-Seiten zu den wichtigsten URLs überhaupt. Genau deshalb sollten sie nicht nur als Seiten, sondern auch als Leistungen modelliert werden.
Typische Haupt- und Ergänzungstypen:
- WebPage
- Service
- BreadcrumbList
Optionale Ergänzungen:
- FAQPage (wenn FAQ-Bereich vorhanden)
- Organization (über provider definiert)
- Offer (wenn ein sichtbares, konkretes Angebotsmodell dahintersteht)
- ContactPoint (wenn ein klarer Kontaktweg direkt an dieser Leistung hängt)
- potentialAction (wenn du künftige Interaktionslogik mitdenken willst)
Blogartikel, Ratgeber und Wissensseiten
Für Content-Seiten ist die Logik in vielen Fällen etwas klarer, aber auch hier wird oft zu oberflächlich gearbeitet. Ein Blogartikel ist nicht einfach nur eine URL mit Text, sondern ein redaktioneller Inhalt mit Autor:in, Publisher und Themenbezug.
Typische Haupt- und Ergänzungstypen:
- WebPage
- Article oder BlogPosting
- BreadcrumbList
Sinnvolle Ergänzungen:
- Person oder Organization als author (Bei Personen lohnt sich auch die Angabe relevanter Credentials, z.B. Education, für mehr Autorität.)
- Organization als publisher
- mainEntityOfPage
- about
- mentions
- FAQPage
Pro-Tipp von uns: Gerade bei Artikeln lohnt sich ein sauberes about oder mentions, wenn wichtige Themen, Tools, Produkte, Persönlichkeiten oder Unternehmen wirklich zentraler Bestandteil des Artikels sind. Man sollte das nicht inflationär verwenden, aber bei gut aufgebauten Fachartikeln kann genau das helfen, thematische Zusammenhänge noch expliziter zu machen.
Teamseiten, Autor:innenprofile und Expert:innenseiten
Diese Seitentypen werden noch viel zu selten sauber modelliert. Dabei sind sie für Vertrauen, Expertise und Entity Building extrem wertvoll (also auch für E-E-A-T).
Typische Haupt- und Ergänzungstypen:
- ProfilePage
- Person oder Organization
- BreadcrumbList
Google hat für Profilseiten inzwischen eine eigene Dokumentation und unterstützt ProfilePage für Seiten, die Informationen über Personen oder Organisationen auf einer Website bereitstellen.
Wichtig bei sameAs: Nicht wahllos alles verlinken. Aber seriöse, konsistente Profile wie Social Media, offizielle Bio-Seiten oder fachlich relevante externe Profile können hier sehr wertvoll sein und Topical Authority stärken.
Kontaktseiten
Kontaktseiten wirken auf den ersten Blick unspektakulär, sind aber aus maschineller Sicht sehr nützlich. Sie definieren nicht nur, wie ein Unternehmen erreichbar ist und welche offiziellen Kontaktpunkte dazugehören, sondern liefern auch genau die Art von klar strukturierten Informationen, die Agenten in (naher?) Zukunft für eine mögliche Kontaktanbahnung brauchen. Aber mehr dazu später.
Typische Haupt- und Ergänzungstypen:
- ContactPage
- WebPage
- Organization
- ContactPoint
- BreadcrumbList
- potentialAction (wenn du künftige Interaktionslogik mitdenken willst)
Wenn ein echter Standort stark im Mittelpunkt steht, kann zusätzlich LocalBusiness sinnvoll sein. Hier sollte man aber nicht automatisch alles in LocalBusiness umdeuten, wenn die Seite gar keine echte lokale Filiale oder Standortseite ist.
Wichtig: NAP-Konsistenz herstellen. NAP steht für Name, Adresse und Telefonnummer – sie sollten auf allen Seiten (auch externen) identisch sein (und alle anderen Daten natürlich auch).
How-to: Strukturierte Daten mit JSON-LD Schema Schritt für Schritt erstellen
Jetzt zum spannenden Teil: Wie kommst du von einer konkreten URL zu sauberem JSON-LD? Als Beispiel nehmen wir eine fiktive industrielle B2B-Unternehmensseite:
Beispiel-URL:
https://www.muster-industriesysteme.de/mobile-kuehlung/
Auf dieser Seite bietet ein Industrieunternehmen mobile Kühllösungen für Produktionshallen und technische Anlagen an. Die Seite ist also keine Produktdetailseite und auch kein Blogartikel, sondern eine klassische Leistungsseite mit industriellem Fokus.
Schritt 1: Seitentyp und Haupt-Entität bestimmen
Bevor du Code schreibst (bzw. schreiben lässt), musst du die Seite fachlich richtig einordnen.
In unserem Beispiel ist die URL nicht nur eine WebPage, sondern inhaltlich vor allem ein Service.
Schritt 2: Die Objekte und Properties festlegen, die du brauchst
Für unsere Beispielseite brauchen wir:
- Organization für das Unternehmen
- WebSite für die gesamte Website
- WebPage für die konkrete URL
- Service für die Leistung
- BreadcrumbList für die Einordnung in die Seitenstruktur
Optional könnten später noch dazukommen:
- FAQPage, wenn ein sichtbarer FAQ-Bereich existiert
- ContactPoint, wenn ein klarer Kontaktkanal auf der Seite hervorgehoben wird, z.B. ein Kontaktformular (ansonsten eher etwas für die Kontakt-Seite)
- Offer, wenn ein konkretes Angebot sichtbar beschrieben wird
Wichtig ist dabei, so viele relevante Informationen wie möglich direkt aus der Seite herauszuziehen und im Schema sauber abzubilden. Je mehr zentrale Inhalte, Eigenschaften und Zusammenhänge strukturiert beschrieben werden, desto klarer wird die Seite für Maschinen verständlich. Dabei geht es aber nicht darum, das Markup künstlich aufzublähen, sondern die Infos zu priorisieren, die für echte Anfragen wirklich nützlich sind. KI-Systeme und Agenten achten vor allem auf Angaben, mit denen sie Fragen konkret beantworten können (eigentlich logisch, oder?). Bei einem Restaurant wären das zum Beispiel Name, Küche, Standort, Öffnungszeiten und Bewertungen – nicht möglichst viel Schema um des Schemas willen.
Gleichzeitig gilt: Ausgezeichnet werden sollte nur das, was auf der Seite tatsächlich sichtbar und inhaltlich nachvollziehbar vorhanden ist. Strukturierte Daten sind kein Ort für zusätzliche Werbeversprechen oder versteckte Informationen (Stichwort Blackhat SEO).
Schritt 3: Saubere IDs vergeben
Jetzt definieren wir zuerst die internen Anker für unseren Graphen. Womöglich sind manche IDs, z.B. zu Organisation und Website, bereits von anderen Schemas auf deiner Seite vordefiniert. Unterschiedliche IDs für dasselbe Schema sollten unbedingt vermieden werden.
- https://www.muster-industriesysteme.de/#org (Organization)
- https://www.muster-industriesysteme.de/#website (Website)
- https://www.muster-industriesysteme.de/mobile-kuehlung/#webpage (WebPage)
- https://www.muster-industriesysteme.de/mobile-kuehlung/#service (Service)
- https://www.muster-industriesysteme.de/mobile-kuehlung/#breadcrumb (Breadcrumb)
Diese @ids sind wichtig, weil wir damit die einzelnen Objekte später sauber miteinander verknüpfen (auch teils über verschiedene Seiten hinweg).
Schritt 4: Schemas bauen
Jetzt geht’s mit der eigentlichen Arbeit los: dem Erstellen der einzelnen Schemas.
Organization-Schema
Jetzt bauen wir zuerst die übergeordnete Entität: das Unternehmen.
Hier geht es darum, wer die Leistung anbietet.
<script type=“application/ld+json“>
{
„@context“: „https://schema.org“,
„@type“: „Organization“,
„@id“: „https://www.muster-industriesysteme.de/#org“,
„name“: „Muster Industriesysteme GmbH“,
„url“: „https://www.muster-industriesysteme.de/“,
„logo“: „https://www.muster-industriesysteme.de/assets/logo.png“,
„sameAs“: [
„https://www.linkedin.com/company/muster-industriesysteme“
]
}
</script>
Was passiert hier?
- @type: Organization sagt, dass es um das Unternehmen geht.
- @id macht das Unternehmen später referenzierbar.
- sameAs kann helfen, die Entität mit externen Profilen zu verknüpfen.
Auf Service-Seiten muss die Organization nicht jedes Mal vollständig neu ausgeschrieben werden. Wenn du bereits eine saubere zentrale Organisationsentität aufgebaut hast (z.B. auf der Startseite oder Über Uns), kann eine Referenz per @id völlig ausreichen. In vielen praktischen Setups ist es trotzdem sinnvoll, ein kompaktes Organization-Schema mit name, url und logo mitzugeben, damit der Anbieter der Leistung direkt im Seitenkontext maschinenlesbar vorhanden ist. Auf der Start- oder Über-Uns-Seite kann man das Schema dann wesentlich ausführlicher gestalten.
Website-Schema
Als Nächstes definieren wir die Website als Ganzes.
<script type=“application/ld+json“>
{
„@context“: „https://schema.org“,
„@type“: „WebSite“,
„@id“: „https://www.muster-industriesysteme.de/#website“,
„url“: „https://www.muster-industriesysteme.de/“,
„name“: „Muster Industriesysteme GmbH“,
„publisher“: {
„@id“: „https://www.muster-industriesysteme.de/#org“
}
}
</script>
Was passiert hier?
- WebSite beschreibt nicht die einzelne Unterseite, sondern die komplette Website.
- Über publisher wird die Website mit der Organisation verbunden.
Hier sieht man schon das Prinzip: Wir schreiben die Organization nicht komplett neu, sondern verweisen per @id auf das bereits definierte Schema.
WebPage-Schema
Jetzt modellieren wir die eigentliche URL.
<script type=“application/ld+json“>
{
„@context“: „https://schema.org“,
„@type“: „WebPage“,
„@id“: „https://www.muster-industriesysteme.de/mobile-kuehlung/#webpage“,
„url“: „https://www.muster-industriesysteme.de/mobile-kuehlung/“,
„name“: „Mobile Kühlung für Industrie und Produktion“,
„isPartOf“: {
„@id“: „https://www.muster-industriesysteme.de/#website“
},
„mainEntity“: {
„@id“: „https://www.muster-industriesysteme.de/mobile-kuehlung/#service“
},
„breadcrumb“: {
„@id“: „https://www.muster-industriesysteme.de/mobile-kuehlung/#breadcrumb“
}
}
</script>
Was passiert hier?
- WebPage beschreibt die URL selbst.
- isPartOf verknüpft sie mit der Website.
- mainEntity zeigt, was der Hauptinhalt der Seite ist: der Service. Man könnte theoretisch auch die Property about nehmen, diese ist aber allgemeiner und beschreibt, worum es auf einer Seite thematisch geht, nicht, was die Haupt-Entität ist. Das lohnt sich also eher für z.B. Artikel.
- breadcrumb verweist auf die spätere Breadcrumb-Struktur.
Service-Schema
Jetzt kommt das wichtigste Schema der Seite: die Leistung selbst.
<script type=“application/ld+json“>
{
„@context“: „https://schema.org“,
„@type“: „Service“,
„@id“: „https://www.muster-industriesysteme.de/mobile-kuehlung/#service“,
„name“: „Mobile Kühlung“,
„description“: „Temporäre Kühllösungen für Industrie, Produktion und technische Anlagen.“,
„serviceType“: „Industrielle Kühllösungen“,
„provider“: {
„@id“: „https://www.muster-industriesysteme.de/#org“
},
„areaServed“: „DE“,
„mainEntityOfPage“: {
„@id“: „https://www.muster-industriesysteme.de/mobile-kuehlung/#webpage“
}
}
</script>
Was passiert hier?
- provider verknüpft die Leistung mit dem Unternehmen.
- mainEntityOfPage macht deutlich, dass dieser Service der zentrale Inhalt der URL (WebPage) ist. mainEntityOfPage ist dabei das Gegenstück zu mainEntity im WebPage Schema: Während dort festgelegt wird, dass der Service der Hauptinhalt der Seite ist, beschreibt mainEntityOfPage aus Sicht des Service, dass genau diese URL seine zentrale Seite ist. So entsteht eine saubere, wechselseitige Verknüpfung zwischen Inhalt und Seite.
- areaServed ist eine interessante Property, wenn dein Service nur in bestimmten Regionen, Städten oder Ländern angeboten wird. Du gibst damit maschinenlesbar an, wo die Leistung verfügbar ist. ChatGPT z.B. kann mittlerweile, genau wie Google, auf den Standort der Nutzer:innen zurückgreifen, um Antworten so personalisiert wie möglich zu gestalten. Hierfür kann diese Property hilfreich sein (eine Garantie gibt es jedoch nicht).
Wenn du zusätzlich klar machen willst, für wen der Service gedacht ist, kannst du bei Service außerdem mit audience arbeiten. Damit lässt sich zum Beispiel modellieren, dass sich ein Angebot speziell an B2C oder B2B richtet.
Breadcrumbs-Schema
Zum Schluss modellieren wir noch die Seitenhierarchie mithilfe eines BreadcrumbList-Schemas. Breadcrumbs zeigen Suchmaschinen und anderen KI-Modellen, wo eine Seite innerhalb der Website-Struktur eingeordnet ist. Gerade bei Leistungsseiten ist das hilfreich, weil dadurch klarer wird, ob eine URL zum Beispiel unter „Leistungen“, „Mietlösungen“ oder einer bestimmten Produkt- oder Service-Kategorie liegt.
<script type=“application/ld+json“>
{
„@context“: „https://schema.org“,
„@type“: „BreadcrumbList“,
„@id“: „https://www.muster-industriesysteme.de/mobile-kuehlung/#breadcrumb“,
„itemListElement“: [
{
„@type“: „ListItem“,
„position“: 1,
„name“: „Startseite“,
„item“: „https://www.muster-industriesysteme.de/“
},
{
„@type“: „ListItem“,
„position“: 2,
„name“: „Leistungen“,
„item“: „https://www.muster-industriesysteme.de/leistungen/“
},
{
„@type“: „ListItem“,
„position“: 3,
„name“: „Mobile Kühlung“,
„item“: „https://www.muster-industriesysteme.de/mobile-kuehlung/“
}
]
}
</script>
Schritt 5: Alles zu einem sauberen Graphen zusammenführen
Es gibt mehrere Möglichkeiten, den Code zu implementieren. In der Praxis würden wir die Bausteine meist nicht als fünf einzelne Skripte ausspielen, sondern in einem gemeinsamen @graph bündeln oder sogar ineinander verschachteln. Letzten Endes gibt es hier jedoch kein Richtig und kein Falsch, solange die Beziehung zwischen den einzelnen Types eindeutig im Code beschrieben ist.
Auch die Reihenfolge ist nicht das Wesentliche. Du kannst mit Organization starten, weil es logisch angenehm ist: erst das Unternehmen, dann die Website, dann die Seite, dann die Leistung, dann die Breadcrumbs. Maschinen lesen den Graphen nicht wie einen Fließtext von oben nach unten, sondern über die Beziehungen zwischen den Objekten. Technisch entscheidend sind also, wie bereits gesagt, die Verknüpfungen, nicht die Reihenfolge.
Schritt 6: Strukturierte Daten validieren und visualisieren
Bevor der Code live geht:
- Syntax prüfen, zum Beispiel über den Schema Markup Validator
- sichtbaren Inhalt gegenprüfen
- prüfen, ob Plugins schon eigenes Markup ausgeben
- Rich Results Test nutzen
- URL-Prüfung in der Search Console nutzen (wenn der Code live ist)
Außerdem kannst du dir den Code visualisieren lassen, um Verknüpfungen zu erkennen. In unserem kleinen Beispiel-Schema von oben sieht das Resultat so aus:
Strukturierte Daten im Agentic Web: erste Experimente und neue Schnittstellen
Nachdem wir uns bisher vor allem damit beschäftigt haben, wie strukturierte Daten Inhalte, Entitäten und Beziehungen sauber beschreibbar machen, stellt sich zwangsläufig die nächste Frage: Reicht das irgendwann noch aus, wenn Websites nicht nur gelesen, sondern auch aktiv von KI-Agenten genutzt werden? Genau an dieser Stelle wird es experimentell.
Unsere ehrliche Meinung dazu ist: Agentenfähigkeit ist noch kein Pflichtprogramm für jede Website, aber sie ist auch keine Science-Fiction mehr. Wer früh verstehen will, wohin sich Websites, Suche und Conversion-Strecken bewegen, darf hier ruhig anfangen zu testen. Genau das tun wir bei WEVENTURE Performance auch. Nicht, weil schon alles standardisiert wäre, sondern weil die Zukunft oft schneller da ist, als viele Teams intern Prozesse, Content und Technik nachziehen können.
Wichtig ist dabei die Trennung zwischen zwei Ebenen: Schema.org und JSON-LD beschreiben Inhalte, Entitäten und Beziehungen, während WebMCP oder agentenspezifische UI-Maps eher in Richtung Interaktion, Tool-Nutzung und Ausführung gehen. Strukturierte Daten sind also nicht die fertige Agentenschnittstelle. Aber sie sind sehr oft die erste saubere Schicht darunter: Maschinen verstehen besser, was eine Seite ist, welche Entitäten wichtig sind, welche Leistung angeboten wird und welche Handlung grundsätzlich denkbar wäre. Schema.org kennt mit Action, potentialAction, SearchAction und EntryPoint seit Jahren genau solche Konzepte für maschinenlesbar beschriebene Aktionen.
Was heute schon mit Schema.org denkbar ist
Wenn du eh an deinen strukturierten Daten arbeitest und im gleichen Atemzug deine Website experimentell auf zukünftige Agenten vorbereiten willst, sind vor allem drei Dinge spannend:
- potentialAction beschreibt, welche Handlung auf einem Objekt grundsätzlich möglich ist.
- SearchAction ist ein spezieller Aktionstyp für Suchvorgänge.
- EntryPoint beschreibt den Zugangspunkt, über den eine Aktion ausgeführt werden kann.
Es ist unwahrscheinlich, dass Google morgen jede Website über solche Properties autonom bedient. Aber es ist eine standardisierte Sprache, mit der du Maschinen nicht nur sagst, was etwas ist, sondern auch, welche Aktion daran hängt. Genau das macht diese Properties im Kontext des Agentic Web wieder deutlich interessanter als noch vor ein paar Jahren.
Plant Amazon agentenspezifische UI-Maps?
Vor Kurzem hat jemand aus unserem Team im Seitenquelltext von Amazon ein interessantes Stück Code entdeckt: ein Block mit type=“application/agent+json“, einem @context unter agent.schema.org und einem Schema-Type namens AgentInterfaceMap. Der Code (siehe unten) wirkte so, als würde er für Agenten definieren, welche Aktion auf der Seite bevorzugt ausgeführt werden soll, welches DOM-Element dafür zuständig ist und welches Eingabefeld dafür relevant ist.
Das ist extrem interessant, weil es einen Schritt weitergeht als klassisches JSON-LD-Markup. Statt nur Inhalte zu beschreiben, wird hier offenbar versucht, eine Benutzeroberfläche zusätzlich als maschinenlesbare Interaktionskarte bereitzustellen. Ein Agent müsste dann nicht mehr nur aus Buttons, Formularen und HTML-Strukturen selbst erschließen, was wichtig ist, sondern bekäme es deutlich direkter mitgeteilt.
Allerdings: Für genau dieses Amazon-Muster gibt es aktuell nach unserem Stand keinen dokumentierten öffentlichen Webstandard, auf den man sich schon verlassen sollte. Deshalb sehen wir es nicht als neues Pflicht-Markup, sondern als sehr interessantes Experiment, das ziemlich gut zeigt, wohin die Reise gehen könnte.
Was heute schon sinnvoll ist – und was noch warten kann
Was du heute schon mitnehmen kannst:
- Strukturierte Daten deutlich sauberer und tiefer umsetzen als nur mit Plugin-Defaults.
- Wichtige Entitäten klar modellieren: Unternehmen, Services, Produkte, Personen, Kontaktpunkte, FAQs, Kategorien.
- Aktionen testweise mitdenken, wenn sie auf der Seite wirklich klar definiert sind, etwa Suchen, Buchen, Anfragen oder Konfigurieren.
- Formulare, Buttons und Suchfelder semantisch sauber bauen, damit Menschen, Suchsysteme und zukünftige Agenten damit arbeiten können.
Was wir aktuell noch nicht empfehlen würden:
- komplett eigene agentenspezifische Interface-Layer ohne klaren Use Case
- große Entwicklungsbudgets nur auf spekulative Protokolle setzen
Unser Blick bei WEVENTURE Performance
Unser Take ist ziemlich klar: Noch muss nicht jede Website voll agentenfähig sein. Aber wer in ein oder zwei Jahren nicht hinterherlaufen will, sollte heute anfangen, die technischen und inhaltlichen Grundlagen zu legen. Wenn Suchsysteme, Assistenten und Agenten stärker in die Customer Journey eingreifen, gewinnt am Ende nicht die lauteste Website, sondern die, die Inhalte, Leistungen und Handlungen am klarsten maschinenlesbar beschreibt und damit den Confidence Score bei KI-Systemen erhöht.
Weißt du, was Google wirklich über deine Website versteht?
Viele Websites haben Inhalte, aber keine klare maschinenlesbare Struktur. Wir analysieren, wie sauber deine Entitäten, Leistungen, Seiten und Markup-Daten miteinander verbunden sind und zeigen dir, wo deine Website für SEO, Rich Results und KI-Sichtbarkeit besser aufgestellt werden kann.
Fazit zu strukturierten Daten
Strukturierte Daten sind längst mehr als ein technisches Extra für SEO. Richtig eingesetzt helfen sie Suchmaschinen, KI-Systemen und perspektivisch auch Agenten dabei, Inhalte, Entitäten und Zusammenhänge besser zu verstehen. Genau deshalb lohnt es sich, das Thema nicht nur oberflächlich mitzudenken, sondern sauber, strategisch und passend zur eigenen Website aufzubauen.
Gleichzeitig muss nicht jedes Unternehmen jedes Detail selbst testen, modellieren und implementieren. Wenn du dir unsicher bist, welche Schema-Typen für deine Website wirklich sinnvoll sind, wie du einen sauberen Entity-Graph aufbaust oder schlicht keine Lust hast, dich selbst durch JSON-LD, Properties und Verknüpfungen zu arbeiten, unterstützen wir dich bei WEVENTURE Performance gern dabei, von der Strategie bis zur konkreten Umsetzung.
FAQ zu strukturierten Daten, JSON-LD und AI Search
Was sind strukturierte Daten einfach erklärt?
Strukturierte Daten sind maschinenlesbare Informationen, die den Inhalt einer Website in standardisierter Form beschreiben. Sie helfen Suchmaschinen und anderen Systemen dabei, Inhalte und Entitäten besser zu verstehen und miteinander zu verknüpfen.
Was ist der Unterschied zwischen Schema.org und JSON-LD?
Schema.org ist das Vokabular, also die Sammlung von Typen und Eigenschaften wie Organization, Article oder Service. JSON-LD ist das Format, in dem diese Informationen auf einer Website eingebunden werden.
Braucht jede Website strukturierte Daten?
Nicht jede Website braucht sofort ein komplexes Schema-Setup, aber fast jede Website profitiert von einer sauberen Grundstruktur. Besonders wichtig sind strukturierte Daten für Unternehmensseiten, Leistungsseiten, Blogs, Produktseiten, Profile und Kontaktseiten.
Welche strukturierten Daten sind am wichtigsten?
Das hängt vom Seitentyp ab. Für viele Websites sind Organization, WebSite, WebPage, BreadcrumbList, Service, Article, Person und ContactPoint ein sehr guter Start. Wichtig ist weniger die Menge als die sinnvolle Auswahl der Informationen und Verknüpfung untereinander
Reicht ein SEO-Plugin wie Yoast oder Rank Math für strukturierte Daten aus?
Für viele Standardfälle ja. Plugins liefern oft eine solide Basis, gerade bei Organization, Article, BreadcrumbList oder allgemeinen WebPage-Typen. Wenn du aber individueller arbeiten willst, zum Beispiel mit eigenen Services, spezifischen Verknüpfungen oder Entity Building, reichen Standard-Setups oft nicht aus.
Sollte man strukturierte Daten manuell ergänzen?
In vielen Fällen ja. Gerade bei strategisch wichtigen Seiten oder komplexeren Websites kann eine manuelle Ergänzung sinnvoll sein, um präziser zu arbeiten. Wichtig ist dabei, dass der Code sauber geprüft wird und nur Inhalte auszeichnet, die auf der Seite wirklich sichtbar vorhanden sind.
Was ist ein Entity-Graph?
Ein Entity-Graph beschreibt das Zusammenspiel mehrerer Entitäten auf einer Website, zum Beispiel Unternehmen, Leistungen, Autor:innen, Artikel, Kontaktpunkte oder Produkte. Ziel ist es, diese nicht isoliert, sondern als zusammenhängendes System zu modellieren.
Warum ist sameAs für Entity SEO wichtig?
Mit sameAs kannst du deine Website mit relevanten externen Profilen und Quellen verbinden, etwa LinkedIn, Crunchbase, GitHub, Wikipedia oder Wikidata. Das hilft Suchmaschinen und KI-Systemen dabei, Entitäten klarer zuzuordnen und deine digitale Identität konsistenter zu verstehen.
Welche Rolle spielen strukturierte Daten für AI Search?
Strukturierte Daten sind kein Garant für Sichtbarkeit in AI Search, aber sie helfen Suchmaschinen und KI-Systemen dabei, Inhalte, Services und Entitäten besser zu verstehen. Je klarer deine Website strukturiert ist, desto leichter fällt es Maschinen, relevante Informationen korrekt einzuordnen.
Braucht man spezielles Markup für Google AI Overviews oder AI Mode?
Nein, aktuell gibt es kein spezielles „AI-Markup“, das Google zusätzlich verlangt. Umso wichtiger sind die Grundlagen: sauber strukturierte Inhalte, sinnvolle Schema-Typen, klare Entitäten und konsistente Informationen.
Können strukturierte Daten dabei helfen, dass meine Marke in KI-Systemen häufiger empfohlen wird?
Sie können dabei helfen, deine Inhalte und deine Marke klarer verständlich zu machen. Das erhöht die Chance, dass Systeme deine Website, deine Leistungen und deine Expertise sauber einordnen können. Entscheidend ist aber immer das Gesamtbild: gute Inhalte, konsistente Signale und technisch saubere Umsetzung.
Was ist der Unterschied zwischen about, mainEntity und mainEntityOfPage?
about beschreibt allgemein, worum es auf einer Seite thematisch geht. mainEntity ist präziser und zeigt, was der Hauptinhalt einer Seite ist. mainEntityOfPage ist das Gegenstück dazu und beschreibt aus Sicht der Entität, dass genau diese Seite ihre zentrale URL ist.
Muss ich die Organization auf jeder Unterseite vollständig ausschreiben?
Nein. Wenn du eine zentrale Organisationsentität sauber aufgebaut hast, kann auf Unterseiten eine Referenz per @id ausreichen. In den meisten Fällen ist es trotzdem sinnvoll, einen kompakten Organisationsknoten mit name, url und logo mitzugeben (evtl. auch Alternativnamen, falls deine Brand unter mehreren Namen bekannt ist, damit es keine Verwirrung gibt).
Sind Breadcrumbs wirklich so wichtig?
Ja, auf Unterseiten sind BreadcrumbList-Daten in der Praxis sehr sinnvoll. Sie helfen Suchmaschinen und KI-Systemen, Seiten innerhalb der Website-Struktur besser einzuordnen. Gerade bei größeren Websites sind sie fast immer empfehlenswert.
Welche Fehler sollte man bei strukturierten Daten vermeiden?
Die häufigsten Fehler sind:
- falsche oder unpassende Schema-Typen
- Markup, das nicht zum sichtbaren Inhalt passt
- doppelte oder widersprüchliche Snippets durch Plugins und manuelle Ergänzungen
- fehlende Verknüpfungen zwischen Entitäten
- zu viel Schema ohne echten Mehrwert
Was bedeutet agentenfähige Website?
Eine agentenfähige Website ist so aufgebaut, dass KI-Systeme oder Agenten Inhalte nicht nur lesen, sondern perspektivisch auch strukturierter nutzen und vielleicht sogar gezielt mit bestimmten Funktionen interagieren können. Strukturierte Daten sind dafür eine gute Grundlage, aber nicht die einzige Voraussetzung.
Was sind potentialAction, SearchAction und EntryPoint?
Das sind Schema.org-Konzepte, mit denen sich mögliche Handlungen maschinenlesbar beschreiben lassen. Sie sind besonders im Kontext von Agenten, AI Search und zukünftigen Interaktionsmustern spannend, aktuell aber noch eher experimentell.
Muss ich meine Website jetzt schon auf das Agentic Web vorbereiten?
Nicht mit riesigem Aufwand und sicher nicht panisch. Aber es ist klug, die Grundlagen heute schon sauber zu legen: klare Entitäten, gute Struktur, sinnvolle Verknüpfungen, semantische Formulare und stabile Seitenlogik. Wer hier früh sauber arbeitet, ist später deutlich besser vorbereitet.
Wann lohnt sich professionelle Hilfe bei strukturierten Daten?
Wenn deine Website viele Seitentypen, Leistungen, Produkte, Autor:innen oder Standorte hat, lohnt sich professionelle Unterstützung oft schnell. Auch wenn du unsicher bist, welche Typen für deine Website sinnvoll sind oder wie du einen sauberen Entity-Graph aufbaust, ist externe Hilfe meist effizienter als Trial-and-Error.
Wie kann WEVENTURE Performance bei strukturierten Daten helfen?
Wir unterstützen bei der strategischen Auswahl der passenden Schema-Typen, beim Aufbau eines sauberen Entity-Graphs, bei der manuellen JSON-LD-Implementierung und bei der Verknüpfung mit SEO-, GEO- und AI-Search-Zielen. Kurz gesagt: nicht nur irgendein Schema auf die Website packen, sondern eines, das wirklich zu deinem Geschäftsmodell passt.
