isPartOf y hasPart en Schema.org: cómo conectar tus páginas al grafo para que la IA te resuelva

isPartOf y hasPart son las dos propiedades de Schema.org que conectan las partes de un grafo de conocimiento con el todo. isPartOf declara a qué entidad mayor pertenece una página o un nodo; hasPart declara qué piezas contiene. Son la relación estructural que convierte un conjunto de bloques JSON-LD sueltos en una entidad única que la IA puede recorrer y resolver.

La mayoría de los sitios publican una WebPage aquí, una FAQPage allá y un Organization suelto, sin decir nunca cómo se relacionan. El validador no se queja, porque son bloques válidos, pero para un motor generativo son piezas sin jerarquía: no hay un hilo que una cada página con su sitio ni cada sección con su artículo.

En este artículo te explico qué son isPartOf y hasPart, en qué se diferencian de la referencia por @id, y por qué son la relación que cose tu grafo. Al final verás cómo SemanticGEO las emite automáticamente desde tu grafo sobre Yoast SEO, sin que escribas una línea de JSON-LD a mano.

Qué son isPartOf y hasPart: la relación que convierte páginas sueltas en una entidad

isPartOf y hasPart son propiedades inversas entre sí. isPartOf apunta desde la parte hacia el todo: una WebPage declara isPartOf hacia la WebSite, un artículo declara isPartOf hacia su colección. hasPart apunta desde el todo hacia las partes: la WebSite declara hasPart hacia cada WebPage, una FAQPage declara hasPart hacia cada Question. Son dos direcciones de la misma relación parte-todo, y juntas permiten que un grafo de conocimiento exprese jerarquía, no solo una lista de nodos.

isPartOf: cada página declara a qué sitio pertenece

El uso más común es WebPage isPartOf WebSite. Con esa referencia le dices al motor que este documento forma parte de un conjunto mayor, identificado por un @id canónico. Sin ella, cada página es una isla; con ella, cada página es una rama de un mismo árbol. Es la base de la autoridad temática: un sitio cuyas páginas se declaran parte de una misma entidad se lee como una sola fuente coherente, no como decenas de documentos sueltos.

hasPart: el todo declara sus piezas

hasPart viaja en sentido contrario. Una WebSite puede enumerar sus secciones principales, y una FAQPage enumera sus preguntas. Es la propiedad que permite describir una entidad compuesta por sus componentes, en lugar de duplicar la descripción en cada página. Cuando el todo y la parte se declaran por ambos extremos, el grafo queda cosido sin ambigüedad posible.

isPartOf y hasPart no sustituyen a @id: se complementan

La referencia por @id dice quién es un nodo; isPartOf y hasPart dicen cómo se relaciona con los demás. @id es identidad, isPartOf es estructura. Un grafo bien cosido usa ambos: cada nodo con su @id único y cada relación parte-todo declarada explícitamente. Esa combinación es el corazón del Graph Stitching, la técnica que separa a un grafo coherente de un montón de bloques aislados.

Por qué el schema tradicional deja las páginas sueltas

La mayoría de los plugins de datos estructurados emiten bloques JSON-LD válidos, pero aislados. Publican una WebPage sin isPartOf, una FAQPage sin hasPart y un Organization sin conexión estructural. El validador de Schema.org da verde, porque cada bloque es correcto por separado, pero el grafo resultante no tiene jerarquía.

Para un motor generativo, eso es un problema real. Los motores no leen keywords, resuelven entidades, y resolver una entidad compuesta exige entender sus partes. Una WebSite que no declara qué páginas la componen es una entidad que la IA no puede recorrer; un artículo que no declara su relación con el sitio es un documento sin contexto. El resultado es el escenario que viven miles de sitios: tienen schema, pero su entidad sigue siendo ambigua. Eso también frena la autoridad temática del dominio, porque sin estructura el motor no puede agrupar tus contenidos bajo una sola identidad.

Cómo conectar tu grafo con isPartOf y hasPart

Conectar el grafo es declarar la jerarquía dentro del @graph. La WebSite se define una sola vez con su @id canónico, y cada WebPage la referencia con isPartOf. No se duplica la descripción del sitio en cada página: se referencia. Ese es el mismo principio del Graph Stitching que separa a un grafo cosido de un conjunto de islas.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://ejemplo.cl/#website",
      "name": "Consultora Ejemplo",
      "publisher": { "@id": "https://ejemplo.cl/#organization" },
      "hasPart": { "@id": "https://ejemplo.cl/servicios/seo/#webpage" }
    },
    {
      "@type": "WebPage",
      "@id": "https://ejemplo.cl/servicios/seo/#webpage",
      "url": "https://ejemplo.cl/servicios/seo/",
      "isPartOf": { "@id": "https://ejemplo.cl/#website" },
      "mainEntity": { "@id": "https://ejemplo.cl/#service-seo" }
    },
    {
      "@type": "Service",
      "@id": "https://ejemplo.cl/#service-seo",
      "name": "Consultoría SEO B2B",
      "provider": { "@id": "https://ejemplo.cl/#organization" }
    }
  ]
}

Fíjate en el detalle: la WebSite no repite la URL de la página ni su contenido, solo la referencia por hasPart; la WebPage no repite el nombre del sitio, solo lo referencia por isPartOf. Cada entidad se define una sola vez y se conecta por @id. Esa es la diferencia entre emitir islas y coser un grafo que la IA puede recorrer de la parte al todo.

La solución tecnológica: SemanticGEO

SemanticGEO emite isPartOf y hasPart automáticamente como parte de su Graph Stitching sobre el grafo de Yoast SEO. La WebSite, la WebPage, la organización, los servicios y las preguntas frecuentes quedan conectados por @id sin que escribas una línea de JSON-LD a mano: el plugin cose la jerarquía completa de tu sitio en una sola entidad coherente.

El flujo es este: defines tu entidad una vez con su Q-ID validado en tiempo real contra la API de Wikidata, y el plugin se encarga de las referencias estructurales. Los 13 packs de nicho importables traen las entidades base de tu vertical ya verificadas, y el llms.txt se genera desde el mismo grafo, así que la jerarquía parte-todo viaja también al resumen que leen los crawlers de IA. Cero tipeo manual, cero islas, cero @id partidos.

Preguntas frecuentes

¿isPartOf y hasPart son lo mismo que la referencia por @id?

No. @id es la identidad de un nodo; isPartOf y hasPart describen su relación parte-todo con otros nodos. Un grafo bien formado usa ambos: cada nodo con un @id único y cada relación estructural declarada. Son complementarios, no equivalentes.

¿En qué se diferencia isPartOf de about o mentions?

about y mentions declaran de qué trata el contenido y qué entidades se mencionan. isPartOf declara la estructura: a qué entidad mayor pertenece la página. Son planos distintos: uno es temático, el otro es jerárquico.

¿Tengo que declarar isPartOf en cada página?

Lo ideal es que sí, porque cada página pertenece al sitio y declararlo le da a la IA el contexto estructural que necesita para recorrer tu grafo. Un plugin de GEO lo hace automáticamente desde el @id canónico del WebSite, sin reescribir nada en cada página.

¿isPartOf garantiza que la IA me cite?

No, y ningún marcado puede garantizarlo. Los motores generativos no confirman oficialmente qué señales consumen. isPartOf y hasPart son la implementación técnica más rigurosa de un factor que estos motores demuestran consumir: la resolución de entidades y su estructura. Es rigor, no magia.

Conclusión

isPartOf y hasPart son dos propiedades pequeñas con un efecto enorme: convierten un conjunto de bloques JSON-LD sueltos en una entidad con jerarquía. Sin ellas, tu sitio es un montón de islas; con ellas, es un grafo que la IA puede recorrer de la parte al todo. En un mundo donde los motores generativos resuelven entidades, declarar la estructura de tu grafo es tan importante como declarar sus identidades.