Black Friday 2026: lista de preparación para tu PrestaShop

Última revisión: junio de 2026 para la próxima temporada. Fechas confirmadas: Black Friday 2026 = viernes 27 de noviembre; Cyber Monday = 30 de noviembre. Las rutas del back office se aplican a PrestaShop 1.7, 8 y 9.

Black Friday 2026 cae el viernes 27 de noviembre, con Cyber Monday el 30 de noviembre; por tanto, el pico de cuatro días irá del 27 al 30 de noviembre, y la ventana inteligente de preparación empieza a finales de septiembre. Las tiendas que salen ganando no son las que aplican los descuentos más agresivos, sino aquellas cuya instalación de PrestaShop ya se ha probado bajo carga, se ha congelado y se ha ensayado antes de que llegue la primera oleada de tráfico. Esta es una cuenta atrás de preparación, semana a semana, que puedes aplicar a cualquier viernes en que caiga Black Friday; en 2026, por ejemplo, será el 27 de noviembre. Cubre qué hacer, cuándo hacerlo y exactamente dónde hacerlo en el back office de PrestaShop.

El plan se mantiene deliberadamente en su terreno. El cómo crear los descuentos, programar las ofertas flash y recuperar los carritos tiene su propio análisis en otros artículos de este bloque; esta publicación es la cronología que te indica cuándo accionar cada palanca, con los pasos de preparación específicos de PrestaShop que las guías de marketing dan por hechos.

La cuenta atrás de 2026 de un vistazo

Ancla cada tarea al 27 de noviembre y trabaja hacia atrás. Las fechas siguientes son plazos límite, no sugerencias: la mayoría de los fallos del día se remontan a un paso que se comprimió en la última semana cuando necesitaba margen.

8 semanas antes (principios de octubre): deja bien asentada la base

El tráfico de Black Friday suele multiplicar varias veces tu volumen normal; es una orientación, no una promesa, y tus propios datos de analítica de noviembre pasado son la única referencia honesta. La razón para empezar aquí es que el trabajo de capacidad y rendimiento no puede hacerse con seguridad en la última semana, porque cada cambio puede introducir un error que ya no tendrás tiempo de detectar.

Haz pruebas de carga antes de optimizar

No adivines dónde se rompe tu tienda: mídelo. Herramientas como k6 o Loader.io pueden simular cientos de usuarios concurrentes entrando en tus páginas de categoría, producto y pago. Ejecuta la prueba contra una copia de staging, no contra producción, y observa dónde empiezan a subir los tiempos de respuesta: una base de datos que va bien con 20 usuarios simultáneos puede venirse abajo con 300. El flujo de pago (el controlador order) es la página que no puede fallar: hazle una prueba de carga específica, con productos que lleguen realmente hasta la confirmación del pedido.

Activa los ajustes de rendimiento que PrestaShop ya incluye

La mayor parte de lo que necesitas está en el back office, en Parámetros avanzados → Rendimiento. No des por hecho que está activado: verifica cada punto:

• Caché de Smarty: configura la caché en Sí y la compilación de plantillas en "Nunca recompilar". Recompilar plantillas en cada solicitud durante un pico de tráfico es CPU desperdiciada que no te puedes permitir.
• CCC (Combinar, Comprimir, Caché): activa "Caché inteligente para CSS" y "Caché inteligente para JavaScript" para que el navegador descargue menos archivos y más ligeros. Prueba después la tienda visible al cliente: a veces CCC choca con un tema mal construido, y quieres descubrirlo ahora, no el 27 de noviembre.
• OPcache: confirma que de verdad está funcionando, no solo instalado. Verifica su estado con las herramientas de tu hosting/servidor o con una página de estado phpinfo/OPcache, en lugar de confiar únicamente en la pantalla de Rendimiento de PrestaShop; si está desactivado, un cambio del servidor no tendrá efecto hasta que lo limpies. Verifica y luego no lo toques.
• Caché (Redis/Memcached): en "Caché", dentro de la misma página, puedes apuntar la caché de PrestaShop a Redis o Memcached si tu proveedor lo ofrece, aunque según tu versión esto suele requerir configuración del servidor o de un módulo para funcionar. Es una de las palancas más importantes cuando la base de datos empieza a sufrir con carritos concurrentes. Mover las sesiones fuera del disco es una tarea aparte: se configura a nivel de servidor/PHP (o mediante un módulo), no desde este ajuste de caché.

También conviene aligerar tus medios: las imágenes de producto sobredimensionadas son el asesino más silencioso de la velocidad de página cuando miles de personas navegan a la vez. Comprímelas y ajústalas al tamaño correcto ahora, mientras aún tienes tiempo para revisar los resultados.

6 semanas antes (mediados de octubre): actualiza y prepárate para congelar

Actualiza el núcleo de PrestaShop, todos los módulos y tu tema ahora, no la semana anterior. Las actualizaciones pueden introducir comportamientos inesperados, y precisamente por eso se hacen con seis semanas de margen: para ganar semanas de colchón en las que detectar y corregir cualquier rotura. Haz primero las actualizaciones en una copia de staging, recorre el pago y un pedido de prueba, y después pásalo a producción.

La disciplina más importante: planifica una congelación estricta del código para el 1 de noviembre. A partir de esa fecha, nada de instalar módulos, tocar el tema o cambiar el núcleo salvo que algo esté realmente ardiendo. Cada "retoque rápido" en noviembre es una oportunidad de romper el pago cuando menos tiempo tienes para darte cuenta. Avisa con antelación de la fecha de congelación a cualquiera que tenga acceso al back office, para que no sea una sorpresa.

4 semanas antes (finales de octubre): crea y prueba los descuentos en staging

Aquí es donde muchos comerciantes mezclan dos trabajos distintos. Diseñar la oferta — qué profundidad tendrá, porcentaje o importe fijo, por niveles, en packs — es una cuestión estratégica que se trata en cómo hacer una promoción en PrestaShop: reglas del carrito, precios específicos y estrategias de descuento, y la regla práctica para proteger el margen está en exclusión de descuentos: por qué algunos productos nunca deberían rebajarse. Lo que corresponde aquí, en la lista, es el paso de preparación: crea lo que hayas decidido, en una copia de staging, y demuestra que se aplica correctamente antes de que toque un carrito real.

En PrestaShop, tus dos mecanismos son Catálogo → Descuentos → Reglas del carrito (cupones, condiciones, códigos automáticos) y Catálogo → Descuentos → Reglas de precio del catálogo / Precios específicos por producto (un precio tachado que se muestra directamente en el producto). Lo que debes verificar con carritos de prueba reales:

• Que el descuento se aplica realmente a los productos previstos, y no a los que has excluido.
• Que los descuentos no se acumulan de una forma que borre tu margen. Una regla del carrito más una regla de precio del catálogo más una reducción por grupo de clientes pueden multiplicarse en silencio.
• Que los umbrales de envío gratuito y las condiciones de carrito mínimo se activan con el importe correcto, incluidos los impuestos cuando tu tienda los muestra.
• Que los campos "Cantidad disponible" y de fecha de una regla del carrito se comportan como esperas: un cupón que se agota o caduca a mitad del fin de semana es un dolor de cabeza para soporte.

Los errores de descuentos durante Black Friday son caros y embarazosos a partes iguales. La solución es poco emocionante: pruébalos cuatro semanas antes, en staging, con una lista de comprobación.

Decide qué funcionará con temporizador y qué será manual

No quieres estar cambiando precios a mano a las 6 de la mañana del día 27. Las reglas del carrito y los precios específicos de PrestaShop incluyen rangos de fecha "desde / hasta", así que una oferta puede configurarse semanas antes y activarse puntualmente sin tocar nada. Para la mecánica de hacer que las promociones empiecen y terminen solas, y las trampas con las zonas horarias del servidor, consulta descuentos programados: configurar promociones que empiezan y terminan automáticamente. Si tu plan implica rotar ofertas durante el fin de semana en lugar de mantener una única promoción estática, la parte de automatización se trata en preparación de Black Friday: automatizar descuentos y promociones, y nuestro módulo Sales Revolution gestiona ofertas flash programadas para que la rotación funcione sin que tengas que vigilarla. El enfoque honesto sobre tácticas de urgencia — temporizadores de cuenta atrás, "hasta fin de existencias" — está en ventas flash: crear urgencia sin manipular.

2 semanas antes (mediados de noviembre): programa, ensaya y prepara las fuentes de datos

Con la congelación en marcha y los descuentos probados, esta quincena va de programar y ensayar, no de construir.

• Define las fechas de activación. Introduce el inicio el 27 de nov. y el final el 30 de nov. (o el 1 de dic.) en cada regla del carrito y precio específico. Revisa dos veces la zona horaria de la tienda en Internacional → Localización → Localización: una oferta programada para "medianoche" se dispara según la hora del servidor, que puede no coincidir con la medianoche de tus clientes.
• Crea el destino de aterrizaje. Una categoría o página CMS dedicada a Black Friday es donde aterriza el tráfico de tus emails y anuncios. Créala ahora (puedes dejarla sin indexar o sin publicar hasta el lanzamiento, si lo prefieres), para que ese día solo tengas que activar un interruptor, no construir bajo presión.
• Banners sin diseñador. Los gráficos principales/promocionales que anuncian la oferta no necesitan una agencia de diseño: consulta Banner Revolution: crear promociones llamativas sin diseñador.
• Fuente de datos de Google Merchant Center. Si haces anuncios de Shopping, rellena los atributos sale_price y sale_price_effective_date para que Google muestre el precio tachado durante la ventana de la oferta. Envíala con tiempo; el reprocesamiento de la fuente de datos no es instantáneo.
• Ensayo completo. Recorre un viaje completo como cliente: aterriza en la página de Black Friday, añade un producto rebajado, aplica un cupón si usas códigos y llega hasta la confirmación del pedido. Después hazlo otra vez desde un móvil. Este único ensayo detecta más problemas reales que cualquier punto de la lista.

1 semana antes (~20 de noviembre): preparación operativa

El código está congelado y probado; ahora asegúrate de que el negocio que hay detrás puede aguantar.

• Inventario. Verifica los niveles de stock en Catálogo → Stocks para todo lo que vas a promocionar. Vender de más y luego cancelar pedidos daña la confianza durante mucho más tiempo que perder una venta. Decide de forma deliberada el comportamiento ante falta de stock (rechazar / permitir pedido pendiente) para cada producto.
• Copias de seguridad. Haz una copia completa de la base de datos y los archivos el día anterior, y confirma que puedes restaurarla de verdad. Una copia que nunca has probado es una esperanza, no una red de seguridad. Parámetros avanzados → Base de datos → Copia de seguridad de BD de PrestaShop cubre la base de datos; tu hosting o una rutina dedicada debería cubrir los archivos.
• Monitorización. Apunta un monitor de disponibilidad (UptimeRobot, Pingdom) a tu página de inicio y a una página profunda como el pago, para recibir una alerta en minutos si el sitio tropieza, no cuando te escriba un cliente.
• Soporte & envíos. Confirma las fechas límite de los transportistas y planifica una cobertura ampliada de soporte. Prepara respuestas para las preguntas previsibles: "¿funciona mi código?", "¿cuándo llegará?", "¿cuál es la política de devoluciones?". Mostrar expectativas de entrega realistas en el pago es exactamente para lo que sirve una visualización automatizada de entrega estimada.

El propio fin de semana (27–30 de noviembre): ejecuta y vigila

Si has hecho el trabajo anterior, el fin de semana será sobre todo observación. Tus ofertas programadas se activan solas; tu trabajo es detectar anomalías rápido.

• Confirma que las ofertas se activaron. A primera hora del día 27, carga la tienda visible al cliente como si fueras un comprador y verifica que los precios rebajados se muestran realmente. Un desliz de zona horaria es el clásico pánico de las 6 de la mañana.
• Vigila los paneles adecuados. Controla la carga del servidor, las tasas de error y la finalización de pagos. En Google Analytics 4, observa las conversiones en tiempo real: una caída repentina suele significar que algo se ha roto, no que la demanda haya desaparecido.
• Mantén los tiempos de respuesta bajo control. Si la carga empieza a subir, cuentas con el margen que construiste en octubre. Resiste la tentación de "instalar un módulo de caché rápido" en pleno fin de semana: ese es exactamente el tipo de cambio que la congelación pretendía evitar.
• Recupera lo que se escapa. Incluso un fin de semana impecable pierde algunos carritos. Merece la pena tener listas las secuencias de carrito abandonado y seguimiento poscompra que recuperan una parte; y son una campaña, no un punto de una lista, así que planifícalas dentro de tu calendario de promociones estacionales más amplio.

Después del fin de semana: recoge lo aprendido

Black Friday no es un evento aislado: es la apertura ruidosa de una temporada que continúa con Navidad y llega hasta la planificación de Año Nuevo. Antes de que se asiente el polvo, anota las cifras mientras están frescas: qué productos se vendieron, qué canales generaron ingresos, dónde sufrió la tienda y qué mecánica de descuento movió realmente los pedidos. Ese documento es la ventaja inicial del año que viene, y es la forma en que un primer Black Friday caótico se convierte en uno tranquilo y repetible.

El patrón de fondo es el mismo todos los años: la victoria se consigue en las semanas anteriores, en staging, bajo prueba de carga y detrás de una congelación de código. La fecha de 2026 está fijada en el 27 de noviembre. Todo lo demás consiste en trabajar hacia atrás desde ahí con margen suficiente para corregir lo que encuentres.

Preguntas frecuentes

¿Qué fecha es Black Friday 2026 y cuándo debería empezar?

Black Friday 2026 es el viernes 27 de noviembre; Cyber Monday es el 30 de noviembre. Trabaja hacia atrás: base técnica y pruebas de carga unas 8 semanas antes (principios de octubre), actualizaciones 6 semanas antes, descuentos creados y probados en staging 4 semanas antes, congelación de código el 1 de noviembre, programación y ensayos dos semanas antes, y preparación operativa (stock, copias de seguridad, monitorización) la semana del 20 de noviembre.

Una oferta que programé para "medianoche" se activó a la hora equivocada. ¿Por qué?

PrestaShop evalúa el "válido desde / hasta" de la regla del carrito según la zona horaria de la tienda, configurada en Internacional → Localización → Localización; es la hora del servidor, no necesariamente la medianoche local de tus clientes. Revisa ese ajuste antes del fin de semana e introduce las fechas teniendo en cuenta el desfase. Este desliz de zona horaria es el clásico pánico de las 6 de la mañana del día 27.

¿Debería crear los descuentos en producción o en una copia de staging?

En staging, siempre. Primero crea y demuestra que los descuentos se aplican correctamente, y que no se aplican a los productos excluidos, en una copia; después lleva la configuración probada a producción. Las pruebas de carga también deben ejecutarse contra staging, no contra la tienda en vivo, para que una prueba con cientos de pagos concurrentes no tumbe el tráfico real.

¿Puedo instalar un módulo de caché durante el fin de semana si el sitio se ralentiza?

No; precisamente para eso existe la congelación de código. Un módulo nuevo durante el pico de tráfico es el cambio más arriesgado que puedes hacer, y el momento en que menos margen tienes para detectar una regresión en el pago. Construye tu margen en octubre. Si la carga sube durante el día, apóyate en la caché y la capacidad que ya probaste, vigila la finalización de pagos y resiste el "arreglo rápido".

¿Necesito almacenamiento de sesiones separado si muevo la caché a Redis?

Sí: son tareas distintas. Apuntar la caché de objetos de PrestaShop a Redis o Memcached (en Parámetros avanzados → Rendimiento → Caché) reduce la carga de la base de datos, pero mover las sesiones de PHP fuera del sistema de archivos se configura por separado a nivel de servidor/PHP o mediante un módulo. Resolver una cosa no resuelve la otra; planifica ambas si tu concurrencia lo justifica.