Un spinner permanente significa que el frontal no alcanzó el estado de finalización esperado. La petición quizá no salió del navegador, quedó bloqueada por Cloudflare, falló en PHP o espera un servicio lento de correo o CAPTCHA.
No pulses varias veces: puedes crear leads duplicados aunque la pantalla continúe bloqueada.
Reproduce una vez con referencia única
Usa una sesión privada sin login, un valor de prueba inocuo y las herramientas del navegador abiertas antes de enviar.
Registra URL, hora, navegador, consentimiento, CAPTCHA y si al recargar aparece una entrada. Prueba otros dispositivos solo después de entender un recorrido.
Revisa la Consola
Busca excepciones JavaScript antes y después del clic. Conserva el primer error, archivo y stack, no la cascada posterior.
Los responsables habituales son optimización, formulario, tema, consentimiento, CAPTCHA y scripts externos. Desactiva una sola optimización sospechosa en staging, no todo JavaScript en producción.
Inspecciona la petición
En Red, localiza el POST, AJAX o REST:
sin petición -> falló el clic o validación
pending -> espera red, servidor o servicio externo
403 -> nonce, WAF, CAPTCHA o seguridad
404 -> endpoint, dominio o enlaces
500 -> error fatal PHP
200 con cuerpo inválido -> caché, proxy o pluginGuarda estado y extracto sin datos personales ni tokens.
Relaciona servidor y WordPress
Cruza hora o request ID con logs web, PHP y entradas del formulario. Un stack de 500 puede señalar el callback, memoria o timeout.
Activa diagnósticos sin mostrar errores públicamente. No registres nombres, emails, mensajes o archivos completos. Si existe entrada, el servidor procesó al menos una parte.
Prueba si el correo bloquea la respuesta
Algunos plugins envían de forma síncrona antes de responder. Una conexión SMTP lenta, DNS o timeout del proveedor deja al navegador esperando.
Revisa logs y compara en staging con notificaciones deshabilitadas pero guardando entrada. Si responde rápido, repara SMTP o desacopla el tiempo de notificación mediante el método compatible.
No dejes los avisos desactivados en producción sin un flujo alternativo.
Compara además la duración observada con los timeouts de CDN, servidor web, PHP y cliente SMTP. Si el proxy abandona a los 100 segundos pero PHP continúa, el visitante verá un fallo mientras el servidor todavía puede guardar o enviar. Añade identificadores idempotentes para impedir que un reintento cree otra entrada.
Comprueba seguridad y CDN
Cloudflare, ModSecurity y límites pueden bloquear cuerpos POST, endpoints o adjuntos. Busca el ID exacto del evento.
Crea una excepción limitada a la regla y endpoint comprobados, no a todos los POST. Purga caché solo si confirmas un script o nonce antiguo. Los endpoints de formularios no deben cachearse como contenido estático.
Verifica interfaz y resultado
Tras reparar, envía una vez. Confirma que el spinner termina, aparece un mensaje accesible y veraz, se guarda una única entrada y llega una sola notificación.
Prueba validación, consentimiento, CAPTCHA, adjuntos y teclado móvil. La analítica debe registrar conversión después de la confirmación del servidor.
Evita leads duplicados o abandonados
Comprueba si cada clic creó otra entrada antes de repetir. El botón puede deshabilitarse mientras existe una petición, pero debe reactivarse tras un error verdadero.
No escondas el spinner con un temporizador que muestre éxito. La interfaz debe obedecer a la respuesta real. Ante fallo, conserva campos seguros y ofrece reintento sin revelar rutas PHP o reglas.
Si las consultas son urgentes, publica un canal alternativo monitorizado hasta estabilizar el envío.
Cuándo pedir reparación
Solicita ayuda si el spinner produce entradas desconocidas o duplicadas, si el endpoint devuelve 403/500 o SMTP bloquea la respuesta. Facilita URL, hora, estado y error de Consola redactado.
La reparación debe corregir la petición y el feedback del usuario, no únicamente ocultar la animación.