reCAPTCHA tiene una parte en el navegador que obtiene un token y otra en el servidor que lo verifica. El script puede no cargar, la clave no coincidir con el hostname, el token caducar o un umbral rechazar tráfico legítimo.
Determina qué lado falla antes de sustituir o desactivar la protección.
Reproduce el contexto del visitante
Anota página, hostname, hora, dispositivo, navegador y red. Usa datos sintéticos e inspecciona consola y actividad de red.
Comprueba si carga la API, si se solicita token y qué devuelve el endpoint final. No copies tokens; son datos de seguridad temporales.
Prueba sin sesión y siguiendo el flujo normal de consentimiento.
Relaciona la petición con los códigos devueltos por la verificación, como secret inválido, token ausente, duplicado o caducado. Conserva solo el nombre del error y la hora; el código orienta hacia configuración, navegador o reutilización sin guardar el token.
Verifica tipo de clave y hostname
Confirma que site key y secret pertenecen a la misma versión y proyecto. Una clave v2 checkbox no sustituye v3, y las variantes invisibles tienen requisitos distintos.
Revisa dominios autorizados para host canónico, www/sin www y subdominio de producción. Una migración suele dejar únicamente el dominio antiguo.
Separa credenciales de staging y nunca expongas el secret en el HTML.
Revisa consentimiento y bloqueo
Un gestor de cookies puede bloquear scripts de Google hasta consentir. Decide con el responsable de privacidad si CAPTCHA es seguridad esencial o servicio sujeto a consentimiento y aplica esa clasificación con coherencia.
Si el script queda bloqueado, el formulario no debe permanecer inutilizable en silencio. Ofrece explicación accesible y alternativa aprobada.
Inspecciona CSP y errores de privacidad en vez de pedir desactivar protecciones.
Comprueba optimización y orden
Delay, defer o combinación pueden ejecutar el formulario antes de que la API esté lista. Busca callbacks inexistentes, cargas duplicadas y condiciones de carrera.
Excluye solo los handles demostrados y regenera assets. No desactives toda la optimización.
Revisa widgets duplicados o popups que inicialicen la API más de una vez.
Diagnostica la caducidad
Los tokens duran poco y suelen ser de un solo uso. Un formulario largo puede llegar al final con token caducado.
Compara un recorrido rápido y uno tras el retraso reportado. Refresca mediante el flujo compatible justo antes de enviar, no amplíes la aceptación indefinidamente.
Evita que un doble envío reutilice el mismo token.
Si el formulario falla y permite reintentar, genera un token nuevo para el segundo intento. Restaurar el mismo estado visual sin renovar reCAPTCHA produce otro rechazo aunque el visitante haya corregido los campos.
Revisa puntuación y acción de v3
Para reCAPTCHA con score, inspecciona en el servidor el resultado, nombre de acción y puntuación de pruebas controladas. La acción esperada debe coincidir con la solicitada por el navegador.
Ajusta el umbral con tráfico legítimo y compleméntalo con honeypot o rate limiting. No publiques detalles que ayuden a evadir controles.
Ofrece revisión manual o alternativa para consultas limítrofes. Prueba teclado, zoom y anuncios de lector de pantalla.
Verifica la comunicación del servidor
WordPress debe alcanzar el endpoint de verificación y validar la respuesta. Revisa DNS, HTTPS saliente, confianza CA, reloj y errores PHP.
No omitas la verificación TLS ni aceptes una respuesta sin comprobar success, hostname, action y campos relevantes.
Guarda solo el resultado mínimo, nunca tokens o cuerpos completos.
Demuestra rutas válidas e inválidas
Tras reparar, prueba escritorio y móvil real con el estado normal de consentimiento. Confirma una entrada, notificación y llegada final.
Prueba caducidad y un token inválido aprobado para que el visitante reciba un error útil y la protección siga activa.
Solicita reparación urgente si no se conoce al propietario de las claves, las puntuaciones legítimas varían demasiado o la privacidad entra en conflicto. Comparte hostname y errores redactados, nunca secrets, tokens o datos.