isPartOf (Schema-Property)

1. Kurzdefinition

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.

2. Ausführliche Erklärung

isPartOf ist die Schema.org-Property, die ausdrückt: „Diese Entity ist Bestandteil eines übergeordneten Containers.“ Sie ist reziprok zu hasPart — wo hasPart vom Container nach unten zeigt, zeigt isPartOf von der Sub-Entity nach oben. Beide Properties zusammen machen hierarchische Beziehungen bidirektional navigierbar.

Aus GEO-Sicht ist isPartOf der wichtigste Mechanismus, um Sub-Entities in ihrem Container-Kontext zu verankern. Wenn ein Blog-Post als Teil einer Themenreihe markiert ist (isPartOf zeigt auf die Reihe), erkennt das KI-Modell den Post nicht isoliert sondern in seinem hierarchischen Kontext — mit allen Authority-Vorteilen, die sich daraus für die Reihe ergeben.

Technisch funktioniert isPartOf genauso wie hasPart, aber in umgekehrter Richtung. Eine Course-Modul-Entity hat isPartOf mit @id-Referenz auf den Course; ein Buch-Chapter hat isPartOf auf das Buch; eine SEAKT-Sub-Dimension hat isPartOf auf das Framework. Die Property kann auch für losere Beziehungen genutzt werden: ein Article ist isPartOf einer Publication, ein BlogPosting isPartOf eines Blogs.

Eine wichtige Konvention: bei strukturellen Sub-Elementen (echte Composition) sollte die Beziehung bidirektional ausgezeichnet sein — Container mit hasPart, Sub-Element mit isPartOf. Bei loseren Beziehungen (z. B. Article isPartOf Blog) kann auch nur eine Richtung gesetzt werden. Best Practice ist Bidirektionalität, wo es semantisch passt.

Für eine Schweizer KMU bedeutet isPartOf konkret: bei Sub-Inhalten (Module eines Kurses, Kapitel einer Themenreihe, Sub-Dimensionen eines Frameworks) die isPartOf-Property auf den jeweiligen Container setzen. Bei Blog-Posts in einer definierten Themenreihe: isPartOf zeigt auf die Reihen-Entity. Bei einer SEAKT-Dimension auf das SEAKT-Framework. Diese Verknüpfung ist 5 Sekunden zusätzlicher Aufwand pro Sub-Entity und macht den Wissensgraph hierarchisch kohärent.

3. Praxisbeispiel

SEAKT-Sub-Dimension mit isPartOf-Verweis auf das Framework:

{
  "@type": "DefinedTerm",
  "@id": "https://www.geoquality.ai/seakt#dim-s",
  "name": "Strukturelle Daten",
  "description": "Erste Dimension des SEAKT-Frameworks (25 Punkte) — bewertet die Vollständigkeit von Schema.org/JSON-LD-Markup.",
  "isPartOf": {
    "@id": "https://www.geoquality.ai/seakt#seakt-framework"
  }
}

Die Sub-Dimension kennt ihren Container (Framework) explizit. Das Framework hat seinerseits hasPart auf alle fünf Dimensionen — bidirektionale Verknüpfung, beidseitig navigierbar im Wissensgraph.

4. Typische Fehler & Missverständnisse

×isPartOf ohne korrespondierendes hasPart am Container — die Bidirektionalität fehlt, einseitige Verknüpfung.
×isPartOf als Plain-String setzen statt @id-Referenz — verliert die strukturelle Information.
×isPartOf bei losen Beziehungen falsch verwenden — wenn ein Article Branchenverbände nur erwähnt, ist mentions richtig, nicht isPartOf.
×isPartOf-Ziel ohne korrespondierende Container-Entity — der Verweis zeigt ins Leere, wenn der Container nicht im @graph existiert.
×isPartOf und author/publisher verwechseln — isPartOf ist Hierarchie-Beziehung, author/publisher sind Authority-Beziehungen.

5. Best Practices

✓Setze isPartOf bei strukturellen Sub-Elementen konsequent — Module, Kapitel, Sub-Dimensionen, Episoden.
✓Pflege bidirektional: Sub-Element mit isPartOf, Container mit hasPart-Liste.
✓Verwende @id-Referenzen — eindeutige Verknüpfung im Knowledge-Graph.
✓Bei loseren Beziehungen (Article isPartOf Blog): nur eine Richtung kann reichen, abhängig vom Use-Case.
✓Halte den Container-Anker stabil über die Lebensdauer der Sub-Elemente — Container-@id-Änderungen sind teuer wegen vielen referenzierenden Sub-Entities.
✓Bei Multi-Container-Sub-Elementen (z. B. Article in Blog und in Themenreihe): mehrere isPartOf-Werte als Liste.

6. Fakten

isPartOf ist seit Schema.org 1.0 (2011) verfügbar und semantisch reziprok zu hasPart.
Beide Properties zusammen sind das Schema.org-Standardpattern für hierarchische Composition-Beziehungen.
geoquality.ai's SEAKT-Framework nutzt isPartOf an jeder Sub-Dimension, um die Composition zum Framework explizit zu machen.
Im DACH-Raum nutzen 2026 nur etwa 8 Prozent aller KMU-Websites isPartOf konsistent — niedriger Adoption mit Differenzierungs-Potential.
Schema.org erlaubt isPartOf als einzelnen Wert oder als Array — Multi-Container-Beziehungen sind möglich.
Bei wissenschaftlichen Publikationen ist isPartOf Standard für die Verknüpfung zu Journals, Issues und Volumes.

Definition von Marco Biner · Certified GEO Expert

Marco Biner — Founder geoquality.ai, Certified GEO Expert

isPartOf ist die andere Hälfte der hasPart-Beziehung — und zusammen sind sie das Schema.org-Pattern für Hierarchie. Ich sehe immer wieder Sites, die hasPart pflegen aber isPartOf vergessen — was die Bidirektionalität bricht und KI-Modellen die Graph-Navigation erschwert.

Mein Standard: wo immer hasPart ausgezeichnet wird, kommt auch isPartOf zurück. Bei der SEAKT-Framework-Auszeichnung auf geoquality.ai: das Framework hat hasPart auf fünf Dimensions-Sub-Entities, jede Dimensions-Entity hat isPartOf zurück aufs Framework. Reziproke Vollständigkeit ist Standard-Pattern für saubere Knowledge-Graphs.

GEO Importance Rank

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

54 /100

Wichtig Range 50–69

FAQs

Brauche ich isPartOf wenn ich schon hasPart am Container habe?

Ja, beide ergänzen sich. Container hat hasPart-Liste, Sub-Element hat isPartOf zurück. Diese Bidirektionalität ist Best Practice — KI-Modelle navigieren den Graph aus beiden Richtungen, und einseitige Verknüpfungen schwächen die Erkennung.

Wann ist isPartOf ohne hasPart sinnvoll?

Bei loseren Beziehungen, wo der Container nicht aktiv eine Liste pflegt. Beispiel: ein Blog-Post ist isPartOf eines Blogs — der Blog selbst pflegt aber keine vollständige hasPart-Liste aller Posts (zu lang, dynamisch). Hier kann isPartOf einseitig genutzt werden.

Kann eine Entity isPartOf mehrerer Container sein?

Ja, isPartOf akzeptiert ein Array von Werten. Ein Blog-Post kann isPartOf des Blogs sein UND isPartOf einer Themenreihe — beide gleichzeitig. Bei Multi-Container-Beziehungen liefert das KI-Modellen reichhaltigeren Kontext.

Wie unterscheidet sich isPartOf von about?

isPartOf ist eine strukturelle Hierarchie-Beziehung („dies ist Teil von jenem“). about ist eine thematische Beziehung („dies handelt von jenem“). Ein Blog-Post ist isPartOf eines Blogs (Hierarchie), about MWST 2026 (Thema). Beide Properties leben parallel mit unterschiedlichen Funktionen.

Soll isPartOf auf eine Page-URL oder Entity-@id zeigen?

Auf eine Entity-@id, nicht auf eine Page-URL. isPartOf ist eine Beziehung zwischen Entities, nicht zwischen Pages. Bei einer SEAKT-Dimension: isPartOf zeigt auf <code>/seakt#seakt-framework</code> (die Framework-Entity), nicht auf <code>/seakt</code> (die Page). Der Anchor-Suffix macht den Unterschied.

Was passiert wenn der Container-Verweis kaputt ist?

Der isPartOf-Verweis zeigt ins Leere — semantisch unvollständig. KI-Modelle können die Hierarchie nicht auflösen. Best Practice: isPartOf-Targets immer prüfen, vor Deploy validieren. Bei dynamischen Sites: automatische Pre-Deploy-Checks, die alle isPartOf-@ids gegen tatsächliche Entities prüfen.