Auditoría de datos estructurados eCommerce (plantilla)

Si vendes online, el schema es uno de los pocos “idiomas” que Google entiende de forma determinista. Y en la era de los resultados con IA, esa claridad importa más: cuando tu web no explica bien qué es un producto, cuánto cuesta, si hay stock o cómo se envía, el buscador rellena huecos… y a veces lo hace mal.

Este artículo es una guía práctica (sin humo) para hacer una auditoría de datos estructurados en un eCommerce: qué marcado necesitas, cómo probarlo y cómo convertir hallazgos en un plan de implementación en 7 días. Si quieres que lo ejecutemos contigo (o automatizar el control en n8n), puedes ver cómo trabajamos en nuestro método o pedir ayuda desde el formulario de contacto.

1. Qué datos estructurados necesita un eCommerce (mínimos)

Para un eCommerce, el objetivo del marcado no es “poner schema por poner”, sino reducir ambigüedad y aumentar la probabilidad de elegibilidad para resultados enriquecidos. En junio de 2026, el set mínimo recomendado se puede resumir en tres capas: (1) entidad del negocio, (2) navegación (breadcrumbs) y (3) catálogo (producto y ofertas).

Capa 1: identidad del sitio. En la home y páginas corporativas, utiliza Organization (o LocalBusiness si aplica) y enlaza tus perfiles con sameAs. Añade WebSite (y opcionalmente SearchAction si tienes buscador interno). Esto ayuda a consolidar entidad y coherencia, especialmente cuando hay menciones en otras fuentes.

Capa 2: navegación. En cualquier página de categoría, producto y contenidos, incluye BreadcrumbList. Aunque parezca “menor”, es uno de los marcados que más a menudo se rompe con cambios de plantillas, filtros o facetas. Un breadcrumb correcto mejora comprensión de jerarquía y puede reflejarse en el snippet.

Capa 3: catálogo. En fichas de producto, lo mínimo de Product + Offer(s) bien definido. En un eCommerce real, casi nunca es un solo precio: hay variantes, diferencias por color/talla, packs, o precios por canal. Tu auditoría debe confirmar que el schema refleja el “producto vendible” de esa URL.

Campos que, en la práctica, suelen marcar la diferencia:

• name, image, description: coherentes con el contenido visible.
• sku, gtin (si existe), brand: reducen duplicidad y confusión en catálogo.
• offers: price, priceCurrency, availability, url, y si aplica priceValidUntil.
• shippingDetails y hasMerchantReturnPolicy: cada vez más relevantes para políticas (envíos/devoluciones) y coherencia de tienda.
• aggregateRating / review: solo si existen reseñas reales mostradas al usuario (si no, es un riesgo).

¿Y las categorías? No existe un rich result “universal” de categoría como el de producto, pero las categorías se benefician de un marcado limpio (BreadcrumbList, ItemList si listas productos, y coherencia entidad/colección). Si tu plantilla de categoría usa ItemList, audita que no “liste” 200 items (mejor listados paginados y representativos) y que no contradiga precios/stock de producto.

Si tu eCommerce tiene guía de tallas, FAQs de producto o comparativas, puedes sumar FAQPage o HowTo donde aplique, pero no lo consideraría “mínimo” del catálogo. Primero asegura Product/Offer y breadcrumbs impecables.

2. Cómo auditar tu schema paso a paso (sin humo)

Una auditoría efectiva combina validación técnica + verificación semántica + control de consistencia entre páginas, plantillas y feeds. En otras palabras: no basta con que “pase” un test; tiene que ser correcto, consistente y útil.

Paso 1: define el muestreo (no audites al azar). Selecciona URLs que representen casos reales del catálogo:

• Productos con descuento, sin descuento, y con variaciones.
• Productos en stock y agotados.
• Productos con reseñas y sin reseñas.
• Categorías con filtros/facetas y categorías “limpias”.
• 2–3 breadcrumbs de niveles distintos (home > categoría > subcategoría > producto).

Paso 2: comprueba el renderizado real. Muchos eCommerce inyectan JSON-LD con JS, y el HTML inicial no lo contiene. La auditoría debe confirmar que:

• El JSON-LD está presente en el DOM renderizado.
• No hay duplicidad (por ejemplo, dos Product distintos en la misma URL).
• No se generan valores “placeholder” (precio 0, moneda vacía, disponibilidad genérica).

Paso 3: valida elegibilidad de rich results. Verifica si el marcado cumple requisitos para resultados enriquecidos de producto (campos esenciales en offers, formato de availability, moneda, etc.). Ojo: “elegible” no significa “se mostrará”; significa “no te estás auto-saboteando”.

Paso 4: revisa consistencia con el contenido visible. Esto es crítico para evitar inconsistencias que pueden desactivar señales:

• El precio en schema coincide con el precio visible (incluye impuestos si el usuario los ve).
• La moneda coincide con el mercado.
• El stock coincide con el botón de compra (si no se puede comprar, no debería figurar como InStock).
• Las reseñas marcadas existen en la página (y son del mismo producto).

Paso 5: audita duplicidades y canónicos. Problema típico: filtros/facetas crean URLs indexables con el mismo Product/Offer o con variaciones inconsistentes. Revisa:

• Si varias URLs publican el mismo sku y el mismo offers.url, hay conflicto.
• Si el canonical apunta a otra URL, el schema debería alinearse con la canónica.

Paso 6: controla errores comunes de implementación (los verás en la plantilla): comas mal puestas en JSON, arrays donde debería haber string, campos vacíos, imágenes no accesibles, y valores no normalizados (por ejemplo availability en español en vez del valor de schema.org).

Paso 7: documenta y prioriza. Una auditoría sin backlog no sirve. Clasifica cada hallazgo por:

• Impacto (alto/medio/bajo): ¿afecta a Product/Offer? ¿impide rich results?
• Riesgo (alto/medio/bajo): ¿puede causar inconsistencias o problemas de calidad?
• Esfuerzo: ¿es cambio de plantilla, de datos, o de CMS?

Si además quieres convertir esto en un control continuo (y no una auditoría anual), puedes montarlo como proceso recurrente con automatización. En nuestros servicios combinamos auditoría + implementación + monitorización para que el schema no se rompa en el próximo cambio de theme o app.

3. Plantilla de auditoría: campos, pruebas y prioridades

Abajo tienes una plantilla práctica para copiar a tu hoja de cálculo o a tu sistema de tickets. La idea es que cada URL tenga un “score” claro y, sobre todo, un listado de fixes accionables.

Plantilla (por URL)

• Tipo de URL: producto / categoría / home / corporativa
• Plantilla: PDP (product detail page), PLP (category/listing), etc.
• Indexable: sí/no (robots, noindex, canonical)
• Schema detectado: Product, Offer, BreadcrumbList, Organization, WebSite, ItemList…
• Render: server-side / client-side / mixto

Checklist de producto (Product + Offer)

• Product.name: existe y coincide con H1
• Product.image: URL(s) accesibles, sin 403, con tamaño adecuado
• Product.description: no vacía, no “plantilla genérica”
• brand: presente (si la marca existe en catálogo)
• sku y/o gtin: presentes cuando estén disponibles
• offers.price y priceCurrency: correctos
• offers.availability: valor válido y consistente con la UX
• offers.url: apunta a la URL canónica del producto
• offers.priceValidUntil: si hay promos con fin definido (si no, omitir)
• shippingDetails y returnPolicy: presentes si tu tienda los define claramente

Checklist de breadcrumbs

• BreadcrumbList existe en PLP y PDP
• Orden correcto (position incremental)
• URLs de cada item devuelven 200 y no redirigen
• El último breadcrumb coincide con el contexto (producto o categoría real)

Checklist de categoría (PLP)

• BreadcrumbList correcto
• Si hay ItemList: items representativos y paginación coherente
• Evitar que facetas indexables generen listas infinitas con marcado contradictorio
• Consistencia: títulos, H1, contenido y enlaces internos

Pruebas de calidad (prioridades)

• P0 (bloqueantes): JSON inválido, Product sin Offer, priceCurrency ausente, availability incorrecta, offers.url no canónica, duplicidad de Product contradictorios.
• P1 (alto impacto): falta brand/sku/gtin (si existen), imágenes no accesibles, breadcrumbs rotos, políticas de envío/devolución ausentes cuando son claves en la compra.
• P2 (mejora): campos opcionales, enriquecimiento semántico, ItemList optimizado, limpieza de valores, normalización de descripciones.

Errores comunes que vemos en auditorías (y por qué importan):

• Marcar reseñas que no se muestran: genera señales de baja calidad y puede invalidar enriquecimientos.
• Precio en schema distinto al visible: suele ocurrir por impuestos, moneda, o apps de descuento. Es un “red flag”.
• Stock incorrecto: InStock cuando el CTA está deshabilitado o hay preventa sin indicarlo.
• Variantes mal modeladas: una URL con 20 variaciones pero un solo Offer fijo (o peor, precio mínimo sin contexto).
• Duplicar Organization/Website en cada URL con datos diferentes: inconsistencias de entidad.

Si estás rediseñando tu tienda o cambiando plantilla, este es el momento ideal para integrar el schema “bien” de base. En SEOAGIL Webs lo trabajamos junto a rendimiento y tracking para evitar que el SEO técnico se convierta en un parche posterior.

4. Conclusión: plan de fixes en 7 días para rich results

Una auditoría útil termina en un plan de implementación realista. Aquí tienes un enfoque de 7 días pensado para equipos pequeños (marketing + dev) o para una tienda en Shopify/Woo/Prestashop con recursos limitados. Ajusta según tu volumen de URLs y tu stack.

Día 1 — Inventario y muestreo: elige las URLs representativas, identifica plantillas (PDP/PLP) y documenta qué genera el schema (tema, módulo, app, plugin). Objetivo: saber dónde tocar sin “romper” todo.

Día 2 — Fix P0 en producto: asegura Product + Offer correctos, JSON válido, priceCurrency, availability y offers.url canónica. Si tu sistema genera dos schemas distintos (app + theme), elimina duplicidades.

Día 3 — Consistencia de precio/stock: alinea la lógica del precio (impuestos, descuentos, moneda) y el stock (incluye reglas de backorder/preventa). Si hay diferencias por variación, define una estrategia: URL por variante o modelado consistente en una sola PDP.

Día 4 — BreadcrumbList en todas las plantillas: arregla jerarquía, posiciones, URLs y nombres. Además, revisa que facetas no generen breadcrumbs “falsos” o rutas imposibles.

Día 5 — Envío y devoluciones (si aplica): incorpora shippingDetails y políticas de devolución si están claramente definidas en la web. No inventes datos: si no está publicado, primero publícalo en contenido visible y luego márcalo.

Día 6 — QA y regresión: re-audita el muestreo inicial y añade 10 URLs nuevas (para evitar que el fix solo funcione en un caso). Verifica especialmente productos agotados, en oferta y con variaciones.

Día 7 — Monitorización: crea una rutina: revisión mensual de una muestra + alerta cuando cambien plantillas/apps. Si quieres escalar, automatiza el check (por ejemplo, extrayendo JSON-LD y comparándolo con reglas) y alimenta un backlog de tickets. Para eso, puedes apoyarte en SEOAGIL como partner de implementación y automatización.

El resultado que buscas no es solo “pasar tests”, sino construir un catálogo semántico estable: cuando tu eCommerce crece, cambia precios, añade variantes o migra de theme, el schema no debería degradarse. Si lo tratas como un componente del producto (igual que el checkout o el feed de anuncios), te devuelve visibilidad y reduce fricción en SEO técnico.

Preguntas frecuentes

¿Tener datos estructurados garantiza rich results de productos?

No. El schema correcto te hace elegible, pero la aparición depende de múltiples factores (calidad del sitio, coherencia, intención de búsqueda, competencia y decisiones del propio buscador). Aun así, sin un Product/Offer consistente, normalmente te auto-excluyes.

¿Puedo marcar Product en páginas de categoría?

En general, no deberías “fingir” que una categoría es un producto. En categorías, usa BreadcrumbList y, si aplica, ItemList para listar elementos. El marcado de Product debería representar la entidad principal de la URL (la ficha de ese producto).

¿Qué pasa si mi precio cambia varias veces al día?

Entonces el schema debe generarse desde la misma fuente que el precio visible (o al menos sincronizarse). Audita que no haya cachés que sirvan un JSON-LD desactualizado mientras el frontend muestra otro precio.

¿Es mejor JSON-LD o microdatos?

En la mayoría de eCommerce, JSON-LD es más mantenible y menos propenso a romperse con cambios de HTML/CRO. La auditoría debe revisar que el JSON-LD esté presente y correcto en el renderizado final.

¿Cómo evito duplicar schema si tengo apps/plugins que lo añaden?

Identifica qué fuente genera cada bloque (tema, app, plugin) y decide una única “fuente de verdad”. Duplicar Product con valores distintos (precio/stock/URL) es una de las causas más comunes de problemas en auditorías.