9 marcados de esquema de comercio electrónico que toda tienda debe conocer

Escrito por Evan Huang

Publicado el 21 de julio de 2026 • 18 min de lectura

El marcado de esquema de comercio electrónico proporciona a los buscadores una descripción estructurada de los productos, ofertas, políticas y detalles del negocio que los compradores ya pueden ver en una tienda en línea. Sin él, un rastreador debe deducir si un número es un precio, si un artículo tiene existencias, qué color corresponde a cada variante y si una política se aplica a un producto o a toda la tienda.

Estas distinciones importan a medida que el descubrimiento de productos se expande por los resultados de búsqueda normales, las experiencias de compra, la búsqueda de imágenes y la investigación asistida por IA. Los datos estructurados precisos pueden facilitar que las máquinas interpreten una tienda y que las páginas elegibles estén disponibles para presentaciones de búsqueda más completas. No garantizan posiciones, resultados enriquecidos, citas ni recomendaciones de IA.

Esta guía explica por qué importa el esquema de comercio electrónico, dónde corresponde cada tipo y qué nueve marcados merecen prioridad. También ofrece un ejemplo completo de JSON-LD, un flujo de pruebas y una forma práctica de separar la preparación técnica de las páginas de la visibilidad real de los productos en IA.

¿Qué es el marcado de esquema de comercio electrónico?

El marcado de esquema de comercio electrónico son datos estructurados añadidos a las páginas de una tienda para describir entidades y relaciones en un formato estandarizado y legible por máquinas. El vocabulario suele proceder de Schema.org, mientras que los buscadores publican sus propias reglas de elegibilidad para las funciones específicas de datos estructurados que admiten.

Tres términos aparecen con frecuencia:

• Marcado de esquema es el vocabulario para etiquetar entidades como Product, Offer, Organization o Review.
• Datos estructurados es la información legible por máquinas creada con ese vocabulario.
• JSON-LD es el formato que Google recomienda para implementar datos estructurados. Normalmente aparece dentro de un elemento <script type="application/ld+json"> en el HTML de la página.

Es importante distinguir entre la validez según Schema.org y la elegibilidad para una función de Google. Schema.org contiene un vocabulario amplio. Google admite determinados tipos y propiedades para experiencias de búsqueda específicas. Un bloque de marcado puede ser válido según Schema.org y aun así no ser elegible para un resultado enriquecido de Google porque le falta una propiedad obligatoria o no coincide con el propósito de la página.

Por qué importa el esquema

Las páginas de comercio electrónico contienen datos que cambian rápidamente y entidades muy relacionadas. Una sola página de producto puede incluir nombre, marca, SKU, precio, moneda, disponibilidad, variantes, reseñas, condiciones de envío y reglas de devolución. Un esquema claro ayuda a las máquinas a conectar esos datos con el producto y la oferta correctos.

Claridad de datos de producto

El texto y el diseño visual aportan contexto a los compradores, pero las máquinas se benefician de etiquetas explícitas. priceCurrency identifica la moneda asociada a un precio. availability identifica si el artículo tiene existencias. sku, gtin y mpn ayudan a distinguir un producto de otro. ProductGroup puede conectar variantes de talla o color con un producto padre común.

Los datos estructurados deben coincidir con el contenido actual y visible de la página. Un precio o estado de existencias obsoleto puede crear señales contradictorias y volver poco fiable una implementación técnicamente válida.

Elegibilidad para resultados enriquecidos

Google indica que los datos estructurados de producto pueden hacer que la información de producto sea elegible para presentaciones mejoradas en Search, Google Images y Google Lens. Según la página y los datos disponibles, esas presentaciones pueden incluir precio, disponibilidad, valoraciones, información de envío y devoluciones.

La elegibilidad es la expectativa correcta. Google no garantiza que los datos estructurados válidos aparezcan como un resultado enriquecido. La presentación en búsquedas depende de la consulta, el dispositivo, la ubicación, la calidad de la página, las políticas y otros sistemas.

Datos de producto coherentes

La implementación de esquemas suele revelar problemas operativos que ya afectan a los compradores. Un catálogo puede mostrar un precio en el HTML visible, otro en un bloque JSON-LD generado por una aplicación y un tercero en un feed de productos. Auditar los datos estructurados obliga a identificar una fuente fiable para precios, inventario, identificadores y políticas.

La coherencia apoya el SEO de Shopify, la calidad de feeds, el rastreo y el mantenimiento. Su beneficio va más allá del marcado.

Legibilidad por máquinas y límites de visibilidad en IA

Los datos estructurados dan a los sistemas automáticos pistas explícitas sobre productos y políticas. Eso puede mejorar la legibilidad de la página para sistemas que analizan HTML y marcado estructurado. Sin embargo, las respuestas de IA también pueden depender del acceso de rastreo, la calidad del contenido, la autoridad de marca, las citas de terceros, los datos de marketplaces, la relevancia del producto, la actualidad y el proceso de recuperación del modelo.

La preparación del esquema y la visibilidad real en IA requieren mediciones separadas. Un bloque JSON-LD limpio no puede demostrar que un producto se mencione, cite, posicione o recomiende en una respuesta de IA en directo.

Asignar esquemas a cada página

Las distintas plantillas de página tienen propósitos diferentes. Añadir el mismo gran grafo de esquemas a todas las URL suele crear duplicación y entidades irrelevantes. Un enfoque mejor asigna a cada tipo de página su entidad principal y añade marcado de apoyo únicamente cuando lo justifica el contenido visible.

El mapa es un punto de partida. Una tienda debe añadir únicamente los tipos y propiedades respaldados por el contenido real de la página. Google recomienda centrar el marcado de resultados enriquecidos de producto en páginas sobre un producto o varias variantes del mismo producto, en lugar de una página general de categoría.

9 marcados de esquema de comercio electrónico que deben conocer las tiendas en línea

Los nueve grupos siguientes cubren los casos de uso más habituales del comercio electrónico. Una tienda no necesita todos los tipos en cada página. La prioridad debe seguir el propósito de la página, la estructura del catálogo y las funciones de búsqueda importantes para el negocio.

1. OnlineStore y Organization

OnlineStore es un subtipo de Schema.org para un negocio de comercio electrónico. Puede describir el nombre, URL, logotipo, datos de contacto, identificadores y relaciones de la tienda con políticas o marketplaces. Organization es el tipo más amplio y también el que Google documenta para detalles empresariales y políticas de devolución a nivel de organización.

Utiliza un ID de entidad estable, como https://example.com/#organization, y haz referencia a él desde otros bloques de marcado. Esto ayuda a evitar la creación de varias versiones desconectadas del mismo negocio.

Mejor ubicación: la página de inicio o un grafo para todo el sitio generado desde una única fuente de referencia.

2. Product

Product identifica el artículo descrito en una página de detalles de producto. Las propiedades habituales incluyen name, image, description, sku, gtin, mpn, brand, color, size, category y offers.

Para la elegibilidad en fichas de comerciante de Google, name, image y una Offer anidada son requisitos centrales. Los identificadores deben reflejar datos reales del fabricante o del catálogo. Una tienda no debe inventar un GTIN cuando no existe.

Mejor ubicación: una página de detalles centrada en un producto o en las variantes de ese producto.

3. Offer

Offer describe las condiciones comerciales asociadas a un producto. Es donde suelen corresponder precio, moneda, disponibilidad, estado, URL de compra, detalles de envío y reglas de devolución específicas del producto.

Como mínimo, una oferta de producto que pueda comprarse debe mantener price y priceCurrency sincronizados con la página visible. Los detalles recomendados, como availability, url e itemCondition, reducen la ambigüedad. Si se indica una fecha de caducidad de la oferta mediante priceValidUntil, debe mantenerse actualizada porque una fecha pasada puede afectar a cómo se muestra la ficha.

Mejor ubicación: dentro del Product correspondiente.

4. ProductGroup

ProductGroup conecta variantes pertenecientes al mismo producto padre. Una camisa vendida en cuatro colores y cinco tallas puede representar un grupo de productos con variantes enlazadas mediante hasVariant o isVariantOf.

Utiliza URL estables para las variantes y marca la propiedad distintiva, como color o talla, con variesBy. Cada variante debe llevar su propio SKU, URL, imagen, precio y disponibilidad cuando esos valores sean diferentes.

Mejor ubicación: familias de productos con variantes seleccionables. Evita tratar productos sin relación como variantes simplemente porque comparten categoría.

5. AggregateRating y Review

AggregateRating resume un conjunto auténtico de valoraciones con valores como ratingValue y reviewCount. Review describe una reseña individual, incluidos autor, texto de la reseña, fecha y valoración.

Marca únicamente reseñas mostradas en la página y asociadas al producto concreto. Las valoraciones creadas por la propia tienda, las reseñas importadas sin procedencia clara y el contenido de reseñas oculto pueden infringir las directrices de calidad de datos estructurados.

Mejor ubicación: páginas de producto que muestren visiblemente reseñas de producto elegibles.

6. BreadcrumbList

BreadcrumbList describe la jerarquía que lleva a la página actual. Una ruta de producto podría ser Inicio, Recipientes para bebidas, Tazas de viaje y Taza de viaje Aster. Cada paso se representa mediante un ListItem con posición, nombre y URL.

El marcado de migas de pan ayuda a los buscadores a entender la estructura del sitio y puede permitir una ruta de navegación más significativa en los resultados. La ruta marcada debe coincidir con la que los usuarios pueden recorrer en la página.

Mejor ubicación: páginas de productos, colecciones, blogs e información con migas de pan visibles.

7. ItemList

ItemList describe un grupo de elementos ordenado o no ordenado. En una página de colección puede identificar los productos mostrados y sus posiciones. Debe representar la lista visible, en lugar de un conjunto de inventario oculto o mucho mayor.

ItemList no convierte una página de categoría en una página de resultados enriquecidos de producto. Google recomienda ese marcado para páginas centradas en un producto específico o sus variantes. El marcado de colección resulta útil para describir la estructura de la página, mientras que las URL individuales de producto contienen los datos detallados de Product y Offer.

Mejor ubicación: páginas de colecciones, categorías, listas comparativas y selecciones de productos elaboradas editorialmente.

8. MerchantReturnPolicy

MerchantReturnPolicy comunica los países cubiertos, el plazo de devolución, el método, las tarifas y las condiciones de reembolso. Google recomienda definir una política global bajo Organization cuando la mayoría de los productos comparte las mismas condiciones. Una política a nivel de producto bajo Offer puede sustituir la global en una excepción.

El esquema debe coincidir con la página visible de la política y la experiencia de pago. Los códigos de país, días de devolución, tarifas y excepciones estacionales necesitan mantenimiento continuo.

Mejor ubicación: el grafo de organización para una política global, con excepciones a nivel de oferta solo cuando sean necesarias.

9. ShippingService y OfferShippingDetails

ShippingService puede describir una política de envío para toda la tienda. OfferShippingDetails describe el envío asociado a una oferta específica, incluidos destino, tarifa, tiempo de preparación y tiempo de tránsito. Una tienda puede utilizar referencias @id estables para conectar ofertas con un servicio de envío global.

El marcado de envío se vuelve complejo cuando las tarifas varían según región, valor del carrito, nivel de servicio o producto. Cada condición debe reflejar lo que los compradores pueden recibir realmente. El envío gratuito utiliza un valor numérico de 0 con la moneda correcta, no una frase promocional.

Mejor ubicación: ShippingService en el grafo de políticas a nivel de organización y OfferShippingDetails dentro de una oferta cuando se necesitan detalles a nivel de producto.

Cómo implementar esquemas con seguridad

Los proyectos de datos estructurados suelen fallar porque varios sistemas escriben marcado superpuesto. Un tema, una aplicación de reseñas, un complemento SEO, una aplicación de feeds y un script personalizado pueden generar cada uno su propia entidad Product. La implementación debe comenzar con un inventario de lo que ya existe.

1. Auditoría de salida renderizada

Inspecciona páginas representativas de cada plantilla, incluidos productos con y sin reseñas, productos con variantes, artículos rebajados, artículos agotados, colecciones y páginas de políticas. Registra todos los bloques JSON-LD y el sistema que los generó.

2. Fuente única de referencia

El precio y el inventario normalmente deben proceder de la plataforma de comercio. Los recuentos de reseñas deben proceder del sistema de reseñas. Las condiciones de devolución y envío deben proceder de datos de políticas mantenidos. Define la responsabilidad antes de cambiar el marcado.

Un campo no debe tener valores contradictorios entre el HTML visible, los datos estructurados y los feeds de productos.

3. ID de entidad estables

Usa URL completas con fragmentos para @id. Por ejemplo:

• https://example.com/#organization
• https://example.com/products/aster-travel-mug#product
• https://example.com/products/aster-travel-mug#offer
• https://example.com/policies/returns#policy

Los ID estables permiten referirse a una misma organización, producto, oferta o política sin repetir copias contradictorias.

4. Despliegue en lote representativo

Publica primero los cambios en un grupo limitado de páginas. Prueba un producto estándar, uno con variantes, un artículo rebajado, uno agotado y las páginas de políticas pertinentes. Esto facilita aislar los errores de las plantillas.

5. Desencadenantes de mantenimiento

El esquema debe volver a probarse después de cambios de tema, instalaciones de aplicaciones, migraciones de catálogo, cambios de moneda o proveedor de reseñas y actualizaciones de políticas de envío o devolución. El plan de mantenimiento importa tanto como el código inicial.

Ejemplo completo de esquema de producto

El siguiente ejemplo de JSON-LD describe un producto ficticio y una oferta activa. Incluye identidad del producto, marca, precio, disponibilidad, valoración agregada, detalles de envío y una política de devolución a nivel de producto. Las políticas de envío y devolución de toda la tienda pueden, en su lugar, residir bajo el grafo de organización y referenciarse mediante @id.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/aster-travel-mug#product",
  "name": "Aster Insulated Travel Mug, 16 oz",
  "description": "A 16-ounce stainless steel travel mug with a leak-resistant lid.",
  "image": [
    "https://example.com/images/aster-mug-1x1.jpg",
    "https://example.com/images/aster-mug-4x3.jpg",
    "https://example.com/images/aster-mug-16x9.jpg"
  ],
  "sku": "ATM-16-NAVY",
  "gtin13": "0123456789012",
  "brand": {
    "@type": "Brand",
    "name": "Example Brand"
  },
  "color": "Navy",
  "offers": {
    "@type": "Offer",
    "@id": "https://example.com/products/aster-travel-mug#offer",
    "url": "https://example.com/products/aster-travel-mug",
    "price": 29.99,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "US"
      },
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": 0,
        "currency": "USD"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 2,
          "maxValue": 5,
          "unitCode": "DAY"
        }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "US",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.7,
    "reviewCount": 128
  }
}
</script>

Este ejemplo es una plantilla, no datos para copiar y pegar en producción. El nombre del producto, las imágenes, identificadores, precio, estado de existencias, valoración, plazos de envío, destinos y condiciones de devolución deben coincidir con la página donde aparezca el código.

Para las variantes, una tienda puede añadir un ProductGroup con variesBy y conectar cada variante mediante hasVariant. Una URL de variante individual debe identificar la variante seleccionada y su oferta específica. Las tiendas que venden en varias monedas deben revisar la recomendación de Google de utilizar una URL distinta para cada moneda.

Cómo probar y supervisar esquemas

La validación necesita varias herramientas porque la sintaxis, el vocabulario de Schema.org, la elegibilidad de Google, el resultado renderizado y el rendimiento real en búsquedas son cuestiones separadas.

Elegibilidad para resultados enriquecidos

Utiliza la prueba de resultados enriquecidos de Google con código y URL activas. Corrige primero los errores críticos. Las advertencias sobre propiedades recomendadas pueden identificar mejoras útiles, pero no siempre bloquean la elegibilidad.

Validación completa del grafo Schema.org

Utiliza Schema Markup Validator para inspeccionar tipos y propiedades que la prueba de Google quizá no evalúe. Es especialmente útil para OnlineStore, ItemList y los nodos conectados de organización o políticas.

Inspección de URL renderizada

Utiliza Inspección de URLs en Google Search Console para confirmar que Google puede acceder a la página y al marcado renderizado. Comprueba si las reglas de robots, noindex, los requisitos de inicio de sesión, los errores de JavaScript o los problemas del servidor bloquean la página.

Google señala que el marcado de producto generado dinámicamente puede hacer que los rastreos de compras sean menos frecuentes y fiables, especialmente cuando los precios y la disponibilidad cambian rápidamente. Los datos de producto renderizados en el servidor o presentes en el HTML inicial pueden reducir ese riesgo.

Seguimiento tras el despliegue

Sigue en Search Console los informes de mejoras, los problemas de fichas de comerciante, los problemas de fragmentos de producto, los cambios de rastreo y las acciones manuales. Vuelve a probar muestras después de publicar cambios de catálogo y políticas. Un resultado válido hoy no demuestra que el resultado de las plantillas futuras siga siendo preciso.

Medir lo que el esquema no demuestra

Un validador responde si el marcado es legible o elegible para una función compatible. No responde si una página es lo bastante sólida para ser citada, si un producto aparece en respuestas de IA orientadas al comprador o si los competidores reciben más recomendaciones.

Esa distinción es fundamental para la optimización de motores generativos. La preparación de las páginas y la visibilidad observada pertenecen a capas de medición separadas.

Preparación SEO y GEO por página

El comprobador de puntuación GEO de Nexscope evalúa señales de cada página en SEO, preparación para GEO y visibilidad en IA, salud técnica y autoridad del contenido. Sus comprobaciones abarcan preparación para el rastreo, intención de búsqueda, SEO de imágenes, datos estructurados, señales de confianza, reconocimiento de marca en IA, preparación para citas y correcciones priorizadas.

La puntuación resultante mide si una página está preparada para que los sistemas de búsqueda e IA accedan a ella, la entiendan y potencialmente la citen. No mide el posicionamiento real de un producto ni su frecuencia de recomendación dentro de una plataforma de IA.

El informe de ejemplo siguiente ilustra cómo los hallazgos técnicos y de contenido se separan en comprobaciones sobre las que se puede actuar.

El comprobador se aplica a URL individuales de comercio electrónico, productos, colecciones, artículos y servicios. Los resultados deben interpretarse dentro del alcance del rastreador y la plataforma mostrado en el informe.

Menciones en IA y recomendaciones de productos

La herramienta de visibilidad de productos en IA examina otro resultado: si un producto aparece en respuestas de compra pertinentes asistidas por IA. Su informe incluye un cuadro de visibilidad, cobertura de preguntas de compradores, evidencia por consulta, comparativas de LLM y competidores, carencias de citas y señales y un plan de acción priorizado.

Un informe oficial de ejemplo de visibilidad en IA muestra cómo se presentan esas dimensiones.

Los resultados observados dependen de la consulta, el modelo, la ubicación, el idioma y el momento. Deben tratarse como una muestra medida del comportamiento de la plataforma, no como una garantía permanente. Esto importa a medida que la compra con IA cambia el descubrimiento de productos y las preguntas de los compradores se vuelven más conversacionales.

Errores habituales de esquema

La mayoría de los problemas de esquemas de comercio electrónico proviene de sistemas en conflicto, datos de catálogo obsoletos o marcado que describe contenido que los usuarios no pueden ver.

• Entidades de producto duplicadas: un tema y varias aplicaciones generan bloques Product separados con valores diferentes.
• Precio o disponibilidad obsoletos: el JSON-LD no se actualiza cuando cambia el precio visible del producto o el inventario.
• Moneda, URL o estado ausentes: una oferta carece del contexto necesario para interpretar sus condiciones comerciales.
• Identificadores inventados: una tienda crea un GTIN, MPN o valor de marca en lugar de utilizar datos reales del producto.
• Marcado de reseñas no válido: las valoraciones están ocultas, no corresponden al producto, son creadas por la propia tienda o no coinciden con el recuento visible de reseñas.
• Modelado incorrecto de variantes: cada variante se trata como un producto sin relación, o se reutiliza una oferta padre pese a que las variantes tienen precios y existencias específicos.
• Marcado de producto en páginas de colección: una categoría se marca como un solo producto aunque enumera artículos sin relación entre sí.
• Desactualización de políticas: los destinos, tarifas y plazos de envío o los periodos de devolución ya no coinciden con la página de políticas o el proceso de pago.
• Fallos de renderizado de JavaScript: el esquema de producto se inyecta tarde, de forma intermitente o solo después de una interacción del usuario.
• Lenguaje de garantía: la implementación se presenta como prueba de posicionamiento, resultados enriquecidos, citas o recomendaciones de IA.

Cuando una auditoría descubre problemas en temas, aplicaciones, feeds, datos de catálogo, contenido y rutas de conversión, la solución puede requerir más que editar código. Los servicios de crecimiento de comercio electrónico de Nexscope pueden revisar páginas de tienda y producto, identificar carencias de SEO, GEO, contenido y conversión, recomendar cambios de esquema y página y crear un plan de implementación priorizado.

Conclusión: convierte los hallazgos de esquemas en un plan de crecimiento

Un esquema eficaz de comercio electrónico empieza con datos precisos de productos y políticas. Product y Offer merecen prioridad en páginas de productos que pueden comprarse. ProductGroup respalda las relaciones entre variantes. OnlineStore, Organization, MerchantReturnPolicy y ShippingService establecen la identidad y las políticas de la tienda. BreadcrumbList e ItemList aclaran la estructura de las páginas.

La implementación debe avanzar después por un ciclo controlado: auditar el resultado existente, asignar la responsabilidad de los datos, conectar entidades, desplegar páginas representativas, validar el código renderizado y supervisar los cambios. Un esquema válido crea elegibilidad y un contexto legible por máquinas más claro. No garantiza posiciones, resultados enriquecidos ni recomendaciones de IA.

El siguiente paso depende de la pregunta. Utiliza el comprobador de puntuación GEO para diagnosticar la preparación de las páginas, la herramienta de visibilidad de productos en IA para observar menciones y recomendaciones, y los servicios de crecimiento de comercio electrónico cuando los hallazgos requieran un plan coordinado de tienda, productos, contenido o implementación.

Preguntas frecuentes

¿Qué es el marcado de esquema comercial?

El marcado de esquema de comercio electrónico son datos estructurados que etiquetan la información de una tienda en formato legible por máquinas. Puede describir productos, ofertas, precios, inventario, reseñas, variantes, envíos, devoluciones, migas de pan e identidad empresarial. Schema.org proporciona el vocabulario, mientras que buscadores como Google definen qué tipos y propiedades son elegibles para funciones de búsqueda específicas. JSON-LD es el formato de implementación recomendado por Google.

¿Qué esquema es más importante?

Product con una Offer anidada suele ser el marcado de mayor prioridad para una tienda que vende mediante páginas de detalles de producto. Identifica el producto y sus condiciones comerciales activas, incluidos precio y moneda. Las siguientes prioridades dependen del catálogo: ProductGroup para variantes, AggregateRating para reseñas elegibles y visibles, y políticas de envío y devolución a nivel de organización para las condiciones de toda la tienda.

¿Mejora las posiciones en Google?

Google no describe los datos estructurados válidos como un aumento garantizado de posicionamiento. El esquema puede mejorar la comprensión de Google del contenido de la página y hacer que sea elegible para presentaciones compatibles de resultados enriquecidos o compras. Una presentación más completa puede afectar a cómo aparece el resultado y cómo interactúan los compradores con él. El posicionamiento sigue dependiendo de muchas señales técnicas, de relevancia, calidad y autoridad.

¿Ayuda a aparecer en recomendaciones IA?

El esquema puede ayudar a los sistemas automáticos a interpretar productos, ofertas y políticas cuando analizan marcado estructurado. No puede garantizar una mención, cita, posición o recomendación de IA. Esos resultados también pueden depender del acceso de rastreo, relevancia del producto, contenido, autoridad de marca, fuentes externas, señales de marketplaces, formulación de la consulta, comportamiento del modelo y actualidad. La visibilidad real debe medirse mediante preguntas repetidas de compradores y respuestas registradas de las plataformas.

¿Shopify y WooCommerce lo añaden automáticamente?

Muchos temas, funciones de plataformas y complementos generan automáticamente algunos datos estructurados de producto, pero su cobertura y calidad varían. El marcado automático puede omitir variantes, políticas, identificadores, detalles de envío o datos de reseñas. Varias aplicaciones también pueden generar duplicados. Los responsables de las tiendas deben inspeccionar el resultado renderizado en plantillas de página representativas y verificar que precios visibles, inventario, reseñas y políticas coincidan con el JSON-LD.

¿Cómo validarlo?

Utiliza Rich Results Test de Google para comprobar la elegibilidad para funciones de búsqueda compatibles y Schema Markup Validator para inspeccionar el grafo más amplio. Después utiliza Inspección de URLs en Google Search Console para confirmar que Google puede rastrear y renderizar la página activa. Prueba productos estándar, variantes, artículos rebajados, artículos agotados, colecciones y páginas de políticas. Continúa supervisando después de cambios de tema, aplicaciones, catálogo y políticas.

¿Cada variante necesita esquema separado?

Cada variante significativa debe tener datos específicos precisos, especialmente cuando difieran su SKU, URL, imagen, precio, disponibilidad, tamaño o color. ProductGroup puede conectar variantes bajo un padre compartido e identificar las propiedades que varían. La URL y el marcado deben reflejar la variante seleccionada. Las tiendas deben evitar publicar varias entidades de variante idénticas que los buscadores no puedan distinguir.

¿Cómo corregir duplicados de aplicaciones?

Identifica primero todos los sistemas que escriben JSON-LD, incluidos tema, aplicación SEO, aplicación de reseñas, aplicación de feeds y scripts personalizados. Elige un responsable para cada entidad y campo. Elimina o desactiva el resultado superpuesto cuando sea posible y conecta después los nodos restantes con valores @id estables. Valida las páginas renderizadas después del despliegue porque los ajustes de aplicaciones y las actualizaciones del tema pueden reintroducir marcado duplicado.

Fuentes

1. Google Search Central. (2025). Incluir datos estructurados relevantes para comercio electrónico. Recuperado de developers.google.com
2. Google Search Central. (2025). Introducción a datos estructurados de productos. Recuperado de developers.google.com
3. Google Search Central. (2025). Datos estructurados de fichas de comerciantes. Recuperado de developers.google.com
4. Google Search Central. (2025). Pautas generales de datos estructurados. Recuperado de developers.google.com
5. Schema.org. (2026). OnlineStore. Recuperado de schema.org