Desde la reforma del Real Decreto-ley 24/2021, cada rebaja que anuncia una tienda online en España tiene que ir acompañada del precio anterior, y ese precio anterior es el más bajo aplicado en los 30 días previos. Lo dice el art. 20.1 de la Ley 7/1996 de Ordenación del Comercio Minorista, que transpone el art. 6a de la Directiva 98/6/CE en la redacción que le dio la Directiva Omnibus. WooCommerce no guarda historial de precios, así que esa cifra la tiene que calcular un plugin o código propio. Aquí verás qué dice exactamente la norma, cómo debe funcionar el historial de precios en WooCommerce, en qué trampas cae la implementación típica y cómo comprobar en una hora si tu tienda muestra la cifra correcta.
Este artículo describe el contenido de las normas y el funcionamiento del software a la fecha de publicación. No es asesoramiento jurídico individual para tu tienda.
Qué exige la Directiva Omnibus en las rebajas de precio
La Directiva (UE) 2019/2161, conocida como Directiva Omnibus (EUR-Lex), añadió a la Directiva 98/6/CE sobre indicación de precios un nuevo art. 6a (EUR-Lex, texto consolidado). El artículo tiene cinco apartados:
- Todo anuncio de una reducción de precio indica el precio anterior que el comerciante aplicó durante un periodo determinado antes de la reducción.
- El precio anterior es el precio más bajo aplicado por el comerciante durante un periodo no inferior a 30 días antes de aplicar la reducción.
- Los Estados miembros pueden fijar reglas distintas para los productos que se deterioran o caducan rápidamente.
- Si el producto lleva menos de 30 días en el mercado, los Estados pueden prever un periodo más corto.
- Los Estados pueden disponer que, cuando la reducción aumenta de forma progresiva, el precio anterior sea el precio sin reducción previo a la primera aplicación de la rebaja.
España incorporó este artículo modificando el art. 20 de la Ley 7/1996, de 15 de enero, de Ordenación del Comercio Minorista. El cambio lo hizo el art. 85 del Real Decreto-ley 24/2021, de 2 de noviembre. El núcleo de la obligación está en el apartado 1:
Siempre que se oferten artículos con reducción de precio, deberá figurar con claridad, en cada uno de ellos, el precio anterior junto con el precio reducido, salvo en el supuesto de que se trate de artículos puestos a la venta por primera vez. Se entenderá por precio anterior el menor que hubiese sido aplicado sobre productos idénticos en los treinta días precedentes. A estos efectos no se tendrá en consideración el precio que hubiese podido ser aplicado, con la finalidad de reducir el desperdicio alimentario, sobre productos idénticos cuyas fechas de caducidad o consumo preferente estuviesen próximas a vencer.
Fuente: art. 20.1 de la Ley 7/1996 de Ordenación del Comercio Minorista, texto consolidado (BOE).
De ese párrafo salen cuatro requisitos técnicos para la tienda. El precio anterior tiene que figurar con claridad, en cada artículo, junto con el precio reducido, así que no basta con esconderlo en la pestaña de descripción. La ventana se cuenta hacia atrás desde la rebaja: son los treinta días precedentes a la reducción, y la directiva lo ancla expresamente a la aplicación de la rebaja. Se trata del precio que hubiese sido aplicado, es decir, el precio al que el cliente pudo comprar de verdad; un precio programado en el panel para el mes que viene todavía no se ha aplicado. Y la comparación es sobre productos idénticos, y en WooCommerce lo razonable es tratar cada variación de un producto variable como un producto distinto a efectos del historial.
El apartado 2 del mismo artículo añade una regla que afecta a cómo planificas campañas: el uso de actividades de promoción de ventas no puede condicionarse a una reducción porcentual mínima o máxima. La norma regula qué precio de referencia muestras, no cuánto tienes que rebajar.
La directiva habla de “cualquier anuncio” de una reducción de precio. Por eso conviene tratar del mismo modo el banner de la página de inicio con un precio rebajado o la newsletter con el precio de oferta: cualquier sitio donde ofertas un artículo con reducción necesita el precio anterior a la vista. Para una tienda online, la lectura más práctica es esta: allí donde aparece el precio tachado junto al precio de oferta, aparece también el precio más bajo de 30 días.
Cuándo los 30 días se cuentan de otra forma
El caso típico es el que acabas de leer. Hay tres situaciones que cambian el cálculo o que obligan a la tienda a tomar una decisión.
Producto puesto a la venta por primera vez
La directiva permite a los Estados fijar un periodo más corto para productos que llevan menos de 30 días en el mercado. España eligió otra vía: el art. 20.1 exceptúa de la obligación de indicar el precio anterior a los artículos puestos a la venta por primera vez. Para el historial de precios esto significa que la tienda tiene que distinguir un lanzamiento de un producto que ya estaba en el catálogo. Sin una fecha de primera publicación o un primer registro de precio fiable, no hay forma de saber en qué caso estás.
Aquí aparece una trampa para las tiendas que acaban de instalar el plugin. Un producto que vendes desde hace dos años tiene, en el plugin nuevo, un historial que empieza hoy. El plugin no sabe que el producto es antiguo y no tiene ningún registro anterior a la instalación, así que podría tratarlo como si fuera nuevo. Por eso un plugin sensato tiene un ajuste para el caso “sin historial”, y tú tienes que decidir de forma consciente qué muestra la tienda durante los primeros 30 días después de instalarlo. Lo más prudente es no lanzar rebajas nuevas hasta que el historial cubra la ventana completa, o importar el historial del plugin anterior si lo había.
Alimentos próximos a caducar
La directiva deja a los Estados fijar reglas propias para productos perecederos. La norma española no crea un modo de cálculo aparte para ellos. Lo que hace es excluir del cálculo un tipo de precio concreto: el aplicado, para reducir el desperdicio alimentario, a productos idénticos cuya fecha de caducidad o de consumo preferente está próxima a vencer.
Para una tienda de alimentación con WooCommerce esto tiene un efecto práctico claro. Si rebajas el yogur que caduca pasado mañana, ese precio no puede convertirse en el mínimo de 30 días del mismo yogur con fecha larga. El historial necesita saber que ese precio fue una rebaja antidesperdicio, por ejemplo con un indicador en el registro o con un lote o SKU distinto para el producto a punto de caducar. Si el plugin no permite marcarlo, la vía más segura es vender esos lotes como producto separado.
Rebaja que aumenta por etapas
La directiva, en su art. 6a.5, permite a los Estados fijar que, en una rebaja que crece en pasos sucesivos, el precio de referencia siga siendo el anterior al primer paso. El art. 20.1 no recoge esa opción: el texto consolidado no dice nada sobre reducciones progresivas.
Con una lectura literal, cada nuevo paso es una nueva reducción con su propia ventana de 30 días. Ejemplo ilustrativo: un producto cuesta 100, el lunes baja a 90 y una semana después a 80. En el momento del segundo paso, el precio más bajo de 30 días es 90, porque ese precio se aplicó dentro de la ventana anterior a la segunda rebaja. Si planificas campañas del tipo “cada semana más barato”, el precio tachado y el porcentaje que anuncias tienen que cuadrar con esa cifra. Si no, el cliente verá “-20 %” junto a un precio anterior de 90 y un precio de 80.
¿WooCommerce trae de serie el precio más bajo de 30 días?
No. Revisamos el código de WooCommerce en la rama principal del repositorio en GitHub el 27 de octubre de 2026: buscar “omnibus” y “lowest price” no devuelve nada, y el núcleo no tiene ninguna tabla ni campo con historial de precios.
Un producto de WooCommerce guarda el estado actual:
| Dato | Método en WC_Product | Qué dice del pasado |
|---|---|---|
| Precio normal | get_regular_price() | Solo el valor actual |
| Precio rebajado | get_sale_price() | Solo el valor actual, también si la oferta aún no ha empezado |
| Inicio de la oferta | get_date_on_sale_from() | Fecha prevista, sin rastro de ofertas anteriores |
| Fin de la oferta | get_date_on_sale_to() | Igual que el anterior |
| Precio activo | get_price() | El precio vigente ahora |
Cuando cambias un precio, el valor anterior desaparece. WooCommerce activa las ofertas programadas con una tarea en segundo plano (woocommerce_scheduled_sales) que cambia el precio activo en el momento de inicio. Cuando la oferta termina, vuelve el precio normal y la tienda no guarda constancia de que la oferta existió.
La conclusión es una: el precio más bajo de 30 días no se puede calcular con los datos de WooCommerce ni reconstruir a posteriori. Hace falta un registro de historial separado, desde el día de la instalación. Eso lo hace un plugin o código propio. Si se lo encargas a un programador, la especificación tiene que describir el registro del historial y las reglas para calcular el mínimo. La etiqueta en sí se añade en media hora; un historial correcto es un módulo aparte con sus pruebas. Si necesitas ese módulo o una auditoría del que ya tienes, lo explicamos en la página de desarrollador WooCommerce.
Cómo funciona un historial de precios correcto
El historial de precios es una tabla de registros: producto (o variación), precio, moneda y fecha desde la que se aplica ese precio. Con ella calculas el mínimo dentro de la ventana. Parece sencillo, pero cada una de las reglas siguientes nace de un error que alguien ya cometió.
El registro se crea cuando el precio empieza a aplicarse
El registro se añade cuando cambia el precio activo, es decir, el precio al que el cliente puede comprar. Guardar el producto en el panel no basta, porque en ese mismo guardado puedes programar una oferta para el mes que viene. Si el plugin guarda entonces el precio rebajado, ese precio entra en el historial antes de que nadie pudiera comprar a ese precio y, cuando empiece la oferta, pasará a ser “el precio más bajo de 30 días”. Con una oferta programada, el registro debe crearse en el momento en que WooCommerce la activa.
La segunda regla son los cambios dentro del mismo día. Si por la mañana bajas el precio y por la tarde lo vuelves a subir, durante unas horas el cliente pudo comprar más barato. Un historial que guarda solo un precio al día pierde ese cambio, y ese precio se aplicó.
La ventana se cuenta desde el inicio de la rebaja
La ventana de 30 días termina en el momento en que empieza la rebaja y no se desplaza con la fecha de hoy. Ejemplo ilustrativo: una oferta empieza el 1 de noviembre y dura tres semanas. El 15 de noviembre, el precio más bajo de 30 días sigue siendo el mínimo del periodo del 2 al 31 de octubre. Si el plugin cuenta “los últimos 30 días desde hoy”, a los pocos días de oferta el propio precio rebajado entra en la ventana y la tienda muestra “precio más bajo de 30 días: 80” junto a un precio de 80. Un mensaje así no le dice nada al cliente y contradice la norma.
El precio vigente al abrirse la ventana
Aquí tropieza la mayoría de las implementaciones sencillas. Los registros solo se crean cuando cambia el precio. Ejemplo ilustrativo: un producto cuesta 100 durante 40 días y hoy entra una rebaja a 80. El último registro con precio 100 tiene 40 días, así que dentro de la ventana de 30 días no hay ningún registro. Una consulta del tipo “mínimo de los registros de los últimos 30 días” devuelve un resultado vacío o solo el 80.
La lógica correcta toma el mínimo de dos fuentes: los registros dentro de la ventana y el último registro anterior al inicio de la ventana, porque ese precio seguía vigente cuando la ventana se abrió. En este ejemplo, el resultado es 100. La misma condición vale para la limpieza del historial: la tarea que borra registros de más de 30 días no puede borrar el último registro anterior a la ventana, porque es la única prueba del precio 100.
La moneda guardada en cada registro
Una tienda que cambió de moneda base, o una tienda con un plugin multimoneda, tiene en el historial precios en monedas distintas. Cada registro necesita su moneda, y la consulta del mínimo tiene que filtrar por la moneda en la que el cliente está viendo el producto. Si no, junto a un precio en euros aparecerá un precio más bajo en dólares o libras, o un mínimo calculado con cifras que no se pueden comparar.
Los impuestos, igual que el precio de al lado
WooCommerce permite introducir precios con o sin IVA y configurar por separado cómo se muestran en la tienda y en el carrito. El precio más bajo tiene que pasar por los mismos ajustes de visualización que el precio que lo acompaña, por ejemplo con wc_get_price_to_display(). Si la tienda introduce precios sin IVA y los muestra con IVA, la cifra en bruto del historial saldrá más baja por el importe del impuesto y confundirá al cliente.
Producto variable calculado por variación
Un producto variable de WooCommerce no tiene precio propio. Los precios están en las variaciones, y la ficha de producto muestra un rango. El historial tiene que llevarse para cada variación por separado, y la información del precio más bajo debe aparecer al elegir la variación, junto con su precio. Encaja con el criterio de “productos idénticos” del art. 20.1: una camiseta en talla M y la misma en talla XL pueden tener historiales distintos. En los listados de productos, donde se ve el rango, la tienda necesita una regla pensada, por ejemplo mostrar la información de la variación que marca el límite inferior del rango.
La limpieza del historial conserva el registro anterior a la ventana
El historial crece con cada cambio de precio, así que el plugin lo recorta. La tarea de limpieza borra registros antiguos, pero para cada producto conserva el último registro anterior a la ventana. Esa tarea también tiene que funcionar después de actualizar el plugin, sin reactivarlo.
Cómo calcular el precio más bajo de 30 días en una oferta programada
La oferta programada es la fuente más habitual de cifras erróneas, porque en el panel de WooCommerce el precio rebajado existe antes de empezar a aplicarse. Ejemplo ilustrativo paso a paso:
- El producto cuesta 100 desde hace mucho. El historial tiene un registro: 100, de hace 60 días.
- El 20 de octubre fijas un precio rebajado de 80 con fecha de inicio 1 de noviembre y guardas el producto.
- Hasta el 31 de octubre el cliente paga 100. El historial no puede tener un registro de 80, porque ese precio no se ha aplicado.
- El 1 de noviembre WooCommerce activa la oferta. En ese momento el historial recibe el registro 80.
- La ventana va del 2 al 31 de octubre. Dentro no hay registros, así que cuenta el registro anterior a la ventana: 100.
- La tienda muestra el precio 80, el 100 tachado y el aviso “precio más bajo de los 30 días anteriores a la rebaja: 100”.
- El 15 de noviembre el resultado es el mismo, porque la ventana está fijada al 1 de noviembre.
Si en el paso 2 el plugin guarda 80 en el historial enseguida, en el paso 6 mostrará un precio más bajo de 80. Si en el paso 5 ignora el registro anterior a la ventana, no mostrará nada o mostrará 80. Si en el paso 7 cuenta la ventana desde hoy, mostrará 80. Cada uno de esos resultados es un error distinto, y los tres se ven igual en la tienda.
Qué falla en la práctica al calcular el precio más bajo
Cualquier implementación de historial de precios, sea un plugin comercial o código a medida, puede caer en las mismas trampas. Las describimos una a una: de dónde vienen, cómo detectarlas en tu tienda y qué hace una implementación correcta.
Oferta programada registrada antes de empezar
De dónde viene. La implementación guarda el historial al guardar el producto en el panel. Si en ese guardado programas una oferta para la semana que viene, el precio rebajado entra en el historial antes de aplicarse y puede quedar como el precio más bajo de 30 días.
Cómo detectarlo. Programa una oferta para mañana y revisa la ficha del producto cuando empiece. Si el precio más bajo coincide con el precio rebajado, el historial registró la oferta demasiado pronto.
Qué hace una implementación correcta. Registra solo la oferta en curso, en el momento en que WooCommerce la activa.
El precio rebajado mostrado como el más bajo
De dónde viene. La ventana de 30 días se cuenta desde la fecha de hoy. A los pocos días de oferta, su precio entra en la ventana y pasa a ser el mínimo. El mismo efecto lo produce un historial que guarda un solo precio al día y pierde los cambios intradía.
Cómo detectarlo. En un producto rebajado, compara el precio de oferta con el “precio más bajo de 30 días”. Si coinciden y antes de la oferta el producto costaba más, el cálculo está mal.
Qué hace una implementación correcta. Cierra la ventana en el momento en que empieza la rebaja y registra cada cambio del precio activo, también varios cambios en un mismo día.
Sin registro en la ventana para un producto de precio estable
De dónde viene. Los registros solo se crean cuando cambia el precio, así que un producto con el mismo precio durante más de 30 días no tiene ningún registro en la ventana. Una consulta que calcula el mínimo solo con los registros de dentro de la ventana no encuentra nada. Una limpieza que borra todo lo que tiene más de 30 días elimina la única prueba del precio anterior a la rebaja.
Cómo detectarlo. Toma un producto cuyo precio no ha cambiado en más de un mes y rebájalo. El aviso tiene que mostrar el precio antiguo.
Qué hace una implementación correcta. Calcula el mínimo con los registros de la ventana más el último registro anterior a ella, y la limpieza conserva siempre ese registro.
Precio más bajo en otra moneda
De dónde viene. El historial guarda importes sin moneda, o guarda la moneda pero la consulta del mínimo no la usa. Una tienda que cambió de moneda base, o una con un plugin multimoneda que cambia la moneda en cada petición, muestra entonces el precio más bajo en una moneda junto a un precio de venta en otra.
Cómo detectarlo. Cambia la moneda en la tienda y mira un producto rebajado. El precio más bajo tiene que estar en la misma moneda que el precio de venta.
Qué hace una implementación correcta. Guarda la moneda en cada registro y filtra el mínimo por la moneda de la petición actual.
Ajustes que dan un resultado no conforme
De dónde viene. Los plugins suelen tener ajustes para la duración de la ventana y el comportamiento en casos límite. Algunos llevan a un resultado contrario a la norma: una ventana inferior a 30 días, la opción “hoy” como fuente del precio más bajo o mostrar el precio actual como el más bajo.
Cómo detectarlo. Revisa los ajustes del plugin Omnibus de tu tienda: duración de la ventana y comportamiento sin historial.
Qué hace una implementación correcta. Viene con valores por defecto conformes a la norma y avisa cuando alguien los cambia por otros que no lo son.
Sin aviso en las cuadrículas de producto de un tema de bloques
De dónde viene. En los temas de bloques, los listados de productos los construye el bloque Product Collection. WooCommerce ejecuta los hooks clásicos del bucle de productos solo en la cuadrícula de la tienda, así que una implementación basada en esos hooks no muestra el aviso en la página de inicio, en productos relacionados ni en las ventas cruzadas del carrito. Con dos fuentes de visualización, el mismo aviso también puede aparecer dos veces.
Cómo detectarlo. Inserta en la página de inicio un bloque Product Collection con un producto rebajado y comprueba que junto al precio tachado aparece el precio más bajo de 30 días, y solo una vez.
Qué hace una implementación correcta. Añade el aviso en cada cuadrícula que muestra un precio tachado, sea cual sea el bloque o la plantilla.
Sin aviso en la ficha de producto con plantilla de Elementor Pro
De dónde viene. La plantilla de ficha de producto de Elementor Pro sustituye el hook woocommerce_single_product_summary. Una implementación que engancha el aviso solo a ese hook no muestra nada en esa ficha.
Cómo detectarlo. Abre un producto rebajado en una ficha construida con Elementor y comprueba que el aviso está junto al precio.
Qué hace una implementación correcta. Da soporte a las plantillas del constructor o añade el aviso en el propio renderizado del precio.
Importación de historial que cuenta una oferta solo programada
De dónde viene. La importación desde el plugin antiguo lee el campo en bruto del precio rebajado. Ese campo también contiene ofertas solo programadas, así que un precio al que nadie compró entra en el historial como precio de venta.
Cómo detectarlo. Tras la importación, compara el precio más bajo de un producto que tenía una oferta programada pero no iniciada con el precio al que realmente se vendía.
Qué hace una implementación correcta. Traslada solo los precios que se aplicaron, con sus fechas y su moneda.
Datos estructurados sobrescritos con la cifra del historial
De dónde viene. La implementación mete el precio más bajo de 30 días en el JSON-LD del producto en lugar del precio rebajado o del precio normal de WooCommerce. El buscador ve entonces un precio distinto del que paga el cliente.
Cómo detectarlo. Abre el código fuente de la página de un producto rebajado y busca el bloque application/ld+json. El campo price de la oferta tiene que coincidir con el precio que paga el cliente.
Qué hace una implementación correcta. Añade el precio más bajo junto al precio rebajado y al normal, que se quedan como estaban.
Prefijo técnico en el carrito
De dónde viene. WooCommerce muestra los datos de cada línea del carrito con el formato “etiqueta: valor”. Si el aviso del precio más bajo llega ahí con una clave técnica, el cliente ve, por ejemplo, el prefijo “Omnibus:”.
Cómo detectarlo. Añade un producto rebajado al carrito y lee lo que aparece debajo del nombre de la línea.
Qué hace una implementación correcta. Muestra una frase que se entiende sin conocer el plugin.
Limpieza del historial que deja de funcionar tras una actualización
De dónde viene. La tarea diaria que recorta el historial solo se programa al activar el plugin. Una actualización sin reactivación la deja sin programar.
Cómo detectarlo. En WooCommerce > Estado > Acciones programadas (o en la lista de tareas de WP-Cron), comprueba que la tarea del plugin Omnibus está programada.
Qué hace una implementación correcta. Revisa la programación tras cada actualización y vuelve a programar la tarea si falta.
Resumen
| Trampa | Síntoma en la tienda | Cómo comprobarlo |
|---|---|---|
| Oferta programada registrada enseguida | Precio más bajo igual al rebajado desde el primer día | Oferta para mañana, revisión tras el inicio |
| Ventana contada desde hoy | A los pocos días de oferta el precio más bajo baja al rebajado | El mismo producto el día 1 y el día 10 de la oferta |
| Falta el precio anterior a la ventana | Sin aviso o con el precio rebajado como el más bajo | Rebaja de un producto con precio estable más de 30 días |
| Moneda ignorada en la consulta | Precio más bajo en otra moneda que el de venta | Cambio de moneda en un producto rebajado |
| Impuestos ignorados | Precio más bajo inferior por el importe del IVA | Tienda con precios sin IVA en el panel y con IVA en la web |
| Sin variaciones | Sin aviso al elegir la variación | Producto variable con oferta en una sola variación |
| Cuadrículas Product Collection | Sin aviso en la página de inicio y en relacionados | Bloque Product Collection con un producto rebajado |
| Plantilla de Elementor Pro | Sin aviso en la ficha de producto | Producto rebajado en una ficha de Elementor |
| Importación desde el plugin antiguo | Precio más bajo tomado de una oferta que no empezó | Comparar el historial antes y después de importar |
| JSON-LD sobrescrito | Precio distinto en los datos estructurados y en la página | Código fuente, campo price |
| Limpieza sin programar | El historial crece sin límite | Lista de acciones programadas |
Cómo lo resuelven nuestros plugins
Desarrollamos dos plugins para WooCommerce con soporte para Omnibus. Shoplex es el plugin de cumplimiento normativo para tiendas en la UE, y Polski for WooCommerce está pensado para tiendas polacas. Los dos registran una oferta programada solo cuando WooCommerce la activa, y los dos avisan cuando fijas una ventana inferior a 30 días. Las opciones “hoy” y “mostrar el precio actual como el más bajo” aparecen marcadas como no conformes con el art. 6a.2 de la Directiva 98/6/CE.
Ficha de producto en una tienda de pruebas con Shoplex (interfaz en inglés). El precio más bajo de 30 días (16,00 EUR) aparece bajo el precio rebajado, en la misma moneda y junto al precio por unidad. El ejemplo muestra también una regla de este artículo: el precio más bajo de la ventana no tiene por qué coincidir con el precio tachado.
Polski for WooCommerce, además, guarda la moneda en cada registro del historial y calcula el mínimo en la moneda en la que el cliente ve el producto. Tiene en cuenta el precio vigente al abrirse la ventana y los cambios de precio dentro del mismo día. Muestra el aviso según los ajustes de impuestos de WooCommerce, en las variaciones de productos variables, en las cuadrículas Product Collection de los temas de bloques y en las fichas de producto de plantillas de Elementor Pro. En los datos estructurados añade el precio más bajo junto al precio rebajado y al normal. Tiene un ajuste específico para productos sin historial y puede importar el historial de precios guardado por el plugin Omnibus de iworks.
Dónde más muestra la tienda una rebaja
La norma cubre cualquier oferta de un artículo con reducción de precio y pide el precio anterior en cada uno de ellos. En WooCommerce el precio tachado aparece en muchos sitios, y cada uno lo renderiza un código distinto.
Temas de bloques. El archivo de la tienda, la página de inicio, los productos relacionados y las ventas cruzadas del carrito son, en un tema de bloques, bloques distintos. Un plugin escrito para los hooks clásicos cubrirá el archivo, y el resto de cuadrículas se quedará sin aviso. Si pasas la tienda a un tema de bloques, revisa cada una por separado. Las diferencias entre temas clásicos y de bloques las explicamos en el artículo sobre temas clásicos y temas de bloques.
Constructores de páginas. Elementor Pro, y otros constructores con plantillas propias de ficha de producto, sustituyen los hooks estándar de WooCommerce. El aviso tiene que engancharse al punto que usa el constructor o al propio precio.
Carrito y resumen del pedido. Si el carrito muestra un precio tachado, está mostrando una rebaja. El texto del aviso tiene que ser legible para el cliente, sin nombres técnicos.
Datos estructurados. Los datos de producto en JSON-LD los lee el buscador, y de ellos salen los resultados con precio. El campo price de la oferta debe seguir siendo el precio de venta que paga el cliente. El precio más bajo de 30 días no sustituye ni al precio rebajado ni al normal.
Tarifas por cantidad y precios por grupo. Una tienda con precios que dependen de la cantidad o del rol del cliente tiene varios precios a la vez para el mismo producto. Antes de elegir un plugin Omnibus, comprueba qué precio trata como precio activo y si el precio de un grupo de clientes entra en el historial. La arquitectura de esos precios la explicamos en el artículo sobre precios escalonados y unitarios en WooCommerce B2B.
Publicidad con precio. El art. 6a de la directiva se refiere a cualquier anuncio de una reducción de precio. Un banner promocional en la web que da el precio rebajado y una newsletter con el precio de oferta son contenidos que preparas fuera de la ficha de producto, así que la cifra del historial hay que llevarla allí a mano o con una integración.
Cómo cambiar de plugin Omnibus sin perder el historial de precios
El historial de precios es la única prueba de qué precio estaba vigente antes de la rebaja. Cambiar de plugin sin importar el historial lo pone a cero, y la tienda vuelve durante 30 días a la situación “sin historial”. En España esto pesa más de lo que parece: si el historial se pierde, la tienda tampoco puede distinguir un producto antiguo de uno puesto a la venta por primera vez.
Antes del cambio, comprueba tres cosas:
- Si el plugin nuevo importa el historial del actual. Polski for WooCommerce importa el historial del plugin Omnibus de iworks. Para otras combinaciones, revisa la documentación o pide a tu programador un script de migración.
- Qué se importa exactamente. La importación tiene que trasladar los precios que se aplicaron, con fechas y moneda. El campo en bruto del precio rebajado no sirve, porque también contiene ofertas solo programadas.
- Cómo se comporta el plugin nuevo sin historial. Para los productos que la importación no cubra, el plugin usará el ajuste para el caso sin historial. Comprueba qué muestra entonces antes de lanzar rebajas.
El orden más seguro es: copia de la base de datos, instalación del plugin nuevo junto al antiguo, importación, comparación del precio más bajo en varios productos en ambos plugins y, solo después, desactivación del antiguo. Si para el mismo producto los dos historiales dan cifras distintas, averigua la causa antes de desactivar el antiguo, porque después ya no tendrás con qué comparar.
Cómo comprobar si tu tienda muestra el precio más bajo correcto
La prueba siguiente lleva alrededor de una hora en una copia de la tienda (staging). Las cifras son ilustrativas y cada paso dice qué resultado es el correcto.
- Oferta programada. Elige un producto de 100 cuyo precio no haya cambiado en más de 30 días. Programa una oferta de 80 que empiece mañana. Hoy, la ficha de producto no puede mostrar ni el 80 ni el aviso del precio más bajo. Mañana, cuando empiece la oferta, el aviso tiene que mostrar 100.
- Producto de precio estable. Si no quieres esperar a mañana, toma otro producto con el mismo precio desde hace 40 días y rebájalo ya. El precio más bajo de 30 días es el precio antiguo. Si ahí aparece el precio rebajado o no aparece nada, hay un error.
- Ventana fijada al inicio. Tras unos días de oferta, vuelve al producto del paso 1. El aviso tiene que seguir mostrando 100.
- Cambio intradía. En un producto de prueba, baja el precio durante una hora y luego restáuralo. Después lanza una oferta nueva. El precio más bajo tiene que tener en cuenta esa rebaja de una hora.
- Producto variable. Pon una oferta en una sola variación de un producto variable. Al elegir esa variación, el aviso del precio más bajo tiene que aparecer junto al precio de la variación. Al elegir una variación sin oferta, el aviso tiene que desaparecer.
- Moneda. Si la tienda usa un plugin multimoneda, cambia de moneda en un producto rebajado. El precio más bajo tiene que estar en la misma moneda que el precio de venta.
- Impuestos. Compara el precio más bajo con el precio de venta en una configuración en la que la tienda introduce precios sin IVA y los muestra con IVA. Las dos cifras tienen que incluir el impuesto de la misma forma.
- Página de inicio y otras cuadrículas. Pon un producto rebajado en un bloque Product Collection de la página de inicio y revisa después los productos relacionados y las ventas cruzadas del carrito. Junto a cada precio tachado tiene que haber un aviso, y solo uno.
- Plantilla del constructor. Si la ficha de producto sale de Elementor Pro u otro constructor, revisa un producto rebajado en esa ficha.
- Carrito. Añade un producto rebajado al carrito. El aviso tiene que ser una frase para el cliente, sin prefijos técnicos.
- Datos estructurados. Abre el código fuente de la página de un producto rebajado o la prueba de resultados enriquecidos de Google. El precio de la oferta tiene que coincidir con el precio rebajado.
- Tarea de limpieza. En WooCommerce > Estado > Acciones programadas, comprueba que la tarea del plugin Omnibus está programada. Cuando se haya ejecutado, repite el paso 2: el registro anterior a la ventana tiene que seguir ahí.
- Ajustes. Comprueba que la ventana es de 30 días y que ninguna opción obliga a mostrar el precio actual como el más bajo.
Guarda el resultado de la prueba con fecha y capturas de pantalla. Si la tienda cambia de tema, de constructor o de plugin de precios, repite la prueba, porque cualquiera de esos cambios puede llevar el precio a un sitio que el plugin no cubre.
Qué hacer si la prueba encuentra un error
Si el error está en los ajustes (ventana inferior a 30 días, opción que muestra el precio actual), lo corriges tú mismo en el panel del plugin. Si afecta a la visualización (sin aviso en una cuadrícula de bloques, en la plantilla del constructor o en el carrito), normalmente basta con actualizar el plugin o con un cambio pequeño en el tema. Si afecta al propio historial (ofertas registradas antes de empezar, falta el precio anterior a la ventana, moneda ignorada), la corrección exige cambios en la lógica de registro y, a menudo, limpiar el historial que se recogió mal.
Un historial erróneo no se arregla solo al actualizar el plugin. Los registros de ofertas guardadas antes de empezar se quedan en la base de datos y siguen bajando el mínimo hasta que alguien los borra o hasta que salen de la ventana. Después de cada corrección de la lógica, revisa el historial de los productos que tuvieron ofertas programadas en los últimos 30 días.
Aplicamos el mismo criterio a otras obligaciones de consumo en la tienda, por ejemplo al botón de desistimiento: la norma describe el resultado, y la tienda tiene que construirlo con datos que WooCommerce no recoge por sí solo. Tienes un repaso de otros plugins para tiendas en nuestra selección de plugins de WooCommerce.
Si quieres que revisemos el historial de precios de tu tienda, que lo migremos desde otro plugin o que montemos el soporte de Omnibus para un tema de bloques, un constructor o precios por grupo de clientes, escríbenos desde la página de desarrollador WooCommerce. Empezamos con la prueba de este artículo sobre una copia de tu tienda y fijamos el alcance del trabajo según su resultado.
Última actualización: 27 de octubre de 2026.
