Documentación: Protección Contra Bots

Protección Contra Bots: Máquinas, No Humanos

Un "bot" es un programa que accede a tu web automáticamente sin interacción humana. Algunos bots son buenos (Google), otros son maliciosos (spam, scraping, ataques).

Bot Protection de SeenSecure detecta qué está accediendo realmente es un humano o una máquina. Si es bot malicioso, lo bloquea. Si es bot bueno (Googlebot), lo deja pasar.

Nota: No todos los bots son malos. Google necesita acceder para indexar. SeenSecure distingue entre buenos y malos.

Tipos de Bots

Bots Legítimos (Permitidos)

Bot	Propósito	Beneficio
Googlebot	Indexar para búsqueda Google	Tu sitio aparece en Google
Bingbot	Indexar para búsqueda Bing	Tu sitio aparece en Bing
Facebook Crawler	Obtener metadata para compartir	Links en Facebook ven preview
Slack Bot	Obtener metadata para Slack	Links en Slack muestran info

Bots Maliciosos (Bloqueados)

Scrapers: Copian tu contenido
Brute Force Bots: Intentan contraseñas automáticamente
Spam Bots: Publican spam en comentarios
DDoS Bots: Envían miles de requests para tumbar sitio
Malware Bots: Buscan vulnerabilidades
Bots de Rotación de Proxies: Esconden identidad para evadir bloqueos

Bots Ambiguos (Depende del Contexto)

Algunos bots no son claramente buenos o malos. Ejemplo:

Pingdom: Monitoreo de uptime legítimo
Crawlers Genéricos: Podrían ser research o malicioso
SEO Tools: Herramientas de análisis (legales pero agresivas)

Capa 1: Filtrado por Identidad

La primera capa no analiza comportamiento ni espera a ver qué hace el visitante — juzga por lo que dice de sí mismo en la propia petición HTTP, antes de que WordPress cargue siquiera. Es la más barata de ejecutar (ninguna consulta a base de datos, ningún cálculo) y por eso va primero: descarta el tráfico obviamente automatizado en microsegundos, dejando que las capas más costosas se ocupen solo de lo que ya ha pasado este primer filtro.

Blocklist de User-Agent

Cada visitante (humano o máquina) envía una cabecera User-Agent que dice qué software está usando. Un navegador real envía algo como Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36. Muchas herramientas automatizadas de scraping y ataque, en cambio, usan su nombre real sin disimular — porque el que las programó nunca pensó en ocultarlo, o porque cambiar el User-Agent en según qué herramienta requiere configuración extra que casi nadie hace.

Navegador real:   Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Bot legítimo:     Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Herramienta:      python-requests/2.25.1
Herramienta:      curl/7.68.0
Herramienta:      Scrapy/2.5.0 (+https://scrapy.org)
Vacío:            (sin cabecera User-Agent)

SeenSecure mantiene una lista de 21 firmas conocidas de herramientas de escaneo y pentest (sqlmap, Nikto, Nmap, masscan, Metasploit, Hydra, etc.) y bloquea la petición en cuanto el User-Agent coincide — antes de gastar ningún otro recurso en analizarla.

Bloqueo de HTTP/1.0

HTTP tiene varias versiones del protocolo. HTTP/1.0, de 1996, es la más antigua y ya no la usa prácticamente ningún navegador moderno — Chrome, Firefox, Safari y Edge negocian automáticamente HTTP/1.1, HTTP/2 o HTTP/3 con el servidor. Si una petición real llega anunciándose como HTTP/1.0, casi con toda certeza no sale de un navegador de verdad, sino de un script simple hecho con una librería mínima que nunca actualizó su versión de protocolo por defecto.

Cabecera de idioma ausente o inconsistente

Un navegador real siempre envía la cabecera Accept-Language, indicando en qué idioma prefiere recibir el contenido (la configura el propio sistema operativo o el navegador). Un script escrito a mano casi nunca se molesta en añadirla — a nadie que solo quiere extraer datos o probar vulnerabilidades le importa en qué idioma le responde el servidor. Su ausencia total es, por tanto, una señal fuerte de tráfico no-humano.

Y no solo la ausencia importa: también se compara el idioma declarado con el país de origen de la IP (vía geolocalización). Un visitante que dice preferir "zh-CN" (chino) pero conecta desde una IP residencial de un país donde ese idioma es raro es una combinación típica de tráfico enrutado a través de un proxy o VPN mal configurado — no prueba nada por sí sola, pero suma puntos de sospecha junto con el resto de señales de esta capa.

Ninguna señal decide sola. Ninguno de estos cuatro checks de la Capa 1 bloquea en solitario salvo la blocklist de User-Agent (coincidencia = bloqueo directo, porque es una firma conocida). Los demás suman una puntuación de sospecha que se combina con las Capas 2 y 3 antes de decidir nada — así se evita bloquear, por ejemplo, a un usuario real que simplemente tiene el navegador configurado de forma poco común.

Rutas Excluidas del Anti-Bot (Crons y Scripts Externos)

¿Para qué sirve? Hay tareas automáticas que no navegan por tu web con un navegador, sino que llaman a una URL concreta desde otro servidor: un cron que pica /planificacion/script_general_diario.php cada noche, un webhook de un proveedor de pagos, un script de sincronización, etc. Esas peticiones no envían la cabecera Accept-Language (ni otras que sí envía un navegador real), y la Capa 1 las confunde con bots y las bloquea. Este campo te permite decirle al firewall: «a estas rutas concretas no les apliques el Anti-Bot, son legítimas».

Recomendado (más seguro): Antes de excluir una ruta, valora añadir la IP del servidor que ejecuta el cron a la Whitelist (Firewall › Gestión de IPs › Whitelist). Así esa IP queda marcada como «de confianza» y se salta todo el firewall sin abrir la ruta a nadie más. Un atacante nunca podrá usar esa IP de confianza para saltarse el Anti-Bot. Si la IP del servidor que llama es fija, usa siempre esta opción en lugar de excluir rutas.

Solo si no puedes fijar la IP: El campo de rutas excluidas es la alternativa para los casos en que el servidor que llama no tiene una IP fija (p. ej. servicios de cron en la nube que rotan IPs, webhooks de terceros). Al excluir una ruta, se abre una puerta: un atacante podría enviar tráfico a esa ruta concreta y la Capa 1 no lo frenaría por idioma vacío. Las demás capas del WAF sí siguen aplicándose, pero esta capa concreta ya no. Por eso: excluye solo lo imprescindible y solo rutas concretas, nunca /.

Cómo identificar exactamente qué ruta excluir

Abre Firewall › Registros › Traffic Log y busca la fila del bloqueo (motivo «Sin Idioma»).
Copia la parte de la ruta de la columna Request, p. ej. /planificacion/script_general_diario.php.
Pégala en el campo «Rutas excluidas del Anti-Bot», una ruta por línea, y guarda la Capa 1.

Se admite el comodín * (p. ej. /cron/* excluye todo lo que cuelgue de /cron/) y la coincidencia por prefijo (/webhook/ cubre cualquier URL que empiece así). /wp-cron.php ya está excluido por defecto.

Cómo queda la seguridad

WAF, rate limiting, listas de IP, validación DNS de crawlers y validación de login siguen protegiendo esa URL. Solo se relaja la comprobación automatizada de la Capa 1.

No ralentiza nada

Las exclusiones se comprueban en milisegundos contra una lista en memoria. No hay impacto en el rendimiento de tu web.

Capa 2: Huella de Navegador

Un atacante más sofisticado no usa un script simple con curl — usa un navegador headless (Chrome o Firefox reales, pero controlados por código en vez de por un humano, sin interfaz visual) precisamente para pasar la Capa 1 sin problema: el User-Agent es idéntico al de un Chrome normal, la versión de HTTP es la correcta, y hasta puede enviar Accept-Language. La Capa 2 existe para detectar precisamente ese caso, mirando propiedades del navegador que el software de automatización deja expuestas aunque intente pasar por un navegador normal.

Qué intenta conseguir el atacante: hacer scraping masivo de contenido, probar credenciales robadas contra el formulario de login, o rellenar formularios de forma automatizada (spam, fraude) — todo ello ejecutando JavaScript real como lo haría un usuario, algo que un simple script sin navegador no puede hacer, pero un navegador headless sí.

Cómo funciona: cuando un visitante carga una página protegida, un pequeño script en el navegador recoge un puñado de características técnicas — si responde a peticiones de Canvas y WebGL (gráficos), qué plugins tiene instalados, la resolución real de pantalla, el orden en que llegan las cabeceras HTTP, y cuánto tarda en reaccionar. Cada una suma o resta a una puntuación de 0 a 100: un humano normal, con un navegador de verdad, saca una puntuación alta; un navegador headless sin interfaz gráfica falla varias de esas comprobaciones a la vez y saca una puntuación baja.

Ejemplo real: un visitante humano con Chrome normal, plugins instalados y pantalla de 1920×1080 responde a un desafío en unos 2 segundos — puntuación alta, pasa sin fricción. Un bot con Chrome headless, sin plugins, sin soporte de WebGL, responde en 0,1 segundos — puntuación baja, se le aplica la acción configurada (registrar, CAPTCHA o bloqueo).

Cómo activarla y configurarla

SeenSecure > Firewall > Anti-Bot > Capa 2: Bot Fingerprint Analyzer > Activado

Campo	Qué hace
Acción al detectar bot	Solo registrar, forzar CAPTCHA, o bloquear el acceso directamente
Puntuación mínima	Deslizador de 0 a 100: los visitantes por debajo de este umbral se tratan como sospechosos
Verificar en	Página de login y/o frontend (comentarios, formularios públicos)
Módulos de detección	5 interruptores independientes: Detección Headless, Canvas Fingerprint, WebGL Renderer, Análisis de Timing, Detección de Features

Recomendación: empieza con la acción en «Solo registrar» durante unos días y revisa el log — así ves qué puntuaciones sacan tus visitantes reales antes de pasar a bloquear o exigir CAPTCHA. Si notas visitantes legítimos con puntuación baja (navegadores muy minimalistas, extensiones de privacidad agresivas, algunos navegadores de accesibilidad), sube el umbral con cuidado o cambia la acción a «Forzar CAPTCHA» en vez de bloqueo directo.

Capa 2+: Detección Avanzada de Comportamiento Humano (PRO)

Por qué hace falta otra capa además del Fingerprint: hoy existen herramientas de ataque capaces de "leer" y resolver un CAPTCHA visual, incluidos los que usan letras deformadas o emojis. Si un bot ya sabe resolver ese tipo de pruebas, hace falta otra señal que no dependa de acertar un desafío. Esta capa no evalúa si el CAPTCHA se resolvió bien, sino cómo se comportó el visitante mientras rellenaba el formulario. Es una protección adicional, no un sustituto de la Capa 2 (Fingerprint) — la complementa.

Cómo funciona: el ratón de una persona se mueve de forma irregular, con pequeñas correcciones y pausas — nunca en línea recta perfecta. Al escribir, hay ritmos naturales entre teclas que nunca son perfectamente iguales. Un script automatizado, en cambio, suele mover el ratón en línea recta hasta el campo (o no moverlo en absoluto) y teclea con un intervalo entre pulsaciones casi idéntico siempre. Estas señales se suman a la misma puntuación que ya calcula la Capa 2 — no es una puntuación ni una acción independiente.

Probado en la práctica: en pruebas con un asistente de IA real intentando iniciar sesión de forma automatizada, resolvió correctamente el CAPTCHA visual a la primera y aun así el acceso fue denegado por "puntuación de seguridad demasiado baja" — exactamente la señal que esta capa está diseñada para detectar.

¿Dónde actúa? Por defecto, solo en los formularios de acceso — inicio de sesión y registro. Opcionalmente se puede ampliar a cualquier formulario del sitio (contacto, comentarios, y formularios de otros plugins como Contact Form 7 o WPForms). Un bot legítimo como Googlebot no rellena formularios: navega el sitio e indexa páginas con normalidad, así que nunca pasa por esta comprobación y no se ve afectado, elijas la opción que elijas.

Cómo activarla

SeenSecure > Firewall > Anti-Bot > Capa 2+: Detección Avanzada de Comportamiento Humano > Activado

Al activarla, se suma a la puntuación de la Capa 2: si el comportamiento resulta sospechoso, la puntuación baja y se aplica la misma acción (registrar, CAPTCHA o bloqueo) ya configurada en la Capa 2 — no hay un ajuste independiente que configurar.

PRO: esta capa es exclusiva de los planes PRO. En sitios FREE, el interruptor aparece desactivado y bloqueado — el resto de la Capa 2 (Fingerprint) sigue funcionando con normalidad.

Capa 3: Verificación de Crawlers

Cualquiera puede poner "Googlebot" en su User-Agent — es solo texto, no hay ninguna comprobación automática que lo impida a nivel de protocolo. Muchos bots maliciosos hacen justamente eso, fingiendo ser Googlebot o Bingbot para intentar que el firewall los deje pasar sin más preguntas, aprovechando que muchos sitios confían ciegamente en ese nombre.

SeenSecure verifica la identidad real con una técnica estándar de la industria: DNS inverso. Cuando una petición dice ser Googlebot, el sistema resuelve el nombre de dominio real asociado a esa dirección IP (Google, por ejemplo, siempre resuelve a un dominio terminado en .googlebot.com o .google.com) y, si coincide, hace una segunda comprobación en el sentido contrario (DNS directo de ese dominio a la IP) para confirmar que no ha sido falsificado. Solo si ambas comprobaciones coinciden se confía en que la petición es realmente de Google.

Por qué esta doble comprobación importa: un atacante podría controlar un servidor cuyo DNS inverso resuelve a un nombre que él mismo eligió — pero no puede hacer que ese dominio, a su vez, resuelva de vuelta a su propia IP salvo que sea el dueño real de ese dominio. La doble comprobación (inversa + directa) es lo que hace prácticamente imposible falsificar la identidad de un crawler conocido.

Combinación de capas: ninguna de estas tres capas decide en solitario en los casos más ambiguos — SeenSecure combina las señales de las Capas 1, 2 y 3 antes de aplicar la acción configurada (bloquear, desafiar con CAPTCHA o solo registrar). Así se reduce el riesgo de bloquear tráfico legítimo por una única señal poco fiable de forma aislada.

Cómo Configurar Bot Protection

Paso 1: Activar Protección

SeenSecure > Firewall > Bot Protection > Habilitar

Paso 2: Elegir Nivel de Protección

Permisivo: Solo bloquea bots obviamente maliciosos. Googlebot pasa sin CAPTCHA
Moderado (Recomendado): Detecta bots sospechosos, puede pedir CAPTCHA a algunos
Agresivo: Todo bot no reconocido = CAPTCHA. Google también debe probar

Paso 3: Definir Comportamiento al Detectar

Bloquear: Rechaza inmediatamente (error 403)
Desafío: Pide resolver CAPTCHA
Registrar: Solo guarda en log, permite acceso (debug)

Paso 4: Permitir Bots Específicos (Whitelist)

Si hay crawlers legítimos que quieres permitir sin CAPTCHA:

Whitelist:
- Googlebot
- Bingbot
- facebookexternalhit
- Slurp (Yahoo)

Paso 5: Bloquear Bots Específicos (Blacklist)

Si conoces bots específicamente maliciosos:

Blacklist:
- MJ12Bot (SEO malicioso)
- DotBot (scraper)
- AhrefsBot (agresivo)

Recomendación: Empieza con "Moderado". Revisa logs una semana. Si todo bien, sube a "Agresivo" si necesitas más seguridad.

Capa 4: Control de robots.txt y Sitemap XML

Esta capa no bloquea nada por sí sola — es una guía que le dices a los buscadores (Google, Bing) sobre qué partes de tu web pueden rastrear. Complementa a las otras capas: mientras Capa 1-3 detectan bots maliciosos que ignoran las reglas, Capa 4 ordena el comportamiento de los bots legítimos que sí las respetan.

¿Qué es robots.txt? Un archivo de texto en la raíz de tu web (tusitio.com/robots.txt) que actúa como un "cartel de entrada" para los crawlers: les indica por dónde pueden pasar y qué zonas están restringidas. Es una guía, no una orden — los crawlers legítimos la respetan, pero los maliciosos pueden ignorarla. Nunca lo uses para "ocultar" información sensible: cualquiera puede leerlo directamente.

Editor de robots.txt

En Firewall > Anti-Bot > Capa 4, activa "Personalizar robots.txt" y elige entre:

Plantillas predefinidas: configuraciones ya hechas para casos comunes (bloquear /wp-admin/, permitir todo, bloquear todo, etc.), listas para usar sin escribir una sola línea
Directivas personalizadas: eliges tú mismo, casilla a casilla, qué partes de WordPress bloquear a los buscadores (zona de administración /wp-admin/, archivos internos /wp-includes/, API REST /wp-json/ y /?rest_route=, o /xmlrpc.php)

Generador de Sitemap XML

En la misma pantalla, activa "Servir sitemap.xml generado por SeenSecure" para publicar un mapa completo de tu web en tusitio.com/sitemap.xml — el archivo que los buscadores usan para descubrir todas tus páginas de una vez, en lugar de tener que encontrarlas navegando enlace a enlace.

Opción	Qué hace
Excluir rutas bloqueadas	El sitemap no incluye las páginas que ya marcaste como bloqueadas en las directivas de robots.txt de arriba
Caché (segundos)	Cuánto tiempo se guarda el sitemap generado antes de recalcularlo. No hace falta esperar: se regenera solo, automáticamente, cada vez que publicas o actualizas contenido
Rutas adicionales	URLs que no son páginas/posts de WordPress pero quieres incluir igualmente (una por línea; también acepta URLs externas completas)

Automático de verdad: no tienes que darle a "generar" cada vez que escribes algo nuevo. El sitemap se actualiza solo en segundo plano cuando publicas o editas contenido — el botón "Generar sitemap ahora" solo sirve para forzar una actualización inmediata si no quieres esperar.

Capa 5: Validación Estricta de IPs (Anti-Spoofing)

Esta capa no es un límite nuevo — protege a todas las demás. Rate limiting, bloqueos de login, geo-bloqueo, listas de IPs... todas esas protecciones deciden qué hacer según la dirección IP del visitante. El problema: hay cabeceras HTTP (X-Forwarded-For, X-Real-IP, CF-Connecting-IP) que un visitante puede fabricar a mano para hacerse pasar por otra IP distinta a la real de su conexión — y si el firewall se fía de esas cabeceras sin más, todos tus contadores y bloqueos por IP se pueden esquivar simplemente mintiendo sobre la propia IP.

Función PRO. Disponible en el plan PRO. Se activa en Firewall > Anti-Bot > Capa 5, con dos interruptores independientes: "Activar Validación Estricta de IPs" (que empieza a usar siempre la IP real de la conexión TCP en vez de fiarse de las cabeceras) y, solo si el anterior está activo, "Bloquear IP que intenta spoofing" (que además rechaza directamente a quien intente falsificar su IP).

Capa 6: Protección Escaneo Masivo 404

Para qué sirve: cuando el mismo visitante pide, una tras otra en pocos minutos, muchas páginas que no existen en tu web, es una señal muy fiable de que está escaneando en busca de puntos débiles — ningún humano navega así, y ningún bot legítimo de buscador (Google, Bing) genera ese patrón. Esta capa cuenta esos errores 404 por IP y corta el escaneo antes de que termine.

Por qué lo intenta un atacante: las herramientas automáticas de escaneo (como Nuclei o Nikto) prueban decenas o cientos de rutas conocidas en segundos — /wp-config.php.bak, /.env, /database.sql, /admin.php — buscando algún archivo sensible que se haya quedado accesible por error. Es un paso de reconocimiento previo a un ataque real: cuantas más rutas prueba, más probabilidades tiene de encontrar algo explotable.

Ejemplo real: Un escáner pide 50+ rutas inexistentes en pocos segundos. Con la configuración por defecto (12 errores 404 en una ventana de 5 minutos), al llegar al 12º intento la IP se bloquea automáticamente durante el tiempo configurado (10 minutos por defecto) — el escáner se queda sin respuesta a mitad de su lista y se detiene.

Cómo funciona: por cada IP, el plugin cuenta cuántas páginas 404 pide dentro de la ventana de tiempo configurada. Si supera el umbral, se bloquea esa IP durante la duración configurada (o solo se registra en el log, según la acción elegida). Como en el resto del firewall, esta capa respeta el modo global: en Monitor solo registra, nunca bloquea; en Protection/Strict aplica la acción configurada. Puedes excluir rutas que generan 404 legítimos (favicon.ico, robots.txt, etc.) para que no cuenten en el umbral.

Configuración

Campo	Qué hace	Por defecto
Umbral de 404s	Nº de páginas no encontradas que activan el bloqueo	12
Ventana de tiempo	Periodo en el que se cuentan los 404s	5 min
Duración del bloqueo	Tiempo que la IP queda bloqueada	10 min
Acción	Bloquear IP (403) o solo registrar	Bloquear

Falsos positivos: si tu web tiene enlaces internos rotos, un visitante real podría acumular varios 404 legítimos. Si ves bloqueos de visitantes reales, sube el umbral o la ventana de tiempo, y añade a la lista de exclusión las rutas que generen 404 falsos de forma recurrente. Esta capa nunca bloquea a Google o Bing legítimos — si ves sus IPs bloqueadas, probablemente son IPs falsificadas, que la Capa 5 (Validación Estricta de IPs, PRO) detectaría.

Modo Privado

Un interruptor pensado para sitios que no deben aparecer en ningún buscador: intranets, entornos de staging, webs en construcción o proyectos privados. Al activarlo desde Firewall > Anti-Bot, ocurren tres cosas a la vez:

robots.txt pasa a bloquear todo (Disallow: /), sea cual sea la configuración de la Capa 4
Cada página envía la cabecera X-Robots-Tag: noindex, nofollow, la señal directa que le dice a un buscador "no me guardes en tu índice ni sigas mis enlaces"
El firewall bloquea a cualquier bot detectado, incluidos los motores de búsqueda legítimos como Google o Bing — no hay excepciones

Úsalo solo si de verdad no quieres indexación. Es una medida radical: si tu sitio ya es público y buscas visibilidad, activar Modo Privado te sacará de Google. Está pensado para sitios que todavía NO deben ser públicos, no para "reforzar" un sitio ya publicado.

Mejores Prácticas

Para Sitios Públicos (Blog, Tienda)

Usa nivel "Permisivo"
Deja Googlebot y Bingbot sin CAPTCHA (necesitas indexación)
Bloquea bots scrapers conocidos

Para Sitios Privados (Admin, Comunidad)

Usa nivel "Agresivo"
Requiere CAPTCHA para todo acceso inicial
Whitelist solo IPs de empleados (no bots)

Para E-commerce (Tienda Online)

Nivel "Moderado"
Protege checkout agresivamente (Agresivo en /checkout)
Público puede navegar sin CAPTCHA

Interpretación de Logs

Bot = Googlebot, pide CAPTCHA: No es real Googlebot, es falso. Bloquéalo.
User-Agent vacío + Headers sospechosos: Claramente malicioso.
Bot legítimo bloqueado: Revisa si es falso positivo, whitelist si es legítimo.

Importante: Si bloqueares Googlebot real, tu sitio desaparece de Google Search. Ten cuidado con demasiada agresividad.

🔧 Solución de Problemas

Un visitante legítimo fue bloqueado o le sale CAPTCHA constantemente

Es el síntoma más común de un falso positivo. Antes de tocar nada, confirma la causa real en Firewall → Traffic Log: busca la IP o la fecha aproximada y mira la columna "PROTECCIÓN" — te dice exactamente qué capa actuó, no asumas que fue Bot Protection sin comprobarlo.

Si fue Capa 2 (Fingerprint) o Capa 3 (Verificación de crawlers): en su propia tarjeta, dentro de Firewall → Anti-Bot, cada una tiene su desplegable de acción con la opción 📝 "Solo registrar" — cámbiala ahí temporalmente en vez de apagar la capa entera: sigues viendo en el Traffic Log qué habría bloqueado, sin dejar fuera a nadie mientras ajustas.
Si fue Capa 5 (Validación Estricta de IPs): la propia tarjeta de esa capa ya avisa de la causa más típica: algunos proxies corporativos o de operadoras móviles reescriben la cabecera X-Forwarded-For en conexiones legítimas. Si activaste ahí el interruptor extra "🚫 Bloquear IP que intenta spoofing", desactívalo primero — puedes dejar la validación encendida (corrige la IP de los contadores) sin el bloqueo duro.

Necesito desbloquear a alguien ahora mismo

Añádelo directamente en Firewall → Listas de IPs (whitelist): tiene prioridad absoluta sobre cualquier capa Anti-Bot, incluida la Capa 2+. No hace falta esperar a que expire el bloqueo ni tocar la configuración de la capa.

Preguntas Frecuentes

¿Ralentiza mi sitio con CAPTCHA? Solo si algún visitante es detectado como bot. Humanos entran sin CAPTCHA normalmente.

¿Puedo permitir Googlebot pero bloquear otros bots? Sí, eso es lo ideal. Whitelist Googlebot/Bing, blacklist el resto.

¿Qué pasa si usuarios legítimos son marcados como bots? Les pides resolver CAPTCHA. Si ocurre frecuentemente, reduce agresividad.

¿RSS feeds están afectados? No, RSS es diferente. Pero algunos readers pueden ser detectados como bots (normal).

¿Qué es la "Primera Línea" que menciona el panel de Rate Limiting? Es una capa de protección aparte, que no es específica de bots: actúa antes incluso de que WordPress se cargue, para frenar picos de tráfico o ataques demasiado grandes o rápidos para que el resto del plugin llegue a reaccionar. Se activa y configura en Firewall → Rate Limiting → "🚀 Primera Línea". Como parte de esa protección, y para no perjudicar tu posicionamiento, también comprueba que una visita que dice ser un buscador o asistente de IA legítimo lo sea de verdad antes de aplicarle cualquier límite — no le basta con el texto que envía la petición: se contrasta contra datos oficiales de la empresa correspondiente, así que nadie se cuela solo cambiando una cabecera.

¿La Capa 2+ (Comportamiento Humano) solo funciona en login y registro? Por defecto sí, porque ahí es donde más importa (un bot genuino de búsqueda navega y lee, nunca intenta iniciar sesión). Puedes ampliarla a "cualquier formulario del sitio" desde su propia tarjeta en Firewall → Anti-Bot si quieres proteger también un formulario de contacto o similar.

¿Qué diferencia hay entre bloquear y "solo registrar" en cada capa? "Solo registrar" deja ver en el Traffic Log qué habría bloqueado esa capa sin afectar a ningún visitante real — útil para probar una capa nueva antes de activarla en serio.

¿Puedo desactivar una sola capa y dejar el resto activas? Sí, cada una de las 6 capas (y la 2+) se activa/desactiva de forma independiente; no dependen unas de otras para funcionar.

¿Afecta a mi posicionamiento en Google si subo la agresividad? No debería: Googlebot y el resto de buscadores/asistentes de IA legítimos se verifican por DNS inversa (Capa 3) y por listas oficiales, no por lo que digan sus cabeceras — siguen pasando aunque el resto del tráfico se endurezca.

Conclusión: Bot Protection es última línea de defensa contra acceso automatizado malicioso. Combina con otras protecciones para cobertura completa.