Un fallo exclusivo de móvil puede proceder del diseño responsive, validación, teclado, capas táctiles, JavaScript, CAPTCHA o red. Un test de escritorio no reproduce esas condiciones.
Identifica si el botón no se puede pulsar, la petición falla o el mensaje se entrega sin feedback.
Reproduce en un móvil real
Usa un perfil limpio y el tipo de red informado cuando sea posible. Registra dispositivo, sistema, navegador, orientación, URL, hora y consentimiento.
Introduce una referencia única. No pulses repetidamente un botón congelado; revisa las entradas antes. La emulación ayuda con diseño, pero no reproduce teclado, políticas de Safari o red celular.
Inspecciona obstáculos táctiles
Comprueba si un pie fijo, chat, banner de cookies o capa transparente cubre Submit. Prueba zoom, horizontal y teclado abierto.
Usa inspección remota para saber qué elemento recibe el toque. Corrige stacking y espacio en la fuente. No eleves sin más el z-index del formulario por encima de consentimiento o navegación.
Revisa valores introducidos en móvil
Los teclados de email, teléfono o fecha pueden añadir espacios, puntuación inteligente o formatos locales. La validación cliente puede rechazarlos sin mostrar un error visible.
Mantén labels y errores por encima del teclado y mueve el foco al primer campo inválido. Usa tipos semánticos, pero valida y sanea también en servidor. Prueba nombres acentuados y teléfonos internacionales previstos.
Captura JavaScript y red
Usa depuración remota o herramientas con el mismo navegador. Localiza el primer error y el estado de la petición.
Una red lenta revela carreras: expira el token CAPTCHA, llega tarde una dependencia o vence el request. No eleves timeouts sin confirmar si el servidor recibió y guardó la entrada.
Prueba también el modo de ahorro de datos y navegadores integrados de redes sociales si forman parte del tráfico real. Pueden aplazar scripts, bloquear ventanas o modificar cookies de una manera que Chrome de escritorio no reproduce.
Prueba CAPTCHA, consentimiento y privacidad
Bloqueadores móviles, protección estricta o estado del consentimiento pueden impedir cargar scripts externos. El formulario debe seguir siendo comprensible y mostrar un error específico si no carga la verificación.
Revisa dominio y clave del proveedor y CSP. No desactives CAPTCHA para todo móvil; corrige integración o usa otro control compatible. Prueba aceptación y rechazo de consentimiento opcional según la configuración aprobada.
Compara variantes responsive y caché
Un constructor puede generar formularios separados para escritorio y móvil u ocultar una copia con CSS. Pueden duplicarse IDs o nonces e inicializarse scripts dos veces.
Inspecciona DOM y Red. Prefiere un formulario responsive único. Revisa variantes móviles de CDN por scripts o tokens antiguos y purga solo después de corregir la fuente.
Verifica servidor, notificación e interfaz
Tras reparar, prueba iOS/Safari y Android/Chrome cuando sean relevantes. Confirma éxito HTTP, una entrada, un email y una confirmación accesible.
Prueba validación, rotación, navegación atrás y adjuntos. La conversión de Analytics debe dispararse solo tras confirmar el servidor.
Prueba las limitaciones reales
Utiliza al menos un dispositivo real con datos móviles y otro con Wi-Fi. Registra versión, hora y si llegó la petición.
Comprueba que los campos aceptan datos realistas sin autocorrecciones perjudiciales. Mantén el error junto al campo y desplaza el foco para que el visitante no quede bloqueado fuera de pantalla.
Para uploads, prueba una foto autorizada desde la cámara con formato y tamaño habituales. El límite, HEIC u otra regla de seguridad puede fallar solo con archivos móviles.
Cuándo pedir reparación móvil
Solicita ayuda si intervienen overlays, Safari, CAPTCHA o caché móvil. Facilita dispositivo, navegador, URL, hora y error redactado, sin datos personales.
La reparación debe hacer fiable el recorrido móvil real, no solo superar la emulación de escritorio.