SÄULE 02 · VERTRAUEN & AUTORITÄT
Teil der Business Growth Architecture. Maschinen- und Menschenvertrauen als Conversion-Voraussetzung - Entity, Reputation, Knowledge Graph.
Säule ansehen →
Structured Data Engineering · Aktualisiert: 23. September 2026

Schema.Als Graph,nicht Fragment.

Als technischer SEO-Architekt biete ich Ihnen die komplette Schema.org-Implementation als Projekt-Service an: Ich liefere einen produktions-ready JSON-LD-Graph mit @id-Verknüpfungen für Person, Organization, Article, Product, FAQPage und HowTo, validiert, deployed und CI-gegated. Unterstützte Stacks: Next.js, Nuxt, Astro, WordPress, Shopify, HubSpot, plus GTM-Fallback für Legacy.

Kerntypen
OrganizationPersonArticleProductFAQPageHowTo
Murat Ulusoy
JSON-LD Graph
„Schema ohne @id-Graph ist wie ein Satz ohne Syntax."
Murat Ulusoy
CEO · Head of SEO · SUMAX
Validiert100 %
30+
Schema-Typen
@id
Graph-Kohärenz
100 %
Validiert
CI-Gate
Deployment
01 - Schema-Typen

Kern-Stack für SEO & GEO.

01

Organization

Name, logo, url, sameAs, founder, foundingDate, knowsAbout, identifier (LEI/HRB).

02

Person

name, jobTitle, worksFor, sameAs (LinkedIn/ORCID), alumniOf, knowsLanguage.

03

Article / BlogPosting

headline, author (@id), datePublished, dateModified, articleSection, mentions.

04

Product

name, brand (@id), sku, gtin, offers, aggregateRating, review, isVariantOf.

05

FAQPage

mainEntity: Question + acceptedAnswer. Seit Mai 2026 ohne Rich-Result-Ausspielung — bleibt als saubere, maschinenlesbare Q&A-Deklaration bestehen.

06

HowTo

step, supply, tool, totalTime. Für Tutorial-Inhalte: LLMs ziehen HowTo-Strukturen häufig als Antworten.

07

LocalBusiness

address, geo, openingHours, telephone, priceRange. Grundlage für Local Knowledge Panels.

08

BreadcrumbList

Positionierte URL-Hierarchie. Pflicht für informationale Hubs.

09

Event / Course / JobPosting

Domain-spezifische Typen mit Rich-Result-Potenzial.

02 - Definition

Was bedeutet Schema-Implementation 2026?

Schema-Implementation bedeutet 2026 Structured-Data-Engineering als laufender Prozess, kein einmaliges Plugin-Setup. Im Zentrum steht JSON-LD, das Google in seiner Dokumentation als in den meisten Fällen einfachstes Format empfiehlt, gegenüber Microdata oder RDFa. Microdata verschachtelt Schema-Properties direkt in HTML-Attribute (itemprop, itemscope) und macht Templates fragil; JSON-LD läuft als eigenständiger script-Block, sauber getrennt vom Content, leichter zu warten und gut geeignet für Headless- und JAMstack-Architekturen. Entscheidend ist die Architektur als @id-Graph: Statt isolierter Fragmente verknüpft ein Mini-Knowledge-Graph alle Entities der Domain über stabile @id-URIs. Article referenziert Person (Author) per @id und Organization als publisher, alles auf konsistenten Knoten. Erst ein kuratierter sameAs-Cluster (LinkedIn, Wikidata, gepflegte Autoren- und Branchenprofile) macht die Entität als konsistenten Knoten lesbar. Ob daraus ein Knowledge Panel, ein Rich Result oder eine KI-Zitation wird, entscheidet Google; eine Garantie gibt es laut Google selbst bei korrektem Markup nicht.

Rich Results sind nicht mehr der Hauptgrund für Schema. FAQ-Rich-Results erscheinen seit dem 7. Mai 2026 nicht mehr in der Google Suche, und Google dokumentiert, dass für AI Overviews und AI Mode kein spezielles Markup nötig ist. Schema bleibt trotzdem Pflicht: für die weiterhin unterstützten Search-Features, für die maschinenlesbare Beschreibung von Entitäten und als Konsistenz-Fundament für alle weiteren Entity-Signale. Professionelle Implementation verlangt Entity-zentrierte Modellierung, Validation gegen Schema.org-Vokabular und Rich Results Test und CI/CD-Integration mit Quality Gates: Jedes Deployment durchläuft ein Validierungs-Set, bevor es in Production geht.

FORMAT

JSON-LD-Architektur

Eigenständiger script-Block mit application/ld+json, getrennt von HTML-Templates. Komplette Graphen statt verschachtelter Microdata-Attribute - prädestiniert für Headless, Next.js, Astro.

GRAPH

Entity-Verknüpfung

@id-URIs als Anker, sameAs-Cluster zu Wikidata, LinkedIn, ORCID, Crunchbase. Article referenziert Author per @id, Organization per publisher-@id. Knowledge-Graph-Lesbarkeit als Ziel.

PIPELINE

CI/CD-Integration

Schema-Generierung als Build-Step, Versionierung im Repo, automatisierte Validation gegen Rich Results Test und Schema.org Validator vor jedem Deployment in Production.

QUALITY

Quality Gates

Validation-Pass-Rate, @id-Kohärenz-Prüfung, Property-Coverage-Threshold, Schema-Drift-Detection nach Content-Updates. Deployment-Block bei Validation-Fehlern.

03 - Phasen

Vier Phasen bis Produktion.

Jede Schema-Implementation folgt einer dokumentierten Phasenlogik mit klaren Übergabepunkten, vom initialen Crawl-Audit über Schema-Design und Deployment bis zu kontinuierlichem Drift-Monitoring. Die Phasen werden an Stack-Komplexität und Content-Frequenz angepasst.

01

Audit & Gap-Analyse

Crawl aller URLs, Extraktion bestehender Schema-Blöcke, Validitäts-Check, @id-Kohärenz-Prüfung, Property-Coverage-Analyse, Wettbewerber-Schema-Vergleich, Priorisierungs-Matrix.

CrawlerValidatorCoverage
02

Schema-Design

Entity-Mapping, @id-Namespace-Definition, Property-Matrix pro Content-Typ, Vererbungsregeln für Template-Injection, sameAs-Cluster-Strategie, Wikidata-Verknüpfung.

@id-NamespaceInheritancesameAs
03

Implementation

CMS-Plugin, Template-Injection (Next.js/Nuxt/Astro) oder GTM-Fallback. Version-Control im Repo, Review-Gates im PR-Workflow, automatisierte Validation in der Deployment-Pipeline.

Next.jsWordPressGTM
04

Monitoring

Rich-Result-Test automatisiert in CI, Graph-Kohärenz-Gate, Monitoring auf Schema-Drift nach Content-Updates, monatlicher Coverage-Report, Alerts bei Validation-Regressions.

CI/CDDrift-WatchAlerts
04 - Schema-Typen

Sechs Kerntypen mit Property-Tiefe.

Jeder Schema-Typ hat eine eigene Property-Logik. Erst saubere Property-Coverage macht Schema-Blöcke für Knowledge Graph und LLMs lesbar, generische Minimal-Implementierungen bleiben Fragmente. Diese sechs Kerntypen decken 90 % der typischen Domain-Architekturen ab.

01 - ENTITY ROOT

Organization

Pflicht-Properties: name, url, logo, sameAs (LinkedIn, Wikidata, Crunchbase), founder, foundingDate. Erweitert: identifier (LEI, HRB, DUNS), knowsAbout, areaServed, contactPoint, address. Root-Entity für jeden @id-Graph.

02 - AUTHORITY

Person

Pflicht: name, jobTitle, worksFor (@id zu Organization), sameAs (LinkedIn, ORCID, Wikidata, Mastodon). E-E-A-T-Hebel: alumniOf, knowsAbout, knowsLanguage, award, hasCredential. Author-Entity für Article.

03 - COMMERCE

Product

Pflicht: name, brand (@id), sku, gtin, offers (price, priceCurrency, availability, priceValidUntil). Rich-Result-relevant: aggregateRating, review, isVariantOf, hasMerchantReturnPolicy, shippingDetails.

04 - EDITORIAL

Article / BlogPosting

Pflicht: headline, author (@id zu Person), publisher (@id zu Organization), datePublished, dateModified, image. GEO-relevant: articleSection, mentions (@id zu erwähnten Entities), about, citation.

05 - DIALOG

FAQPage / HowTo

FAQPage: mainEntity (Question + acceptedAnswer). HowTo: step, supply, tool, totalTime, estimatedCost. Einordnung: Beide lösen keine Rich Results mehr aus (FAQ seit Mai 2026 eingestellt) — implementiert werden sie als semantische Struktur-Deklaration, nicht als Ausspielungs-Hebel.

06 - YMYL

MedicalEntity

Subtypen: MedicalCondition, Drug, MedicalProcedure, MedicalGuideline. Pflicht: code (ICD-10, SNOMED), guideline, recognizingAuthority, evidenceLevel. YMYL-relevant, mit höchster E-E-A-T-Anforderung.

05 - Abgrenzung

Manuell, Plugin, SaaS oder Custom Engineering?

Vier verschiedene Implementierungspfade mit sehr unterschiedlichen Cost-Outcome-Profilen. Die Wahl hängt von Stack-Komplexität, Content-Frequenz, Team-Reife und Anspruch an @id-Graph-Kohärenz ab. Custom Schema Engineering ist die Antwort, wenn Knowledge-Graph-Wirksamkeit und CI/CD-Integration ernsthaft verfolgt werden.

KriteriumManuelle ImplementationCMS-PluginsAutomated SaaSCustom Schema Engineering
@id-Graph-KohärenzTheoretisch, schwer skalierbarSelten, meist Fragment-OutputTeilweise, Template-gebundenVoll, als Architektur-Prinzip
WartungHoher Aufwand pro URLAuto, aber Black-BoxAuto via Vendor-UpdatesCI/CD-gegated, versioniert
ValidationManuell pro ReleasePlugin-abhängig, meist fehlendSaaS-internAutomatisierte Quality Gates
Custom Schema-TypenVoll möglichEingeschränkt (Plugin-Scope)Vendor-Roadmap-abhängigVoll möglich, inkl. Branchenlogik
sameAs & WikidataManuellSeltenSeltenStrategisches Cluster
Geeignet fürSingle-Page-SitesStandard-CMS, kleine SitesE-Commerce-StandardfälleEnterprise, Multi-Market, GEO
06 - Investment

Drei Engagement-Modelle.

Investmentlogik richtet sich nach Stack-Komplexität, Anzahl Content-Typen, internationaler Asymmetrie und Maintenance-Tiefe. Alle Modelle inkludieren Validation gegen Rich Results Test und Schema.org Validator, dokumentierten @id-Namespace und einen Hand-Off-Plan. Konkrete Konditionen werden im Scope-Gespräch nach Stack-Discovery definiert.

SPRINT

Audit-Sprint

4-6 Wochen, fester Scope. Crawl- und Validierungs-Audit, Gap-Analyse, Property-Coverage-Report, Wettbewerber-Vergleich, priorisierter Implementation-Plan.

  • Crawl aller URLs + Schema-Extraktion
  • Validation gegen Rich Results Test
  • @id-Kohärenz-Prüfung
  • Implementation-Roadmap
PROJECT

Implementation-Project

8-16 Wochen. Schema-Design, Template-Injection, CI/CD-Integration, Quality Gates, sameAs-Cluster-Aufbau, Wikidata-Verknüpfung, Production-Deployment.

  • @id-Namespace + Property-Matrix
  • Template-Injection (Next.js/WP/Shopify)
  • CI/CD-Validation-Gates
  • sameAs-Cluster + Wikidata
RETAINER

Continuous Schema Engineering

Retainer 6-12 Monate. Drift-Monitoring, Quality-Gate-Wartung, neue Schema-Typen pro Roadmap, Wettbewerber-Tracking, monatlicher Coverage-Report.

  • Schema-Drift-Monitoring
  • Neue Content-Typen onboarden
  • Wettbewerber-Schema-Tracking
  • Monatliches Executive-Reporting
07 - Verwandt

Schema im größeren Stack.

08 - FAQ

Häufige Fragen.

Antworten auf die häufigsten Fragen zu Schema.org-Implementation, JSON-LD-Architektur und Continuous Schema Engineering. Weitere Fragen werden im Scope-Gespräch geklärt.

Was ist JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) ist das von Google bevorzugte Format für strukturierte Daten. Eingebettet als script-Block mit MIME-Typ application/ld+json, getrennt von HTML-Templates, wartungsarm, prädestiniert für Headless- und JAMstack-Architekturen.

JSON-LD vs. Microdata - was ist besser?

JSON-LD ist 2026 vorzuziehen. Microdata verschachtelt Properties direkt in HTML-Attribute (itemprop, itemscope), und das macht Templates fragil. JSON-LD läuft als eigener Block, kann komplette Graphen darstellen, ist von Google explizit empfohlen. Microdata bleibt Legacy-Lösung.

Was ist ein @id-Graph?

Verknüpfter Schema-Graph über stabile @id-URIs: Article referenziert Person (Author) und Organization (Publisher) per @id. Das ergibt einen konsistenten Mini-Knowledge-Graph pro Domain. Voraussetzung für Knowledge-Graph- und LLM-Lesbarkeit.

Wie verhält sich Schema zum Knowledge Graph?

Schema-Markup ist das wichtigste deklarative Signal an Googles Knowledge Graph. Über sameAs-Properties verknüpfen Sie zu Wikidata, LinkedIn, Crunchbase, ORCID. Erst dann wird Ihre Entity als verifizierter Knoten lesbar, was Voraussetzung für Knowledge-Panel-Emergenz ist.

Welche Rich Results funktionieren 2026 noch?

Laut Googles Search Gallery weiterhin unterstützt: Product, Recipe, Event, JobPosting, Kursliste (Course), Movie, BreadcrumbList, Article, LocalBusiness, VideoObject. Eingestellt: FAQ-Rich-Results erscheinen laut Google-Dokumentation seit dem 7. Mai 2026 nicht mehr in der Google Suche; HowTo wurde bereits zuvor entfernt. FAQPage-Markup bleibt als semantische Deklaration valide, löst aber kein SERP-Feature mehr aus. Wichtiger als Rich Results sind heute Knowledge-Graph-Signale und konsistente Entity-Resolution.

Welche Tools werden zur Validation genutzt?

Rich Results Test + Schema.org Validator (validator.schema.org) + Bing Webmaster Markup Validator + eigener Graph-Kohärenz-Parser für @id-Referenzen und Property-Coverage, automatisiert als CI-Gate vor jedem Deployment.

Was bedeutet Schema für GEO und LLM-Citations?

Google dokumentiert: Für die generativen KI-Funktionen der Google Suche ist kein spezielles Schema-Markup erforderlich — strukturierte Daten sind kein AI-Ranking-Schalter. Eigene Daten: In unserer Audit-Kohorte korrelieren konsistente Person-/Organization-Graphen mit kuratiertem sameAs-Cluster mit stabilerer Entity-Auflösung über Modelle hinweg — Beobachtung, keine Google-Zusage. Fazit: Schema ist Entity-Fundament und Pflicht-Hygiene, kein GEO-Geheimhebel.

Wie wird Schema-Maintenance organisiert?

Drei Säulen: Schema-Drift-Monitoring nach Content-Updates, CI/CD-Validation-Gates vor jedem Deployment, quartalsweise Schema-Audits mit Coverage-Report. Schema ist kein Einmal-Projekt, sondern laufender Engineering-Prozess.

Welche KPIs misst eine Schema-Implementation?

Primär: Validation-Pass-Rate (Ziel 100 %), @id-Graph-Kohärenz, Property-Coverage pro Content-Typ, Rich-Result-Impressions in Search Console. Sekundär: Knowledge-Panel-Emergenz, Citation-Rate in AI-Suchsystemen, sameAs-Cluster-Größe, Wikidata-Verknüpfung.

Was kostet eine professionelle Schema-Implementation?

Investment richtet sich nach Stack-Komplexität, Anzahl Content-Typen, Internationalisierung und Maintenance-Tiefe. Drei Modelle: Audit-Sprint (4-6 Wochen), Implementation-Project (8-16 Wochen), Continuous Schema Engineering (Retainer, 6-12 Monate). Konditionen nach Stack-Discovery.

Wie läuft das Onboarding ab?

Vier Schritte über die ersten 14 Tage: Stack-Discovery (CMS, Frameworks, Pipeline), Crawl- und Validierungs-Audit aller URLs, Gap-Analyse mit Property-Matrix pro Content-Typ, Implementation-Plan mit @id-Namespace und Inheritance-Regeln. Anschließend startet die Implementation- oder Engineering-Phase.

Let's talk

Ihr Schema - Graph oder Fragmente?

30 Minuten: Live-Audit Ihrer aktuellen Schema-Implementierung, Gap-Diagnose, Scope-Vorschlag.