Cart is empty
Un JSON-LD @graph no es simplemente una forma ordenada de agrupar schema. Es la diferencia entre publicar varios fragmentos que describen partes de un sitio y modelar las relaciones que permiten a un buscador o a un motor generativo resolver quién es tu empresa, qué ofrece, quién respalda el contenido y de qué trata cada página.
Si ya usas datos estructurados y aun así tu marca se percibe como ambigua en resultados generativos, el problema no suele ser la ausencia de una propiedad aislada. Suele ser la arquitectura: Organization, WebPage, Article, Person y Service aparecen como islas, se duplican o no comparten un identificador. Los motores generativos no leen keywords, resuelven entidades y sus relaciones.
Para una agencia SEO, un desarrollador WordPress o un consultor B2B, el cambio práctico es pasar de preguntar «¿qué schema agrego?» a preguntar «¿qué nodo es la fuente de verdad y cómo se conecta con el resto del grafo?». Esa es la base técnica del SEO semántico, el Entity SEO y la autoridad temática sostenible.
Qué representa un @graph dentro de JSON-LD
JSON-LD es una sintaxis para expresar datos enlazados con JSON. Su propiedad @graph permite declarar varios nodos en un mismo conjunto: una organización, una página, un artículo, una persona autora y un servicio, por ejemplo. Pero que todos estén físicamente dentro de @graph no los vuelve automáticamente un grafo de conocimiento útil.
Un grafo es coherente cuando cada nodo tiene una identidad estable y las relaciones apuntan a ella. La página de servicio debe referenciar a su proveedor; el artículo debe tener un autor identificable; la organización debe ser el publisher; y las entidades de las que se habla deben dejar de ser texto ambiguo cuando existe una referencia verificable. La conexión importa tanto como el tipo de schema.
| Implementación fragmentada | Arquitectura de grafo conectada |
|---|---|
| Un bloque Organization en una página y otro con datos distintos en otra. | Un nodo Organization canónico, definido una vez y reutilizado por @id. |
| Un Service escrito como texto sin proveedor verificable. | Un Service que enlaza provider al @id de la organización. |
| Un autor visible que no existe en el marcado. | Un nodo Person con worksFor, knowsAbout y perfiles verificables. |
| Etiquetas y términos que solo viven en el copy. | Entidades reutilizables en about, mentions y keywords. |
El error: confundir schema válido con significado conectado
Schema.org aporta el vocabulario: tipos como Organization, Person, Service y Article, además de propiedades como sameAs, author o areaServed. Es indispensable, pero no decide por sí solo si dos menciones de una empresa representan exactamente la misma entidad.
Un sitio puede superar un validador y seguir enviando señales débiles: un logo con URL HTTP en un nodo, HTTPS en otro; el nombre comercial y la razón social mezclados; un mismo proveedor repetido dentro de varios bloques; o perfiles externos declarados sin relación con la entidad central. La sintaxis es correcta, pero la identidad queda partida.
Por qué la duplicación cambia la interpretación
Para una persona, dos bloques que dicen «Consultora Norte» parecen suficientes. Para un sistema, pueden ser dos nodos diferentes si cada uno tiene atributos, URL o identificadores distintos. Cuando publisher, provider, worksFor y founder apuntan al mismo @id, se expresa una afirmación mucho más precisa: todas esas relaciones convergen en la misma entidad.
Qué debe compartir un nodo canónico
- Una URL o
@idestable, normalmente asociado al dominio y al tipo de entidad. - Nombre canónico, URL principal y logo consistentes.
- Relaciones de negocio expresadas con propiedades adecuadas, no con texto decorativo.
- Referencias externas comprobables mediante
sameAscuando correspondan. - Una política de HTTPS que no parta la identidad entre variantes de URL.
Nota de entidad: un Q-ID no es una etiqueta, es una referencia verificable
El Q-ID Q3475322 fue validado contra la API pública de Wikidata. No convierte por sí mismo una página en autoridad ni garantiza una cita. Su valor está en que ancla una referencia a una identidad externa concreta, en vez de dejar que el sistema infiera el significado solo desde una cadena de caracteres.
Cómo pasar de bloques aislados a relaciones resolubles
La prioridad no es añadir todos los tipos posibles de Schema.org. Es diseñar un modelo mínimo y consistente. Una empresa B2B suele necesitar una organización como nodo central, personas vinculadas cuando aportan experiencia demostrable, servicios conectados a su proveedor, cobertura territorial cuando es relevante y páginas que declaren con claridad su entidad principal.
{
"@type": "Service",
"@id": "https://ejemplo.com/consultoria-seo/#service",
"name": "Consultoría SEO B2B",
"provider": { "@id": "https://ejemplo.com/#organization" },
"areaServed": { "@id": "https://www.wikidata.org/wiki/Q298" }
}El ejemplo no pretende ser una plantilla universal. Muestra el principio: el proveedor no se vuelve a describir dentro del servicio, se referencia. Así se reduce la duplicación y se facilita que las páginas del sitio compartan una misma base de identidad. Para profundizar en el enfoque, revisa qué es el SEO semántico, la guía sobre Entity SEO y Wikidata y nuestra explicación de GEO o Generative Engine Optimization.
La relación entre grafo y Topical Authority
La Topical Authority se construye con contenido útil, cobertura consistente de un tema, experiencia demostrable y relaciones claras entre sus piezas. El grafo no reemplaza esa labor editorial. Sí evita que la arquitectura técnica contradiga el contenido: si diez artículos explican una especialidad, knowsAbout, el autor y las entidades mencionadas pueden expresar esa especialización con una capa estructurada coherente.
La solución tecnológica: SemanticGEO
SemanticGEO extiende el grafo que Yoast SEO ya produce, no lo reemplaza. Mediante Graph Stitching, agrega y conecta nodos usando referenciación estricta por @id, para que Organization, Person, Service, SoftwareApplication y WebPage no terminen como fragmentos redundantes. Es una forma de evolucionar Yoast gratuito hacia una arquitectura semántica más rigurosa.
Su biblioteca central permite definir una entidad una sola vez. El Q-ID y las URLs de Wikipedia y Wikidata se validan en tiempo real contra la API pública antes de usarse; luego, la entidad se reutiliza en el sitio mediante sameAs doble, mentions o knowsAbout. Los 13 packs de nicho importables aceleran esa base para agencias sin obligarlas a tipear identificadores manualmente.
Además, genera un archivo llms.txt sincronizado con el grafo, incluyendo Entity Facts, servicios, preguntas frecuentes, contenido reciente y perfiles oficiales. Es un estándar emergente y ningún proveedor de LLM garantiza que lo use para citarte. Por eso SemanticGEO no promete apariciones mágicas: ofrece una implementación técnica consistente, limpia y verificable para reducir ambigüedades donde la búsqueda generativa necesita resolver entidades.
Preguntas frecuentes sobre JSON-LD @graph
¿Un @graph garantiza que la IA cite mi empresa?
No. Un @graph ordenado mejora la claridad técnica de las entidades y sus relaciones, pero una cita depende de la consulta, la calidad del contenido, la evidencia externa, la disponibilidad del sitio y los criterios de cada motor.
¿Todos los nodos de un @graph deben tener @id?
Los nodos que se reutilizan o que reciben relaciones desde otros nodos deben tener un identificador estable. Usar @id permite referenciarlos sin copiar la misma entidad una y otra vez.
¿JSON-LD y Knowledge Graph son lo mismo?
No. JSON-LD es un formato de representación. Un Knowledge Graph es un modelo de entidades y relaciones. Puedes emitir JSON-LD válido sin haber modelado un grafo coherente.
¿Debo eliminar el schema que genera Yoast para usar un grafo?
No. Lo más seguro es extender el grafo existente cuando su arquitectura lo permite. Duplicar emisores de schema suele crear conflictos, nodos paralelos e inconsistencias que complican la interpretación.
¿Qué relación tiene llms.txt con el @graph?
Un llms.txt útil puede presentar en Markdown información ya presente y coherente en el grafo, como entidades, servicios y preguntas frecuentes. No sustituye el schema ni es una garantía de indexación o citación por parte de un LLM.
Conclusión: conecta la identidad antes de sumar más etiquetas
El valor de un JSON-LD @graph no está en tener más líneas de código. Está en evitar que cada página describa a tu empresa, autores y servicios como si fueran entidades distintas. Cuando el schema comparte identificadores, referencias verificables y relaciones semánticas precisas, el sitio entrega una señal más clara a buscadores y sistemas generativos.
Convierte tu schema en una arquitectura de entidades
Explora SemanticGEO si necesitas extender el grafo de Yoast con entidades verificadas, relaciones por @id y un llms.txt sincronizado, sin reconstruir tu WordPress desde cero.
Ver planes y precios
