Datos estructurados y resultados enriquecidos de productos en PrestaShop
Audita el marcado de PrestaShop, corrige ofertas y variantes de producto, valida los requisitos de resultados enriquecidos y supervisa Search Console.
Usa datos estructurados para describir los productos y la información del negocio que los clientes pueden ver en tu tienda. Audita la salida actual antes de añadir otro proveedor y valida después las páginas públicas finales.
Qué haríamos
Conservaríamos la salida nativa precisa y corregiríamos una carencia demostrada antes de añadir otro generador. El enfoque depende de tu tema actual, los módulos SEO y de reseñas, los datos del catálogo, las integraciones de precios y existencias, los mercados y el equipo que los mantiene. Registra quién se encarga de cada entidad y qué sistema proporciona sus valores.
Ensaya una sustitución en una copia de pruebas con los mismos módulos pertinentes y configuración, aislada de los correos e integraciones de producción. Mantén las restricciones de acceso e indexación de la copia y prueba el HTML capturado mediante la entrada de código de la Prueba de resultados enriquecidos y de Schema Markup Validator, ya que sus pruebas por URL pueden no acceder a una copia protegida. Guarda la configuración anterior, demuestra que la sustitución resiste la limpieza y el almacenamiento en caché y después realiza el cambio en un periodo planificado con un procedimiento de reversión. Vuelve a comprobar las URL públicas tras el cambio.
Si no está claro el origen del marcado conflictivo, PrestaShop SEO Audit & Action Plan puede identificar la causa y priorizar las correcciones para tu desarrollador.
Audita el tema activo antes de añadir marcado
Schema.org proporciona un vocabulario para productos, ofertas, organizaciones y otras entidades. Google admite determinados tipos de datos estructurados para funciones de búsqueda concretas. La validez sintáctica de schema y la elegibilidad para una función de Google son comprobaciones independientes. Google recomienda JSON-LD cuando resulta práctico, aunque los microdatos admitidos siguen siendo válidos; cambiar solo el formato no corrige valores inexactos ni campos obligatorios ausentes.
Las versiones del tema Classic pueden generar JSON-LD para Product, Offer, Organization, WebSite o WebPage, rutas de navegación y listas de productos. La salida de Product puede incluir marca, identificadores, disponibilidad y valoraciones según las condiciones. Las plantillas antiguas y los temas personalizados pueden variar. No supongas que PrestaShop solo proporciona unos pocos microdatos.
- Abre una página pública de producto y revisa su HTML en busca de JSON-LD y microdatos.
- Pasa la URL por la Prueba de resultados enriquecidos.
- Repite con un producto con combinaciones, un artículo no disponible, una categoría, la página de inicio y una página CMS.
- Identifica qué tema o módulo controla cada entidad y qué valores emite.
- Comprueba la respuesta final una vez ejecutadas las cachés y los módulos de limpieza de salida.
Varios bloques no son automáticamente un error. Se convierten en un problema cuando describen la misma entidad de forma incoherente. Mantén coherentes los identificadores y las relaciones y evita precios o valores de disponibilidad contradictorios.
Distingue las funciones de búsqueda y sus requisitos
Los datos de producto pueden llegar a Google mediante datos estructurados en la página, feeds de Merchant Center o ambos. El marcado en la página no es la única vía para todas las experiencias enriquecidas de producto. Consulta la visión general de los datos de producto de Google.
| Función | Requisito básico | Comprobación práctica |
|---|---|---|
| Fragmento de producto | Un nombre de Product y al menos una de las propiedades review, aggregateRating u offers, con los campos obligatorios de esa propiedad | Valida el caso de uso de fragmentos en vez de aplicar todas las reglas de fichas de comerciante |
| Ficha de comerciante | Un Product que se pueda comprar, con nombre, imagen y una Offer, incluidos los campos obligatorios de precio vigente y moneda | Haz que coincida con la oferta que el cliente puede comprar en la página |
| Mejora de reseñas | Datos aplicables y auténticos de reseñas o valoración agregada | Comprueba el contenido visible de reseñas y sus directrices |
| Apariencia de la ruta de navegación | Una BreadcrumbList compatible que describa la jerarquía de la página | Google puede mostrar rutas de navegación en escritorio; los resultados móviles usan el dominio |
Usa los requisitos actuales de fragmentos de producto y fichas de comerciante para cada caso. Los errores de campos obligatorios pueden impedir la elegibilidad. Los avisos de campos recomendados indican posibles mejoras; no todos invalidan una ficha.
Google dejó de mostrar resultados enriquecidos de preguntas frecuentes en mayo de 2026. Conserva las preguntas útiles en tu página para los clientes, pero no planifiques un resultado desplegable de preguntas frecuentes en Google ni su monitorización como resultado enriquecido. Consulta las actualizaciones de la documentación de la Búsqueda.
Los datos Organization pueden describir tu negocio y sus políticas. WebSite, CollectionPage y Article pueden describir otros tipos de página cuando corresponda. Ninguno garantiza un panel de conocimiento ni una presentación especial en búsquedas.
Mantén correctos los precios, la disponibilidad y los identificadores
Genera las ofertas a partir del contexto de producto y de cliente usado para la página. Comprueba descuentos, visualización de impuestos, moneda, condición y combinación seleccionada. El importe del marcado debe coincidir con la oferta visible.
Usa identificadores reales de producto. Un SKU de la tienda no es automáticamente un número de pieza del fabricante ni un GTIN. Proporciona la marca de los datos reales de marca de tu catálogo y evita inventar valores ausentes para eliminar un aviso.
Stock cero no significa siempre OutOfStock. Si el artículo seleccionado se puede pedir para entrega posterior, su política de pedidos puede requerir BackOrder. Asigna la disponibilidad según la cantidad y la política real de pedidos.
Incluye priceValidUntil solo cuando la oferta tenga una caducidad real. No insertes el fin de año o una fecha futura móvil solo para rellenar el campo. Revisa la salida generada incluso si un tema o módulo proporciona ese valor automáticamente.
Para los detalles de la oferta, usa shippingDetails con OfferShippingDetails y hasMerchantReturnPolicy con MerchantReturnPolicy, y proporciona tus países, costes, plazos de entrega, métodos y políticas reales. No copies ejemplos de devoluciones gratuitas o precios de envío fijos en el marcado de producción. Completa las propiedades anidadas obligatorias cuando añadas esas mejoras.
Para la generación personalizada, construye una estructura de datos en el servidor y serialízala con un codificador JSON adecuado y opciones seguras de inserción en scripts. Escapar cadenas JavaScript no sustituye a la serialización JSON.
Describe las combinaciones con identidades de variante estables
Las distintas combinaciones pueden tener precios, imágenes, identificadores y existencias diferentes. Pruébalas individualmente. La oferta de la combinación predeterminada no puede representar sin más todos los tamaños o colores disponibles.
El modelo de variantes de Google usa ProductGroup con productGroupID, variesBy y hasVariant. Cada Product de variante necesita una identidad distinta y datos de oferta adecuados.
Proporciona una URL que preseleccione la variante y muestre su imagen, precio y disponibilidad. Confirma que el cliente puede añadir esa variante seleccionada al carrito. Elige una gestión de URL canónicas adecuada según las variantes compartan una página o usen páginas separadas.
Automatic SEO Schema Rich Snippets puede usar ProductGroup y Products de variantes cuando existen URL distintas y adecuadas para las variantes. En caso contrario, puede publicar la Offer de la combinación mostrada. Los pasos de configuración e integración se encuentran en la ayuda del módulo de schema.
Una combinación antes y después de la corrección
Piensa en una camiseta cuya talla pequeña está disponible, mientras que la talla grande, más cara, se puede pedir con entrega posterior. Antes de la corrección, abrir la URL de la talla grande muestra la selección correcta a los compradores, pero sus datos estructurados siguen describiendo la talla pequeña más barata como InStock.
Después de la corrección, abrir de nuevo esa URL directamente selecciona la talla grande, muestra su precio y condiciones de pedido actuales y describe esa misma variante y oferta. Comprueba su identidad, imagen, identificador y disponibilidad; después añádela al carrito para confirmar que se conserva la selección. Si la URL no puede preseleccionar la combinación de forma fiable, resuelve esa limitación antes de publicar un grupo de variantes.
Publica reseñas y valoraciones auténticas
Marca las valoraciones y reseñas que pertenecen al producto y están disponibles para los visitantes. Mantén el agregado, el recuento y la escala coherentes con el sistema de reseñas. No inventes reseñas ni uses una muestra seleccionada como valoración global.
No hay una regla general que te obligue a esperar a un pequeño número concreto de reseñas. Los datos deben ser auténticos y cumplir los requisitos aplicables de reseñas. Proporcionarlos sigue sin garantizar estrellas en las búsquedas.
Los datos importantes de producto son más fiables si están presentes en el HTML inicial. Las reseñas renderizadas por JavaScript no son automáticamente invisibles para Google. Usa la salida renderizada de Inspección de URLs o la Prueba de resultados enriquecidos para comprobar qué está disponible en vez de decidirlo solo desde Ver código fuente.
Si el módulo de reseñas y el proveedor de marcado son distintos, confirma la integración. Una Offer puede ser válida sin proporcionar valoraciones. Corrige la conexión de datos en vez de fijar una valoración en el código.
Elige y mantén una implementación coherente
Puedes conservar la salida nativa, personalizar plantillas o usar un módulo. Basa la elección en el comportamiento que falta y en quién lo mantendrá. Un tema hijo no se sobrescribe necesariamente con cada actualización y un módulo conectado a un hook no es automáticamente compatible con todas las versiones futuras.
| Tu auditoría detecta | Opción inicial | Pruebas que pedir |
|---|---|---|
| La salida nativa es precisa y cubre la función objetivo | Conservarla | Las páginas representativas superan las pruebas pertinentes |
| Una integración personalizada de precios o reseñas proporciona valores incorrectos | Corregir la conexión de datos | El generador lee la misma fuente que la página visible |
| Falta cobertura y el personal necesita controles en el back office | Evaluar un módulo de schema para esa carencia | Compatibilidad con tu tema, reseñas y limpieza de salida |
| Un catálogo o una regla de precios poco habituales requieren generación personalizada | Usar una plantilla o integración de módulo con mantenimiento | Un responsable concreto, pruebas repetibles y un plan de actualización |
Usa un entorno de pruebas para comprobar las interacciones entre el tema y los módulos de reseñas y SEO. Si sustituyes el marcado existente, confirma que la limpieza conserva la nueva salida prevista y no elimina entidades útiles ajenas al cambio.
El módulo de marcado identifica su JSON-LD generado con data-mprschema="1", y su limpiador conserva ese atributo de propiedad. Valida la página final tras la limpieza y confirma que el JSON-LD previsto sigue presente.
Completa primero los datos subyacentes del catálogo. Un generador automático no puede aportar un identificador auténtico o una reseña si esos datos faltan. Mantén separadas la validación de vista previa y la validación de páginas públicas.
En pruebas, cambia el precio y la disponibilidad para pedidos de un producto de prueba mediante el flujo habitual del catálogo o la integración. Compara respuestas nuevas y en caché. Si la página visible se actualiza pero su schema solo cambia tras una purga manual, revisa la invalidación de caché antes del lanzamiento. Repite con los idiomas, monedas y tiendas que realmente publicas.
Valida la salida y mide el comportamiento en búsquedas
La Prueba de resultados enriquecidos comprueba las funciones admitidas de Google. El Schema Markup Validator comprueba de forma más amplia el vocabulario y la estructura del marcado. Revisa por separado los errores y los avisos opcionales y confirma que los valores indicados coinciden con la página visible.
Corrige la causa por orden de prioridad
- Corrige primero el JSON roto y las contradicciones con la oferta visible, aunque un validador acepte la sintaxis.
- Resuelve los errores de campos obligatorios de la función de búsqueda prevista. Agrupa las URL afectadas por plantilla o fuente de datos para corregir la causa compartida.
- Evalúa las advertencias opcionales según los datos reales del catálogo y las políticas. Deja ausente un identificador desconocido en lugar de inventarlo.
- Vuelve a probar los tipos de página afectados tras actualizar la caché, conserva la salida anterior y posterior y usa el flujo de validación de Search Console cuando esté disponible.
En Search Console, usa los informes de fragmentos de producto y fichas de comerciante de la sección Compras cuando estén disponibles. Usa los informes de mejoras pertinentes, como rutas de navegación, para otros tipos compatibles. Inspecciona una URL modificada y solicita su indexación cuando proceda; el nuevo rastreo no tiene un plazo fijo de finalización.
El marcado válido permite que una página elegible pueda considerarse. Google aún puede elegir un resultado simple según la consulta, la página y la presentación. Que desaparezcan las estrellas no demuestra automáticamente un nuevo error de validación.
Antes de cambiar el marcado, exporta de Search Console una referencia inicial de impresiones, clics, CTR y posición de las URL afectadas y registra la fecha de despliegue; repite la exportación cuando Google haya vuelto a rastrear las páginas modificadas. Usa los filtros disponibles de Apariencia en el buscador y compara consultas, dispositivos, países y páginas similares durante periodos comparables. Un CTR superior en otras páginas con resultados enriquecidos no demuestra que el marcado haya causado la diferencia.
Repite las pruebas de páginas representativas tras cambiar temas, precios, gestión de stock, reseñas, generación de URL o módulos de marcado. Consulta la guía de feeds para comerciantes para el flujo independiente de feeds de productos.
Preguntas de los responsables de tiendas
¿Puede nuestro equipo hacerlo sin editar plantillas?
Sí, cuando el tema existente o un módulo compatible ofrece los ajustes necesarios. Asigna al personal la responsabilidad sobre los datos del catálogo y las políticas, y acuerda cuándo debe intervenir un desarrollador en una integración personalizada. Pide una entrega de la configuración que puedan repetir.
¿Deberíamos poner una sola oferta Product en una categoría?
Una categoría enumera distintos productos. Describe correctamente la colección y sus artículos; no presentes toda la lista como un solo producto comprable para intentar obtener un resultado de producto.
¿Resolverá schema nuestros problemas SEO generales?
No lo compres como una mejora de posicionamiento. El contenido útil de producto, el acceso de rastreo y los títulos de página adecuados siguen necesitando su propio trabajo. Evalúa una presentación más completa junto con esas bases.
¿Qué preguntar al desarrollador o agencia antes de aprobar?
Pregunta qué generadores han cambiado, qué entidades se mantienen y dónde están registrados las URL probadas y los resultados anteriores y posteriores. Solicita los pasos de reversión, el responsable tras las actualizaciones y pruebas de que un cambio normal de precio o existencias llega al marcado final.