--- title: hasPart (Schema-Property) slug: has-part-property canonical_url: https://www.geoquality.ai/glossar/has-part-property md_url: https://www.geoquality.ai/glossar/has-part-property.md language: de last_modified: 2026-05-03T00:00:00+00:00 related_terms: [entity, is-part-of-property, json-ld, knowledge-graph, schema-org, structured-data] content_hash: 593275060fe7d765 license: CC BY 4.0 author: Marco Biner (geoquality.ai) schema_type: DefinedTerm --- # hasPart (Schema-Property) 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. ## Erläuterung 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. ## 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. ## Häufige Fehler - 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). ## 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. ## 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. ## FAQ ### 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 /kurs/mwst-2026#modul-1 . 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. ## Experten-Definition 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. ## Verwandte Begriffe - [Entity](https://www.geoquality.ai/glossar/entity.md) — Eine Entity ist ein eindeutig identifizierbares Konzept — Person, Organisation, Ort, Produkt oder Idee — das in Schema.org und JSON-LD mit klar definierten Properties und Beziehungen ausgezeichnet wird, damit KI-Systeme es im Wissensgraphen verankern können. - [isPartOf (Schema-Property)](https://www.geoquality.ai/glossar/is-part-of-property.md) — isPartOf ist eine Schema.org-Property, die ein Werk oder eine Entity als Bestandteil eines übergeordneten Containers ausweist — die reziproke Property zu hasPart, beide gemeinsam machen hierarchische Beziehungen bidirektional navigierbar. - [JSON-LD](https://www.geoquality.ai/glossar/json-ld.md) — JSON-LD ist ein W3C-standardisiertes Format zur Einbettung strukturierter Daten in Webseiten — typischerweise nach Schema.org-Vokabular — und der von Google sowie allen grossen KI-Crawlern bevorzugte Weg, Entitäten und Beziehungen maschinenlesbar zu beschreiben. - [Knowledge Graph](https://www.geoquality.ai/glossar/knowledge-graph.md) — Ein Knowledge Graph ist eine Datenstruktur, die Entitäten und ihre Beziehungen als verknüpftes Netzwerk repräsentiert und KI-Systemen die Faktenbasis liefert, aus der sie Antworten zusammensetzen. - [Schema.org](https://www.geoquality.ai/glossar/schema-org.md) — Schema.org ist das von Google, Microsoft, Yahoo und Yandex gemeinsam entwickelte Vokabular zur strukturierten Beschreibung von Web-Inhalten — der De-facto-Standard für maschinenlesbare Auszeichnung und das technische Fundament jeder GEO-Strategie. - [Strukturierte Daten](https://www.geoquality.ai/glossar/structured-data.md) — Strukturierte Daten sind maschinenlesbare Auszeichnungen von Web-Inhalten — typischerweise als JSON-LD im HTML-Head — die Entitäten, Beziehungen und Metadaten explizit benennen statt sie nur implizit im Fliesstext zu hinterlassen. ## Quelle und Zitation - HTML-Original: https://www.geoquality.ai/glossar/has-part-property - Lizenz: CC BY 4.0 - Zitiervorschlag: "hasPart (Schema-Property) (geoquality.ai Glossar, Biner 2026)"