Schema markup avanzado con Graph para rich results

Introducción

El uso de schema markup avanzado con Graph y propiedades anidadas se ha convertido en un factor crítico para conseguir rich results consistentes y escalables en proyectos SEO serios. Si todavía estás generando fragmentos de JSON-LD aislados por plantilla sin pensar en la arquitectura global de datos, estás desaprovechando una de las palancas técnicas más potentes para mejorar el CTR y la comprensión semántica de tu sitio por parte de Google.

En este artículo, desde la experiencia de proyectos complejos (ecommerce, medios y sitios B2B), veremos cómo estructurar un @graph sólido, cómo relacionar entidades con propiedades anidadas y cómo evitar errores habituales que bloquean la elegibilidad a rich results. El objetivo es que puedas pasar de un marcado básico a un modelo de datos bien diseñado, mantenible y alineado con tus objetivos de negocio y de SEO.

Qué es schema markup avanzado con graph

El marcado estructurado basado en Schema.org se puede implementar de múltiples formas, pero el enfoque moderno recomendado por Google para sitios medianos y grandes es el uso de JSON-LD con un contenedor @graph. En lugar de tener múltiples bloques independientes de JSON-LD, agrupas todas tus entidades en un único grafo de conocimiento local para la página.

De forma simplificada:

• JSON-LD simple: uno o varios bloques independientes, sin relaciones explícitas entre entidades.
• JSON-LD con @graph: un conjunto de nodos (entidades) relacionados entre sí mediante identificadores (@id) y propiedades anidadas.

Este enfoque avanzado permite:

• Describir la página como parte de un ecosistema de entidades (organización, autor, producto, breadcrumbs, etc.).
• Reducir duplicidades de información (por ejemplo, definir la organización una vez y reutilizarla).
• Facilitar a los motores de búsqueda la construcción de su propio grafo de conocimiento sobre tu marca y tus contenidos.

Ventajas seo de usar graph y propiedades anidadas

Trabajar con un grafo bien diseñado genera ventajas prácticas, no solo teóricas:

• Mayor elegibilidad a rich results: reseñas, FAQ, breadcrumbs, eventos, productos, artículos, etc.
• Mayor coherencia semántica: todas las entidades de la página se relacionan con la misma organización, autor o marca, reduciendo ambigüedades.
• Mejor mantenimiento: actualizas datos clave (por ejemplo, nombre de la empresa) en un único nodo del grafo.
• Escalabilidad: en sitios con miles de URLs, el uso de patrones de grafo permite plantillas reutilizables y menos errores.
• Mejor alineación con Knowledge Graph: si tu marca o tus productos pueden entrar en el grafo de conocimiento de Google, un marcado claro ayuda a ese proceso.

Conceptos clave: entidades, @id y propiedades anidadas

Antes de entrar en la parte práctica, es esencial dominar tres conceptos técnicos:

Entidades en schema.org

Una entidad es un “algo” del mundo real o digital que se puede describir: una organización, una persona, un artículo, un producto, un evento, etc. En Schema.org, las entidades se describen con tipos como Organization, Person, Article, Product, BreadcrumbList, etc.

Uso estratégico de @id

La propiedad @id actúa como identificador único de la entidad dentro del grafo. Suele representarse como una URL (real o “hash” interno) y permite:

• Referenciar una entidad desde múltiples nodos sin duplicar su definición.
• Conectar entidades entre sí de forma explícita.
• Ayudar a los motores de búsqueda a fusionar información de distintas páginas sobre la misma entidad.

Ejemplo conceptual: la misma Organization se referenciará desde el WebSite, el WebPage, los Article y los Product como publisher o brand.

Propiedades anidadas

Las propiedades anidadas son campos que contienen a su vez subobjetos estructurados. En lugar de usar solo cadenas de texto, se usan objetos completos. Por ejemplo:

• author de un Article puede ser una entidad Person con su propio @id, name, url, etc.
• brand de un Product puede ser una Organization o Brand definida una sola vez en el grafo.
• itemListElement de un BreadcrumbList contiene elementos ListItem con su propia estructura.

Esto es fundamental para que el grafo sea rico y expresivo, y para que Google pueda seguir las relaciones entre entidades.

Arquitectura recomendada de un @graph para sitios avanzados

No existe un único modelo válido, pero en proyectos SEO avanzados se repiten ciertos patrones que funcionan bien.

Entidades base casi siempre presentes

En la mayoría de sitios con ambición SEO deberías considerar incluir, al menos:

• Organization o LocalBusiness: la entidad principal de la marca.
• WebSite: el sitio completo.
• WebPage: la página concreta (cada URL).
• BreadcrumbList: si hay breadcrumbs visibles.

Sobre esa base, se añaden entidades específicas según el tipo de página:

• Article / NewsArticle / BlogPosting: para contenidos editoriales.
• Product: para fichas de producto.
• FAQPage: para páginas con preguntas frecuentes.
• Event, Course, JobPosting, etc., según el caso.

Ejemplo de relaciones típicas en el grafo

La tabla siguiente resume un patrón de relaciones muy utilizado en entornos profesionales:

Este tipo de diseño permite que cada entidad sea reutilizable y que las relaciones sean claras y previsibles para los motores de búsqueda.

Uso de propiedades anidadas para rich results

Los rich results más valiosos suelen requerir propiedades anidadas bien implementadas. Algunos ejemplos prácticos:

Product con brand, offers y aggregaterating

• brand: entidad Brand o Organization con @id propio.
• offers: entidad Offer con precio, moneda, disponibilidad, URL de compra.
• aggregateRating: entidad AggregateRating con valor medio y número de reseñas.

Estas propiedades, correctamente anidadas y conectadas con WebPage y Organization, son las que habilitan rich results de producto con precio, disponibilidad y estrellas.

Article con author y publisher

• author: entidad Person (o Organization) con name, url y, opcionalmente, sameAs a perfiles sociales.
• publisher: normalmente la Organization principal del sitio, referenciada por su @id.
• image: objeto ImageObject con url, width y height cuando sea posible.

Este conjunto de propiedades anidadas ayuda a Google a mostrar rich results de artículos con imagen, nombre del medio y autor.

Faqpage con mainentity anidado

Para que las FAQs sean elegibles para rich results, Google recomienda usar el tipo FAQPage con mainEntity que contenga una lista de entidades Question, cada una con su acceptedAnswer del tipo Answer.

En un contexto de grafo, puedes:

• Definir la entidad FAQPage con su propio @id.
• Relacionarla con el WebPage mediante mainEntity o mainEntityOfPage.
• Incluir las preguntas y respuestas como propiedades anidadas de FAQPage.

Pasos para diseñar e implementar un @graph avanzado

Para pasar de un marcado disperso a un grafo sólido, es útil seguir un proceso ordenado. A continuación, una guía práctica:

Paso 1: inventario de tipos de página y objetivos de rich results

1. Lista todas las plantillas principales del sitio: home, categorías, fichas de producto, posts, landing pages, etc.
2. Asocia a cada tipo de página los rich results deseados: producto, artículo, FAQ, breadcrumbs, logo, sitelinks search box, etc.
3. Prioriza según impacto de negocio (ej. fichas de producto y páginas de servicio primero).

Paso 2: definir las entidades globales reutilizables

1. Define la entidad Organization (o LocalBusiness) con un @id estable (normalmente en la home con hash).
2. Define WebSite con su @id y relación publisher con la organización.
3. Decide qué otras entidades globales necesitas (por ejemplo, Brand si difiere de la organización, o Person si hay un autor principal muy relevante).

Paso 3: diseñar el modelo de grafo por plantilla

1. Para cada tipo de página, define qué entidades aparecerán en el @graph (WebPage, Product, Article, FAQPage, BreadcrumbList, etc.).
2. Define qué propiedades conectan esas entidades (p. ej. WebPage.isPartOf => WebSite, Product.brand => Organization).
3. Define los @id de cada entidad siguiendo una convención clara (URL de la página + hash + tipo suele ser una buena práctica).

Paso 4: implementación técnica en el cms o framework

1. Centraliza la definición de entidades globales (Organization, WebSite) en un módulo o plantilla común.
2. Para cada plantilla, genera el bloque de JSON-LD con @graph que incluya:
   • Las entidades globales referenciadas (por @id).
   • Las entidades específicas de esa página.
3. Evita generar múltiples bloques separados de JSON-LD para la misma página; es preferible un único bloque con @graph completo.

Paso 5: validación con herramientas de google y testing incremental

1. Usa la herramienta de Rich Results Test de Google para validar URLs representativas de cada plantilla.
2. Corrige errores de sintaxis, tipos incorrectos y propiedades obligatorias faltantes.
3. Despliega primero en un entorno de staging si es posible y monitoriza antes de extender a todo el sitio.

Paso 6: monitorización continua y mantenimiento

1. Revisa periódicamente los informes de Mejoras en Google Search Console (Productos, Artículos, FAQ, etc.).
2. Detecta patrones de errores o advertencias por plantilla y corrígelos en el modelo de grafo.
3. Ajusta el marcado cuando cambien las directrices de Google o se añadan nuevos tipos de rich results relevantes para tu negocio.

Errores frecuentes al trabajar con graph y cómo evitarlos

Duplicar entidades sin necesidad

Un error común es definir múltiples entidades Organization ligeramente distintas en cada página. Esto confunde a los motores de búsqueda y dificulta la consolidación de señales. Usa un único @id para tu organización y referéncialo en todo el sitio.

Falta de coherencia en los @id

Si cambias el patrón de @id con frecuencia o generas identificadores pseudoaleatorios, rompes la continuidad de tu grafo. Define una convención clara (por ejemplo, URL canónica + hash + tipo) y respétala a largo plazo.

Marcado desconectado del contenido visible

Google insiste en que el contenido marcado debe estar visible para el usuario. Crear entidades o propiedades que no se corresponden con la realidad de la página (por ejemplo, FAQs no visibles) puede provocar pérdida de confianza y pérdida de elegibilidad.

Mezclar microdatos y json-ld sin criterio

Es preferible optar por JSON-LD como formato principal y evitar mezclar microdatos en el HTML salvo que sea imprescindible. Una mezcla desordenada puede generar inconsistencias y datos contradictorios.

No actualizar el grafo cuando cambian las urls o la arquitectura

Si haces una reestructuración de URLs o cambias la arquitectura de navegación, debes revisar también el grafo: url, isPartOf, itemListElement de breadcrumbs, etc. De lo contrario, tu marcado quedará desfasado y potencialmente conflictivo.

Buenas prácticas avanzadas para proyectos grandes

Uso de sameas y vínculos externos

Para reforzar la identidad de tu organización y de tus autores, utiliza sameAs apuntando a perfiles oficiales en redes sociales, directorios relevantes y, si existe, entradas en Wikipedia o Wikidata. Esto ayuda a conectar tu grafo local con el Knowledge Graph global.

Versionado y control de cambios del marcado

En proyectos enterprise, trata el schema markup como código: usa control de versiones (Git), revisiones por pares y pruebas automatizadas cuando sea posible. Un cambio mal implementado en el grafo puede afectar a miles de páginas.

Plantillas de grafo reutilizables

Define “plantillas de grafo” por tipo de página en tu CMS o framework para que los equipos de desarrollo y contenido trabajen con modelos consistentes. Por ejemplo:

• Plantilla “Artículo SEO” con Article + WebPage + WebSite + Organization + BreadcrumbList.
• Plantilla “Producto ecommerce” con Product + Offer + AggregateRating + WebPage + WebSite + Organization + BreadcrumbList.
• Plantilla “FAQ SEO” con FAQPage + WebPage + WebSite + Organization.

Documentación interna y formación de equipos

Documenta las convenciones de @id, los tipos usados, las propiedades obligatorias y opcionales por plantilla. Forma a los equipos de contenido y desarrollo para que entiendan el impacto SEO del grafo y no lo vean como un “bloque misterioso” que no deben tocar.