Sobrevivir a la avalancha de ?q=: cómo el tráfico de rastreadores convierte la búsqueda facetada de PrestaShop en un riesgo de DoS

Te despiertas con una cadena de correos de clientes preguntando por qué la tienda estuvo caída a las 3 de la madrugada. El volumen de pedidos es normal, la página de error aparece de forma intermitente y el panel de administración parece correcto. El proveedor de hosting envía una gráfica que muestra las conexiones MySQL clavadas en el límite y todos los workers de PHP-FPM ocupados. Ninguna de esas solicitudes venía de clientes reales.

Una tienda PrestaShop con búsqueda facetada puede estar expuesta a este patrón según sus URLs, el tráfico de rastreadores y su capacidad. La forma del problema es anodina, la causa es estructural y la solución correcta no es la primera a la que recurren la mayoría de propietarios de tienda. En una avalancha de ?q=, el tráfico ordinario de rastreadores puede convertir tu propia búsqueda facetada en una superficie de denegación de servicio autoinfligida. Nuestra lista de comprobación de endurecimiento de seguridad para PrestaShop conecta todas las capas de protección.

Última actualización: junio de 2026.

El síntoma

Los logs muestran miles de solicitudes a URLs como /category-slug?q=Brand-Brand-A/Brand-Brand-B/Color-Red, cada una ligeramente distinta, procedentes de IPs rotativas y de una mezcla de user agents declarados. Algunas dicen ser Bingbot, otras dicen ser Chrome, y otras se identifican como GPTBot, ClaudeBot o PerplexityBot. La URL de categoría en sí es legítima: es tu propia búsqueda facetada exponiendo filtros de marca y atributos como parámetros de query string. Lo que no es legítimo es el volumen ni la diversidad combinatoria de las solicitudes.

Los foros de PrestaShop han ido reuniendo informes de este patrón de propietarios de tiendas que ejecutan 1.7.x y 8.x durante 2024 y 2025. La forma es coherente: un solo hilo documenta a propietarios viendo cómo se rastrean decenas de miles de URLs ?q= únicas al día, con el controlador respondiendo incluso después de desactivar el módulo ps_facetedsearch.

El primer intento suele ser desactivar el módulo de búsqueda facetada. Eso puede reducir el trabajo de filtrado, pero no detiene las peticiones a URLs conocidas. ps_facetedsearch proporciona la interfaz y la lógica de los filtros; una solicitud GET a /category-slug?q=anything todavía puede arrancar PrestaShop y llegar al controlador de categoría tras desactivarlo. La barra de filtros desaparece, pero los clientes automatizados pueden seguir solicitando las URLs que ya descubrieron.

Por qué el volumen está creciendo

La naturaleza combinatoria de las URLs de búsqueda facetada existe desde que se lanzó el módulo. Lo nuevo es la escala del tráfico automatizado que las encuentra y las rastrea.

El análisis de julio de 2025 de Cloudflare sobre tráfico de rastreadores en su red informó de lo siguiente:

• El tráfico de rastreadores subió un 18% interanual, con picos del 32% en abril de 2025.
• Googlebot: crecimiento del 96%, pasando de aproximadamente el 30% al 50% de todo el tráfico de rastreo.
• GPTBot: crecimiento del 305%, del 2,2% al 7,7% de cuota.
• PerplexityBot: de prácticamente cero a una presencia significativa en un solo año.
• ClaudeBot: descenso del 46% en solicitudes tras los cambios de principios de 2025.
• Bytespider: descenso del 85%.

La composición cambia mes a mes, pero la tendencia no: más rastreadores, golpeando más URLs, con más frecuencia. Una página de categoría que genera unos cientos de combinaciones de filtros se convierte en objetivo de todo, desde Googlebot construyendo índices de datos estructurados hasta scrapers de entrenamiento de IA recopilando atributos de producto. La propia Cloudflare empezó a bloquear por defecto los bots de entrenamiento de IA en las zonas nuevas a mediados de 2025, lo que deja claro cómo interpreta la plataforma la trayectoria.

Sobre ese tráfico legítimo de rastreadores se superpone una capa mucho más pequeña pero más agresiva de automatización hostil: scrapers, bots de inteligencia competitiva y tráfico de pruebas de estrés. Estos no respetan robots.txt, rotan IPs de forma agresiva y falsifican cadenas de user-agent legítimas. Pueden sobrecargar la tienda, aunque los rastreadores legítimos también pueden generar una carga excesiva. Detener esa clase más amplia de automatización no deseada, no solo la avalancha de ?q=, es una disciplina propia; cubrimos el enfoque general en bloquear bots malos y tráfico no deseado.

Por qué las soluciones obvias no funcionan

La mayor parte de los consejos en los foros de la comunidad cae en uno de cinco grupos. Ninguno basta por sí solo.

Desactivar el módulo de búsqueda facetada. Elimina la interfaz, deja la superficie de URL. El controlador de categoría sigue respondiendo a solicitudes ?q=.

Añadir Disallow: /*?q= a robots.txt. Googlebot lo respeta en gran medida. Bingbot lo respeta de forma irregular: hay informes públicos de que rastrea patrones de consulta desautorizados de todos modos. Los rastreadores de IA respetan robots.txt en grados muy distintos según el operador. Los scrapers hostiles lo ignoran por completo. Merece la pena hacerlo, pero nunca es suficiente.

Un bloqueo general en .htaccess sobre cualquier URL que contenga ?q=. Esto atrapa a los bots, pero también rompe tus propias solicitudes AJAX de filtros (el mismo patrón de URL que usa la tienda para obtener resultados de filtro sin recargar la página) y rompe todas las URLs de filtros guardadas o compartidas por clientes reales. El daño SEO se agrava si Google había indexado alguna de esas páginas de filtro como canónica para consultas de larga cola. Sí hay lugar para reglas de servidor ajustadas a mano, pero no para un mazazo; nuestras reglas de seguridad y rendimiento .htaccess para PrestaShop cubren las que merece la pena conservar.

Bloquear user-agents de bots concretos. Es jugar al gato y al ratón. Aparecen bots nuevos cada semana, los bots hostiles falsifican cadenas UA y también bloquearías los referentes legítimos de IA (ChatGPT, Perplexity, Copilot) que ya generan una parte creciente de los clics entrantes. La relación rastreo-clic sigue siendo pobre para los bots de IA, pero no es cero: los propios datos de Cloudflare muestran que existen referencias.

Caché de página completa para URLs ?q=. Cuando los rastreadores piden muchas combinaciones distintas y apenas las reutilizan, la tasa de acierto puede ser baja. Guardar cada URL nueva puede añadir escrituras sin ahorrar mucho trabajo al origen. Mide la reutilización y el comportamiento de la caché antes de confiar en esta defensa.

La opción restante, y a la que dedicamos el resto de esta publicación, es poner la decisión de quién puede llegar a esas URLs completamente delante de PrestaShop, donde puede tomarse de forma barata y sin arrancar PHP.

La solución correcta: un Managed Challenge de Cloudflare sobre la forma de búsqueda facetada

Managed Challenge de Cloudflare puede ayudar: evalúa las solicitudes coincidentes antes de PrestaShop y no requiere una lista de nombres de bots. Algunos navegadores pasan sin interacción; otros reciben un desafío interactivo o no lo superan. Una excepción para X-Requested-With: XMLHttpRequest puede preservar los filtros AJAX, pero esta cabecera es trivialmente falsificable y no demuestra que la solicitud proceda de la interfaz de tu tienda.

Usa una regla personalizada para solicitudes GET con q, añadiendo la condición de puntuación solo si tu suscripción incluye Bot Management. Un plan de pago por sí solo no da acceso a cf.bot_management.score. Antes de activar cualquiera de las variantes siguientes, prueba las rutas reales de categoría y todos los demás usos de q. Añade una condición and que limite la regla a rutas confirmadas de categorías con filtros cuando otras rutas compartan el parámetro. Para la primera prueba, selecciona un conjunto pequeño y explícito de esas rutas. Ten en cuenta la ruta base de la tienda, los prefijos de idioma y las rutas de módulos/API localizadas o personalizadas; las exclusiones /module/ y /api/ solo cubren esas rutas en la raíz.

Si tu suscripción incluye Bot Management

Excluye los bots verificados dentro de esta regla. Mantén not cf.client.bot en la regla específica de q. No omitas globalmente todas las reglas personalizadas posteriores: las demás protecciones deben seguir aplicándose a los rastreadores verificados. cf.client.bot es una clasificación de Cloudflare, no un bloqueo de seguridad ni una garantía de que un rastreador no sobrecargue la tienda.

Desafía la automatización probable en las rutas facetadas confirmadas. Combina el ámbito de rutas descrito arriba con estas condiciones lógicas:

• http.request.method eq "GET"
• y len(http.request.uri.args["q"]) >= 0: la solicitud lleva un parámetro q
• y not cf.client.bot: no es un rastreador verificado
• y not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest"): la solicitud no lleva este marcador AJAX falsificable
• y not starts_with(http.request.uri.path, "/module/")
• y not starts_with(http.request.uri.path, "/api/")
• y cf.bot_management.score gt 1 and cf.bot_management.score lt 30: el intervalo de puntuaciones bajas elegido aquí para detectar automatización probable

Acción: Managed Challenge. La regla selecciona las GET con q de las rutas elegidas, exceptuando bots verificados, solicitudes con el marcador AJAX y rutas de módulos/API identificadas en la tienda. Con Bot Management también debe coincidir el intervalo de puntuación. Las solicitudes que superen el desafío o queden fuera de la regla todavía pueden llegar al origen: no se detiene toda la automatización.

Para cf.bot_management.score eq 1 puedes añadir una regla antes de la regla de desafío. Conserva el mismo ámbito de categorías, las condiciones GET con q y las excepciones de bots verificados, AJAX, módulos y API. La puntuación 1 es la clasificación de automatización más fuerte de Cloudflare, no una prueba de intención maliciosa. Prueba Managed Challenge o, si los falsos positivos son aceptables, Block, antes de ampliar el ámbito.

Sin Bot Management (también Free y Pro)

Free y Pro admiten reglas personalizadas y Managed Challenge, pero no expresiones regulares ni la acción Log de estas reglas. Business admite regex, pero no Log; Enterprise admite ambos. Consulta la disponibilidad por plan y los requisitos de los operadores de Cloudflare. Estas condiciones comunes no usan regex ni presuponen un prefijo de URL de categoría. Combínalas con el ámbito de rutas reales descrito arriba antes de activarlas:

http.request.method eq "GET"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")
and not starts_with(http.request.uri.path, "/module/")
and not starts_with(http.request.uri.path, "/api/")

Sin la habilitación de Bot Management, no uses cf.bot_management.score. El antiguo campo cf.threat_score recomendado por algunas guías está fijado permanentemente en 0 y no distingue solicitudes de riesgo.

len(http.request.uri.args["q"]) >= 0 es una comprobación válida de presencia: una clave ausente en el mapa hace que la comparación se evalúe como false en el lenguaje de Cloudflare. Consulta el comportamiento documentado de los valores ausentes. Eso no demuestra que q sea un filtro. Prueba valores vacíos y con contenido, URLs de búsqueda y rutas de módulos/API localizadas o personalizadas. Los filtros codificados en una ruta reescrita necesitan una condición aparte basada en las rutas reales de la tienda.

Usa Managed Challenge para el tráfico coincidente después de las comprobaciones siguientes. La URL filtrada queda intacta, pero los clientes deben poder superar cualquier desafío requerido. No se garantiza un paso con un clic ni un número fijo de viajes de ida y vuelta. Prueba marcadores y enlaces compartidos en navegadores reales, también móviles, y el filtrado AJAX: una página de desafío devuelta a una solicitud AJAX puede romper la interfaz. Los bots verificados, las solicitudes con marcador AJAX y los clientes que superan el desafío pueden seguir generando carga en el origen.

Advertencias importantes antes de activar nada de esto

Prueba con las herramientas disponibles en tu plan. En Enterprise puedes usar Log durante 24–48 horas y revisar los eventos antes de activar Managed Challenge. Free, Pro y Business no ofrecen la acción Log de las reglas personalizadas: revisa primero los datos disponibles en Security Analytics y los registros de solicitudes; después prueba Managed Challenge de forma controlada en unas pocas rutas de categoría confirmadas y monitoriza Security Events. Comprueba también las solicitudes legítimas de búsqueda, módulos/API, sitemaps y herramientas de analítica. Amplía la regla solo tras revisar falsos positivos y comportamiento de los navegadores. El detalle de analítica y registros depende del plan; consulta la tabla de disponibilidad de Cloudflare.

La excepción X-Requested-With preserva la UX, pero no es una barrera de seguridad. Cualquier cliente HTTP puede enviar la cabecera y eludir esta regla, incluida su condición de puntuación. Los clientes AJAX que omiten la cabecera no quedan exentos. cf.client.bot clasifica bots verificados y la puntuación estima automatización; ninguno bloquea nada por sí solo. Mantén las demás protecciones y vigila la carga del tráfico excluido, incluidos los rastreadores verificados.

Proxy en todos los hostnames web públicos (nube naranja), pero gestiona correctamente el correo y los registros no HTTP. Los registros Mail/MX y otros no HTTP, por lo general, no deben proxificarse a través de Cloudflare, y el proxy de nube naranja no puede proteger servicios no HTTP de la misma manera. El riesgo real es cualquier registro solo DNS (nube gris), ya sea mail, dev o un subdominio de administración, que resuelva al mismo servidor que la tienda, porque eso filtra la IP de origen web. Quien encuentre el origen puede saltarse Cloudflare por completo y golpear PrestaShop directamente. Mantén correo y otros registros no HTTP como solo DNS, pero asegúrate de que no apunten ni revelen la IP de origen web: mueve mail, dev y admin a IPs separadas, o restríngelos. Audita tu panel DNS antes de confiar en el WAF.

Restringe el origen a las IPs de Cloudflare. Incluso con todo proxificado, bloquea de forma estricta el origen en el firewall para aceptar HTTP/HTTPS solo desde los rangos de IP publicados por Cloudflare. De lo contrario, un atacante que conozca la IP de origen por historiales DNS antiguos puede golpearla directamente. Mientras restringes el acceso al origen, asegúrate de que ese origen sea solo HTTPS de extremo a extremo: nuestra guía sobre configurar SSL y HTTPS en PrestaShop cubre la parte de certificados y redirecciones para que el edge y el origen estén alineados.

Si dependes de referencias desde búsquedas con IA, vigila el impacto. Algunos rastreadores de IA ayudan a los servicios a descubrir páginas que después podrán enlazar. Desafiar sus solicitudes puede afectar al descubrimiento y posiblemente a las referencias, según los rastreadores y rutas realmente incluidos. Revisa la analítica tras una semana y compara las visitas útiles con la carga ahorrada al origen; el equilibrio varía según la tienda.

La alternativa de respaldo: un override del Dispatcher

Si Cloudflare no está disponible hoy, una alternativa en PHP es un override del Dispatcher que redirija determinadas solicitudes de categoría ?q= no AJAX a la misma categoría sin filtro. Limítalo a rutas confirmadas de categorías con filtros: eliminar q en todo el sitio también descartaría parámetros de búsqueda o de módulos/API.

El punto de extensión es override/classes/Dispatcher.php, con una clase que extiende DispatcherCore y sobrescribe dispatch(). Primero resuelve o identifica explícitamente una ruta de categoría de la tienda e idioma actuales. Procesa solo solicitudes GET con una clave q en la cadena de consulta analizada y sin el marcador AJAX probado (HTTP_X_REQUESTED_WITH, comparado sin distinguir mayúsculas y minúsculas). Excluye búsqueda y todas las rutas de módulos/API. Analiza $_SERVER['REQUEST_URI'], elimina solo q y reconstruye la consulta con http_build_query(), conservando los demás parámetros. El destino debe mantener ruta de categoría, ruta base de la tienda y prefijo de idioma, usando el origen configurado de la tienda; Tools::getShopDomainSsl(true) por sí solo no aporta un subdirectorio de tienda. Evita bucles de redirección. Envía la respuesta Location elegida y ejecuta exit; en los demás casos, llama a parent::dispatch().

En las rutas de categoría seleccionadas, una 301 elimina permanentemente el filtro de los enlaces directos. Úsala solo si esas URLs deben resolver de forma permanente a la categoría sin filtrar. Prueba primero una redirección temporal antes de aplicar una permanente que pueda almacenarse en caché. Las solicitudes con marcador AJAX siguen exentas, incluidos los bots que lo copian: comprueba los filtros del tema real. Revisa los overrides existentes y la compatibilidad de módulos, y limpia la caché del índice de clases tras instalarlo. Esto reduce el trabajo de las solicitudes coincidentes, sin eliminar el arranque de PHP ni proteger todos los endpoints.

Tres compromisos que debes entender antes de desplegar esto:

• Impacto SEO. Redirigir una URL filtrada a una categoría sin filtrar cambia el destino y puede afectar al posicionamiento en consultas de larga cola. Revisa Search Console antes de desplegarlo. Conserva las páginas de filtros valiosas o asígnalas explícitamente a páginas de destino pertinentes; no supongas que todas las URLs facetadas tienen poco valor en buscadores.
• Marcadores y enlaces compartidos. Dentro del ámbito de redirección, los enlaces guardados pierden la vista filtrada. La regla Cloudflare conserva la URL si el visitante supera el desafío requerido; añadir una redirección elimina el filtro de todos modos.
• Solo ayuda con la carga del lado PHP. La solicitud sigue llegando a PHP: simplemente sale rápido con un 301 en lugar de ejecutar la página de categoría completa. Si tu cuello de botella es el número de conexiones más que la CPU, esto ayuda menos que la solución en el edge.

Despliégalo como medida temporal. Pasa a Cloudflare en cuanto puedas.

Edge frente a origen: qué solución para cada cuello de botella

Las dos defensas no son intercambiables. Elige según dónde esté sufriendo realmente tu tienda.

Combina las defensas solo si es aceptable perder la vista filtrada en los enlaces directos seleccionados. El override sigue redirigiendo aunque Cloudflare deje pasar al visitante y no sustituye la protección frente a todo el tráfico que llega al origen.

El ángulo arquitectónico: sustituir la propia superficie de URL

Las páginas de filtros indexables deben ser URLs deliberadas, no combinaciones accidentales de rastreadores.

Ambas medidas pueden reducir el tráfico no deseado en la superficie de URLs existente de ps_facetedsearch. Ninguna cambia el amplio espacio público de combinaciones de filtros que expone el módulo.

Una clase distinta de módulo de filtros evita el problema en origen: el estado del filtro vive en el lado del cliente (o en un único AJAX POST), la URL pública se mantiene limpia y solo las páginas de destino SEO creadas deliberadamente, una página hecha a mano para "zapatillas de running para hombre" en lugar de cada combinación de marca-color-talla, se vuelven indexables. Construimos Filter Revolution con ese enfoque, en parte como respuesta a exactamente los patrones de tráfico descritos aquí. Entonces, ¿qué significa eso para ti? Reduce la superficie pública de URLs de alta cardinalidad que hace atractivo ps_facetedsearch para los rastreadores, lo que significa menos páginas combinatorias que los bots puedan descubrir y posiblemente menos carga de rastreadores, configurado desde el back office y sin bifurcar tu tema. No es un escudo mágico contra los rastreadores de IA, nada lo es, y no desindexa retroactivamente las URLs que Google y Bing ya encontraron. Puede reducir el descubrimiento de nuevas combinaciones de filtros, pero las URLs conocidas y los endpoints AJAX siguen necesitando controles de tráfico adecuados.

Si tienes prevista una revisión de la búsqueda facetada, considera sustituir el módulo. Si el actual encaja en la tienda, mantén la regla Cloudflare y revísala cuando cambien las rutas, el comportamiento AJAX o el tráfico.

Una última cosa: los carritos vacíos

En el núcleo de PrestaShop, una GET a una página de categoría no crea automáticamente una fila ps_cart para cada visitante. La persistencia del carrito depende del flujo de la solicitud, del tema y de los módulos, y de si crean o guardan un carrito. Si la automatización activa ese comportamiento, pueden acumularse carritos vacíos, ralentizar los listados administrativos o distorsionar los flujos de recuperación de carritos abandonados. Confirma la causa en tu tienda antes de atribuir cada carrito anónimo a un bot.

Una regla eficaz en el edge puede reducir nuevos carritos de bots procedentes del tráfico interceptado; no garantiza que se detenga todo el crecimiento ni limpia filas existentes. Revisa las herramientas de limpieza instaladas y la política de conservación. Ocultar de contadores y listados los carritos cuyo origen bot esté confirmado puede mejorar la usabilidad y conservar datos para investigar. Un carrito anónimo o vacío no prueba por sí solo un origen automatizado. Si hace falta borrar datos, usa copias de seguridad y una limpieza controlada que proteja carritos legítimos y referencias a pedidos. Es una tarea aparte que acompaña a los controles del tráfico.

Dónde encaja esto en tus defensas más amplias

La avalancha de ?q= es un modo de fallo concreto, pero el plano de control que construyes para detenerla se amortiza en el resto de tu postura de seguridad. Algunas tareas adyacentes que merece la pena alinear una vez instalada la regla en el edge:

• Bloqueo por visitante y baneos de IP. Cuando una sola fuente sigue tanteando después del desafío, necesitas una forma limpia de cortarla y de ver quién te está golpeando: consulta información adicional del cliente y baneos de IP.
• Spam de formularios, separado de las avalanchas de tráfico. La misma automatización que rastrea facetas también machacará tus formularios de contacto y registro; ahí la respuesta es un desafío al enviar: consulta reCAPTCHA para PrestaShop.
• Si todavía no puedes actualizar el core. Las tiendas atrapadas en un PrestaShop antiguo tienen menos palancas nativas; el enfoque edge-y-override de aquí forma parte de una estrategia más amplia de parcheo virtual en endurecimiento avanzado para tiendas que todavía no puedes actualizar.
• Si todo esto es nuevo para ti. Si la terminología anterior pesa, empieza por la guía en lenguaje claro para propietarios de tienda y avanza desde ahí.

Preguntas frecuentes

¿Por qué desactivar el módulo de búsqueda facetada no detiene la avalancha de ?q=?

Desactivar ps_facetedsearch retira la interfaz y puede reducir los cálculos de filtrado, pero URLs conocidas como /category-slug?q=anything aún pueden arrancar PrestaShop y llegar al controlador de categoría. Los clientes automatizados pueden seguir solicitándolas.

¿Disallow en robots.txt arregla la avalancha de ?q=?

Ayuda, pero nunca basta por sí solo. Disallow bloquea el rastreo, no la indexación, y lo más importante: solo lo obedecen los rastreadores bien comportados. Googlebot lo respeta en gran medida, Bingbot lo respeta de forma irregular, los rastreadores de IA varían según el operador y los scrapers hostiles lo ignoran por completo. El tráfico que ignora robots.txt necesita controles separados; incluso los rastreadores que lo respetan pueden sobrecargar URLs permitidas. Merece la pena hacerlo, pero nunca es toda la respuesta. La inclusión en el sitemap depende del módulo de sitemap y de su configuración o política de URLs, no solo de la versión del núcleo de PrestaShop. Excluir URLs facetadas no deseadas puede reducir su descubrimiento, pero no detiene las solicitudes a URLs conocidas.

¿Por qué no bloquear sin más cualquier URL que contenga ?q= en .htaccess?

Un bloqueo global también afecta a filtros AJAX legítimos, URLs de filtro guardadas y otros usos de q, como búsqueda o API. Una regla Managed Challenge delimitada puede reducir el tráfico no deseado conservando las URLs. Sus excepciones de bots verificados y marcador AJAX dejan parte de la automatización fuera de la regla: prueba las solicitudes reales de filtros y vigila la carga restante en el origen.

¿Cuál es la solución más rápida si hoy no puedo desplegar Cloudflare?

Un override/classes/Dispatcher.php probado puede redirigir GET no AJAX con q en rutas de categorías con filtros identificadas explícitamente. Conserva la ruta base de la tienda, el prefijo de idioma y los demás parámetros; excluye búsqueda y rutas de módulos/API. Revisa la compatibilidad de overrides y limpia la caché del índice de clases. Usa 301 solo si la pérdida permanente de esas URLs filtradas es intencionada. PHP sigue arrancando y los bots pueden imitar la excepción AJAX: es una medida temporal delimitada, no una protección completa contra la avalancha.

¿Por qué esta avalancha también llena mi tabla de carritos con miles de carritos vacíos?

Puede ocurrir si el tema, los módulos o el flujo de la solicitud crean y guardan carritos durante visitas automatizadas. Una GET de categoría por sí sola no crea en el núcleo de PrestaShop una fila ps_cart para cada visitante. Identifica el componente que guarda los carritos. El filtrado en el edge puede reducir el tráfico pertinente, pero las filas no deseadas existentes necesitan una limpieza separada y controlada. Los carritos anónimos no son automáticamente carritos de bots.

Deja de envolver el problema: reduce la superficie

Tanto las soluciones de Cloudflare como las de Dispatcher protegen la superficie de URL de alta cardinalidad existente; no la eliminan. Filter Revolution mantiene el estado del filtro en el lado del cliente para que la URL pública siga limpia y solo las páginas de destino SEO creadas deliberadamente sean indexables: menos páginas combinatorias para que los rastreadores descubran desde el principio. Junto a la regla en el edge, Cleanup Revolution recorta la contaminación de carritos de bots y Security Revolution cubre el endurecimiento más amplio del que esta avalancha es solo una esquina.

Lista rápida de comprobación

• Activa Cloudflare para el dominio. Proxifica todos los hostnames web públicos (nube naranja); mantén correo y otros registros no HTTP como solo DNS y asegúrate de que no apunten ni revelen la IP de origen web.
• Crea la regla q delimitada con not cf.client.bot dentro de ella. Enterprise: observa con Log durante 24–48 horas. Free/Pro/Business: revisa Security Analytics y los registros disponibles, después prueba Managed Challenge en unas pocas rutas de categoría confirmadas y monitoriza Security Events.
• Prueba las URLs reales de categoría, otros usos de q, rutas de módulos/API localizadas o personalizadas, y AJAX y marcadores en navegadores reales. Confirma el acceso esperado de rastreadores y mide el tráfico que todavía alcanza el origen.
• Tras revisar falsos positivos, Enterprise puede pasar de Log a Managed Challenge; en Free/Pro/Business amplía la prueba controlada solo a rutas validadas. Sigue monitorizando Security Events y carga en el origen.
• Restringe el firewall de origen a los rangos de IP de Cloudflare. Esto es lo que cierra el circuito.
• Si Cloudflare no está disponible, prueba un override del Dispatcher limitado a categorías que conserve la ruta base de la tienda y los demás parámetros, y planifica la migración.
• Si tienes pendiente rehacer el módulo de filtros, evalúa sustituir ps_facetedsearch por completo.
• Limpia por separado la contaminación de carritos en el back office para que la administración de carritos siga siendo usable.

Cierre

Las combinaciones de URLs facetadas pueden crear un riesgo de DoS cuando el volumen de rastreadores supera la capacidad de la tienda. El riesgo depende del módulo instalado, las rutas expuestas, el tráfico y los recursos; no es inevitable en todas las instalaciones PrestaShop. Examina las solicitudes reales y elige controles que preserven el uso legítimo.

Una regla personalizada sin puntuación de bots está disponible en Cloudflare Free, pero el análisis de rutas, las pruebas de navegador y la monitorización continua siguen requiriendo trabajo. Un WAF ajustado y un origen con acceso restringido proporcionan una base para otras defensas; credential stuffing, scraping y falsos procesos de compra necesitan controles propios.

Para el enfoque completo por capas, vuelve a la lista de comprobación de endurecimiento de seguridad para PrestaShop. Para ver qué ocurre cuando una tienda queda comprometida por algo más sofisticado que abuso de rastreadores, consulta la anatomía de un ataque de estilo Magecart en una tienda PrestaShop 1.7.x. La guía defensiva tiene la misma forma en ambos casos: controles baratos en el edge, excepciones estrechas donde tengas que hacerlas y absolutamente ninguna afirmación de seguridad que descanse en cadenas de user-agent.