Aunque todas las páginas de tu sitio incluyan schema, después de procesarlo un motor de IA puede seguir sin saber a qué sitio pertenece una WebPage ni quién lo gestiona. El problema no es cuántas etiquetas hay, sino que esas etiquetas no se reconocen entre sí. Definir Organization, WebSite y WebPage como fragmentos aislados de JSON-LD equivale a entregar a la máquina tres tarjetas de presentación sin relación alguna. @graph traza vínculos claros entre ellas y permite que la IA comprenda de una sola vez la estructura de entidades de todo el sitio web.
Por qué un schema fragmentado impide que la IA reconstruya tu sitio web
En la mayoría de los sitios, los plugins o las plantillas del CMS generan el schema de forma automática: Organization para la página de inicio, Article para los artículos y Product para la página de precios. Cada elemento tiene su propio schema. Por separado, todos pueden ser válidos y superar la prueba de resultados enriquecidos. El problema aparece cuando la máquina intenta responder: «¿Quién publica este artículo y es una fuente fiable?». Solo encuentra varios objetos aislados, sin ningún campo que indique que el publisher de Article es la misma Organization definida en la página de inicio. Para los motores de respuestas y resúmenes con IA, la posibilidad de vincular el contenido con una organización real y verificable influye de forma importante en la decisión de citarlo. Sin esa relación, el contenido deja de parecer información oficial de una empresa y pasa a ser un texto de procedencia desconocida.
Qué hace exactamente @graph
@graph es un campo de nivel superior de JSON-LD cuyo valor es un array capaz de contener varios objetos de entidad. Permite reunir en un mismo archivo y espacio de nombres entidades que, de otro modo, se repartirían entre varias etiquetas script. Lo importante no es solo «ponerlas juntas», sino permitir que, una vez reunidas, se referencien mediante @id. Se declara un @id en Organization y se incluye ese mismo @id en el campo publisher de WebSite; así, la máquina entiende que ambos apuntan a la misma entidad y no es necesario copiar de nuevo toda la información de Organization. Este modelo de definir una vez y referenciar desde cualquier lugar es uno de los principios básicos de los grafos de conocimiento. schema.org admite @graph para que una página exprese relaciones entre entidades, en lugar de limitarse a enumerar atributos.
Una sola etiqueta script puede contener todo el @graph de una página. Esto también resuelve un problema habitual: tres plugins que definen por separado la misma Organization y generan atributos contradictorios. Con @graph, la empresa aparece una sola vez, se convierte en la única fuente de verdad del sitio y solo requiere cambios en un punto cuando llega el momento de mantenerla.
@id: una dirección estable para cada entidad
@id es la base de todo este enfoque. Se trata de una cadena de identificación única para todo el dominio, normalmente formada por una URL seguida de un fragmento, como https://example.com/#organization. No es imprescindible que esa dirección pueda abrirse: su función es identificar, no actuar como enlace. Si una entidad utiliza siempre el mismo @id en todo el sitio, la IA puede agrupar bajo un mismo sujeto la información distribuida entre distintas páginas. Cuando el mismo @id aparece en la página de inicio, un artículo y la página de precios, la máquina puede combinar las descripciones de la empresa para construir un perfil más completo y difícil de falsificar.
- Para Organization, utiliza la raíz del dominio más un fragmento, como https://example.com/#organization. Debe ser único en todo el sitio y referirse siempre a la misma empresa.
- Para WebSite, utiliza la raíz del dominio más #website, que representa la entidad del sitio web completo.
- Para la WebPage de cada página, utiliza «la URL de la página + #webpage». El valor cambia en cada página.
- Define una convención común para nombrar los fragmentos (#organization, #website, #webpage). No uses #org hoy y #company mañana.
- Una vez publicado un @id, no lo cambies sin motivo. Modificarlo equivale a crear una entidad nueva y rompe todas las relaciones acumuladas hasta ese momento.
Cómo se relacionan las tres entidades
La dirección de las relaciones sigue una lógica clara: de lo específico a lo general, es decir, desde la página hasta la entidad principal. WebSite utiliza publisher para apuntar a Organization y declarar que la empresa gestiona el sitio. Cada WebPage emplea isPartOf para apuntar a WebSite e indicar que forma parte de él. Si la página trata sobre la propia empresa —por ejemplo, «Quiénes somos» o precios—, utiliza about o mainEntity para volver a referenciar Organization. En los artículos, haz que el publisher de Article también apunte al @id de esa Organization para completar la relación con el editor.
Ejemplo completo listo para implementar
El siguiente @graph se inserta en el <head> de la página. Una sola etiqueta script puede contener las tres entidades: cada una declara su @id una vez y después utiliza @id para referenciar a las demás, sin volver a copiar Organization. En la práctica, Organization y WebSite se extraen a una plantilla compartida por todo el sitio y se definen una sola vez. La parte correspondiente a WebPage puede generarse dinámicamente con los valores de url, name y @id de cada página. { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example company", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "Pricing plan", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
Los cuatro errores más frecuentes
- @id incoherente: en la página de inicio se utiliza #organization, pero el publisher del artículo contiene una URL completa diferente o carece del fragmento después de la almohadilla. La máquina los interpreta como dos empresas distintas.
- Incluir el objeto completo donde debería haber una referencia: se vuelve a definir toda la Organization dentro de publisher. Esto crea dos copias de la misma entidad, cuyos atributos pueden entrar en conflicto.
- Entidades aisladas: WebPage no incluye isPartOf y Article no incluye publisher. Aunque los objetos sean válidos, quedan desconectados de la entidad principal.
- Usar una URL variable como @id: cada cambio en una URL con parámetros de seguimiento o de sesión genera una entidad adicional y obliga a reconstruir todas las relaciones desde cero.
Para que la IA confíe en tu sitio web no necesitas acumular etiquetas, sino definir con claridad las relaciones entre las entidades.
Comprueba estos tres puntos antes de publicar
Publicar el marcado no significa haberlo implementado correctamente. Primero, pega el @graph completo en Rich Results Test o Schema Markup Validator y confirma que no haya errores de sintaxis. Después, realiza una comprobación que muchas personas omiten: toma cada @id referenciado y verifica, uno por uno, que esté realmente definido en el mismo grafo. No apuntes a identificadores inexistentes. Por último, carga la página en el navegador, revisa el HTML renderizado y confirma que el script aparezca de verdad. Muchos sistemas SSR o CMS lo eliminan de forma silenciosa en este punto. La conexión entre entidades es una de las áreas de mayor impacto dentro del GEO técnico: no exige muchas horas de trabajo, pero influye directamente en que la IA considere tu sitio una fuente fiable. Si no sabes con certeza si Organization, WebSite y WebPage están realmente conectados o si la relación publisher está incompleta, puedes solicitar un diagnóstico GEO de 30 minutos. Capturaremos el HTML renderizado y señalaremos, una por una, las relaciones que falten.
