Una zapatilla tiene tres colores y varios talles. La tienda muestra un selector, el inventario guarda una referencia por combinación y algunas opciones tienen una URL propia. Para implementar datos estructurados necesitás ordenar esas relaciones antes de agregar código: qué comparten las variantes, qué identifica a cada una y qué oferta puede comprar el usuario.

ProductGroup representa la familia; Product, cada variante concreta; y Offer, sus condiciones de venta. Vamos a construir un ejemplo y a revisar cómo comprobarlo. El objetivo es que el marcado describa el catálogo real y pueda mantenerse cuando cambian precio, disponibilidad o referencias.

Abrí el catálogo antes de abrir el editor de código

Elegí una familia pequeña que conozcas bien. Anotá modelo, atributos de variación, SKU de cada combinación, precio, disponibilidad, imagen y dirección que permite seleccionar esa opción. Contrastá lo que aparece en administración con lo que recibe una persona que abre la ficha sin sesión.

Un modelo puede variar por color y talle; otro, por material o capacidad. No agrupes productos solamente porque tienen nombres parecidos. Necesitás identificar una relación de variantes que el catálogo y el comprador puedan reconocer. Un set de accesorios y una zapatilla no se convierten en versiones del mismo producto porque se vendan juntos.

Separá el identificador de la familia del identificador de cada variante. En nuestro caso ficticio, el grupo será ECLIPSE y las variantes tendrán SKU propios. Conservá esos identificadores cuando se actualice una descripción. Si cambian cada vez que se publica una ficha, se vuelve más difícil relacionar inventario, marcado y seguimiento.

Tres niveles, tres preguntas

ProductGroup: ¿a qué familia pertenece?

Reúne características compartidas e identifica las propiedades que varían mediante variesBy. productGroupID conserva un identificador del conjunto y hasVariant relaciona sus productos.

Product: ¿qué opción es esta?

Describe la combinación concreta: nombre, SKU, imagen y atributos como color o talle. Tiene que permitir distinguirla de las otras opciones del grupo.

Offer: ¿en qué condiciones se vende?

Expresa precio, moneda, disponibilidad y una URL de compra pertinente. Esos valores deben corresponder a la variante que el comprador puede seleccionar.

El identificador @id conecta entidades dentro del marcado; no reemplaza al SKU ni significa que exista una página indexable para cada fragmento. Usá valores estables y no confundas la dirección que identifica una entidad con la URL que abre una compra.

Un ejemplo completo para una familia de una sola página

Supongamos que la ficha principal permite elegir color sin recargar toda la página. Las direcciones con parámetros abren el mismo producto con una opción preseleccionada. Para mantener breve el ejemplo, mostramos dos variantes de color en un mismo talle. Los nombres, URLs, precios y referencias son ficticios.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "@id": "https://example.com/zapatilla-eclipse/#grupo",
  "url": "https://example.com/zapatilla-eclipse/",
  "name": "Zapatilla Eclipse",
  "description": "Zapatilla de lona de la colección de ejemplo.",
  "brand": {
    "@type": "Brand",
    "name": "Marca de ejemplo"
  },
  "productGroupID": "ECLIPSE",
  "variesBy": ["https://schema.org/color"],
  "hasVariant": [
    {
      "@type": "Product",
      "@id": "https://example.com/zapatilla-eclipse/#blanca-38",
      "name": "Zapatilla Eclipse blanca, talle 38",
      "description": "Variante blanca en talle 38.",
      "sku": "ECL-BLA-38",
      "color": "Blanco",
      "size": "38",
      "image": "https://example.com/media/eclipse-blanca-38.webp",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/zapatilla-eclipse/?color=blanco",
        "price": "60.00",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "itemCondition": "https://schema.org/NewCondition"
      }
    },
    {
      "@type": "Product",
      "@id": "https://example.com/zapatilla-eclipse/#negra-38",
      "name": "Zapatilla Eclipse negra, talle 38",
      "description": "Variante negra en talle 38.",
      "sku": "ECL-NEG-38",
      "color": "Negro",
      "size": "38",
      "image": "https://example.com/media/eclipse-negra-38.webp",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/zapatilla-eclipse/?color=negro",
        "price": "62.00",
        "priceCurrency": "USD",
        "availability": "https://schema.org/OutOfStock",
        "itemCondition": "https://schema.org/NewCondition"
      }
    }
  ]
}
</script>

En una implementación real tendrías que completar las combinaciones correspondientes y sus condiciones. No copies URLs de ejemplo ni agregues identificadores comerciales que el producto no tenga. El SKU puede ser interno; un GTIN debe ser el identificador real asignado al producto, cuando corresponda.

El ejemplo ilustra la relación entre grupo, variantes y ofertas. No incluye toda la información comercial que una tienda puede necesitar publicar, como envío o devoluciones. La validación debe considerar el conjunto de requisitos aplicable a tu caso y los datos que efectivamente podés respaldar.

Probá las URLs como si estuvieras por comprar

Abrí la dirección de la variante blanca en una ventana nueva. ¿Queda seleccionado el color blanco? ¿El talle corresponde al ejemplo? ¿La imagen, el precio y la disponibilidad coinciden? Después repetí con la negra. Si ambos enlaces muestran siempre la misma opción, el marcado describe una distinción que el recorrido no conserva.

Si hay más de un talle, la dirección de cada oferta debe permitir llegar a la combinación pertinente, usando el mecanismo que realmente tenga la tienda. No agregues parámetros inventados que el selector no interpreta. Una URL diferente en el código no crea por sí sola una variante seleccionable.

Comprobá también que un cambio de color no deje el precio anterior visible mientras el carrito agrega otra combinación. Esa falla afecta la compra antes que el SEO. La relación entre marcado e interfaz se revisa con una operación real de selección, no solamente mirando el texto del script.

Qué cambia cuando cada variante tiene su propia página

Si la tienda usa páginas separadas, cada una necesita describir la variante que presenta y mantener una relación consistente con la familia. Las propiedades compartidas no deberían contradecirse entre versiones. El modo de distribuir el marcado cambia respecto de una ficha única con selector.

Definí primero la arquitectura que el negocio necesita sostener. El marcado no decide por sí solo qué URLs deben indexarse ni corrige un canonical contradictorio. Tampoco conviene crear páginas adicionales únicamente para poder escribir un Product distinto.

Cuando tengas URLs muy similares, revisá intención, contenido y selección de la opción antes de cambiar señales. La guía sobre filtros y URLs de una tienda ayuda a separar decisiones de navegación, indexación y consolidación. Las variantes merecen su propio inventario dentro de ese análisis.

En el CMS, buscá quién está generando cada entidad

Una tienda puede recibir marcado del tema, del sistema de productos y de una integración SEO al mismo tiempo. Antes de pegar otro script, inspeccioná la salida pública y registrá qué entidades ya existen. Dos descripciones del mismo producto con precios distintos generan una contradicción que no se arregla sumando una tercera.

Pedí que la generación use el catálogo y el inventario como origen de los datos. Mantener manualmente precios dentro de un bloque de código obliga a recordar una segunda actualización. Esa dependencia suele fallar cuando hay promociones, cambios de stock o productos retirados.

Probá también la caché. Una variante puede mostrar disponibilidad actual en el selector y conservar una oferta anterior en el HTML. Si el sistema actualiza distintas capas con tiempos diferentes, documentá cuándo se invalida cada una y cómo se comprueba la salida que recibe un visitante.

Validá sintaxis, coherencia y recorrido

  1. Leé el JSON. Confirmá estructura válida, comillas y propiedades en el nivel correcto. Un error de sintaxis puede impedir interpretar el bloque completo.
  2. Usá la Prueba de resultados enriquecidos. Revisá errores críticos y advertencias. Una advertencia necesita evaluación; no siempre representa el mismo tipo de problema que un campo obligatorio ausente.
  3. Abrí cada URL de la muestra. Compará variante seleccionada, imagen, precio y disponibilidad con el marcado.
  4. Probá una opción agotada. El ejemplo de la variante negra debe coincidir con la condición que muestra la tienda y con lo que permite agregar al carrito.
  5. Modificá un dato en ensayo. Cambiá precio o stock y verificá que interfaz y marcado se actualicen según lo previsto.
  6. Inspeccioná el resultado que obtiene Google. Si parte del contenido depende de scripts, comprobá que los datos y el producto puedan procesarse.

La auditoría de renderizado JavaScript permite investigar diferencias entre HTML inicial y contenido procesado. Es una revisión complementaria: un JSON correcto no prueba que todo el recorrido de la ficha esté disponible.

Cuándo podés dar la implementación por comprobada

Dejá una muestra que incluya una familia sencilla, otra con varios atributos, un cambio de precio y una opción sin stock. Registrá qué entidades debería producir cada una y qué prueba confirma el comportamiento. Esa muestra sirve para revisar futuras actualizaciones del tema o del sistema de tienda.

El marcado puede hacer que una página sea elegible para determinadas presentaciones de producto, pero no garantiza que aparezcan. Tampoco demuestra una mejora de ventas. Tu primer criterio de aceptación es más concreto: la información es válida, coherente con la compra y mantenible desde el catálogo real.

Si la ficha todavía deja dudas al elegir una combinación, revisá también cómo hacer que el catálogo ayude a elegir. Describir bien una variante y permitir comprarla con claridad forman parte del mismo trabajo.