Visitor Control: bloquear bots maliciosos y tráfico no deseado

Abre el back office de PrestaShop, ve a Estadísticas → Visitantes online en una tarde tranquila y quizá veas más "visitantes" que clientes reales. Una parte importante del tráfico de cualquier tienda está automatizada: rastreadores, scrapers, scripts y sondas que no tienen ninguna intención de comprar. Parte de esa automatización es vital para tu negocio: Googlebot tiene que rastrearte para poder posicionarte. El resto te cuesta dinero. Consume CPU y ancho de banda de tu alojamiento, llena tus tablas de carrito con basura, distorsiona cada métrica de conversión que informes y, en el caso de los ataques de relleno de credenciales y los escáneres de vulnerabilidades, es el primer movimiento de un ataque real. Esta guía trata de distinguir esas dos poblaciones en una tienda PrestaShop, detectar la mala en tus propios logs y en tu base de datos, y dejarla fuera sin bloquear por accidente a Google ni a un cliente real.

Este es el capítulo sobre bots y automatización dentro de nuestro bloque de seguridad. Se mantiene deliberadamente en su terreno: bloquear por IP a personas problemáticas concretas se cubre en Customer Extra Info and IP Bans; detener el spam de formularios con un reto se explica en reCAPTCHA for PrestaShop; la sobrecarga específica de la búsqueda facetada provocada por rastreadores tiene su análisis en profundidad en cómo sobrevivir a la avalancha de ?q=; y las reglas del servidor web están en reglas de seguridad .htaccess para PrestaShop. Para entender dónde encaja el filtrado de bots en el panorama general, empieza por la lista completa de refuerzo de seguridad.

Revisado en junio de 2026 según el comportamiento actual de Estadísticas y SQL Manager en PrestaShop, y la guía de verificar Googlebot mediante DNS inverso que sigue vigente.

No todos los bots son el enemigo, y bloquear los equivocados perjudica

El error más caro que cometen los comerciantes al bloquear bots es bloquear demasiado. Prohíbe Googlebot en un arrebato de "paremos los bots" y no tendrás una tienda más segura: tendrás una tienda que desaparece de las búsquedas. Así que la primera tarea es una taxonomía clara, porque tus reglas de bloqueo tratarán a estos dos grupos de formas opuestas.

Fíjate en la consecuencia: un instrumento tosco que bloquea "bots" solo por reputación es peligroso, porque las listas buena y mala se solapan en las mismas técnicas. Un filtrado eficaz trata de identidad y comportamiento, no de un único interruptor de encendido/apagado.

Cómo detectar tráfico de bots maliciosos dentro de PrestaShop

No necesitas un panel externo para ver el problema: PrestaShop ya registra la mayor parte, y tu alojamiento registra el resto. Tres lugares donde mirar, en orden de esfuerzo.

1. Las estadísticas del back office (la comprobación de dos minutos)

En Estadísticas, los paneles Origen de los visitantes, Páginas no encontradas y Páginas más vistas dan señales discretas. Una avalancha de 404 en rutas que tu tienda nunca tuvo (/wp-login.php, /.env, /administrator/) es un escáner de vulnerabilidades recorriendo una lista genérica de exploits: ni siquiera son rutas de PrestaShop, y precisamente por eso sabes que es un bot indiscriminado. Una "página más vista" que de repente es tu página de inicio de sesión o de recuperación de contraseña, y no un producto, es una firma de relleno de credenciales.

2. La base de datos (los números honestos)

PrestaShop registra sesiones en ps_connections y ps_guest. Ten en cuenta que ps_guest guarda atributos analizados del navegador y del sistema operativo (navegador, versión, sistema operativo, resolución de pantalla) en lugar de una cadena User-Agent sin procesar: no existe una columna http_user_agent en PrestaShop estándar, así que no esperes leer el agente literal desde la base de datos. Lo que las tablas sí te dan es el volumen de solicitudes por IP, suficiente para sacar a la luz una fuente que está machacando la tienda. Una consulta como la siguiente (ejecútala en Parámetros avanzados → SQL Manager, ajustando el prefijo) ordena los visitantes recientes por número de impactos:

SELECT c.ip_address, COUNT(*) AS hits FROM ps_connections c WHERE c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY c.ip_address ORDER BY hits DESC LIMIT 50;

Una sola IP con cientos de impactos en un día no es un cliente. Un comprador real carga unas pocas páginas; un scraper recorre todo tu catálogo en orden. Para ver el User-Agent real que envió cada IP, que es donde los scrapers se delatan con agentes vacíos, genéricos o de script, lee el log de acceso bruto del servidor (lo cubrimos abajo) o usa un módulo que registre el User-Agent sin procesar, ya que las propias tablas de PrestaShop no lo conservan literalmente.

3. Las tablas de carrito (la pista típica de PrestaShop)

Este es un síntoma casi exclusivo de PrestaShop que confunde a miles de comerciantes: decenas de carritos abandonados sin cliente y sin productos, que aparecen en Pedidos → Carritos de compra. PrestaShop crea una fila de carrito mediante sus flujos de carrito y sesión en cuanto se toca un endpoint de añadir al carrito. Los carritos de invitado vacíos pueden generarse por varias cosas: bots y rastreadores, módulos que crean carritos por adelantado o el comportamiento normal de una sesión, así que no asumas que un rastreador concreto es el responsable. Confirma en tus logs qué fuente tocó realmente el endpoint antes de culpar, bloquear o añadir a una lista blanca a un rastreador. Los carritos son filas reales de la base de datos, pero en estos casos son artefactos, no ventas perdidas, y la solución es reconocerlos y purgarlos en lugar de bloquear un rastreador que no has confirmado que los haya creado. Desmontamos este tema en nuestra nota sobre carritos creados por bots; la conclusión práctica es que los carritos de invitado vacíos suelen ser una rareza de registro, no una emergencia.

4. El log de acceso del servidor (la verdad de base)

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Tu log de acceso bruto muestra cada solicitud con su IP, User-Agent y tiempos: la verdad de base que tus analíticas no pueden falsear, porque las analíticas basadas en JavaScript ni siquiera se ejecutan para la mayoría de bots. Busca una IP que solicite páginas de producto en un orden perfectamente secuencial, solicitudes sin User-Agent y ráfagas de impactos a /login, /password-recovery y create-account. Ese log también es donde confirmarás si un "Googlebot" es auténtico: el Googlebot real resuelve a un host googlebot.com / google.com en una búsqueda DNS inversa; uno falso reclama el nombre, pero resuelve a una IP aleatoria de centro de datos.

La escalera de defensa: primero lo más barato y amplio

El filtrado de bots funciona por capas, y el orden inteligente es empezar por los controles que detienen más tráfico con menos esfuerzo y con el menor riesgo de falso positivo. Subes la escalera solo hasta donde lo exija tu problema.

robots.txt: marca expectativas, no una barrera

PrestaShop puede generar por ti un robots.txt sensato en Parámetros de la tienda → Tráfico & SEO → SEO & URLs → Generar robots.txt. Indica a los rastreadores bien comportados que omitan tu carrito, proceso de compra, resultados de búsqueda y páginas de cuenta, lo que recorta el desperdicio de rastreo de los bots que sí quieres conservar. Entiende claramente su límite: los bots buenos lo respetan y los malos lo ignoran, así que es una herramienta de presupuesto de rastreo, nunca un control de seguridad. No listes ahí una ruta esperando ocultarla; estás publicando un mapa de lo que preferirías que otros no vieran.

El WAF en el edge: el paso de mayor palanca

Poner Cloudflare (o un WAF comparable) delante de la tienda saca la pelea por completo de tu alojamiento: las IP maliciosas conocidas, las solicitudes que no parecen venir de un navegador real y las inundaciones volumétricas se filtran en el edge antes de llegar a PHP. En el plan gratuito obtienes modo de lucha contra bots, una base de datos de reputación de IP, comprobaciones de integridad del navegador y reglas básicas de limitación de tasa: suficiente para quitar de encima de tu servidor la mayor parte de la automatización basura. Para la mayoría de tiendas PrestaShop pequeñas y medianas, este único movimiento hace más que todo lo demás junto, y es la misma capa de edge en la que te apoyarías con más fuerza cuando el tráfico de rastreadores se convierte en la avalancha de ?q= en la búsqueda facetada que puede tumbar una tienda.

Limitación de tasa: separar personas de scripts por velocidad

Un cliente real que navega carga quizá entre cinco y diez páginas por minuto; un scraper que recorre tu catálogo carga cien. Un límite de tasa por IP (devolviendo HTTP 429 cuando se supera un umbral) detecta esa diferencia automáticamente. Es más fiable en el edge (Cloudflare) o a nivel de servidor web. Ajústalo con margen: fija el techo claramente por encima de la navegación humana para que una IP compartida de oficina o de operador móvil, donde muchos clientes reales están detrás de una sola dirección, no sea castigada por estar ocupada.

Retos de formulario y honeypots: para los formularios atacados

Los scrapers quieren tus páginas; los bots de spam quieren tus formularios. Los formularios de registro, inicio de sesión, contacto y newsletter son donde se concentran los envíos automatizados, y un reto invisible los detiene sin molestar a los compradores reales; ese tema tiene su propia guía en reCAPTCHA for PrestaShop. Un honeypot lo complementa: un campo oculto que una persona nunca ve, pero que un rellenador de formularios tonto completa obedientemente, marcándose como bot sin coste alguno para tus clientes.

Bloquear por identidad desde el back office de PrestaShop

Las capas anteriores son infraestructura. Pero también necesitas un control al que puedas acceder sin SSH ni desarrollador: un lugar donde decir "este país solo me envía fraude y scrapers, aplícale un reto" o "este User-Agent de un rango de alojamiento está machacando mi inicio de sesión, bloquéalo" directamente desde la administración. Esa es la capa de aplicación, y ahí hacerlo de forma nativa en PrestaShop compensa: el bloqueo ocurre con todo el contexto de sesión (conoce el grupo de cliente, el país, el agente) y sobrevive a actualizaciones de tema y núcleo porque no está atornillado a archivos de configuración del servidor que acabarás olvidando.

Una advertencia antes de recurrir a un bloqueo de IP: sé quirúrgico con las prohibiciones de IP. Las IP residenciales y móviles se reciclan: la IP del scraper de hoy puede ser el cliente de pago de mañana en el mismo operador. Bloquea IP residenciales individuales solo como medida breve y revisada; reserva los bloqueos permanentes de rangos de IP para rangos de centros de datos y VPN donde no vive ningún cliente real. (Prohibir por IP a una persona abusiva concreta es otro trabajo, tratado en Customer Extra Info and IP Bans.) Para trazos amplios, las reglas por país y User-Agent suelen ser más seguras y requieren menos mantenimiento que perseguir direcciones individuales.

Dónde encaja Visitor Control

Visitor Control guarda en el back office las decisiones de bloqueo específicas de la tienda.

Añadir redes de confianza a la lista blanca evita que las reglas de bloqueo amplias atrapen a tu propio equipo.

La tabla de visitantes recopilados es ps_mprvc_info. Esta comprobación rápida muestra si un país o tipo de dispositivo domina el tráfico reciente:

SELECT country_code, device_type, COUNT(*) AS hits
FROM ps_mprvc_info
WHERE date_add > DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY country_code, device_type
ORDER BY hits DESC
LIMIT 20;

Este es exactamente el vacío que nuestro módulo Visitor Control fue creado para cubrir. Hace dos trabajos desde dentro del back office, sin configuración a nivel de servidor y sin tener que conectar ningún servicio externo. Primero, bloquea visitantes no deseados por IP, país o User-Agent, de modo que puedes apartar discretamente a un agente scraper conocido o a un país que solo te envía tráfico de pruebas de tarjetas, usando el propio manejo de solicitudes de PrestaShop en lugar de líneas de .htaccess editadas a mano. Segundo, te muestra quiénes son realmente tus visitantes: dispositivo, IP y país directamente en el perfil del cliente, de modo que cuando decides si un patrón es un bot o un comprador real, trabajas con pruebas en lugar de suposiciones. ¿Y qué consigues con eso? La decisión de bloquear o permitir deja de ser una tarea de administración del servidor que pospones y se convierte en una decisión de dos minutos desde la misma pantalla en la que gestionas la tienda; y como es un módulo, las reglas siguen intactas tras tu próxima actualización de PrestaShop.

Para el ruido de carritos de bots específico de PrestaShop descrito antes, esos carritos de invitado vacíos que distorsionan los contadores del back office, las herramientas dedicadas están en el lado del carrito, etiquetando y purgando carritos de bots sin bloquear los rastreadores que legítimamente pueden crearlos. La clave de separar estos trabajos es la precisión: filtras el tráfico que no quieres mientras conservas los bots que te dan posicionamiento y la indexación que te trae ventas.

Una configuración práctica por capas para una tienda normal

No necesitas un contrato empresarial de gestión de bots para manejar la avalancha diaria. Para una tienda PrestaShop típica, esta pila detiene la gran mayoría de la automatización mala con poca configuración y prácticamente sin riesgo para clientes reales:

• Pon el plan gratuito de Cloudflare delante de la tienda — la mayor reducción individual de tráfico basura, en el edge, antes de que te cueste un solo ciclo de CPU.
• Genera un robots.txt correcto desde Tráfico & SEO para que los rastreadores buenos omitan carrito, búsqueda y páginas de cuenta, y gasten su presupuesto en productos.
• Añade un reto invisible a los formularios de registro, inicio de sesión, contacto y newsletter.
• Bloquea por país y User-Agent los patrones que hayas confirmado como bots, desde el back office, y mantén los bloqueos de IP breves y específicos.
• Revisa por encima tus logs y la consulta de SQL Manager una vez al mes — bloquea reincidentes confirmados y verifica cualquier "Googlebot" sospechoso mediante DNS inverso antes de confiar en él.

Preguntas frecuentes

¿Bloquear bots perjudicará mi posicionamiento en Google?

Solo si bloqueas los equivocados. Los rastreadores de búsqueda (Googlebot, Bingbot) y los generadores de vista previa social necesitan acceder a tu tienda: si los bloqueas, tus páginas desaparecen de las búsquedas durante las semanas siguientes, o los enlaces compartidos se muestran sin vista previa. Todo el trabajo consiste en distinguirlos de los scrapers, los ataques de relleno de credenciales y los escáneres de vulnerabilidades. Bloquea por identidad y comportamiento confirmados, verifica cualquier "Googlebot" mediante DNS inverso antes de confiar en él, y reducirás el tráfico basura sin tocar los bots que traen clientes.

¿Por qué mi tienda tiene tantos carritos abandonados vacíos y sin cliente?

PrestaShop crea una fila de carrito en cuanto se toca un endpoint de añadir al carrito, así que los carritos de invitado vacíos pueden venir de bots, rastreadores, módulos que crean carritos por adelantado o del comportamiento normal de una sesión. Son filas reales, pero normalmente son artefactos, no ventas perdidas. No asumas que un rastreador concreto es el responsable: confirma en tu log de acceso qué fuente tocó realmente el endpoint y luego purga el ruido en lugar de bloquear a ciegas un rastreador que no has confirmado que lo haya creado.

¿Basta con robots.txt para mantener fuera a los bots malos?

No. robots.txt lo respetan los rastreadores buenos y lo ignoran los malos, así que es una herramienta de presupuesto de rastreo, nunca un control de seguridad. Vale la pena generarlo (Tráfico & SEO → Generar robots.txt) para evitar que los rastreadores educados desperdicien presupuesto en URLs de carrito, búsqueda y cuenta, pero nunca listes ahí una ruta esperando ocultarla, porque estás publicando un mapa de lo que preferirías que otros no vieran. Para los bots que lo ignoran, necesitas el WAF en el edge, limitación de tasa y bloqueo basado en identidad.

¿Qué acción individual tiene más impacto?

Para la mayoría de tiendas pequeñas y medianas, pon el plan gratuito de Cloudflare (o un WAF comparable) delante de la tienda. Filtra IP maliciosas conocidas, no navegadores evidentes e inundaciones volumétricas en el edge antes de que lleguen a PHP, y en el plan gratuito sigues teniendo modo de lucha contra bots, reputación de IP, comprobaciones de integridad del navegador y limitación de tasa básica. Ese único movimiento suele hacer más que todo lo demás junto.

¿Debo prohibir permanentemente las direcciones IP de scrapers?

Sé quirúrgico. Las IP residenciales y móviles se reciclan: la IP del scraper de hoy puede ser el cliente de pago de mañana en el mismo operador, así que bloquea IP residenciales individuales solo como medida breve y revisada. Reserva los bloqueos permanentes de rangos para centros de datos y VPN donde no vive ningún cliente real, y prefiere reglas por país y User-Agent para trazos amplios, ya que son más seguras y requieren menos mantenimiento que perseguir direcciones individuales.

La mentalidad que mantiene esto seguro es la que planteamos al principio: el objetivo nunca es "bloquear bots", sino "bloquear los bots que te quitan valor mientras das la bienvenida a los que traen clientes". Acierta con la taxonomía, lee las pruebas de tu propia tienda antes de usar el martillo y añade capas solo hasta donde tu tráfico te obligue. Hecho así, el filtrado de bots es una de las victorias más silenciosas en la seguridad de una tienda: invisible para los clientes que importan, y una fuga constante cerrada en los recursos, las analíticas y la superficie de ataque que, de otro modo, estarías entregando a scripts. Cuando estés listo para encajarlo en el resto de tus defensas, la lista de refuerzo de seguridad y la guía de seguridad en lenguaje claro para propietarios de tiendas conectan todo el bloque.