Guía completa del escudo de 5 segundos de Cloudflare: 3 trucos de configuración para resolver problemas de SEO y experiencia

Introducción

CPU del servidor al 100%, tráfico multiplicado por 10: un ataque CC típico. Entras al panel de Cloudflare, activas el modo I’m Under Attack y en 30 segundos la presión del servidor baja.

Al día siguiente abres Google Search Console: las páginas indexadas pasan de más de 1200 a unas 800, una caída de más del 30%. Tras revisar entiendes que el escudo de 5 segundos también bloqueó a los crawlers.

Sin escudo no aguantas el ataque; con escudo dañas SEO y experiencia. En este artículo veremos cómo usar el escudo de 5 segundos de Cloudflare para frenar ataques sin perjudicar SEO ni a los usuarios.

Capítulo 1: ¿Qué es el escudo de 5 segundos (modo Under Attack)?

Funcionamiento: qué ocurre en esos 5 segundos

En resumen, el escudo de 5 segundos de Cloudflare añade un punto de verificación entre tu sitio y los visitantes. Cuando alguien accede, Cloudflare no lo deja entrar directamente: muestra una página intermedia y le pide esperar unos 5 segundos.

Esos 5 segundos no son en vano. Cloudflare hace tres cosas:

Paso 1: el navegador envía automáticamente la primera petición y Cloudflare escribe la cookie __cfduid, como un pase temporal.

Paso 2: el navegador envía una segunda petición con parámetros cifrados; tras validarla, Cloudflare escribe la cookie clave cf_clearance, el pase real con validez predeterminada de 30 minutos.

Paso 3: el navegador solicita la página de inicio con ambas cookies; Cloudflare verifica y deja pasar. Solo entonces se carga el contenido.

Además de estas tres peticiones, Cloudflare hace otras comprobaciones en segundo plano:

• Verificación JavaScript: inyecta JS ofuscado para comprobar si el navegador ejecuta JavaScript con normalidad. Los navegadores reales pasan; la mayoría de crawlers simples y scripts de ataque fallan aquí.
• Huella digital del navegador: recopila resolución de pantalla, extensiones, fuentes del sistema, etc., para formar una huella única. Identifica herramientas de ataque disfrazadas de navegador normal.
• Detección de comportamiento: analiza frecuencia de peticiones, User-Agent, movimiento del ratón, etc., para distinguir humanos de bots.

Diferencias con otros niveles de seguridad

Cloudflare ofrece varios niveles, no solo el escudo de 5 segundos. Esta tabla lo resume:

Por experiencia, Medium basta en el día a día. Solo cambia a I’m Under Attack cuando el ataque es real. No lo dejes siempre activo: es como llevar una máscara antigás todo el día.

¿Qué ataques puede frenar el escudo de 5 segundos?

Primero, una nota sobre la clasificación de ataques DDoS. En el modelo OSI hay siete capas; cuanto más arriba, más cerca de la capa de aplicación.

El escudo protege sobre todo ataques de capa 7, los CC (Challenge Collapsar): simulan visitas normales pero con volumen masivo que agota los recursos del servidor.

Contra DDoS de volumen en capas inferiores (UDP Flood, SYN Flood) el efecto es limitado; Cloudflare usa otros mecanismos. La documentación oficial lo deja claro: es uno de los últimos recursos, no una panacea.

Cloudflare dice: realiza comprobaciones de seguridad adicionales para ayudar a mitigar ataques DDoS de capa 7. Fíjate en ayudar a mitigar, no en bloquear por completo. En DDoS masivos hacen falta más medidas además del escudo.

Capítulo 2: Impacto real en SEO y experiencia de usuario

¿Pueden pasar el escudo los crawlers de buscadores?

Lo he probado y la respuesta es: depende.

Googlebot puede ejecutar JavaScript y en teoría pasa la verificación. Pero el tiempo del crawler es valioso: no espera 5 segundos como un humano; pasa a otros sitios y vuelve más tarde.

Tras activar el escudo observé en Google Search Console varios patrones:

1. Menor frecuencia de rastreo: de unas 1200 peticiones diarias a 400-600.
2. Más errores de rastreo: muchos timeouts y errores de servidor.
3. Indexación más lenta: artículos nuevos pasan de 1-2 días a 4-5 días.

Baiduspider tiene peor suerte: su JavaScript es débil y con el escudo suele fallar. Un colega con sitio en chino me contó que tras 3 días con escudo activo la indexación en Baidu cayó de más de 2000 a poco más de 1000.

Bing queda en el medio: puede pasar, pero más lento, con una caída de indexación del 15-20%.

Datos reales de experiencia de usuario

No basta la teoría; hay que mirar datos. Hice una prueba A/B y registré el comportamiento antes y después:

Tasa de rebote en aumento:

• Antes: 35%
• Después: 62%
• Aumento: 77%

De cada 10 visitantes nuevos, 6 cierran al ver la espera de 5 segundos. En PC ya es alto; en móvil llega al 75%.

Tiempo medio de permanencia:

• Antes: 3 min 15 s
• Después: 1 min 48 s
• Caída: 45%

Conversión a la mitad:
Si tu sitio tiene registro, compra u otros objetivos, espera que la conversión caiga a la mitad. El usuario entra con interés, espera 5 segundos y se enfría.

Un amigo con e-commerce activó el escudo durante un ataque: los pedidos pasaron de 60 a 22 al día. El ataque se frenó, pero el negocio también.

Distorsión de datos en herramientas de analítica

Este problema es más sutil. La documentación de Cloudflare dice que, al requerir JavaScript para la página intermedia, es normal que las herramientas de analítica basadas en JS se vean afectadas.

En concreto:

Google Analytics muestra menos datos:

• La página de espera de 5 segundos no lleva el código de GA
• Los que rebotan no se contabilizan
• Solo ves usuarios que pasaron la verificación; el tráfico real es mayor

Mapas de calor inútiles:
Hotjar, Crazy Egg, etc., no registran comportamiento en la página de espera. Parece que todos entran, pero la mitad se queda en la puerta.

Seguimiento de anuncios ciego:
Con Google Ads o Facebook Ads, el seguimiento de conversiones se rompe. Facebook Pixel y las etiquetas de Google Ads no cargan: gastas dinero sin datos.

Desastre para APIs y servicios de terceros

El impacto en páginas web es tolerable; en APIs es catastrófico.

Problema 1: todas las peticiones API fallan

Las llamadas API son programa a programa, no navegador. No ejecutan JavaScript ni esperan 5 segundos: devuelven error directamente.

El peor caso que vi: un desarrollador con API protegida por Cloudflare activó el escudo en todo el sitio por error. Más de 50 000 usuarios activos de la app quedaron fuera de servicio al instante.

Problema 2: integraciones de terceros desconectadas

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Muchos sitios integran servicios externos:

• Callbacks de pago (PayPal, Stripe)
• Webhooks (GitHub, Slack)
• Suscripciones RSS
• Monitorización (Uptime Robot)

Estas peticiones no pasan la verificación y se bloquean. Lo peor son los callbacks de pago: el usuario paga, tu sitio no recibe aviso y el pedido no se actualiza.

Problema 3: apps móviles inaccesibles

Si tu app iOS o Android habla con el servidor por Web API, el escudo en todo el sitio deja la app inutilizable: loading infinito y error de red.

Con APIs, apps móviles o integraciones críticas, nunca actives el escudo en todo el sitio. Usa Page Rules para excluir esas rutas; el siguiente capítulo lo detalla.

Capítulo 3: Activar el escudo solo en rutas específicas (Page Rules en la práctica)

¿Qué son las Page Rules?

Page Rules son reglas condicionales de Cloudflare. Puedes definir distinto nivel de seguridad, estrategia de caché, etc., según la ruta URL.

Por ejemplo:

• example.com/api/* → Security Level: Low, sin interceptación
• example.com/admin/* → Security Level: I’m Under Attack, verificación estricta
• Resto de páginas → Medium

Así logras protección selectiva: solo donde hace falta, sin afectar al resto.

Mala noticia: en junio de 2024 Cloudflare anunció que Page Rules se retirarán gradualmente y las funciones migrarán a Configuration Rules, Cache Rules, etc. Buena noticia: las Page Rules existentes seguirán funcionando y la migración la hace Cloudflare.

El plan gratuito tiene 3 Page Rules, suficiente para muchos sitios personales. Pro: 20; Business: 50.

Reglas de coincidencia URL: uso correcto del comodín *

El núcleo de Page Rules es la coincidencia de URL. El comodín más usado es *.

Reglas básicas:

• * coincide con cualquier cadena (incluida vacía)
• Puede usarse en cualquier posición
• Se permiten varios *

Patrones habituales:

example.com/api/*
→ coincide example.com/api/users
→ coincide example.com/api/posts/123
→ no coincide example.com/apiv2/users (hace falta barra tras api)

example.com/*.jpg
→ coincide example.com/logo.jpg
→ coincide example.com/images/banner.jpg (también subdirectorios)
→ no coincide example.com/logo.png

example.com/*admin*
→ coincide example.com/wp-admin
→ coincide example.com/admin/users
→ coincide example.com/myadmin (cualquier URL con admin)

Regla de prioridad (muy importante):

Las Page Rules se ejecutan de arriba abajo. Al encontrar la primera coincidencia se aplica y las siguientes no se evalúan.

Por tanto:

1. Reglas específicas primero; genéricas después
2. Si el orden es inverso, la genérica se come todo y las específicas nunca se ejecutan

Ejemplo incorrecto:

Regla 1: example.com/* → Security Level: I'm Under Attack
Regla 2: example.com/api/* → Security Level: Low

La regla 2 nunca se aplica porque la 1 intercepta todo.

Orden correcto:

Regla 1: example.com/api/* → Security Level: Low (ruta específica primero)
Regla 2: example.com/* → Security Level: I'm Under Attack (comodín después)

Escenario 1: proteger solo login y panel

Es el caso más común: los atacantes suelen atacar el login con fuerza bruta.

Con WordPress, por ejemplo:

Regla 1: proteger wp-admin

• URL: example.com/wp-admin*
• Ajuste: Security Level → I’m Under Attack

Regla 2: proteger login

• URL: example.com/wp-login.php
• Ajuste: Security Level → I’m Under Attack

Regla 3: resto con nivel medio

• URL: example.com/*
• Ajuste: Security Level → Medium

Solo el panel y el login activan el escudo; el resto de visitantes y el SEO no se ven afectados.

Escenario 2: excluir APIs

Si tienes API, no puede quedar detrás del escudo.

Regla 1: API con nivel bajo

• URL: example.com/api/*
• Ajuste: Security Level → Low

Regla 2: API en subdominio móvil

• URL: api.example.com/*
• Ajuste: Security Level → Low

Regla 3: resto con nivel alto

• URL: example.com/*
• Ajuste: Security Level → I’m Under Attack

Las reglas de API deben ir primero.

Con varias versiones de API:

example.com/api/v1/*
example.com/api/v2/*

Consume muchas reglas. Mejor:

example.com/api*

Coincide con todo lo que empiece por /api.

Escenario 3: proteger páginas dinámicas, liberar estáticos

Imágenes, CSS y JS no suelen necesitar escudo; interceptarlos rompe la carga de la página.

Regla 1: liberar imágenes

• URL: example.com/*.jpg
• Ajuste: Security Level → Low, Cache Level → Cache Everything

Reglas similares para .png, .css, .js, pero gastan reglas. Mejor subdominio CDN:

• cdn.example.com/* → Security Level: Low

Regla 2: páginas dinámicas con alta protección

• URL: example.com/*
• Ajuste: Security Level → I’m Under Attack

El HTML queda protegido; imágenes y estilos cargan con normalidad.

Pasos completos de configuración

Paso 1: iniciar sesión en Cloudflare Dashboard

Abre cloudflare.com, inicia sesión y elige el dominio.

Paso 2: entrar en Page Rules

Menú lateral: Rules → Page Rules
(En el panel nuevo puede ser: Rules → Page Rules (Legacy))

Paso 3: crear la primera regla

Pulsa Create Page Rule.

En If the URL matches escribe el patrón, por ejemplo:

example.com/api/*

Desplázate, pulsa + Add a Setting, elige Security Level y pon Low.

Pulsa Save and Deploy.

Paso 4: crear el resto de reglas

Repite el paso 3. El orden importa.

Paso 5: ajustar prioridad

En la lista, arrastra con el icono de tres líneas: específicas arriba, genéricas abajo.

Paso 6: probar

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

En modo incógnito visita distintas rutas y confirma:

• API sin escudo ✓
• Páginas normales con escudo ✓
• Estáticos cargando bien ✓

Cómo aprovechar al máximo las 3 reglas del plan gratuito

Solo 3 reglas: hay que optimizarlas.

Regla 1: proteger la entrada más crítica

example.com/wp-admin*
Security Level: I'm Under Attack

Regla 2: liberar API y estáticos

example.com/api*
Security Level: Low

Regla 3: resto con protección media

example.com/*
Security Level: Medium

Proteges lo esencial sin romper el uso diario. Sin ataque activo, no cambies a I’m Under Attack a la ligera.

Capítulo 4: Mejores prácticas de Challenge Passage

¿Qué es Challenge Passage?

Tras pasar el escudo la primera vez, Cloudflare guarda la cookie cf_clearance en el navegador. Es un pase temporal: mientras sea válida, el visitante no vuelve a ver la página de espera.

Challenge Passage es el tiempo de validez de ese pase.

El valor predeterminado es 30 minutos: durante media hora puedes navegar sin repetir la verificación. Pasado ese tiempo, la cookie caduca y hay que validar de nuevo.

Detalles técnicos interesantes:

Margen de desfase horario: Cloudflare añade unos minutos extra para evitar falsos positivos por diferencia entre reloj del cliente y del servidor.

Tratamiento especial de XmlHTTP: en peticiones Ajax da hasta 1 hora extra para evitar que SPAs con caché corta fallen con frecuencia.

Herencia de nivel de seguridad: si pasaste un Interactive Challenge (el más estricto), la cookie vale para cualquier nivel. Si solo pasaste uno bajo, un desafío alto puede exigir revalidación.

Dónde configurar Challenge Passage

En Cloudflare Dashboard:

Security → Settings → Challenge Passage

Pulsa el icono de edición; la unidad son minutos. Cloudflare recomienda 15-45 minutos.

Es configuración global para todo el dominio; no hay ajuste por ruta.

Valores recomendados por escenario

Según experiencia práctica:

Alta seguridad (finanzas, pagos, datos sensibles): 15-20 minutos

• Banca online, pagos, OA empresarial
• Prioridad máxima a seguridad; visitas cortas; revalidación frecuente aceptable
• UX: cada 15 minutos otra verificación; molesto pero comprensible

Equilibrio (e-commerce, web corporativa, SaaS): 30 minutos (predeterminado)

• La mayoría de sitios comerciales
• Equilibra seguridad y experiencia; basta para una compra o sesión
• La mayoría termina antes de 30 minutos sin segunda verificación

Prioridad UX (contenido, blogs, medios): 40-45 minutos

• Noticias, blogs técnicos, vídeo
• Visitas largas con muchos saltos entre páginas; validar a menudo interrumpe la lectura
• Puedes leer varios artículos seguidos sin interrupciones

En mi blog técnico uso 40 minutos: los lectores suelen ver varios artículos y 30 minutos a veces no alcanzan.

Tres errores comunes

Error 1: cuanto más corto, más seguro

Muchos piensan que 5 minutos y revalidar cada 5 minutos es lo más seguro.

Es una ilusión. El escudo distingue humanos y máquinas, no evita que la misma persona vuelva. Si un humano ya pasó, obligarlo cada 5 minutos solo le molesta.

El tráfico malicioso o falla en el primer intento (sin cookie) o usa herramientas avanzadas (da igual 5 o 30 minutos).

Error 2: poner horas para mayor comodidad

Alguien dice: 2 horas y mejor experiencia.

Pero una cookie demasiado larga reduce mucho la seguridad. Escenario:

1. Usuario pasa el escudo en WiFi público de una cafetería
2. Se va, pero la cookie sigue válida
3. Otra persona en la misma red (o un atacante) podría usar esa cookie
4. Durante 2 horas el atacante entra sin fricción

El tope de 45 minutos de Cloudflare tiene sentido; no lo alargues por tu cuenta.

Error 3: pensar que aplica a todas las reglas

Yo caí en esto: configuré Challenge Passage y algunas reglas seguían disparando verificaciones.

Challenge Passage no aplica a Rate Limiting Rules. Con límite de frecuencia, al superarlo el usuario debe revalidar sin importar el Challenge Passage.

Cómo saber si tu configuración es adecuada

No te fíes solo de la intuición; mira datos. Suelo observar:

1. Quejas de usuarios

Si dicen que siempre tienen que esperar 5 segundos, quizá el Challenge Passage es corto. Revisa su patrón de navegación y ajusta.

2. Security Events

En Security → Events ves cuántas veces se dispara el desafío al día. Muchas repeticiones del mismo IP en poco tiempo pueden indicar un periodo demasiado corto.

3. Rebote y permanencia

Si el rebote sube y la permanencia baja, puede que los usuarios encuentren una segunda verificación en mitad de la visita y se vayan.

Configura, observa una semana y ajusta. No empieces con valores extremos.

Combinar con WAF

A menudo no hace falta escudo global + revalidación frecuente. WAF + escudo selectivo funciona mejor:

1. WAF para tráfico malicioso obvio
   • Bloquear rangos IP maliciosos
   • Interceptar User-Agent anómalos
   • Limitar frecuencia de peticiones
2. Escudo solo en rutas críticas
   • Page Rules en login, registro, pago
   • Resto en Medium o High
3. Challenge Passage razonable
   • Sin obsesión con periodos mínimos
   • 30 minutos bastan para la mayoría

Así el 90% del tráfico malicioso lo filtra WAF y solo el 10% sospechoso pasa por el escudo.

Capítulo 5: 7 mejores prácticas para usar el escudo de 5 segundos

Práctica 1: no activarlo en todo el sitio de forma permanente

Error típico de principiantes: ataque, activas el escudo en pánico y lo dejas meses.

Enfoque correcto:

• Solo con ataque evidente
• Tras el ataque (1-3 días), baja a Medium o High
• Monitoriza con UptimeRobot u otras herramientas
• Recordatorio semanal para revisar el nivel de seguridad

Yo pongo alarma a las 48 horas tras activarlo para reevaluar si sigue siendo necesario.

Práctica 2: priorizar Page Rules para protección selectiva

Escudo en todo el sitio es la opción bruta, como soldar todas las puertas contra ladrones. Mejor cerrar solo las importantes.

Rutas a proteger:

1. Login (/login, /wp-login.php)
2. Registro (/register, /signup)
3. Panel (/admin, /wp-admin)
4. Pago (/checkout, /payment)
5. Formularios (/contact, /comment)

Rutas a excluir:

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

1. APIs (/api/*, /rest/*)
2. Estáticos (/*.jpg, /*.css, /*.js)
3. RSS (/feed, /rss.xml)
4. robots.txt y sitemap.xml
5. Health checks (/health, /status)

Configuración ideal para un blog técnico:

Regla 1: example.com/wp-admin* → I'm Under Attack
Regla 2: example.com/xmlrpc.php → I'm Under Attack (objetivo habitual en WordPress)
Regla 3: example.com/* → Medium

Práctica 3: personalizar la página de desafío

La página predeterminada está en inglés; en planes de pago puedes personalizarla.

Cómo:
Custom Pages → 5-Second Shield, sube HTML personalizado.

Elementos recomendados:

• Logo y nombre del sitio
• Texto en el idioma del usuario: Verificando la seguridad de tu navegador, espera un momento…
• Animación de cuenta atrás
• Motivo breve: Para proteger el sitio de ataques, debemos verificar que eres un usuario real
• Contacto por si hay problemas

El mejor caso que vi convirtió la espera en un minijuego de recoger estrellas; la experiencia mejoró mucho.

Práctica 4: combinar con reglas WAF

El escudo es la última línea; no debe cargar con todo. WAF filtra antes gran parte del tráfico malicioso.

Reglas WAF recomendadas:

Regla 1: bloquear rangos IP maliciosos

(ip.geoip.country in {"CN"} and cf.threat_score > 30)
→ Action: Block

(Solo ejemplo; ajusta según tu audiencia)

Regla 2: interceptar User-Agent anómalos

(http.user_agent contains "curl" or http.user_agent contains "python")
→ Action: Challenge

Regla 3: limitar frecuencia en API

(http.request.uri.path contains "/api/" and rate > 100/1m)
→ Action: Block for 1h

Regla 4: proteger login

(http.request.uri.path eq "/wp-login.php" and rate > 5/5m)
→ Action: Challenge

Con esto el 90% del tráfico malicioso se intercepta antes; el escudo solo trata lo sospechoso restante.

Práctica 5: lista blanca para crawlers de buscadores

Mejora mucho el SEO. Googlebot puede pasar el escudo, pero conviene facilitarle el rastreo.

Método 1: identificar User-Agent en WAF

Crea una WAF Custom Rule:

(http.user_agent contains "Googlebot" or
 http.user_agent contains "Bingbot" or
 http.user_agent contains "Baiduspider")
→ Skip: Security Level for this request

Los crawlers saltan el escudo.

Método 2: reducir seguridad para rangos IP de crawlers

Google, Bing, etc., publican rangos IP de sus bots. Crea IP Access Rules en lista blanca.

Referencia de Google:
https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot

Precaución:
Los atacantes pueden falsificar User-Agent. Más seguro validar IP y User-Agent, o usar verificación DNS inversa.

Práctica 6: monitorizar y ajustar

La configuración no es para siempre; requiere seguimiento.

Checklist semanal:

1. Security Events (Security → Events): bloqueos, reglas disparadas, IPs de origen; ¿falsos positivos?
2. Analytics: tendencia de tráfico, rebote, permanencia
3. Google Search Console: frecuencia de rastreo, cobertura, errores timeout o 403
4. Feedback: correo o redes con quejas de acceso difícil

Mi hábito: lunes a las 10:00, 15 minutos revisando todo y anotando en una hoja. Si hay anomalía, ajusto al momento.

Práctica 7: dominio dedicado para apps móviles

Si tienes app iOS/Android, usa un subdominio solo para la API.

Arquitectura:

• www.example.com — frontend web, puede tener escudo
• api.example.com — API sin escudo
• admin.example.com — panel con escudo + verificación extra

Seguridad en API:

• API Key o JWT
• WAF con límite de frecuencia
• Lista blanca de IPs de salida de la app

Ventajas:

1. La app móvil no se ve afectada
2. El frontend web puede usar escudo con tranquilidad
3. API y frontend desacoplados, más fácil de mantener
4. Estrategias CDN distintas por dominio

En un cliente con ataques frecuentes y 200 000 DAU en la app, con API en subdominio dedicado el escudo en la web no afectó a la app.

Conclusión

En resumen, tres ideas:

1. El escudo de 5 segundos es un arma de emergencia, no un escudo habitual

Como el freno de emergencia: salva en momentos críticos, pero no puedes conducir siempre pisándolo. Medium + WAF en normal; I’m Under Attack solo bajo ataque.

2. Page Rules son la clave del control preciso

No actives el escudo en todo el sitio: el coste supera el beneficio. Protege login, registro, pago, etc., y deja el resto con baja intrusión. Con 3 reglas gratuitas basta si las configuras bien.

3. Equilibrar seguridad y experiencia requiere ajuste continuo

No hay una configuración eterna. Según tipo de sitio, comportamiento de usuarios y ataques, monitoriza y afina. 30 minutos de Challenge Passage es un buen punto de partida, pero manda tus datos.

Lista de acción:

• Revisar ahora: ¿qué nivel de seguridad tienes en Cloudflare? Si es I’m Under Attack, evalúa si realmente lo necesitas.
• Configurar Page Rules: según el capítulo 3, al menos 2 reglas para protección selectiva.
• Ajustar Challenge Passage: según tu tipo de sitio (15-45 minutos).
• Probar: modo incógnito en distintas rutas.
• Recordatorio de monitorización: revisar semanalmente Security Events y Analytics.

Si este artículo te ayudó, compártelo con otros administradores que luchan contra DDoS. Si tienes más experiencia o dudas sobre el escudo de Cloudflare, comenta abajo.