Strukturierte Daten (schema.org): warum die KI manche Seiten zitiert und andere nicht

Was strukturierte Daten sind

Eine Maschine, die deine Website liest, sieht Text, versteht aber nicht immer, was jedes Ding ist. Strukturierte Daten kleben Etiketten dran: Das ist ein Produkt, das ist sein Preis, das ist eine häufige Frage, das ist der Autor. Das Standardvokabular heißt schema.org und wird sowohl von Suchmaschinen als auch von KI-Modellen genutzt. Dieser Guide erklärt, warum sie dir helfen, zitiert zu werden, welche Typen auf welche Seite gehören, mit vollständigen Beispielen, welche Fehler Glaubwürdigkeit kosten und wie du prüfst, ob alles stimmt.

JSON-LD, der einfache Weg

Es gibt mehrere Arten, Schema zu schreiben, aber die empfohlene ist JSON-LD: ein Script-Block im JSON-Format, den du in den Head oder Body der Seite setzt. Er ändert nichts an dem, was der Nutzer sieht, und bleibt vom sichtbaren HTML getrennt, also ist er leicht zu erzeugen und zu prüfen. Wenn du Cursor, Bolt oder Lovable nutzt, ist die Bitte an deine KI, das JSON-LD für eine bestimmte Seite zu erzeugen, eine Sache von einem Prompt. Die Alternative, Mikrodaten direkt in den HTML-Tags, funktioniert genauso, ist aber schwerer zu pflegen.

Warum es hilft, zitiert zu werden

Wenn ein Modell deine Seite zusammenfassen muss, reduziert Schema die Mehrdeutigkeit. Statt zu folgern, dass eine Zahl ein Preis ist, weiß es das. Statt zu raten, wer den Artikel geschrieben hat, liest es das. Statt abzuleiten, dass „Scanaris" ein Unternehmen und keine Person ist, steht es deklariert da. Weniger Raten heißt mehr Vertrauen, und mehr Vertrauen heißt höhere Wahrscheinlichkeit, als Quelle genutzt zu werden. Außerdem verbindet Schema deine Website mit dem Rest des Internets: Das Feld sameAs verlinkt deine Profile, und das Modell versteht, dass alles von derselben Entität spricht.

Welche Typen du hinzufügst und mit welchen Eigenschaften

Organization auf der Startseite: Name, Logo, URL, Ein-Satz-Beschreibung und sameAs mit deinen öffentlichen Profilen.
SoftwareApplication (oder Product) auf der Produkt- oder Preisseite: Name, Beschreibung, Kategorie, Betriebssystem oder Plattform und offers mit Preis und Währung.
FAQPage dort, wo es echte, sichtbare Fragen und Antworten gibt.
Article oder BlogPosting bei Beiträgen, mit Autor, Veröffentlichungs- und Änderungsdatum.
BreadcrumbList, um Kontext zu geben, wo jede Seite hingehört.
WebSite auf der Startseite, mit dem Namen der Site, was hilft, dass sie in den Ergebnissen korrekt erscheint.

Füg nicht alle einfach so hinzu. Zeichne nur aus, was wirklich auf der Seite steht.

Ein vollständiges Beispiel für eine App

So sieht der Block der Startseite eines Softwareprodukts aus, mit Organisation und Anwendung in einem Graphen:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://deinedomain.com/#org",
      "name": "Dein Produkt",
      "url": "https://deinedomain.com",
      "logo": "https://deinedomain.com/logo.png",
      "description": "Dein Produkt ist ein [was es ist] für [wen], das [was es bewirkt].",
      "sameAs": [
        "https://github.com/deinprodukt",
        "https://www.linkedin.com/company/deinprodukt",
        "https://x.com/deinprodukt"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "name": "Dein Produkt",
      "applicationCategory": "DeveloperApplication",
      "operatingSystem": "Web",
      "url": "https://deinedomain.com",
      "description": "Dein Produkt ist ein [was es ist] für [wen], das [was es bewirkt].",
      "publisher": { "@id": "https://deinedomain.com/#org" },
      "offers": {
        "@type": "Offer",
        "price": "24",
        "priceCurrency": "EUR",
        "url": "https://deinedomain.com/pricing"
      }
    }
  ]
}
</script>

Beachte, dass die Beschreibung in beiden Blöcken derselbe Satz ist, und es sollte derselbe sein, der auf der Startseite, in der Meta-Description und in der llms.txt steht. Diese exakte Wiederholung ist das, was die Modelle am Ende zitieren.

Und eines für häufige Fragen

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Verändert Dein Produkt meine Website?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nein. Es führt reine Lesezugriffe auf öffentliche Informationen durch."
      }
    }
  ]
}
</script>

Jede Frage im JSON muss mit demselben Text im sichtbaren Teil der Seite existieren.

Die häufigsten Fehler

Auszeichnen, was man nicht sieht. Häufige Fragen, die nicht auf der Seite stehen, erfundene Bewertungen, ein Preis im JSON, der vom Preis auf der Seite abweicht. Das kostet Glaubwürdigkeit und kann dir eine manuelle Maßnahme von Google einbringen.
Veraltete Daten. Du änderst den Preis auf der Seite und vergisst das Schema. Erzeuge das JSON-LD aus derselben Datenquelle wie die Seite, nicht von Hand.
Inkonsistenter Name. „Dein Produkt" auf der Startseite, „DeinProdukt" im Schema, „dein-produkt" in den Profilen. Wähl eine Schreibweise und nutz sie überall.
Falscher Typ. Ein physisches Product für einen Webdienst oder ein Article auf einer Preisseite.
Ungültiges JSON. Ein Komma zu viel und der ganze Block wird stillschweigend ignoriert.

Wo es je nach Framework hinkommt

In Next.js ein script-Element mit type="application/ld+json" im Layout oder auf der Seite, mit dem aus einem Objekt serialisierten JSON. In Nuxt mit useHead und einem Script desselben Typs. In einer Vite-SPA in der index.html, wenn der Block statisch ist, oder beim Prerendern injiziert, wenn er je Seite variiert. Wichtig ist, dass es im initialen HTML ankommt: Ein JSON-LD, das erst nach Ausführung von JavaScript existiert, lesen Bots, die nicht rendern, nicht.

Wie du prüfst, ob es stimmt

Fordere deine Seite mit curl an und such den Block:

curl -s https://deinedomain.com/ | grep -o 'application/ld+json' | wc -l

Kommt null heraus, kommt es nicht im HTML an. Validiere danach den Inhalt mit dem Test für Rich-Suchergebnisse von Google oder dem Validator von schema.org, die dir Syntaxfehler und unbekannte Eigenschaften anzeigen. Und lies es selbst: Sagt es dasselbe wie die Seite? Wenn nicht, lügt einer von beiden.

Scanaris prüft dein Schema

Die KI-Sichtbarkeits-Säule von Scanaris erkennt, ob du strukturierte Daten hast, von welchem Typ, ob sie ohne JavaScript im HTML ankommen und ob sie zur Seite passen, und gibt dir einen Fix-Prompt mit dem vorgeschlagenen JSON-LD zum Einfügen in deine KI. Es ist ein reiner Lesezugriff auf das öffentliche HTML deiner Website. Das gehört zum AEO-Guide und zur Betrachtung von SEO und AEO auf derselben Seite.

Häufige Fragen

Bestraft Google fehlerhaftes Schema?

Schema mit Syntaxfehlern wird einfach ignoriert. Irreführendes Schema (Bewertungen oder Fragen auszeichnen, die es nicht gibt) kann eine manuelle Maßnahme nach sich ziehen, die dir die Rich-Ergebnisse nimmt. Zeichne nur das Sichtbare aus.

JSON-LD oder Mikrodaten?

JSON-LD. Das empfehlen Google und schema.org, es wird aus Daten erzeugt, ohne das sichtbare HTML anzufassen, und ist viel leichter zu pflegen.

Braucht man es auf jeder Seite?

Auf den öffentlichen, die verstanden werden sollen: Startseite, Produkt, Preise, Blog, FAQ. Das private Dashboard braucht es nicht, weil niemand von außen es liest.