Schema.org-Subtypen

Definition

Schema.org-Subtypen sind spezialisierte Typen im Schema.org-Vokabular, die für konkrete Inhaltskategorien definierte Pflicht- und Empfehlungsfelder vorsehen. Statt einer allgemeinen Klassifikation wie CreativeWork beschreibt etwa Recipe ein Kochrezept mit recipeIngredient, recipeInstructions, cookTime und nutrition. Diese semantische Präzision macht den Inhalt für Suchmaschinen und KI-Antwort-Engines maschinenlesbar und ist Voraussetzung für viele Rich-Result-Darstellungen.

Schema.org definiert 2026 über 800 Typen, organisiert in einer hierarchischen Struktur mit Thing als Wurzel. Subtypen erben alle Properties ihrer Eltern und ergänzen sie um spezialisierte Felder. Article hat etwa NewsArticle und BlogPosting als Subtypen, NewsArticle hat zusätzlich Felder wie printSection und printColumn. Die hierarchische Vererbung ist zentral für konsistente Auszeichnung.

Mechanismus und Spezifikation

Subtypen werden in JSON-LD über das @type-Feld ausgezeichnet. Ein Recipe-Markup sieht etwa so aus:

{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "Zürcher Geschnetzeltes",
  "author": {"@type": "Person", "name": "Max Mustermann"},
  "datePublished": "2026-06-07",
  "recipeIngredient": ["500g Kalbfleisch", "200g Champignons"],
  "recipeInstructions": [
    {"@type": "HowToStep", "text": "Fleisch in Streifen schneiden."}
  ],
  "cookTime": "PT30M",
  "nutrition": {"@type": "NutritionInformation", "calories": "450 kcal"}
}

Verschachtelte Typen wie HowToStep, Question, Offer, NutritionInformation oder PostalAddress werden in den Properties gesetzt, in denen sie erwartet werden. Schema.org definiert für jeden Typ die expected types der Properties, sodass eine recipeInstructions-Liste sowohl HowToStep-Items als auch reine Text-Items aufnehmen kann.

Wichtig ist die Unterscheidung zwischen Schema.org-Konformität und Google-Rich-Result-Konformität. Schema.org definiert das Vokabular. Google publiziert in Search Central pro Rich-Result-Typ eine eigene Spezifikation, die häufig mehr Pflichtfelder verlangt, als Schema.org als required markiert. Für Recipe-Rich-Results verlangt Google etwa zusätzlich image und author. Beide Spezifikationen müssen geprüft werden.

Praxis und Anwendung

Wichtige Subtypen mit typischen Use-Cases:

• NewsArticle: Nachrichten und redaktioneller Content. Pflichtnah: headline, image, datePublished, author, publisher.
• BlogPosting: Magazin-artige Inhalte. Felder wie Article plus blog-spezifische Properties.
• Recipe: Kochrezepte. Pflichtnah: name, image, recipeIngredient, recipeInstructions.
• HowTo: Schritt-für-Schritt-Anleitungen. Step-Items mit Bild, Beschreibung und Tools.
• FAQPage: Sammlungen von Question-Items, als Rich Result seit August 2023 auf autoritative Government- und Health-Sites beschränkt.
• Event: Veranstaltungen. Pflichtnah: name, startDate, location (Place oder VirtualLocation).
• Product mit Offer: E-Commerce. Pflichtnah: name, image, offers mit price und availability.
• JobPosting: Stellenangebote. Pflichtnah: title, datePosted, hiringOrganization, jobLocation.
• VideoObject: Videos. Pflichtnah: name, thumbnailUrl, uploadDate.
• LocalBusiness: Lokale Geschäfte. Pflichtnah: name, address, telephone.
• Course: Online-Kurse. Pflichtnah: name, description, provider.
• Dataset: Offene Datensätze. Pflichtnah: name, description, license.

In komplexen Sites werden Subtypen häufig serverseitig im CMS oder Headless-Framework generiert. Templates pro Content-Type liefern konsistente Markups. Validierung erfolgt im Build und im Deploy via Rich Results Test und Schema Markup Validator.

Für AEO-Programme empfiehlt sich eine explizite Subtyp-Strategie: pro Vertical und Content-Type den präzisesten verfügbaren Subtyp wählen, alle Pflichtfelder setzen, möglichst viele Empfehlungsfelder ergänzen und sameAs-Properties für Knowledge-Graph-Linking nutzen (etwa Verlinkung auf Wikidata-Q-IDs).

Häufige Fehler

• Allgemeiner Typ statt Subtyp: Article statt NewsArticle, CreativeWork statt Movie, Thing statt Person verschenkt Citation- und Rich-Result-Chancen.
• Pflichtfelder von Google ignorieren: Schema.org sagt optional, Google verlangt required. Beide Specs prüfen.
• Verschachtelte Typen falsch gesetzt: HowToStep als reines Text-Item statt als typed object reduziert Maschinenlesbarkeit.
• Veraltete Subtypen verwenden: Schema.org deprecated alte Typen, neue Versionen kommen mehrmals jährlich.
• Falsche Hierarchie: ScholarlyArticle als Article auszeichnen verliert spezielle wissenschaftliche Felder.
• JSON-LD-Konflikte: Mehrere @type-Blöcke mit Widersprüchen auf einer Seite verwirren Crawler.
• sameAs-Linking unterlassen: Person, Organization und Place ohne sameAs zu Wikidata oder offiziellen Profilen verschenkt Knowledge-Graph-Anbindung.
• Empfehlungsfelder weglassen: Author, Publisher, datePublished sind oft optional, aber essenziell für AEO-Citation.

Abgrenzung

• Schema.org-Typ vs. Subtyp: Typen sind alle Klassen im Vokabular, Subtypen sind Spezialisierungen mit zusätzlichen Properties.
• Schema.org vs. JSON-LD: Schema.org ist das Vokabular, JSON-LD ist das Format. JSON-LD kann auch andere Vokabulare tragen.
• Schema.org vs. Microformats: Microformats sind ein älteres, leichtgewichtiges Format mit deutlich weniger Verbreitung.
• Schema.org vs. Dublin Core: Dublin Core ist ein klassisches Metadaten-Vokabular für Bibliotheken, weniger granular als Schema.org.
• Schema.org vs. OpenAPI: OpenAPI beschreibt REST-APIs, nicht Content-Inhalte.
• Schema.org vs. RDF: Schema.org ist in RDF formalisiert, aber als kuratiertes Vokabular leichter einsetzbar als freies RDF.