Strukturierte Daten für GEO — JSON-LD @graph & Schema

Strukturierte Daten sind die semantische Schicht deiner Webseite: sie sagen Maschinen, was eine URL darstellt — Firma, Ort, FAQ, Artikel — und wie diese Dinge zusammenhängen. Für GEO und AIO sind sie Zuordnungshilfe, nicht Ersatz für zitierfähigen Fließtext. Dieser Leitfaden ist die Unique-Evidence-Schicht für Schema als GEO-Infrastruktur: @graph-Muster, Typen-Disziplin, sameAs-Regeln, Census-Gap und die klare Grenze zu KI-Zitationen — gebunden an JSON-LD, Schema.org und die Webseite-Modernisierung.

Wie helfen strukturierte Daten bei KI-Sichtbarkeit?

Antwort zuerst: JSON-LD erleichtert die Zuordnung von Marke, Ort, Leistung und FAQ — zitiert wirst du trotzdem nur über extrahierbare HTML-Passagen, nicht über versteckte Properties allein.

Suchmaschinen und generative Engines brauchen zwei Dinge: (1) crawlbares, schnelles HTML mit Direct Answers und (2) eine konsistente Entity-Identität. JSON-LD liefert die zweite Schicht in einem Format, das Parser zuverlässig lesen. Ohne Schema raten Systeme stärker; mit widersprüchlichem Schema raten sie schlechter — und verlieren Vertrauen.

Was Schema kann: Organization und LocalBusiness mit NAP verknüpfen, FAQPage-Paare markieren, Article/DefinedTerm auf Wissens-URLs auszeichnen, @id-Knoten zwischen Seiten referenzieren. Was Schema nicht kann: eine leere Leistungsseite „AI-sichtbar“ machen, Pagebuilder-Rauschen kompensieren oder Princeton-GEO-Taktiken (Stats, Quellen, Zitate) ersetzen. Aggarwal et al. (arXiv:2311.09735) setzen auf belegbare Fakten im sichtbaren Content — Markup ist Infrastruktur, nicht der Visibility-Lift selbst.

Praktisch heißt das für dich: baue zuerst eine Seite, die eine konkrete Frage in zwei bis drei Sätzen beantwortet; hebe danach dieselben Fakten ins @graph. So arbeiten Extraktion (Passagen) und Klassifikation (Typen) zusammen — statt dass du hoffst, ChatGPT würde Properties zitieren, die niemand auf der Webseite liest.

Warum werde ich trotz Schema.org oft nicht in KI-Antworten gefunden?

Antwort zuerst: Weil Markup ohne Direct Answers, mit NAP-Drift, Schema-Spam oder fehlendem @graph-Konsens die Extraktion nicht rettet — und JSON-LD im Census ohnehin oft fehlt (41,9 % Abdeckung).

Typische Fehlmuster aus Audits:

1. FAQ im Schema, keine FAQ im Body — Parser sehen Properties, Nutzer und Passage-Extraktoren nicht.
2. Doppelte Organization-Blöcke (Theme + Plugin + Cookie-Banner-Script) mit unterschiedlichen URLs, Logos oder Telefonnummern.
3. LocalBusiness ohne echte Adresse oder mit Adresse ≠ Footer ≠ Google Business & NAP.
4. sameAs als Linkfarm — Social-Profile, die nicht existieren, oder Themen-URLs als „Identität“.
5. Nur Homepage-Schema — Themen-, Regions- und Glossar-URLs ohne Entity-Markup trotz Content.

Antwort-Engines zitieren Passagen. Wenn deine Direct Answers fehlen, hilft das sauberste @graph nur begrenzt. Vertiefung: AEO & Answer Engines, AIO & AI Overviews, Empirie-Kontext GEO-Empirie 2026/2027.

Was der Census zu JSON-LD zeigt

Antwort zuerst: Crawl-Basics sind relativ verbreitet; semantische Auszeichnung fehlt — viele Dienstleister-Webseiten sind erreichbar, aber schlecht klassifizierbar.

In der AI-Readiness-Studie (6.675 Audits) liegen die relevanten Benchmarks so:

Mehr Zahlen und Methodik: Studie. Lokal spiegeln Bad Schönborn und Bruchsal dasselbe Muster. Der Gap Sitemap/robots ≫ JSON-LD ist das Unique Evidence Asset dieses Artikels: Technical SEO öffnet die Tür; ohne aligned Schema bleibt die Entity unscharf. Schema allein rettet keinen Agent-Ready-Score von 25/100 — aber wer JSON-LD konsequent mit Answer-first-Seiten koppelt, hebt sich vom Felddurchschnitt 41,9 % ab.

Warum Content first vor Schema kommt

Antwort zuerst: Jede Property muss auf der Seite lesbar sein — Preise, Öffnungszeiten, FAQ-Antworten, NAP, Ansprechpartner. Widersprüche zwischen Markup und Fließtext sind Gift für Local und GEO.

Suchmaschinen und KI-Systeme vergleichen strukturierte Aussagen mit sichtbarem Text. Erfundene Öffnungszeiten im Schema, ein anderer Firmenname im Footer oder FAQ-Antworten nur im JSON erzeugen Misstrauen und schlechte Zuordnung. Regel bei Modern Stack: erst die Passage schreiben, dann denselben Fakt ins @graph heben — nie umgekehrt.

Das gilt besonders für:

• NAP und telephone / address (identisch zu Impressum und Maps)
• FAQ-Fragen und -Antworten (Wortlaut sichtbar)
• name / legalName (kein Marketing-Alias nur im Schema)
• Preise und Angebote (nur wenn öffentlich auf der Seite genannt)

Siehe auch FAQ-Struktur und Local SEO & Regionen.

Was ist ein JSON-LD @graph — und wie setzt du ihn ein?

Antwort zuerst: @graph ist ein Array von Schema-Knoten mit stabilen @id, die sich gegenseitig referenzieren — ein Block statt vieler widersprüchlicher Script-Inseln.

Statt drei Plugins je ein Organization-Snippet zu injizieren, lieferst du einen JSON-LD-Block, in dem Organization, Place, WebSite, FAQPage und Article über @id verknüpft sind. Vorteile:

• eine Wahrheitsquelle pro Entity
• keine doppelten, driftenden @type-Blöcke
• klare Kanten (provider, mainEntity, about, isPartOf)
• wartbar im Code — nicht im Yoast-/Rank-Math-Zufall

Prinzipbeispiel (Felder müssen mit sichtbarem Content und Impressum übereinstimmen — Platzhalter-Host ersetzen):

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Beispiel GmbH",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/beispiel/",
        "https://www.wikidata.org/wiki/Q0"
      ]
    },
    {
      "@type": "LocalBusiness",
      "@id": "https://example.com/#localbusiness",
      "name": "Beispiel GmbH",
      "url": "https://example.com/",
      "telephone": "+491234567890",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Musterstraße 1",
        "postalCode": "76669",
        "addressLocality": "Bad Schönborn",
        "addressCountry": "DE"
      },
      "parentOrganization": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/leistungen/migration#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Was kostet die Migration?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Basis ab 500 € für bis zu 10 Seiten — Details stehen sichtbar auf der Seite."
          }
        }
      ]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/themen/structured-data-geo#article",
      "headline": "Strukturierte Daten für GEO",
      "author": { "@id": "https://example.com/#organization" },
      "publisher": { "@id": "https://example.com/#organization" },
      "mainEntityOfPage": "https://example.com/themen/structured-data-geo"
    }
  ]
}

Offizielles Vokabular: Schema.org. Praxisregeln zu Alignment: Google Intro to structured data.

Welche Kern-Typen brauchst du: Organization, LocalBusiness, FAQPage, Article?

Antwort zuerst: Wenige saubere Typen schlagen Schema-Spam — jede Property muss auf der Seite belegbar sein; Typen ohne sichtbaren Block weglassen.

Organization

Domain-weite Identität: Name, URL, Logo, optional sameAs. Eine kanonische Organization mit stabilem @id (z. B. https://deine-domain/#organization) — referenziert von Article, Service und LocalBusiness. Vertiefung: Organization-Schema.

LocalBusiness

Nur wo Leistungsort und NAP sichtbar sind. Adresse, Telefon, Öffnungszeiten (falls genannt) müssen Footer, Impressum und Google Business treffen. Für reine Remote-/Content-Seiten reicht oft Organization ohne LocalBusiness-Doppelung. Vertiefung: LocalBusiness-Schema, Regionen über Local SEO.

FAQPage

Nur bei echten Q&A-Blöcken auf derselben URL. Keyword-Listen als Pseudo-FAQ sind Spam. Antwort-Engines extrahieren sichtbare Paare; verstecktes Markup ohne Text hilft nicht. Vertiefung: FAQPage-Schema, FAQ-Struktur.

Article (und DefinedTerm)

Themen-, Studien- und Fachartikel tragen Article (Headline, Publisher, mainEntityOfPage). Glossar-Begriffe tragen DefinedTerm, wenn die Seite eine echte Definition liefert — nicht drei Bullet-Teaser. Primärstudien unter /studie eignen sich für Article-/Dataset-nahe Auszeichnung, solange Methodik und Stichprobe auf der Seite stehen.

Service / Offer / Place (optional)

Auf Leistungsseiten: Service oder Offer nur mit dem, was Nutzer sehen — Leistungsname, Einsatzgebiet, Preisrahmen nur wenn öffentlich. Place für Regionen mit verifizierten sameAs (Wikidata/Wikipedia), nicht nur internen Pfaden.

Wie hältst du sameAs-Disziplin?

Antwort zuerst: sameAs bedeutet „dieselbe reale Entität“ — nicht „irgendwie thematisch verwandt“. Nur verifizierte Identitäts-URLs, nie Keyword- oder Themen-Spam.

Erlaubt und sinnvoll:

• Google Business Profile (kanonische Maps-/GBP-URL)
• LinkedIn Company / Person, wo öffentlich und aktuell
• Wikidata / Wikipedia für Orte und klar definierte Entities
• Weitere offizielle Profile der Marke (kein Fake-Social)

Verboten bzw. schädlich:

• erfundene oder tote Profil-Links
• interne Blog-/Themen-URLs als sameAs
• Konkurrenz- oder Branchenverzeichnis-Spam ohne Identitätsbezug
• zehn schwache Social-Accounts statt zwei harter Identitätsanker

Jede neue Regions- oder Themen-URL erbt dieselbe Disziplin: Place-sameAs nur mit verifizierten Externals; Organization-sameAs zentral pflegen, nicht pro Seite neu erfinden. Drift zwischen Schema-sameAs und sichtbaren Footer-Links zerstört genau die Entity-Klarheit, die GEO braucht.

Wie hängen strukturierte Daten und GEO zusammen — ohne Schema-als-Zitat?

Antwort zuerst: Schema ist Entity-Infrastruktur für Zuordnung; GEO-Sichtbarkeit braucht zusätzlich Answer-first-HTML, Claims mit Quellen und oft thematische URLs — Markup allein ist kein Zitationsversprechen.

Trennung, die Modern Stack hart hält:

QI-GEO und QI-GEO-Definition helfen, Qualität der Extraktion zu bewerten — nicht „Schema-Score = Sichtbarkeit“. Princeton GEO (Aggarwal et al.) zeigt Lifts über Stats, Quellen und klare Aussagen auf extrahierbaren Seiten. Reihenfolge bei Modern Stack: Stack/Technical SEO → aligned Schema → thematische Entity-URLs → Conversion. llms.txt für Agenten und Markdown-Negotiation sind optionale Maschinen-Layer daneben, nicht statt @graph.

Kurz: Readiness (technische Scores inkl. JSON-LD) ≠ Visibility (tatsächliche Nennungen in KI-Antworten). Beides anstreben ist ok — Claims nicht vermischen.

Wie setzt Modern Stack Schema in Migration und Betrieb um?

Antwort zuerst: JSON-LD kommt mit der Webseite-Modernisierung im Code — nicht als Plugin-Zufall — und wächst mit thematischen Entity-URLs URL für URL.

Nach WordPress-Migration oder Redesign entfallen Yoast-/Theme-Doppelungen. Stattdessen: ein @graph pro Seitentyp, stabile @id, Alignment-Checks im Release. Optional erweitert Knowledge Graph Schema auf Themen-, Regions- und Glossarseiten konsistent — Census-Gap 41,9 % wird so pro URL geschlossen, nicht nur auf der Startseite.

Validierung nach Go-Live und nach Content-Updates:

1. Rich-Results- / Schema-Validator-Stichprobe
2. Abgleich Markup ↔ Fließtext (NAP, FAQ, Headline)
3. Keine doppelten widersprüchlichen @id
4. sameAs-URLs live erreichbar und identitätsrichtig
5. AI-Bot-Allowlist und Crawl-Smoke bleiben Teil der Technical-SEO-Basis

Referenz mit sauberem Stack und Schema: Mallorca Expats; weitere Praxis: Alexandre Liard.

Welche Fehler killen GEO-Nutzen von Schema?

Antwort zuerst: Widerspruch, Spam und Veraltung — nicht „zu wenig Typen“.

Audit-Klassiker:

• @type passt nicht zum sichtbaren Angebot (z. B. Product-Schema ohne Shop)
• FAQPage ohne FAQ-Body
• mehrere Organization-Blöcke mit verschiedenen Telefonnummern
• LocalBusiness ohne echte Adresse oder mit veraltetem NAP
• sameAs-Leichen und Themen-Spam
• Schema nur einmal beim Launch gepflegt, danach Content geändert ohne Markup-Update
• Microdata + JSON-LD + Plugin-JSON gleichzeitig und widersprüchlich

Nach jeder inhaltlichen Änderung gehört Markup ↔ Fließtext zum Release — nicht nur ein einmaliger Test am Freitag vor Cutover. So bleibt Schema langfristig GEO-tauglich statt nach dem ersten Deploy zu veralten. Branchen-Kontext (Physio, Steuer, Handwerk): Schema folgt dem sichtbaren Leistungsversprechen — siehe u. a. Physiotherapie, Steuerberater, Handwerk.

Vergleich: Plugin-Zufall vs. Modern-Stack-@graph

Checkliste vor dem Schema-Go-Live

Antwort zuerst: Schema geht live erst, wenn Markup, sichtbarer Text und Crawl-Basics auf Staging übereinstimmen — nicht wenn der Validator „grün“ blinkt.

• Eine kanonische Organization mit stabilem @id
• LocalBusiness nur wenn NAP sichtbar und deckungsgleich
• FAQPage nur bei echten FAQ-Blöcken
• Article auf Wissens-/Themen-URLs; DefinedTerm nur bei Definitionen
• @graph ohne doppelte, widersprüchliche Knoten
• sameAs nur verifizierte Identitäts-URLs
• Rich-Results-Stichprobe + Markup↔Text-Abgleich
• Nach Content-Updates erneut prüfen (nicht nur Launch)
• Technical SEO parallel: Canonical, Sitemap, robots, Redirects
• Kein Anspruch „Schema = ChatGPT-Zitat“ in Copy oder Claims

Wenn du unsicher bist, ob ein Typ gerechtfertigt ist: lass ihn weg. Ein sauberer Organization-Knoten plus Article auf Wissens-URLs schlägt ein aufgeblähtes Schema mit zehn Typen und null Alignment. Der Census-Wert 41,9 % misst ohnehin nur „JSON-LD erkennbar“ — nicht Qualität. Dein Ziel ist Qualität pro URL, nicht ein weiterer Plugin-Blob.

Kurz: Strukturierte Daten sind GEO-Infrastruktur — Entity klar machen, Content belegen, Census-Gap schließen. Zitationen verdienst du mit Answer-first-Seiten. Anfrage stellen