Strukturierte Daten & JSON-LD: So erklärst du Suchmaschinen und KI deine Inhalte

17. April 2026 #JSON-LD#Schema.org#Strukturierte Daten#SEO#AEO

Strukturierte Daten sind ein maschinenlesbarer Datensatz, den du zusätzlich zum sichtbaren Inhalt in deine Seite einbettest — meist als JSON-LD-Skriptblock im <head>. Damit sagst du Suchmaschinen und KI-Systemen explizit, was ein Inhalt ist: Ist das eine Firma, ein Produkt, ein Artikel, eine FAQ? Schema.org liefert das gemeinsame Vokabular dafür, JSON-LD das Format. Beides zusammen ist heute die zuverlässigste Methode, um Rich Results in Google zu bekommen und von Answer Engines korrekt zitiert zu werden.

TL;DR

JSON-LD ist das von Google bevorzugte Format für strukturierte Daten — getrennt vom HTML, leicht zu pflegen.
Die wichtigsten Typen für die meisten Websites: Organization, WebSite, Service, Article, FAQPage, BreadcrumbList.
@graph verknüpft mehrere Entitäten über @id-Referenzen sauber zu einem Wissensnetz statt zu isolierten Schnipseln.
Markup muss den sichtbaren Inhalt abbilden — sonst riskierst du eine manuelle Abstrafung statt eines Rankings.

Warum strukturierte Daten 2026 kein Nice-to-have mehr sind

Lange galten strukturierte Daten als Kür für SEO-Nerds. Ein paar Sternchen-Bewertungen im Suchergebnis, vielleicht ein FAQ-Akkordeon — nett, aber verzichtbar. Das hat sich geändert, und zwar deutlich.

Der Grund liegt in der Art, wie KI-Systeme Inhalte verarbeiten. ChatGPT, Perplexity, Google AI Overviews und Gemini lesen Webseiten nicht so, wie ein Mensch sie liest. Sie zerlegen Inhalte in Entitäten und Beziehungen — und genau das liefert strukturiertes Markup frei Haus. Wenn dein Organization-Schema sauber sagt, dass Rocket-Monkeys eine Agentur in München ist, mit dieser URL, diesem Logo und diesen Leistungen, muss kein Modell raten. Es hat die Fakten schwarz auf weiß.

Wir sehen das in der Praxis bei jedem Projekt: Seiten mit konsistentem, korrektem Schema werden zuverlässiger und mit den richtigen Attributen zitiert. Das ist kein magischer Ranking-Boost — Google sagt selbst, strukturierte Daten seien kein direkter Ranking-Faktor. Aber sie sind der Türöffner für Rich Results, und sie reduzieren die Mehrdeutigkeit, an der KI-Systeme sonst scheitern. Weniger Mehrdeutigkeit heißt: Du wirst eher richtig verstanden.

JSON-LD vs. Microdata vs. RDFa — was nehmen?

Es gibt drei Syntaxen, um Schema.org-Daten auszuzeichnen. Die Kurzfassung: Nimm JSON-LD.

Format	Wo es lebt	Pflegbarkeit	Google-Empfehlung
JSON-LD	Separater `<script>`-Block	Hoch — getrennt vom HTML	Ja, ausdrücklich
Microdata	Inline in HTML-Attributen	Niedrig — vermischt mit Markup	Wird unterstützt
RDFa	Inline in HTML-Attributen	Niedrig	Wird unterstützt

Microdata und RDFa kleben Attribute wie itemprop direkt ins HTML. Das klingt erst praktisch — die Daten stehen ja beim sichtbaren Element. In der Realität wird es schnell unwartbar, weil jede Layout-Änderung dein Markup zerschießen kann. JSON-LD lebt in einem eigenen Block, idealerweise serverseitig generiert. Du kannst es zentral pflegen, testen und versionieren, ohne das Template anzufassen. Genau deshalb empfiehlt Google es, und genau deshalb setzen wir ausschließlich darauf.

Die Schema.org-Typen, die du wirklich brauchst

Schema.org hat hunderte Typen. Die meisten brauchst du nie. Für eine typische Unternehmens- oder Agenturseite reicht eine Handvoll — aber die richtig.

Organization (und LocalBusiness)

Das Fundament. Organization beschreibt, wer hinter der Website steht. Für lokale Anbieter ist LocalBusiness (ein Untertyp) oft die bessere Wahl, weil du Adresse, Öffnungszeiten und Geo-Koordinaten mitliefern kannst. Das gehört genau einmal auf die Site, idealerweise auf der Startseite oder global per @id referenziert.

WebSite

Beschreibt die Website als Ganzes und kann eine SearchAction enthalten — die Voraussetzung für die Sitelinks-Searchbox in Google. Klein, aber wirkungsvoll.

Service

Für Dienstleister Gold wert. Jede Leistung — bei uns etwa Webentwicklung, KI-Integration, AEO — lässt sich als Service auszeichnen, verknüpft mit dem provider (deiner Organization). So verstehen Maschinen nicht nur, dass es dich gibt, sondern was du anbietest.

Article (bzw. BlogPosting)

Für jeden Blogartikel. Liefert headline, author, datePublished, image und publisher. Genau dieser Beitrag hier trägt ein BlogPosting-Schema. Ohne das ist ein Artikel für eine Answer Engine schwerer als eigenständiges, datierbares Stück Inhalt zu erkennen.

FAQPage

Strukturiert Frage-Antwort-Paare. Vorsicht: Google hat die Rich-Result-Darstellung für FAQ stark eingeschränkt und zeigt sie nur noch für ausgewählte autoritative Seiten. Trotzdem bleibt FAQPage für KI-Systeme nützlich — sie ziehen daraus saubere, zitierfähige Antworten. Bedingung: Die Fragen und Antworten müssen sichtbar auf der Seite stehen. Verstecktes FAQ-Markup ist ein Verstoß gegen die Richtlinien.

BreadcrumbList

Bildet die Navigationshierarchie ab. Sorgt für die hübschen Breadcrumb-Pfade im Suchergebnis statt einer nackten URL — und hilft Crawlern, deine Seitenstruktur zu begreifen.

@graph: Vom Schnipsel zum Wissensnetz

Hier trennt sich solides von oberflächlichem Markup. Viele Seiten streuen drei, vier isolierte JSON-LD-Blöcke über die Seite — einer für die Organization, einer für den Artikel, einer für die Breadcrumbs. Funktioniert, aber jeder Block lebt für sich. Die Maschine sieht keine Verbindung zwischen ihnen.

@graph löst das. Du packst alle Entitäten in ein einziges Array und verknüpfst sie über @id-Referenzen. Die Organization bekommt eine feste @id wie https://rocket-monkeys.com/#organization. Der Artikel verweist dann per publisher: { "@id": "...#organization" } darauf — statt die Organization-Daten zu duplizieren. Das Ergebnis ist ein zusammenhängender Graph, der genau die Beziehungsstruktur abbildet, die KI-Systeme intern ohnehin aufbauen.

Hier ein vollständiges, realistisches Beispiel für eine Blogseite mit verknüpften Entitäten:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://rocket-monkeys.com/#organization",
      "name": "Rocket-Monkeys",
      "url": "https://rocket-monkeys.com",
      "logo": {
        "@type": "ImageObject",
        "url": "https://rocket-monkeys.com/logo.svg"
      },
      "areaServed": "DE",
      "knowsAbout": ["Webentwicklung", "KI-Integration", "AEO", "SEO"]
    },
    {
      "@type": "WebSite",
      "@id": "https://rocket-monkeys.com/#website",
      "url": "https://rocket-monkeys.com",
      "name": "Rocket-Monkeys",
      "publisher": { "@id": "https://rocket-monkeys.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://rocket-monkeys.com/blog/json-ld/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Blog",
          "item": "https://rocket-monkeys.com/blog" },
        { "@type": "ListItem", "position": 2, "name": "Strukturierte Daten & JSON-LD" }
      ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://rocket-monkeys.com/blog/json-ld/#article",
      "headline": "Strukturierte Daten & JSON-LD",
      "datePublished": "2026-06-11",
      "author": { "@id": "https://rocket-monkeys.com/#organization" },
      "publisher": { "@id": "https://rocket-monkeys.com/#organization" },
      "isPartOf": { "@id": "https://rocket-monkeys.com/#website" },
      "mainEntityOfPage": "https://rocket-monkeys.com/blog/json-ld/"
    }
  ]
}
</script>

Schau dir die @id-Verweise an. Die Organization wird einmal definiert und dreimal referenziert — beim Website-Publisher, beim Autor und beim Publisher des Artikels. Keine Duplikate, keine Widersprüche. Genau so soll es sein.

Häufige Fehler, die wir immer wieder sehen

Wir auditieren regelmäßig fremde Sites, und dieselben Stolperfallen tauchen erstaunlich oft auf.

Markup, das nicht zum sichtbaren Inhalt passt. Der Klassiker. Jemand zeichnet eine aggregateRating mit 4,9 Sternen aus, aber auf der Seite steht keine einzige sichtbare Bewertung. Das ist gegen Googles Richtlinien und kann eine manuelle Maßnahme nach sich ziehen. Regel: Markup beschreibt nur, was wirklich auf der Seite ist.

Falsche oder kaputte @id-Referenzen. Du verweist per @id auf eine Entität, die im Graph gar nicht existiert — Tippfehler, fehlendes #fragment, andere URL. Der Verweis läuft ins Leere, die Verknüpfung greift nicht.

Pflichtfelder vergessen. Jeder Typ hat erforderliche und empfohlene Eigenschaften. Ein Article ohne image oder datePublished, eine Organization ohne name — solche Lücken kosten dich das Rich Result oder schwächen die Aussagekraft.

Datumsformate verhauen. Datumsangaben müssen ISO 8601 sein: 2026-06-11, nicht 11.06.2026. Maschinen sind hier gnadenlos.

Mehrere widersprüchliche Organizations. Plugins und Theme generieren oft je ein eigenes Organization-Schema, und plötzlich behauptet deine Seite, zwei verschiedene Firmen zu sein. Konsolidiere auf eine @id.

Verschachtelung statt Referenz. Bei kleinen Sites okay, aber wenn du dieselbe Organization in jeden Artikel hineinkopierst, hast du fünfzig leicht abweichende Versionen. @id-Referenzen sind die saubere Lösung.

Tools zum Testen — und warum du immer testen solltest

Strukturierte Daten von Hand zu prüfen ist mühsam und fehleranfällig. Nutz die Tools. Wir lassen kein Schema live gehen, das nicht durch mindestens zwei davon gelaufen ist.

Schema Markup Validator (validator.schema.org) — prüft gegen das offizielle Schema.org-Vokabular. Strenger und neutraler als Googles Tool, ideal für die reine Syntax- und Typprüfung.
Google Rich Results Test (search.google.com/test/rich-results) — zeigt, welche Rich Results Google aus deinem Markup erkennt und ob sie für die Anzeige qualifiziert sind. Das eigentlich entscheidende Tool, wenn dir die Google-Darstellung wichtig ist.
Google Search Console — der Reality-Check. Unter “Verbesserungen” siehst du, welche strukturierten Daten Google auf deiner live geschalteten Site tatsächlich gefunden hat, inklusive Fehler und Warnungen über die ganze Domain. Kein Tool ersetzt diesen Blick auf echte, gecrawlte Daten.

Ein Workflow, der sich bewährt hat: Erst lokal mit dem Schema Markup Validator die Struktur absichern, dann mit dem Rich Results Test die Google-Tauglichkeit prüfen, nach dem Deployment die Search Console im Auge behalten. Fehler in der Console sind oft die spannendsten, weil sie Probleme zeigen, die im isolierten Test gar nicht auftauchen.

Wie wir das aufsetzen

Bei unseren Projekten generieren wir JSON-LD serverseitig aus denselben Daten, aus denen auch der sichtbare Inhalt entsteht — eine einzige Quelle der Wahrheit. Bei einer Astro- oder Next.js-Seite heißt das: eine zentrale Helper-Funktion, die aus dem Frontmatter oder CMS-Datensatz den @graph baut. Title, Datum, Autor, Breadcrumbs — alles kommt aus derselben Quelle wie das HTML. So kann das Markup gar nicht erst vom sichtbaren Inhalt abweichen, und genau das ist der häufigste Fehler überhaupt.

Der Aufwand ist überschaubar, der Effekt nachhaltig. Einmal sauber aufgesetzt, trägt jede neue Seite ihr korrektes Schema automatisch — ohne dass jemand daran denken muss.

Wenn du wissen willst, ob deine Site Suchmaschinen und KI-Systemen heute schon klar erklärt, wer du bist und was du anbietest, schauen wir uns das gern in einem unverbindlichen Erstgespräch an. Wir auditieren dein bestehendes Markup, zeigen dir die konkreten Lücken und sagen dir, was sich lohnt. Schreib uns einfach an info@rocket-monkeys.com — dann finden wir heraus, wie deine Inhalte endlich so verstanden werden, wie du sie meinst.