Bots y búsqueda por facetas en PrestaShop: CPU al 100 % y caídas

Sábado por la tarde. Te llega un correo del hosting avisando de que tu cuenta lleva horas al 100 % de CPU. Entras a las estadísticas esperando una avalancha de clientes y te encuentras lo contrario: cuarenta mil páginas vistas y cero pedidos.

No es un ataque, ni un módulo roto, ni tu tienda haciendo cosas raras. Es que alguien se ha puesto a recorrer, uno por uno, todos los filtros de tu catálogo.

Qué está pasando exactamente

Tu tienda tiene búsqueda por filtros: talla, color, marca, precio, disponibilidad, y encima el orden de los resultados. Es lo que la hace cómoda de usar.

El problema es que cada combinación de esos filtros es una dirección web distinta. Talla M en azul de una marca ordenado por precio es una. Talla M en azul de esa marca ordenado por novedad es otra. Y así con todas las combinaciones posibles: en una tienda de tamaño medio salen cientos de miles; en una grande, millones.

Los rastreadores de las redes sociales y de los servicios de inteligencia artificial —los de Facebook, los de TikTok, los de media docena de empresas que ni conoces— han decidido que tienen que verlas todas. Y las piden todas, a la vez, sin pausa.

Cada una de esas direcciones no es una página que tengas guardada: es una búsqueda nueva contra tu base de datos.

El módulo que hay detrás: Búsqueda por facetas de PrestaShop

Los filtros de tu tienda los pinta un módulo concreto, Búsqueda por facetas (ps_facetedsearch), el que viene de serie en PrestaShop desde la 1.7 y que sustituyó a la antigua Navegación por capas. Si tienes filtros en las categorías, lo tienes activo.

Reconocerlo en tus registros es fácil: cada combinación viaja en el parámetro q de la dirección, con esta pinta.

/12-camisetas?q=Talla-M/Color-Azul/Marca-Adidas

Si al abrir el registro de accesos ves miles de líneas con ?q=, todas distintas y seguidas, ya sabes qué te está comiendo la máquina.

Y aquí está el porqué de que sea tan caro. Cuando llega una de esas peticiones, el módulo no solo busca los productos que cumplen el filtro: además recalcula los contadores de todos los demás filtros —ese «Azul (12)», «Verde (5)» que ves junto a cada casilla— y para eso lanza varias consultas de recuento sobre sus tablas de índice. Multiplícalo por un catálogo grande y por miles de peticiones por minuto.

Dos palancas que están en el propio módulo y que casi nadie toca, en Catálogo → Búsqueda por facetas:

• Quitar el número de productos junto a cada filtro. Es la parte más cara de cada petición y, en la mayoría de las tiendas, la que menos se echa de menos.
• Revisar las plantillas de filtros por categoría. Cada filtro que dejas puesto multiplica las combinaciones posibles. Ocho filtros en una categoría no son ocho direcciones: son miles.

Ninguna de las dos arregla el problema por sí sola, pero las dos bajan el coste de cada golpe antes de tocar nada más.

Por qué duele tanto

Una búsqueda con filtros es de las operaciones más caras que hace una tienda: tiene que mirar todo el catálogo, cruzar atributos, contar cuántos productos quedan en cada filtro y ordenar el resultado. Un cliente hace tres o cuatro en toda su visita. Un rastreador hace tres o cuatro por segundo.

Y aquí está la parte que descoloca a todo el mundo: la caché no te salva. Guardar en caché sirve cuando muchos visitantes piden lo mismo. Aquí no se repite ninguna: cada combinación es única, así que todas son «primera visita» y todas van a la base de datos.

El resultado es siempre el mismo. Las peticiones se amontonan, el servidor se queda sin sitio y la tienda deja de responder — para el robot y para el cliente que estaba a punto de pagar. Si además te llega en plena campaña, has pagado la publicidad de una web que no abría.

Cómo saber si es tu caso

Cuatro señales, y con dos que se te junten ya casi es seguro:

• Consumo alto sin ventas. Muchísimas páginas vistas, ningún carrito. Las visitas no cuadran con los pedidos ni de lejos.
• El hosting te avisa de que consumes demasiado, o te suspende la cuenta un rato «para proteger al resto de clientes».
• Se cae a horas raras: de madrugada, un domingo, ratos sueltos sin patrón comercial ninguno.
• En el registro de accesos hay miles de direcciones seguidas con parámetros de filtro, todas distintas, pedidas en segundos.

Si el panel de administración también va lento mientras pasa, tienes la confirmación: no es la parte pública, es que la máquina está saturada. Lo contábamos en cuándo la lentitud es de la tienda y cuándo del servidor.

Lo que te van a proponer, y por qué se queda corto

Este problema tiene un montón de soluciones populares que en la práctica no aguantan:

1. «Bloquéalos en el archivo robots.txt». Ese archivo es una petición educada, no una puerta. Los rastreadores que lo respetan ya no son tu problema; los que te están tumbando ni lo leen. Y si te pasas de frenada, el que sí obedece es Google, y te borras de los resultados tú solo.
2. «Bloquea a Facebook y a TikTok por su nombre». Funciona una semana. Cambian de identidad, entran desde miles de direcciones distintas y aparecen tres nuevos cada mes. Es una lista que nunca terminas de mantener.
3. «Márcalas como no indexables y listo». Que una página lleve la etiqueta de no indexar no evita el gasto: el robot tiene que pedirla igual para poder leer esa etiqueta. Sirve para el buscador, no para tu CPU.
4. «Amplía el servidor». Pagar el doble para servirle gratis el catálogo a un robot es un mal negocio: el pico siguiente será mayor, porque cuanto mejor respondes, más rápido te piden.
5. «Quita la búsqueda por filtros». Resuelve el consumo y te carga la tienda: los filtros son la forma en la que la gente encuentra lo que va a comprar. Se nota en la conversión al día siguiente.
6. «Ponle un CDN delante y listo». Un CDN acelera lo que se repite. Aquí no se repite nada: cada combinación es única y acaba llegando igual a tu base de datos.
7. «Activa el modo bajo ataque». O se lo pones difícil también a tus clientes —y a Google— o los robots siguen pasando. Sirve para aguantar una tarde, no para vivir así.

Todas comparten el mismo defecto: tratan el síntoma, que es el tráfico, en lugar de la causa, que es que tu tienda esté dispuesta a fabricar millones de páginas distintas a quien se las pida.

Por dónde va la solución de verdad

Lo que sí aguanta se monta en tres capas, y ninguna consiste en apagar los filtros:

• Decidir qué combinaciones existen. De todas las que tu tienda podría generar, solo un puñado tienen sentido para un cliente o para Google. El resto no necesitan ser direcciones propias, y dejar de serlo reduce el terreno de juego de millones a unos miles.
• Que lo caro no llegue abajo. Las peticiones que son ruido se responden antes de tocar la base de datos, y se limita cuántas búsquedas por minuto puede lanzar un mismo origen. Un cliente hace tres; quien hace trescientas no es un cliente, y da igual cómo se llame.
• Separar quién compite por los recursos. El rastreo nunca debería pelearse por la misma CPU que el checkout de alguien que está pagando. Bien montado, el robot puede esperar; el cliente no.

Con eso, lo normal es que el consumo baje de golpe el primer día y que la tienda deje de caerse, sin tocar ni un filtro de cara al cliente y sin perder posiciones en Google. Al revés: cuando dejas de gastarle a Google su tiempo en cuatrocientas mil páginas repetidas, empieza a mirar las que te interesan — que es justo lo que contábamos en por dónde empezar cuando no apareces.

Si llevas meses peleándote con esto

Es un problema desagradable porque no da la cara: no hay un error que mirar, solo una tienda que unos días va y otros no, y un hosting que te echa la culpa a ti.

Si has probado ya un par de las soluciones de la lista y sigues igual, escríbenos. Miramos tus registros, te decimos cuántas de esas peticiones son reales y cuántas son ruido, y te dejamos el filtrado montado y midiendo. Lo hemos hecho unas cuantas veces y el primer día ya se nota.

Cuéntanos tu caso