Cómo preparar tu WooCommerce para Hot Sale y CyberMonday: checklist técnico

Este CyberMonday (del 2 al 4 de noviembre) muchas tiendas descubrieron lo mismo de la peor manera: el sitio que andaba bien un martes cualquiera se pone lento o tira error justo cuando entra la gente. No es mala suerte. Es lo que pasa cuando una tienda llega a un evento sin haberse preparado para la carga.

Y la carga es enorme. Según la CACE, el Hot Sale 2026 superó los 6 millones de órdenes de compra en tres días. Si tu tienda participa, una parte de ese tráfico va a pegarte de golpe, en las mismas horas que a todos los demás.

La buena noticia es que casi todo lo que hace caer a una tienda se puede detectar y resolver con tiempo. Esta es la checklist que usamos con nuestros clientes. Si arrancás ahora, llegás bien al Hot Sale 2027 (que la CACE suele hacer en mayo): lo ideal es empezar 8 a 12 semanas antes.

Qué se rompe primero (y por qué)

En una tienda WooCommerce hay dos tipos de páginas:

• Las que se pueden cachear: home, categorías, fichas de producto. Se arman una vez y se le entregan iguales a todos.
• Las que no: carrito, checkout y "mi cuenta". Son distintas para cada cliente, así que cada visita la procesa el servidor desde cero: PHP, base de datos, cálculo de envío, cupones, stock.

Cuando entra el tráfico de un evento, las primeras aguantan bien si la caché está bien hecha. Las segundas son las que tiran abajo la tienda. Y son justo las que generan la plata.

Los síntomas típicos, en el orden en que suelen aparecer:

1. El checkout tarda varios segundos en confirmar.
2. El panel de WordPress se vuelve inusable (no podés ni cargar un cupón).
3. Errores 502 o 504: el servidor no tiene más procesos libres para atender.
4. Pedidos que se pagan pero no se registran, o stock que se descuenta mal.

8 a 12 semanas antes: el diagnóstico

Antes de tocar nada, medí. Lo que no sabés dónde duele no lo podés arreglar.

• Instalá Query Monitor en un entorno de prueba y recorré el camino de compra: agregar al carrito, aplicar un cupón, calcular envío, pagar. Anotá qué plugins suman más consultas y más tiempo.
• Revisá el log de consultas lentas de la base de datos. Una sola consulta mal armada (un filtro de productos, un plugin de reportes) puede trabar todo cuando se multiplica por cien usuarios.
• Mirá cuántos procesos PHP tenés disponibles y cuántos se usan en un día normal. Si en un día tranquilo ya estás cerca del límite, el evento te va a pasar por arriba.
• Hacé inventario de plugins. Cada plugin que se ejecuta en el checkout es un sospechoso. Si hay alguno que no usás, este es el momento de sacarlo.

Caché: qué guardar y qué nunca

Una caché bien configurada es la diferencia entre aguantar o no. Una mal configurada es peor que no tener caché: puede mostrarle a un cliente el carrito de otro.

Sí cachear:

• Home, categorías, fichas de producto, páginas institucionales.
• Imágenes, CSS y JavaScript, idealmente desde un CDN.

Nunca cachear:

• /carrito, /finalizar-compra y /mi-cuenta (o como se llamen en tu tienda).
• Cualquier visita que tenga las cookies de sesión de WooCommerce (woocommerce_items_in_cart, wp_woocommerce_session_*) o de usuario logueado.
• Las llamadas a la API de WooCommerce y los webhooks de las pasarelas de pago.

Si tu caché depende de un plugin, revisá que tenga estas exclusiones activas. Si es a nivel servidor, mejor: la página se entrega sin siquiera arrancar WordPress, y el servidor queda libre para el checkout.

Redis, OPcache y procesos PHP

Las páginas que no se cachean necesitan que cada pedido al servidor sea lo más liviano posible.

• Redis como caché de objetos. WooCommerce repite muchas consultas a la base de datos (opciones, sesiones, datos de productos). Con Redis, esas respuestas salen de memoria. Es probablemente la mejora con más impacto en el checkout.
• OPcache activado y con memoria suficiente, para que PHP no recompile el código en cada visita.
• Procesos PHP dimensionados para el pico. Cada checkout simultáneo ocupa un proceso. Si tenés 10 y entran 40 personas a pagar al mismo tiempo, 30 quedan esperando. Calculá con tu peor hora del último evento, no con un día normal.
• Una versión de PHP actual. PHP 8.2 o superior es bastante más rápido que las versiones viejas, y la mayoría de los plugins ya lo soportan.

Las tareas de fondo: cron y Action Scheduler

WooCommerce hace mucho trabajo "por detrás": mails de confirmación, cambios de estado de pedidos, sincronizaciones con stock, facturación o envíos.

• Desactivá el cron de WordPress que se dispara con las visitas (DISABLE_WP_CRON) y reemplazalo por un cron real del servidor cada minuto. Con mucho tráfico, el cron "por visita" se dispara de más y suma carga justo cuando no la necesitás.
• Revisá la cola de Action Scheduler (WooCommerce › Estado › Acciones programadas). Si hay miles de acciones pendientes o fallidas, limpialas antes del evento.
• Activá HPOS (almacenamiento de pedidos de alto rendimiento) si tu tienda y tus plugins lo soportan. Guarda los pedidos en tablas propias en vez de mezclarlos con el resto del contenido, y se nota cuando hay muchos pedidos juntos.

Pasarelas de pago y servicios externos

Muchas caídas no son del servidor sino de lo que la tienda llama hacia afuera.

• Confirmá que los webhooks de tu pasarela (Mercado Pago, por ejemplo) lleguen bien y no estén cacheados ni bloqueados por el firewall.
• Revisá los plugins que consultan servicios externos en el checkout: cotizadores de envío, validadores de dirección, antifraude. Si uno de esos servicios tarda, tu checkout tarda. Preguntá si tienen un tiempo de espera máximo configurable.
• Tené a mano el contacto de soporte de la pasarela por si algo falla el día del evento.

La prueba de carga

Es el paso que más tiendas se saltean y el que más problemas evita. La idea es simple: simular el tráfico del evento antes del evento.

• Usá una copia de la tienda, no producción, o hacelo en un horario sin ventas y avisando a la pasarela.
• Armá escenarios realistas: gente navegando categorías, gente agregando al carrito y una parte que llega al checkout. Herramientas como k6 permiten describir esos recorridos.
• Subí la carga de a poco hasta encontrar el punto en el que los tiempos de respuesta se disparan. Ese es tu techo real.
• Poné metas concretas: por ejemplo, que el checkout responda en menos de 2 segundos con el doble del tráfico de tu mejor hora del año pasado.

Si la prueba falla, tenés semanas para corregir. Si no la hacés, te enterás el día del evento.

El plan para el día D

• Congelá los cambios una semana antes: nada de actualizar plugins, cambiar el tema ni sumar funcionalidades. Lo que funciona no se toca.
• Hacé un backup completo el día anterior y verificá que se pueda restaurar.
• Precargá la caché de las páginas más visitadas (home, categorías en oferta, productos destacados) antes de que arranque el evento.
• Definí quién mira la tienda y cómo se le avisa. Un monitoreo que te alerte si el sitio se cae o se pone lento, y alguien con acceso para actuar, también a la medianoche del primer día.
• Tené un plan B para lo que más miedo te da: si se cae la pasarela, si se agota el stock, si hay que bajar una oferta.

Después del evento: el post-mortem

Cuando termina, anotá lo que pasó mientras está fresco: horas pico, tiempos de respuesta, errores, pedidos con problemas, quejas de clientes. Es el insumo de la próxima prueba de carga. Las tiendas que mejor llegan a cada evento son las que aprendieron del anterior.

Checklist resumida

• Diagnóstico con Query Monitor y log de consultas lentas
• Inventario de plugins y limpieza de los que no se usan
• Caché de página con carrito, checkout y mi cuenta excluidos
• Redis activo como caché de objetos
• OPcache y procesos PHP dimensionados para el pico
• Cron real del servidor y cola de Action Scheduler limpia
• HPOS activado (si tus plugins lo soportan)
• Webhooks de pagos verificados
• Prueba de carga con metas concretas
• Congelamiento de cambios, backup verificado y caché precargada
• Monitoreo y responsable definido para el día D
• Post-mortem al terminar

Si no querés hacerlo solo

Todo esto se puede hacer por cuenta propia, pero lleva tiempo y conocimiento técnico. En AWPHost lo resolvemos de dos maneras:

• Nuestro hosting WooCommerce ya viene preparado: servidores en Argentina, caché de página en el servidor que deja afuera carrito y checkout, Redis incluido y recursos dimensionados según tu tienda.
• Para las fechas fuertes ofrecemos una guardia para Hot Sale y CyberMonday: prueba de carga antes del evento, congelamiento de cambios, monitoreo en vivo durante las fechas e informe posterior. Escribinos y te contamos cómo funciona.