Errores y problemas

Las rutas sin caché fijan tus límites de tráfico

¿Tu WordPress se cae justo cuando una campaña empieza a funcionar? Durante muchos picos, la portada sigue cargando gracias a la caché, pero el límite real aparece en rutas dinámicas como el carrito, el pago, el acceso de usuarios, las búsquedas o las llamadas a admin-ajax.php.

Índice

Anuncio

Diagnostica el cuello de botella y actúa

Diagnostica el recurso saturado y decide qué corregir en los primeros 30 minutos.

Revisa las señales que sí cambian decisiones

El error más frecuente es medir solo CPU y RAM. Las decisiones útiles requieren mirar también el percentil p95, es decir, el tiempo por debajo del cual se completa el 95 % de las solicitudes, las consultas lentas de MySQL o MariaDB y la tasa de errores.

Relaciona síntoma, causa y respuesta

Usa esta matriz durante el incidente y guárdala para la siguiente campaña.

Síntoma medibleCausa probableAcción inmediataSolución duradera
CPU sostenida por encima del 90 %PHP, cron o tráfico no cacheadoPausar tareas pesadas y campañas secundariasReducir coste por petición o ampliar CPU
Workers PHP agotadosCheckout, AJAX o API externa lentaLimitar peticiones y desactivar extrasColas y ajuste de PHP-FPM
p95 por encima de 3 segundosConsultas lentas o disco saturadoRevisar logs y frenar procesosÍndices y limpieza de base de datos
Errores 502, 503 o 504Servidor, proxy o dependencia caídaActivar página de espera y escalar soporteAlta disponibilidad y circuit breaker
Las rutas sin caché fijan tus límites de tráfico

Calcula capacidad y elige el tipo de escalado

Calcula la carga prevista y escoge una respuesta proporcional antes de contratar recursos.

Define un objetivo que puedas comprobar

Haz una prueba con subida gradual, o ramp-up. Por ejemplo, empieza con 5 RPS, sube 5 RPS cada dos minutos y mezcla rutas reales: un 70 % de páginas públicas, un 20 % de fichas y un 10 % de carrito, búsqueda o pago, si esa es tu distribución habitual.

Ruta de decisión durante un pico
Mide RPS, p95 y 5xx
¿La ruta es cacheable?
Sí: CDN y caché
No: PHP, BD, colas y límites

Si p95 o errores superan el umbral, reduce funciones no críticas antes de aumentar la carga.

Compara las cuatro respuestas posibles

El escalado horizontal reparte solicitudes entre varias instancias mediante un balanceador de carga. Funciona cuando las sesiones están fuera de cada servidor, los archivos se comparten y todas las instancias tienen el mismo código; de lo contrario, un cliente puede perder su carrito al cambiar de nodo.

OpciónTiempo habitualCoste relativoCuándo encaja
VerticalEntre 15 y 60 minutosBajo a medioPico puntual y un servidor limitado
HorizontalEntre 1 y 5 díasMedioCarga repetida en rutas dinámicas
AutoscalingEntre 2 y 10 díasMedio a altoPicos variables y arquitectura preparada
ColasEntre 4 y 12 horasBajo a medioCorreos, PDF, importaciones y sincronizaciones

Convierte la prueba de carga en una previsión de capacidad. Si el escenario objetivo alcanza 80 RPS, con un p95 inferior a 2 segundos y menos de un 1 % de errores, no planifiques el pico exactamente en ese límite: reserva un margen del 30 % al 50 % para variaciones de campaña, bots y dependencias lentas. Calcula también el coste por hora de cada instancia, base de datos, CDN y servicios externos durante el periodo de máxima demanda.

Comparar ese coste con el impacto de pedidos fallidos permite decidir si conviene ampliar temporalmente, configurar autoscaling o reducir trabajo mediante caché y colas.

Las rutas sin caché fijan tus límites de tráfico

Protege rutas dinámicas antes del pico

Protege checkout, login y APIs para conservar las acciones que generan ingresos.

Separa lo cacheable de lo privado

Verifica en modo incógnito que las cabeceras de caché aparecen en las páginas públicas. Después, entra con un usuario de prueba, añade un producto y confirma que el carrito, cupón y checkout cambian en tiempo real sin servir contenido antiguo.

Degrada funciones sin cortar ventas

Aplica rate limiting, un límite de solicitudes por IP o usuario, en login, REST API y búsqueda. Añade un circuit breaker para que, si una API externa falla varias veces, WordPress deje de esperarla temporalmente y muestre una alternativa en lugar de bloquear todos los workers.

No todo el tráfico elevado representa compradores reales. Separa las visitas de campañas, clientes, pasarelas de pago y bots de buscadores del tráfico automatizado que repite búsquedas, login, carrito o llamadas a la REST API. Revisa por ruta, IP, ASN, país, agente de usuario y tasa de solicitudes para detectar patrones anómalos, como cientos de intentos de acceso por minuto o consultas idénticas desde pocas redes.

Aplica reglas de CDN o WAF, desafíos adaptativos y rate limiting progresivo antes de bloquear; así reduces ataques de capa 7 y scrapers sin impedir que un usuario legítimo complete un checkout.

Preguntas y respuestas

Responde estas dudas antes de fijar la fecha de tu campaña.

¿Cómo evito que mi web se caiga por exceso de tráfico?

Evita caídas midiendo el cuello de botella, cacheando páginas públicas y reservando capacidad para las rutas dinámicas. Haz una prueba gradual hasta el RPS previsto y fija un límite de entre el 1 % y el 2 % de errores.

¿Qué hago si WordPress muestra errores 503?

Un error 503 suele indicar que el servicio no puede atender más solicitudes temporalmente. Revisa workers PHP-FPM, CPU, conexiones de base de datos y tareas cron; pausa funciones no críticas antes de ampliar el servidor.

¿Una CDN acelera el checkout de WooCommerce?

Una CDN no acelera por sí sola un checkout con sesión, stock y pago personalizado. Debes excluir esas rutas de caché y reducir el trabajo de PHP, base de datos y APIs durante cada compra.

¿Cómo sé si necesito más hosting?

Necesitas más hosting si un recurso concreto se satura durante pruebas o picos reales. Confírmalo con CPU, workers, p95, TTFB, consultas lentas y errores 5xx, no solo con visitas simultáneas.

¿Qué diferencia hay entre escalado vertical y horizontal?

El escalado vertical añade CPU o RAM a un servidor, mientras el horizontal reparte carga entre varios. El segundo exige sesiones y archivos compartidos para que el usuario no note el cambio de instancia.

¿Cuándo debo hacer pruebas de carga?

Haz pruebas de carga entre 7 y 14 días antes de una campaña importante. Usa datos de rutas reales, subida gradual y un plan para detener la prueba si el p95 o los errores superan tu límite.

¿Qué debo vigilar durante black friday?

Durante Black Friday vigila RPS, p95, p99, TTFB, errores 5xx, workers PHP y latencia de base de datos. Asigna una persona técnica, una persona comercial y un canal único para decidir pausas o cambios.

Cierra el plan y deja responsables asignados

Deja por escrito qué se mide, quién responde y qué función se apaga primero.

Un runbook de una página es suficiente si contiene enlaces al panel de hosting, CDN, registros, copia de seguridad, contacto de soporte y criterios para pausar campañas.

⚠️ No cierres un incidente al desaparecer los errores: confirma pedidos, pagos, colas y registros antes de reactivar todas las campañas y funciones.

La respuesta técnica debe ir acompañada de una comunicación breve y coordinada. Define quién confirma el incidente, quién puede pausar anuncios y quién informa a atención al cliente, dirección o proveedores de pago. Si afecta al checkout, comunica un estado verificable, la hora de la próxima actualización y el canal interno donde se registran las decisiones; evita prometer una hora de recuperación sin datos.

Tras el pico, revisa RPS, p95, errores 5xx, pedidos fallidos, cambios aplicados y coste adicional. Un análisis posterior sin culpabilizar ayuda a convertir cada incidencia en acciones concretas, responsables y fechas de comprobación antes de la siguiente campaña.

Anuncio

Lecturas adicionales

Si quieres ampliar información sobre este tema, estas fuentes pueden interesarte:

RESUMIR CON IA: Extrae lo importante

Comparte este artículo:

Josu Barrios

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.