Bots y scrapers que tumban PrestaShop: bloqueo en .htaccess

Entre abril y julio de 2025 varias tiendas del grupo se caían o se arrastraban sin haber tocado nada. En los registros aparecía siempre lo mismo: miles de peticiones de bots de IA y de scrapers. La solución que más se repitió fue un bloqueo por user agent en el .htaccess que compartió Gustavo; quienes lo aplicaron contaron días después que la web volvía a ir fluida.

Qué estaba pasando

Gustavo lo resumió así: tiene clientes con el sistema optimizado al 90 % o más y, cuando llegan los rastreadores de IA a consultar miles de productos, la tienda cae o queda tocada. En las mismas semanas salieron más casos:

• Un servidor que se caía cada poco. Su administrador lo atribuía a «un escaneo de Google», pero el agente era scrapy. Otro compañero lo aclaró: Google no usa ese agente, y una tienda no debería caerse por eso.
• Una tienda en la que el bot de Amazon recorría las URL de los filtros del listado y tenía la base de datos usando casi el 100 % de un núcleo.
• Ataques dirigidos a los filtros de categoría, con varias peticiones por segundo.

Los filtros son el punto débil de PrestaShop frente a los bots: cada combinación es una URL distinta y cada una lanza consultas pesadas. Un bot que no se detiene puede generar cientos de miles.

El bloqueo que se compartió

Va al principio del .htaccess de la raíz, fuera del bloque que escribe PrestaShop, para que no se pierda cuando se regenera al guardar las URL amigables. Esta es una versión abreviada; la lista original tenía una veintena de agentes (Baiduspider, Sogou, serpstatbot, wget…):

BrowserMatchNoCase "Bytespider" bad_bot
BrowserMatchNoCase "scrapy" bad_bot
BrowserMatchNoCase "python-requests" bad_bot
BrowserMatchNoCase "libwww-perl" bad_bot
BrowserMatchNoCase "PetalBot" bad_bot
BrowserMatchNoCase "Amazonbot" bad_bot
BrowserMatchNoCase "SemrushBot" bad_bot
Order Deny,Allow
Deny from env=bad_bot

Order y Deny son la sintaxis de Apache 2.2. En Apache 2.4 funcionan si el servidor tiene activo mod_access_compat, lo habitual en hostings compartidos. Si no lo tiene, las dos últimas líneas se sustituyen por la forma actual:

<RequireAll>
    Require all granted
    Require not env bad_bot
</RequireAll>

Haz una copia del .htaccess antes de tocarlo: un error de sintaxis deja toda la tienda en error 500.

Qué no meter en la lista

• La lista original incluía zh-CN, zh_CN y undefined. Frenan mucho bot, pero también pueden dejar fuera a personas con el navegador en chino. Si vendes fuera de España, piénsalo.
• Nunca pongas Googlebot ni bingbot.
• Los bots de los asistentes de IA (GPTBot, ClaudeBot, el de Perplexity) son una decisión de negocio, no técnica. Otro miembro del grupo lo planteó: una cosa es capar rastreadores raros y otra cerrar la puerta a los asistentes que pueden recomendar tus productos. Si los bloqueas, que sea porque te están tumbando el servidor.

¿Y el robots.txt?

Los bots serios lo respetan; los que hacen daño, no. Gustavo lo dijo claro: scrapy es el que no hace caso. El robots.txt sirve para pedir y el .htaccess, para impedir. Amazon publica las IP de su bot y qué reglas del robots.txt respeta: Amazonbot.

El falso Googlebot

Cualquiera puede escribir «Googlebot» en su agente o alquilar un servidor en Google Cloud, así que ver una IP «de Google» no basta. Google explica cómo comprobarlo: búsqueda DNS inversa de la IP, que en el caso de Googlebot debe terminar en googlebot.com (otros rastreadores de Google usan google.com o googleusercontent.com), y búsqueda directa de ese nombre, que debe devolver la misma IP (verificar Googlebot).

Un compañero avisó de no hacerlo a mano en el .htaccess por rangos de IP: es fácil acabar bloqueando IP reales de Google. Esa verificación es trabajo del firewall del servidor.

Si el problema son los filtros

• Limita las peticiones por IP en el servidor. Un compañero creó una regla en fail2ban que bloquea unas horas a quien pide demasiadas páginas en 60 segundos, y le funcionó.
• Revisa en Search Console las URL con parámetros de filtro. A otro le habían generado dos millones de URL pendientes de indexar.
• Para saber qué agentes te visitan, mira el log de acceso del servidor. Si prefieres registrarlos desde PHP, como propuso Gustavo, guarda el fichero fuera de la carpeta pública y quita el código al terminar.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación