# @id en JSON-LD: qué es el identificador y cómo elegirlo

> Qué es el identificador @id en JSON-LD, cómo une los nodos de tu schema, por qué conviene que no cambie y cómo evitar dos productos donde hay uno.

URL: https://clione.ai/es/glosario/id-json-ld/
Lang: es

En el bloque [JSON-LD](/es/glosario/json-ld/) de muchas fichas aparece una línea como `"@id": "https://www.example.com/camisa-lino-calella#product"`. Parece un enlace y casi nunca se abre: **es un nombre**. No es el código del producto ni su [SKU](/es/glosario/sku/), tampoco la propiedad `identifier` de [Schema.org](/es/glosario/schema-org/) ni la lista de perfiles de [`sameAs`](/es/glosario/sameas/). Es la palabra clave con la que el propio formato distingue un nodo de otro dentro de los [datos estructurados](/es/glosario/datos-estructurados/) de la página. Te importa porque es lo que une la oferta con la tienda que la vende, y lo que decide si el bloque de tu tema y el de una aplicación describen un producto o dos.

## Cómo funciona

La especificación JSON-LD 1.1 del W3C define `@id` como la palabra clave que **identifica de forma única los nodos descritos en el documento**, con un IRI o con un identificador de nodo anónimo.[^w3c-json-ld11] Explica también para qué: para poder referirse a un nodo desde fuera es importante que tenga un identificador, y en los datos enlazados lo ideal es que, al abrir ese identificador, se obtenga una descripción del nodo.[^w3c-json-ld11]

Un IRI se parece a una URL, pero no es lo mismo. La especificación lo aclara: **una URL localiza un recurso en la web y un IRI lo identifica**. Es buena práctica que se pueda abrir, aunque no siempre es práctico, y pone como ejemplo un identificador `urn:uuid:` que no lleva a ninguna parte.[^w3c-json-ld11] En una tienda, el IRI suele ser la URL de la página con un fragmento detrás (`#product`, `#organization`, `#website`), que nombra cada cosa sin inventar direcciones nuevas.

Un `@id` puede escribirse relativo, por ejemplo `"../"`, y entonces se resuelve contra la dirección base del documento. La especificación avisa del coste: **si el documento cambia de sitio, el identificador cambia con él**.[^w3c-json-ld11] Por eso en una tienda se escriben completos.

Con un nombre, un nodo ya se puede citar. La especificación llama referencia de nodo a un objeto que **solo lleva `@id`**: no describe nada, apunta a un nodo descrito en otra parte del documento.[^w3c-json-ld11] Es lo que hace `"seller": {"@id": "https://www.example.com/#organization"}` dentro de una oferta: dice quién vende sin repetir los datos de la empresa.

Sin `@id`, el nodo es válido, pero anónimo. JSON-LD no obliga a identificar todos los nodos; los que no tienen IRI son nodos en blanco, y si llevan un identificador local (empieza por `_:`), solo vale dentro de su documento: **desde otro documento no se les puede citar**.[^w3c-json-ld11]

Y lo que más afecta a una ficha: cuando se extrae el JSON-LD de una página HTML como datos enlazados, **todos sus bloques `<script type="application/ld+json">` se procesan y se fusionan en un único conjunto de datos**.[^w3c-json-ld11] Al aplanar ese conjunto, se reúnen en un solo mapa todas las propiedades de cada nodo.[^w3c-json-ld11] Dos bloques que describen un nodo con el mismo `@id` acaban siendo un nodo con las propiedades de los dos; dos bloques sin `@id`, dos nodos distintos.

Google lo pide en sus directrices generales. Cuando varios elementos de una página van por separado y se entienden mejor juntos, como una receta y su vídeo, hay que usar `@id` en los dos; si no los enlazas, **la Búsqueda puede no saber que van juntos**, y en su ejemplo eso le impide mostrar el vídeo como parte del resultado enriquecido de la receta.[^google-sd-policies] El ejemplo es de recetas, pero la regla está en las directrices generales, las que se aplican a todos los [resultados enriquecidos](/es/glosario/resultados-enriquecidos/).[^google-sd-policies] El [`@graph`](/es/glosario/graph/) reúne los nodos en un bloque; el `@id` es lo que los conecta.

## En una tienda

**Ejemplo ficticio.** La ficha de una camisa de Calella, una tienda inventada, con dos bloques: el que trae el tema y el que añade una aplicación. Recortados a lo esencial:

```html
<!-- Bloque del tema -->
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "Camisa de lino Calella, azul",
    "offers": { "@type": "Offer", "price": "39.90", "priceCurrency": "EUR" }
  }
</script>

<!-- Bloque de la aplicación -->
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "@id": "https://www.example.com/camisa-lino-calella#product",
    "name": "Camisa de lino Calella, azul",
    "brand": { "@id": "https://www.example.com/#organization" }
  }
</script>
```

Leídos juntos, son **dos productos**: uno anónimo con precio y otro con nombre propio y marca, pero sin precio. Si el tema también escribiera `"@id": "https://www.example.com/camisa-lino-calella#product"`, serían uno solo con las dos cosas.[^w3c-json-ld11] El caso no es raro: el bloque de [Product](/es/glosario/schema-product/) que trae Cornerstone, el tema por defecto de BigCommerce, en su versión 6.22.0, **no lleva `@id`**.[^cornerstone-repo] En una ficha publicada con Clione, su nodo Product lleva un `@id` estable y convive con el del tema en lugar de duplicarlo.

El otro uso diario es el de la [entidad](/es/glosario/entidad/) que se repite en todo el sitio. La tienda es la misma en la portada, en cada categoría y en cada ficha, así que su nodo [Organization](/es/glosario/schema-organization/) debería llamarse igual en todas: `https://www.example.com/#organization`. Cada oferta la cita como vendedora y el nodo [WebSite](/es/glosario/schema-website/) como editora, sin describirla de nuevo.


Creer que el `@id` tiene que ser una página que exista, y escribirle la URL de la ficha a secas. No es obligatorio que se abra: la especificación lo recomienda como buena práctica y admite identificadores que no llevan a ninguna parte.[^w3c-json-ld11] Lo que sí importa es que sea **único**. Si el producto y la página que lo describe (un nodo de tipo página web) usan los dos la URL de la ficha sin fragmento, al leerse juntos se funden en un solo nodo con dos tipos, porque todas las propiedades de un mismo identificador se reúnen en un único mapa.[^w3c-json-ld11]


## Cómo comprobarlo

1. **Abre el código fuente de una ficha** y busca `@id`. Apunta el de cada nodo: producto, oferta, organización, sitio. El que no tenga, es anónimo.[^w3c-json-ld11]
2. **Sigue cada referencia.** Todo objeto que solo lleve `@id` tiene que apuntar a un nodo que exista en la página con ese mismo valor, letra por letra.[^w3c-json-ld11]
3. **Cuenta los nodos de producto.** Si hay dos, mira si comparten `@id`. Si no, son dos productos para cualquiera que lea la página.[^w3c-json-ld11]
4. **Compara el `@id` de la organización en tres páginas**: la portada, una categoría y una ficha. Debería ser el mismo.
5. **Pasa la URL por la [Prueba de resultados enriquecidos](/es/glosario/prueba-de-resultados-enriquecidos/)** y compara los elementos que detecta con los nodos que has contado; si dos que deberían ir juntos salen por separado, falta un `@id` que los una.[^google-sd-policies]

## Concepto cercano: sameAs

Los dos sirven para identificar, y miran en direcciones opuestas. **`@id` es el nombre que le das tú a un nodo dentro de tu marcado**, y lo define el formato JSON-LD.[^w3c-json-ld11] `sameAs` es una propiedad de Schema.org que apunta hacia fuera, a páginas de otros sitios que dicen quién es esa entidad: la entrada de [sameAs](/es/glosario/sameas/) explica cuáles poner. Un nodo de organización bien hecho suele llevar los dos: su `@id` para que tus propios nodos lo citen, y su `sameAs` para que el resto del mundo lo reconozca.

Para seguir, la [ruta de lectura de datos estructurados](/es/aprender/datos-estructurados/) ordena el resto de términos, y la entrada de [`@graph`](/es/glosario/graph/) muestra cómo se combinan varios nodos con sus `@id` en un solo bloque.