@id en Schema.org: el identificador único que evita nodos duplicados y entidades ambiguas

@id es el atributo de JSON-LD que asigna un identificador único, casi siempre una URL, a cada nodo de tu dato estructurado. Su función es una sola y es la más importante de todo el grafo: permitir que los demás nodos se refieran a una entidad sin volver a describirla. Sin @id, tu organización, tu autor o tu servicio se reimprimen como bloques nuevos en cada página, y Google, los validadores y los motores generativos los interpretan como entidades distintas y desconectadas.

Ese es el error técnico más común y más caro del SEO de entidades. Tu sitio «tiene schema», pero en lugar de una entidad fuerte y verificable, emite decenas de islas de datos que parecen empresas distintas: el nombre escrito diferente, el sameAs que aparece en la home y desaparece en las internas, y ninguna referencia entre nodos. Para el Knowledge Graph y para los LLMs, eso es una entidad ambigua, indistinguible de la competencia.

En esta guía vas a ver qué es @id en Schema.org, por qué los nodos duplicados fragmentan tu grafo y cómo referenciar por @id en lugar de reimprimir bloques para coser todo en una única entidad resoluble.

Qué es @id en JSON-LD y para qué sirve

@id es una palabra clave del estándar JSON-LD, no una propiedad de Schema.org en sentido estricto. Su trabajo es asignar un identificador único, un IRI que casi siempre toma la forma de una URL, a un nodo del grafo. Una vez que tu nodo Organization tiene su @id, cualquier otra parte del grafo puede apuntar a esa dirección con {"@id": "https://tu-dominio.cl/#organization"} en lugar de copiar el bloque completo.

La diferencia conceptual es enorme. Reimprimir un bloque significa «acá hay otra organización». Referenciar por @id significa «esta es la misma organización que ya definí». Para un motor que resuelve entidades, la primera lectura multiplica entidades; la segunda las unifica. Ese principio es la base del Graph Stitching: coser nodos por referencia en lugar de duplicarlos.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tu-dominio.cl/#organization",
      "name": "Mi Empresa",
      "sameAs": ["https://www.wikidata.org/wiki/Q2887"]
    },
    {
      "@type": "WebPage",
      "@id": "https://tu-dominio.cl/#webpage",
      "url": "https://tu-dominio.cl/",
      "publisher": { "@id": "https://tu-dominio.cl/#organization" }
    }
  ]
}

Fíjate en la última línea: publisher no repite el nombre, el logo ni el sameAs de la organización. Solo apunta al nodo que ya existe. Eso es referenciación, y es lo que mantiene tu grafo como una red coherente y no como una pila de bloques sueltos.

El problema: nodos duplicados que fragmentan tu entidad

El error clásico de los plugins de schema tradicionales es reimprimir el bloque completo de la organización en cada página, o incrustar un objeto author entero dentro de cada Article. Sin @id, cada reimpresión es, para el consumidor del grafo, una entidad nueva e independiente. Las consecuencias son concretas:

• El nombre se escribe distinto en algunas páginas («Mi Empresa SPA» frente a «Mi Empresa SpA»), y el motor las trata como entidades separadas.
• El sameAs aparece en la home pero se pierde en las páginas internas, así que la mitad de tus nodos quedan sin anclaje a Wikidata.
• El validador no marca error, porque cada bloque individual es válido. Pero el grafo completo es una sopa de nodos desconectados.

Un consultor de SEO técnico lo detecta al leer el JSON-LD crudo: decenas de nodos Organization idénticos en intención pero distintos en forma, sin ninguna referencia entre ellos. Es el escenario exacto que describe el Entity SEO: el sitio «tiene schema», pero para el Knowledge Graph sigue siendo una entidad ambigua.

La solución: referenciar por @id, no reimprimir

La arquitectura correcta es definir cada entidad una sola vez y referenciarla en el resto del grafo por su @id. Así, la organización se define una vez y se referencia desde publisher, provider, founder, worksFor, mainEntity y author, sin duplicar una sola línea.

El @id canónico de tu organización

Tu nodo Organization debe tener un @id canónico y estable, idealmente la URL de tu sitio más un fragmento: https://tu-dominio.cl/#organization. Ese es el identificador que Yoast SEO ya emite por defecto en su grafo, y es el punto de anclaje natural para cualquier extensión que le añadas encima.

@id y sameAs: el par que ancla tu nodo a Wikidata

@id y sameAs resuelven problemas distintos y se complementan. @id identifica el nodo dentro de tu grafo, es tu referencia interna. sameAs conecta ese nodo con una entidad externa verificable, como su entrada en Wikipedia o en Wikidata. Un nodo con @id y sameAs doble (Wikipedia + Wikidata con Q-ID verificado) es la unidad mínima de una entidad que un motor generativo puede resolver y comparar.

Y aquí conviene no confundir @id con la propiedad identifier de Schema.org. @id es el identificador del nodo en JSON-LD, pensado para que otros nodos lo referencien. identifier declara identificadores externos de negocio, como un RUT, un VAT o un DUNS, y suele ir acompañado de propertyID. Son conceptos distintos que muchos tutoriales mezclan.

Nota de Entidad: de la frase libre al dato estructurado

{
  "@type": "City",
  "@id": "https://tu-dominio.cl/#area-santiago",
  "name": "Santiago",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q2887",
    "https://en.wikipedia.org/wiki/Santiago"
  ]
}

Fíjate en el salto de calidad. La frase libre solo la entiende un humano con contexto. El nodo con @id y sameAs lo resuelve una máquina sin ambigüedad, porque Q2887 apunta a una entidad con descripción, relaciones y enlaces oficiales en el grafo abierto. Y como ese nodo se define una sola vez, tu servicio no reimprime «Santiago»: lo referencia con "areaServed": {"@id": "https://tu-dominio.cl/#area-santiago"}. Esa es la esencia del Entity SEO: sustituir texto que se interpreta por identificadores que se resuelven.

Higiene técnica: @id, HTTPS y validadores

El @id tiene que ser estable y coherente en todo el sitio, o el grafo se parte en dos. El caso más clásico es el HTTP/HTTPS: si WordPress quedó configurado con http:// pero tu sitio ya sirve por https://, algunos nodos emitirán http://tu-dominio.cl/#organization y otros https://tu-dominio.cl/#organization. Para un consumidor de grafos, esas son dos entidades distintas, y todo el trabajo de unificación se pierde.

Normalizar el @id a HTTPS en todo el grafo es una de las tareas de higiene más rentables del SEO técnico semántico. Lo mismo aplica a las URLs con o sin www, o con barras finales inconsistentes. Un @id canónico único es la condición de base para que el resto del grafo se cosa correctamente y valide limpio en los validadores.

La solución tecnológica: SemanticGEO

SemanticGEO es un plugin de GEO para WordPress que extiende el grafo de Yoast SEO mediante Graph Stitching, y la referenciación por @id es uno de sus cimientos técnicos. En lugar de reimprimir la organización en cada página, cose los nodos nuevos (Person E-E-A-T, Service, entidades Thing, cobertura territorial) sobre el grafo existente, referenciados por @id.

• Biblioteca central de entidades: cada entidad se define una sola vez con su Q-ID de Wikidata verificado en tiempo real contra la API, y se reutiliza en todo el sitio. Cero inconsistencias.
• sameAs doble (Wikipedia + Wikidata): anclado a la entidad, con el Q-ID validado en el momento de importar. Sin identificadores inventados.
• Cobertura territorial (areaServed): 16 regiones de Chile precargadas y tipo autodetectado desde Wikidata, heredada por los nodos Service.
• 13 packs de nicho importables: despliegan una base de entidades coherente en minutos, sin tipear un solo Q-ID a mano.
• llms.txt automático: renderizado directamente desde el grafo y sincronizado con el schema, para entregar a los motores generativos una entidad sin ambigüedades.

Una nota de honestidad técnica: ningún plugin puede garantizar que una IA te cite, y el @id es un factor más dentro de un grafo completo. SemanticGEO se vende como lo que es: la implementación técnica más rigurosa de los factores que los motores generativos declaran y demuestran consumir.

Preguntas frecuentes

¿Qué es @id en Schema.org?

@id es el atributo de JSON-LD que asigna un identificador único, casi siempre una URL, a un nodo del grafo, para que los demás nodos puedan referenciarlo sin reimprimirlo.

¿Qué pasa si no uso @id en mi schema?

Sin @id, cada bloque que reimprime tu organización o tu autor se interpreta como una entidad nueva e independiente, lo que fragmenta tu grafo y deja a la IA con una entidad ambigua y desconectada.

¿El @id tiene que ser una URL real?

Sí. Lo recomendable es usar la URL canónica de tu sitio más un fragmento estable, por ejemplo https://tu-dominio.cl/#organization, y mantenerla idéntica en todo el grafo, normalizada a HTTPS.

¿@id es lo mismo que la propiedad identifier?

No. @id identifica el nodo dentro del grafo JSON-LD para referenciarlo. La propiedad identifier declara identificadores externos de negocio, como un RUT, un VAT o un DUNS, y suele acompañarse de propertyID.

¿@id garantiza que la IA me cite?

No. Ningún marcado puede garantizar la citación en motores generativos. Lo que @id sí garantiza es una condición técnica de base: una entidad única, referenciada y verificable, en lugar de nodos duplicados que el motor no puede unificar.

Conclusión

El @id parece un detalle técnico menor, pero es la diferencia entre un grafo que multiplica entidades y uno que las unifica. Si tu WordPress emite schema y aun así no resuelves como una sola entidad ante la IA, revisa primero los @id: es probable que estés reimprimiendo bloques en lugar de referenciarlos.

Referenciar por @id, anclar cada entidad con sameAs a Wikidata y normalizar el identificador a HTTPS son las tres decisiones que convierten tu dato estructurado en una entidad verificable. Y es exactamente la arquitectura que SemanticGEO automatiza sobre el grafo de Yoast SEO.