El schema Product completo es el bloque JSON-LD que le dice a buscadores y agentes de IA qué vendes, a qué precio, con qué stock y bajo qué condiciones de envío y devolución. Sus campos críticos: name, sku, gtin, brand, offers con precio y moneda, shippingDetails y hasMerchantReturnPolicy. Aquí tienes el código completo comentado campo por campo, listo para adaptar a tu tienda WooCommerce y validar en la prueba de resultados enriquecidos.
Tabla de Contenidos
¿Por qué los agentes leen el schema antes que tu página?
Porque es la parte de tu ficha que no admite ambigüedad: un humano interpreta que aprox S/ 390 según color es un precio; una máquina necesita price: 389.00 y priceCurrency: PEN. El JSON-LD es el contrato de datos entre tu tienda y cualquier sistema que la lea, del buscador clásico al agente de compra del que hablamos en la guía de qué es el comercio agéntico.
En las tiendas virtuales que construimos, este markup se genera automático desde los datos del producto; aun así, saber leerlo te permite auditar a cualquier proveedor y entender qué declara tu web en tu nombre.
El código completo, listo para adaptar
Va dentro de una etiqueta script de tipo application/ld+json en la ficha del producto. Dominio y valores son de ejemplo:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Taladro percutor inalámbrico 20V TX-200",
"image": ["https://tienda.example/uploads/taladro-tx200.webp"],
"description": "Taladro percutor inalámbrico de 20V con dos baterías y maletín. Perfora concreto, metal y madera; pensado para uso intensivo en obra.",
"sku": "TAL-2001",
"gtin13": "7750001234567",
"brand": { "@type": "Brand", "name": "MarcaEjemplo" },
"offers": {
"@type": "Offer",
"url": "https://tienda.example/producto/taladro-tx200/",
"priceCurrency": "PEN",
"price": "389.00",
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingRate": { "@type": "MonetaryAmount", "value": "15.00", "currency": "PEN" },
"shippingDestination": { "@type": "DefinedRegion", "addressCountry": "PE" },
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
"transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 3, "unitCode": "DAY" }
}
},
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"applicableCountry": "PE",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 7,
"returnMethod": "https://schema.org/ReturnByMail",
"returnFees": "https://schema.org/FreeReturn"
}
}
}Campo por campo: qué declara y qué error evitar
name, image y description
El nombre comercial con su atributo decisivo (no el código interno), la foto principal en una URL accesible al rastreo y la descripción única del producto. Error típico: heredar aquí la descripción del proveedor que ya vive en veinte webs; la máquina detecta el duplicado igual que Google.
sku, gtin13 y brand
La tríada de identidad. El sku es tu código interno (idéntico al visible en la ficha); el gtin13 es el código de barras global del producto, solo si existe de verdad; brand va como objeto, no como texto suelto. Error típico: inventar un GTIN para llenar el campo. Si el producto no tiene, se omite y listo.
offers: price, priceValidUntil y availability
El corazón transaccional: precio con decimales y moneda PEN, vigencia si es promocional y disponibilidad real (InStock, OutOfStock, PreOrder). Error típico: availability eternamente en InStock sin conexión con el inventario; cuando un agente recomienda tu producto agotado, el reclamo te llega a ti, no a él.
shippingDetails
Cuánto cuesta y cuánto demora llegar: tarifa, destino (PE, afinable por región) y tiempos separados en preparación y tránsito. Es de los campos que más diferencian a una tienda recomendable, porque responde la segunda pregunta de todo comprador: ¿cuándo me llega? Error típico: omitirlo por pereza y dejar que el agente asuma lo peor.
hasMerchantReturnPolicy
La política de devoluciones en datos: cuántos días, por qué método y quién paga. Declara lo que tu política escrita realmente dice (7, 15 o los días que ofrezcas), no lo que suena bien. Error típico: declarar FreeReturn mientras la página dice que el cliente asume el envío de retorno; la contradicción anula la confianza que el campo debía construir.
Paso a paso: implementarlo en WooCommerce
Paso 1: Genera la base automática
Activa el schema de producto en Rank Math (o tu plugin de SEO) sobre WooCommerce: name, image, description, sku, price y availability salen solos de los datos del producto. Resultado verificable: la prueba de resultados enriquecidos ya detecta un Product en tu ficha.
Paso 2: Completa los identificadores
Carga marca y GTIN en cada producto (Rank Math y varios plugins agregan el campo; WooCommerce reciente lo trae nativo). Verifica que el sku del markup sea el mismo de la página. Resultado verificable: sku, brand y gtin aparecen en el código fuente de la ficha.
Paso 3: Revisa el bloque offers
Confirma price con priceCurrency en PEN, availability sincronizada con el stock y priceValidUntil si el precio es promocional. Resultado verificable: el validador muestra la oferta completa sin advertencias de campos faltantes.
Paso 4: Declara los envíos
Agrega shippingDetails con destino PE, costo y plazos de manejo y tránsito. Si tu plugin no lo genera, decláralo en la política de envíos enlazada y considera un complemento de schema. Resultado verificable: la advertencia de shippingDetails desaparece del validador.
Paso 5: Declara las devoluciones
Completa hasMerchantReturnPolicy: días de ventana, método y quién paga el retorno, en línea con tu política publicada. Resultado verificable: la advertencia de hasMerchantReturnPolicy desaparece y tu política escrita coincide con lo declarado.
Paso 6: Valida y corrige en ciclo
Pasa tus 10 productos estrella por la prueba de resultados enriquecidos, corrige errores primero y advertencias después, y repite tras cualquier cambio de tema o plugin. Resultado verificable: cero errores en tus fichas principales y las advertencias restantes son decisiones conscientes.
¿Plugin o código a mano?
Plugin, en el 95% de los casos: Rank Math sobre WooCommerce genera el markup desde los datos reales del producto, lo que garantiza la coherencia página-schema y sobrevive a los cambios de tema. El código a mano queda para casos de borde: campos que tu plugin no soporta (shippingDetails fino, políticas por categoría) o catálogos con lógica de precios fuera de WooCommerce.
Si terminas mezclando (plugin más fragmentos manuales), cuida no declarar el mismo Product dos veces: dos bloques en competencia confunden a los validadores y a los agentes por igual. Un solo bloque, una sola fuente de verdad.
Preguntas frecuentes
¿Dónde se coloca el JSON-LD dentro de la ficha de producto?
Dentro de una etiqueta script de tipo application/ld+json, en el head o en el body de la página: a los rastreadores les da igual la posición mientras el bloque sea válido. En la práctica no lo pegas a mano en cada ficha: Rank Math o tu plugin de SEO lo genera automáticamente desde los datos del producto, y tú verificas el resultado con la herramienta de validación.
¿Qué hago si mis productos no tienen GTIN?
No lo inventes jamás: un GTIN falso o reciclado de otro producto es peor que ninguno, porque contradice las bases de datos globales. Si tu producto no tiene código de barras (productos artesanales, a medida, genéricos), declara sku y brand, que son suficientes para identificarlo. El GTIN es obligatorio solo cuando el producto realmente lo tiene.
¿El schema debe coincidir exactamente con lo que muestra la página?
Sí, sin excepciones: precio, disponibilidad, marca y condiciones del markup deben ser los mismos que ve el humano en pantalla. La contradicción (precio viejo en el JSON-LD, stock falso) es la forma más rápida de perder la confianza algorítmica, y los validadores la detectan. Si automatizas con un plugin desde los datos reales del producto, la coherencia viene sola.
¿Puedo declarar costos de envío distintos para Lima y provincias?
Sí: el bloque shippingDetails acepta varias definiciones con regiones distintas (DefinedRegion permite afinar por departamento). Si tu matriz de envíos es compleja, empieza declarando la cobertura general del país con el rango de plazos más representativo y refina después: un dato simplificado pero cierto vale más que una matriz perfecta que nunca publicas.
Toma tu producto más vendido, pasa su URL por la prueba de resultados enriquecidos de Google y compara lo que detecta contra el código de esta guía: cada campo faltante es una tarea concreta. ¿Prefieres que dejemos el markup completo y validado en toda tu tienda? Pide tu propuesta en el cotizador online.
