Dos errores distintos que se suelen confundir
Cuando una tienda sufre oleadas de bots es habitual pasar por dos fases y confundir sus errores, porque aparecen con pocas semanas de diferencia. Son problemas independientes:
Error 503: el servidor no puede atender la petición porque se han agotado los recursos de la cuenta (procesos PHP, CPU, conexiones a base de datos). Es un síntoma de saturación.
Error 403: el servidor prohíbe expresamente el acceso a una ubicación o petición concreta. Es un bloqueo deliberado, normalmente de una regla de mitigación o de ModSecurity.
Que tu web devuelva 503 hoy no significa que las reglas que provocaron 403 hace meses sigan activas, ni al revés. Cada uno se diagnostica por separado.
Por qué los bots provocan el 503
El patrón más frecuente es un rastreo distribuido de combinaciones artificiales de filtros (búsqueda por facetas de WooCommerce o PrestaShop). Un caso real medido en nuestros servidores:
Entre 70 y 120 consultas de filtros costosos por minuto, casi siempre desde IPs distintas.
Cada petición puede permanecer ejecutándose entre 10 y 38 segundos.
La cuenta llega a mantener 60-70 procesos PHP simultáneos y a consumir un 300% de CPU.
El tráfico del administrador o las visitas reales no son la causa: son las URLs de filtros inventadas las que consumen todo.
Por qué una mitigación puede romper la web
La mitigación consiste en bloquear ese patrón antes de que ejecute PHP, para que no consuma recursos. El riesgo es que una regla demasiado amplia alcance también a peticiones legítimas y devuelva 403 en:
Los filtros y la búsqueda de la tienda.
Peticiones AJAX del panel de administración.
Plugins o módulos de transporte y pasarelas de pago.
Por eso el bloqueo tiene que ser quirúrgico: dirigido al patrón exacto del ataque, sin bloquear rangos amplios de IP ni buscadores legítimos.
Qué NO debes hacer por tu cuenta
No añadas reglas al .htaccess mientras hay mitigaciones activas del servidor. Sobre un trabajo acumulado de reglas anteriores, una instrucción nueva suele empeorar el diagnóstico y puede provocar bloqueos cruzados.
No desactives reglas existentes para "probar": pierdes la protección y el ataque vuelve en minutos.
Añadir
Disallowen el robots.txt no detiene un ataque: los bots maliciosos lo ignoran. Solo sirve con rastreadores que respetan el estándar.
Qué datos necesitamos si aparece un 403 después de la mitigación
Para localizar la regla concreta y aplicar una excepción sin reabrir el agujero, necesitamos que anotes, para cada error:
URL exacta donde se produce.
Fecha y hora aproximada, indicando la zona horaria.
Acción que estabas realizando (buscar, filtrar, finalizar compra, guardar en el panel…).
Si estabas autenticado o no.
IP pública desde la que accedías.
Captura de la pestaña Network del navegador, si la conservas.
Sin estos datos no es posible reproducir el bloqueo y solo se puede ir a ciegas.
Cómo comprobar que todo funciona tras la mitigación
Cuando te avisemos de que la mitigación está aplicada, haz una revisión completa, no solo de la portada:
Una compra real de principio a fin, incluyendo el transportista y la pasarela de pago que uses.
Las búsquedas y los filtros de producto.
Los plugins o módulos que hayan dado problemas anteriormente.
El panel de administración, especialmente las pantallas con peticiones AJAX.
Resumen
El 503 es saturación y el 403 es bloqueo: no están relacionados entre sí. La mitigación de un ataque de bots es un trabajo fino que puede requerir varios ajustes, y la forma más rápida de afinarla es que nos aportes datos precisos de cada error en lugar de modificar el .htaccess por tu cuenta.