Cómo reCAPTCHA evalúa las señales en tu propia aplicación

Alcance seguro: esta guía aplica solo a tus entornos de QA, staging y preproducción autorizados. Cubre diagnóstico, pruebas y observabilidad de tu propia integración de CAPTCHA, no de sitios de terceros.

reCAPTCHA decide si confía en una sesión mucho antes de que la persona marque la casilla: combina señales de comportamiento, de sesión y de telemetría en una puntuación silenciosa que determina si aparece un desafío y con qué dificultad. Si lo integras en tu propia aplicación, la pregunta útil no es cómo esquivarlo, sino qué mide y cómo afecta a tus usuarios legítimos.

Empieza por medir: las tres cifras de reCAPTCHA que importan

• La tasa de aparición del desafío v2: cuántas sesiones ven la casilla o el reto de imágenes.
• La distribución de puntuaciones de v3 por acción (login, checkout, alta), para ver qué flujos concentran las puntuaciones bajas.
• Los tiempos de validación en tu backend, del token recibido a su confirmación.

Qué señales evalúa reCAPTCHA (y por qué no se "apagan")

reCAPTCHA no lee una sola variable. Agrega familias de señales que ninguna opción de tu lado desactiva, porque se evalúan en el servidor del proveedor y no en el navegador. Conocerlas no sirve para esquivarlas, sino para no penalizar sin querer a un usuario real cuyo tráfico se parezca al de un bot:

• Edad y reputación de la cuenta, junto al historial asociado a ella.
• Consistencia de la sesión: cookies persistentes y continuidad entre visitas.
• Patrones de navegación: ritmo, orden de interacción y coherencia del recorrido.
• Coherencia del locale: idioma, zona horaria y cabeceras que encajan entre sí.

Un ejemplo cercano: el portal de cita previa

Piensa en un portal de cita previa —un trámite de extranjería o un centro de visados BLS— con el formulario protegido por reCAPTCHA. Un user-agent distinto en CI o un viewport minúsculo bastan para hundir la puntuación de v3 y que el formulario exija desafíos a personas reales. Sin métricas eso llega como "quejas de usuarios"; con ellas sabes qué acción y qué entorno dispararon la regresión.

Iguala la configuración del navegador en todos tus entornos

Usa el mismo viewport, idioma y user-agent por defecto en todos tus runners de QA, staging y CI. Es la causa número uno de tests que pasan en local y fallan en CI sin motivo aparente:

from selenium import webdriver

def make_driver(headless: bool = True) -> webdriver.Chrome:
    options = webdriver.ChromeOptions()
    if headless:
        options.add_argument('--headless=new')
    options.add_argument('--window-size=1280,800')
    options.add_argument('--lang=es-ES')
    return webdriver.Chrome(options=options)

Síntomas frecuentes y qué revisar primero

El flujo de integración, paso a paso

En tu propio staging, CaptchaAI te deja ejercitar este flujo de forma reproducible en cada commit. El patrón es siempre el mismo, sea cual sea tu framework de pruebas:

1. Tu test detecta el widget de CAPTCHA en tu propia página (QA, staging o preproducción).
2. Envía a CaptchaAI los datos públicos del widget: sitekey, URL de la página y tipo de CAPTCHA.
3. CaptchaAI devuelve un token válido para esa página.
4. Tu test inyecta el token en el campo correspondiente y envía el formulario.
5. Tu backend verifica el token con el proveedor, igual que con un usuario real.

Este flujo se aplica solo a integraciones que tú controlas; no sirve para sortear protecciones de sitios ajenos.

Qué registrar en tus pipelines de QA

• Tiempo de resolución por intento, desde la solicitud a CaptchaAI hasta la entrega del token.
• Tasa de éxito por endpoint propio: verificaciones de backend que pasan sobre el total de intentos.
• Distribución de errores por código (ERROR_*, timeouts internos, fallos de red).
• Latencia extremo a extremo: render, resolución del CAPTCHA y respuesta de tu backend.
• Trazas conservadas (logs, capturas, HAR) para reproducir incidentes intermitentes.

Buenas prácticas en tu entorno de QA

• Prueba siempre sobre tu propia aplicación o sobre entornos explícitamente autorizados.
• Mantén una API key de CaptchaAI separada para QA, distinta de la de producción, para no mezclar métricas.
• Define timeouts y reintentos razonables (backoff exponencial) para no acumular trabajos pendientes durante una caída.
• Versiona los snapshots de configuración (sitekey, action, umbrales) con el código de los tests.

Preguntas frecuentes

¿Puedo reducir la aparición de reCAPTCHA para mis usuarios legítimos?

En parte. No controlas el motor de puntuación, pero sí las señales de tu lado: sesiones consistentes, cookies persistentes y un locale coherente. Mide primero la distribución de v3 por acción y actúa sobre las que concentran puntuaciones bajas.

¿Qué tipos de CAPTCHA puedo ejercitar en mi propio QA con CaptchaAI?

Los tipos compatibles: reCAPTCHA v2 y v3, Cloudflare Turnstile y Challenge, GeeTest v3, imágenes/OCR y grid, además de CaptchaFox (beta), Friendly Captcha (beta) y Lemin (beta). CaptchaAI no resuelve hCaptcha ni FunCaptcha, y GeeTest v4 está próximamente.

¿Con qué frecuencia cambia Google los criterios de reCAPTCHA?

De forma continua, con ajustes mayores cada pocos meses. Por eso conviene instrumentar las métricas anteriores: cuando algo cambie, lo verás en tu tasa de aparición y en la distribución de puntuaciones.

¿Cómo manejo los fallos intermitentes de CAPTCHA en mi CI?

Aísla el paso de CAPTCHA en una función con reintentos controlados y backoff exponencial, y registra métricas por intento. Así separas los fallos de red de los timeouts del proveedor y de los errores de configuración.

Guías relacionadas

• Inicio rápido de CaptchaAI
• QA autorizado de CAPTCHA
• Pruebas de endpoints de CAPTCHA en formularios propios
• Cuando la API funciona pero el test de navegador falla
• Resolver reCAPTCHA v2 con la API
• Resolver Cloudflare Turnstile con la API

Valida tus integraciones de CAPTCHA en entornos propios con CaptchaAI.