hasPart (Schema-Property)

1. Kurzdefinition

hasPart ist eine Schema.org-Property, die eine Container-Entity mit ihren Bestandteilen verknüpft — der hierarchische Mechanismus, um Composition-Beziehungen zwischen Werken, Sammlungen und ihren Sub-Elementen maschinenlesbar zu machen.

2. Ausführliche Erklärung

hasPart ist die Schema.org-Property, die ausdrückt: „Diese Entity besteht aus diesen Sub-Entities.“ Sie verknüpft Container mit ihren Bestandteilen — typische Use-Cases sind Bücher mit Kapiteln, Frameworks mit Sub-Dimensionen, Veranstaltungs-Reihen mit Einzel-Events, Podcast-Serien mit Episoden.

Aus GEO-Sicht ist hasPart ein Hierarchie-Hebel im Wissensgraph. KI-Modelle können über hasPart-Verknüpfungen die Composition einer Entity erkennen — bei einer Anfrage wie „Was sind die fünf Dimensionen des SEAKT-Frameworks?“ kann das Modell direkt aus den hasPart-Werten antworten, ohne aus Volltext rekonstruieren zu müssen.

Technisch lebt hasPart an CreativeWork-Sub-Types (Book, Article, MusicAlbum, MovieSeries, Course, Framework). Der Wert ist typisch ein Array von Entity-Referenzen via @id auf die einzelnen Bestandteile. Bei geoquality.ai's SEAKT-Framework-Entity wird hasPart genutzt, um die fünf Dimensionen (Strukturelle Daten, Entity-Klarheit, Autorität, Content-Qualität, Technische Zugänglichkeit) als eigenständige DefinedTerm-Sub-Entitäten zu verlinken.

Die Property ist semantisch reziprok zu isPartOf: wenn A hasPart B, dann B isPartOf A. Best Practice ist bidirektionale Auszeichnung — Container hat hasPart-Liste, jedes Sub-Element hat isPartOf-Verweis zurück. Damit ist die Hierarchie aus beiden Richtungen navigierbar, was KI-Modellen die Knowledge-Graph-Traversal erleichtert.

Für eine Schweizer KMU bedeutet hasPart konkret: bei strukturierten Inhalten mit klarer Composition (z. B. eine Themenreihe mit fünf Blog-Posts, ein Online-Kurs mit Modulen, ein Service-Paket aus Einzelleistungen) die hasPart-Property auszeichnen. Der Container-Inhalt hat eine hasPart-Liste der Sub-Elemente, jedes Sub-Element hat isPartOf zurück. Diese bidirektionale Verknüpfung verdichtet den lokalen Wissens-graph und macht hierarchische Beziehungen explizit.

3. Praxisbeispiel

Course mit hasPart-Verknüpfung auf Module:

{
  "@type": "Course",
  "@id": "https://www.beispiel.ch/kurs/mwst-2026#course",
  "name": "MWST 2026 Praxis-Kurs",
  "hasPart": [
    { "@id": "https://www.beispiel.ch/kurs/mwst-2026/modul-1#module" },
    { "@id": "https://www.beispiel.ch/kurs/mwst-2026/modul-2#module" },
    { "@id": "https://www.beispiel.ch/kurs/mwst-2026/modul-3#module" }
  ]
}

Drei Module via @id-Referenzen verlinkt. Jedes Modul hat isPartOf zurück auf den Course (bidirektional). KI-Modelle können bei Anfragen wie „Wie ist der Kurs aufgebaut?“ direkt aus der hasPart-Liste antworten.

4. Typische Fehler & Missverständnisse

×hasPart als Plain-String-Liste statt @id-Referenzen — verliert die strukturelle Verknüpfung.
×hasPart ohne korrespondierende isPartOf-Verweise an den Sub-Elementen — fehlt die Bidirektionalität.
×hasPart bei Entitäten ohne klare Composition-Beziehung — die Property ist für hierarchische Strukturen, nicht für lose Verlinkung.
×Sub-Elemente nicht als eigene Entities mit @id auszeichnen — dann funktionieren die hasPart-Verweise nicht.
×hasPart und mentions verwechseln — hasPart ist Composition (echter Bestandteil), mentions ist Erwähnung (kein struktureller Teil).

5. Best Practices

✓Verwende hasPart nur bei klaren Composition-Beziehungen — Container und seine Bestandteile, nicht für lose Verlinkungen.
✓Pflege bidirektional: Container hat hasPart-Liste, Sub-Elemente haben isPartOf zurück.
✓Verwende @id-Referenzen statt verschachtelte Voll-Definitionen — saubere Knoten-Trennung im Graph.
✓Bei langen hasPart-Listen (>20 Elemente): überlege Sub-Container-Strukturen, sonst wird der Graph unübersichtlich.
✓Halte hasPart-Sub-Elemente als eigenständige Entities mit eigenen Properties — sie sind nicht nur Verweise, sondern echte Knoten.
✓Bei Schema.org-Sub-Types nutzen: Course mit Modul-hasPart, Book mit Chapter-hasPart, MusicAlbum mit Track-hasPart.

6. Fakten

hasPart ist seit Schema.org 1.0 (2011) verfügbar und gehört zum Core-Vokabular für CreativeWork.
Die Property ist reziprok zu isPartOf — beide gemeinsam machen hierarchische Beziehungen bidirektional navigierbar.
geoquality.ai's SEAKT-Framework nutzt hasPart, um die fünf Dimensionen als eigenständige DefinedTerm-Sub-Entitäten zu verlinken.
Im DACH-Raum nutzen 2026 nur etwa 6 Prozent aller KMU-Websites hasPart konsistent — extrem niedriger Wert mit hohem Differenzierungs-Potential.
Schema.org's hasPart wird besonders intensiv von Akademie-Plattformen für Course-Modul-Hierarchien genutzt.
Die Property kann beliebig tief verschachtelt werden — ein Course kann hasPart Modul haben, das Modul hasPart Lektionen, die Lektionen hasPart einzelne Inhalts-Blöcke.

Definition von Marco Biner · Certified GEO Expert

Marco Biner — Founder geoquality.ai, Certified GEO Expert

hasPart ist der unterschätzte Hierarchie-Hebel in JSON-LD. Die wenigsten Sites nutzen ihn — was schade ist, weil er Composition-Beziehungen explizit macht. Bei geoquality.ai habe ich hasPart konsequent für das SEAKT-Framework eingesetzt: das Framework als Container-Entity, die fünf Dimensionen als hasPart-Sub-Entities. Das macht die Struktur für KI-Modelle 1:1 navigierbar.

Mein Standard für Klienten: bei jeder Inhalts-Hierarchie (Themenreihen, Online-Kurse, Service-Pakete) hasPart auszeichnen — bidirektional mit isPartOf. Setup ist minimaler Aufwand und macht den Wissensgraph deutlich kohärenter.

GEO Importance Rank

Wie wichtig ist dieser Begriff für Generative Engine Optimization?

55 /100

Wichtig Range 50–69

FAQs

Wann nutze ich hasPart vs. mentions?

hasPart bei echten Composition-Beziehungen — der Container besteht strukturell aus den Sub-Elementen. mentions bei losen Erwähnungen — die Entitäten kommen im Inhalt vor, sind aber kein struktureller Teil. Bei einem Kurs mit Modulen: hasPart. Bei einem Blog-Post, der Branchenverbände erwähnt: mentions.

Soll ich hasPart und isPartOf bidirektional setzen?

Ja, das ist Best Practice. Container hat hasPart-Liste der Sub-Elemente, jedes Sub-Element hat isPartOf zurück. Damit ist die Hierarchie aus beiden Richtungen navigierbar — wichtig für Knowledge-Graph-Traversal durch KI-Modelle.

Können hasPart-Listen beliebig lang sein?

Technisch ja, praktisch sollten sie überschaubar bleiben. Bei mehr als 20 Sub-Elementen wird die Liste unübersichtlich — dann besser Sub-Container-Strukturen einführen. Beispiel: ein Buch mit 100 Kapiteln kann besser in Sektionen organisiert werden, jede Sektion hasPart-Container für ihre Kapitel.

Welche Schema-Types nutzen hasPart sinnvoll?

CreativeWork-Sub-Types: Course (mit Modul-hasPart), Book (mit Chapter-hasPart), MusicAlbum (mit Track-hasPart), MovieSeries (mit Episode-hasPart). Aber auch DefinedTerm bei Frameworks (SEAKT mit Dimension-hasPart). Generell überall, wo ein Container strukturell aus Sub-Elementen besteht.

Was wenn die Sub-Elemente keine eigene Page haben?

Dann werden sie als Sub-Entities ohne eigene URL ausgezeichnet — eigene @id mit Anchor-Suffix wie <code>/kurs/mwst-2026#modul-1</code>. Die @id muss eindeutig sein, aber nicht zwingend dereferenzierbar. Bei späterem Ausbau kann jedes Modul eine eigene Page bekommen, ohne die @id zu ändern.

Wirkt hasPart auf KI-Citations?

Indirekt ja. KI-Modelle bei Anfragen zur Struktur eines Inhalts ("Wie ist X aufgebaut?", "Welche Module hat Y?") können direkt aus hasPart-Listen antworten — präziser als aus Volltext-Inferenz. Bei strukturierten Inhalten ist hasPart deshalb ein wertvoller Citation-Hebel.