Reproduce el camino que ha seguido el visitante
Un enlace del perfil de Instagram, el destino de un anuncio y una URL compartida en un mensaje son puntos de entrada distintos que conviene registrar. Estrechar una ventana de escritorio ayuda a revisar el diseño, pero no sustituye todos esos recorridos.
Apunta aplicación y versión, modelo de teléfono, sistema operativo, hora aproximada, enlace original y URL final. Incluye las redirecciones, los cambios de idioma y los avisos de consentimiento. Si el fallo ocurre al volver a un formulario que llevaba un rato abierto, reproduce también esa espera; no pruebes únicamente una página recién cargada.
Acuerda una referencia de prueba inocua con el responsable de la web. Decide dónde llegarán esas consultas para que ventas pueda separarlas de clientes reales. Evita rellenar el formulario en directo una y otra vez hasta comprobar si ya se ha aceptado una entrada. Una pantalla silenciosa puede ocultar un envío correcto cuya respuesta no ha regresado al teléfono.
Después repite en el navegador habitual de ese mismo móvil. Que allí funcione acota la investigación; no demuestra que Instagram, Facebook o el plugin estén siempre rotos. La pregunta útil es qué parte de ese recorrido concreto cambia el resultado.
Localiza el primer paso que falla
| Qué ve la persona | Qué revisar después | Qué no demuestra |
|---|---|---|
| No puede pulsar Enviar | Teclado, elementos fijos y zona que recibe la pulsación | Que WordPress haya recibido algo |
| Pulsa y no ocurre nada | Validación de campos e inicialización de scripts | Un fallo del servidor de correo |
| No puede adjuntar una foto | Selector, formato, tamaño y respuesta de subida | Que fallen todos los campos o todos los móviles |
| Aparece un error o se queda cargando | Petición, resultado de la aplicación y registro correspondiente | Si la entrada ya existe |
| Confirma el envío, pero falta el email | Generación de la notificación, salida y entrega al destinatario | Que el navegador haya impedido enviar |
Prepara una nota sencilla con una fila por prueba acordada: recorrido, hora, síntoma, resultado de la petición y existencia de entrada o notificación en destino. Hace falta comparar dos caminos, no acumular capturas sin fecha hasta perder de vista el problema.
Revisa primero el botón, el teclado y los campos
Abre el teclado y avanza como lo haría un cliente. ¿Se alcanzan el último campo y el botón? ¿Hay un pie fijo, un chat o una capa de consentimiento sobre la zona de pulsación? Gira el teléfono y vuelve al mismo campo. Un botón visible puede tener otro elemento por encima que reciba el toque.
Comprueba los campos obligatorios que aparecen tras una respuesta anterior. Un campo oculto inválido o un aviso fuera de pantalla pueden hacer que parezca que no ocurre nada. Prueba los formatos de email y teléfono que espera el negocio, incluidos números internacionales o nombres con acentos cuando corresponda.
La documentación de validación HTML explica cómo un campo inválido puede impedir el envío normal. El desarrollador debe revisar ese resultado, en lugar de saltarse la validación mediante un envío programado y dar el asunto por arreglado.
Mantén el error cerca del campo y explica cómo continuar. Un visitante obligado a adivinar cuál de doce respuestas está mal difícilmente premiará la investigación con otro intento.
Compara scripts, consentimiento y versiones en caché
Con la pulsación y la validación entendidas, comprueba si los scripts del formulario se inicializan por ambos caminos. Busca el primer error relevante de consola y la petición posterior al envío. Guarda el resultado antes de cambiar opciones: una prueba que funciona después de tocar cinco ajustes explica bastante poco.
WPForms documenta que la optimización JavaScript de LiteSpeed puede interferir con sus formularios y describe exclusiones concretas. Sirve para investigar un conflicto identificado, no para desactivar todas las mejoras de rendimiento de la web.
Trabaja con la página afectada y una comparación controlada. Cambia un ajuste relevante, refresca su caché y repite el mismo recorrido. Si mejora, acota la excepción y comprueba también el navegador habitual. Conserva la configuración anterior para poder deshacer la prueba.
Registra la elección de consentimiento, sin dar por hecho que se conserva al cambiar de navegador. Si una dependencia necesaria no arranca después de la elección prevista, revisa su integración. Pedir al cliente que acepte todos los rastreadores opcionales no es una solución permanente para enviar una consulta.
Cuando lo que falla es una foto, un CV o un adjunto
Un formulario que pide una fotografía, un briefing o un currículum añade otro tramo al recorrido. Primero distingue si abre el selector. Después comprueba si el archivo elegido llega al punto de subida y si se acepta su tipo y tamaño. «No funciona el adjunto» puede describir tres fallos distintos.
WPForms documenta limitaciones de subida en algunos navegadores integrados de Facebook e Instagram en Android. Es una posibilidad respaldada para ese entorno, no una afirmación sobre todas las versiones de las aplicaciones ni todos los formularios WordPress.
En una copia autorizada, compara un archivo pequeño permitido con el tipo de archivo que el cliente suele elegir. Una foto de cámara y un documento pequeño guardado son dos casos útiles. No elimines restricciones de subida en toda la web porque se haya rechazado un archivo desconocido.
Si temporalmente hace falta abrir el navegador externo, explícalo antes de que la persona dedique tiempo a rellenar. Indica si tendrá que introducir los datos otra vez y ofrece una vía de contacto alternativa acordada. El apaño debe conservar una forma de consultar mientras se investiga la limitación.
Lee el resultado del envío antes de culpar al correo
Cuando existe una petición, revisa la respuesta de la aplicación además del código HTTP. Una respuesta HTTP correcta puede contener un error de validación o del plugin. Si hay un bloqueo, busca el registro correspondiente del servidor o la capa de protección; no demuestra automáticamente que la aplicación social sea la culpable.
En Contact Form 7, la guía oficial de errores distingue problemas de correo y envíos considerados sospechosos de spam. Lee el resultado real: el tema puede modificar el aspecto del borde.
Si ninguna petición llega a WordPress, cambiar las credenciales SMTP no arregla ese paso ausente. Si el formulario se aceptó y falta la notificación, sigue el mensaje. WordPress recuerda que un resultado correcto de wp_mail() no demuestra la recepción final.
Antes de repetir tras un tiempo de espera agotado, busca la entrada o el mensaje con la referencia de prueba. Confirma qué plugin almacena entradas, si alguno lo hace, y cuál es el sistema de destino. Generar dos consultas al reintentar es otro problema que resolver; no prueba que el primer envío no ocurriera.
Una buena vista previa no demuestra el recorrido desde redes
La diferencia importa: un listado ordenado de formularios configurados ayuda al editor a saber dónde trabajar. No demuestra qué sucede cuando un cliente pulsa un enlace social, abre el teclado, elige un archivo y espera una confirmación.
Conserva juntas la revisión de configuración y las pruebas del recorrido. La primera explica qué debería ocurrir; la segunda registra qué ocurrió en el camino afectado. Ninguna puede sustituirse por una vista previa bonita.
Si está llegando tráfico de pago mientras falla el formulario
Facilita al responsable de campañas el destino afectado y el recorrido que reproduce el fallo, no solo «el formulario está roto». Acordad si una página alternativa ya comprobada o una vía de contacto puede conservar la consulta mientras se investiga. La persona que prepara los resultados debe conocer el cambio temporal y su retirada posterior.
Compara cada paso por separado: clic publicitario, visita a la página, evento de éxito del navegador, entrada aceptada y consulta cualificada son observaciones distintas. Que suba una no demuestra que suban todas. Si la medición no distingue con fiabilidad las visitas del navegador integrado, indícalo en lugar de inventar su tasa de conversión.
Ejemplo ilustrativo: el mismo documento pequeño permitido abre el selector en el navegador habitual, mientras que el recorrido afectado desde la aplicación ni siquiera lo muestra. Eso orienta la siguiente investigación hacia el selector y el punto de entrada. No demuestra que el correo funcione, que fallen todos los adjuntos ni que haga falta cambiar de plugin.
Registra con campañas la hora de los cambios de destino o formulario. De lo contrario, el recuento posterior puede mezclar experiencias diferentes y dificultar la valoración. Pide a ventas que identifique las referencias de prueba acordadas y trate las consultas reales con su proceso habitual. El resultado útil es una persona que consigue consultar y un equipo capaz de explicar qué ha ocurrido.
Acuerda cuándo se puede dar por reparado
Después de una corrección acotada, repite la entrada original desde la red social y la comparación en el navegador habitual, con los dispositivos reales relevantes. Incluye consentimiento, campos condicionales y adjuntos implicados. Una captura de escritorio confirma aspectos visuales; no certifica una prueba dentro de una aplicación.
- El cliente alcanza y utiliza los campos y el botón necesarios.
- La validación explica los problemas recuperables en una zona visible.
- El envío aceptado genera el registro esperado cuando ese almacenamiento está configurado.
- La notificación o el traspaso posterior acordado se comprueban por separado.
- La persona recibe un resultado claro y no necesita pulsar repetidamente.
Entrega versiones de aplicación y dispositivo, fecha, cambio y limitaciones pendientes. Si se mantiene una solución temporal, indica quién se responsabiliza y cuándo se revisará. Es una propuesta de aceptación, no el informe de una reparación o una prueba de dispositivos realizada para tu negocio.
¿Por qué falla un formulario WordPress dentro de Instagram o Facebook?
Si el formulario funciona en Safari o Chrome, pero falla al abrir el enlace desde Instagram o Facebook, compara el recorrido completo antes de tocar el correo. El fallo puede estar en la pulsación, la validación, los scripts, el selector de archivos, la petición de envío o la notificación. «En mi móvil funciona» aporta poco si has abierto la página en otro navegador.
Empieza con el mismo destino desde la aplicación afectada y desde el navegador habitual del teléfono. Mantén comparables el dispositivo, los datos de prueba y las condiciones. Anota el primer paso que cambia. No todos los navegadores integrados tienen las mismas limitaciones ni todo envío fallido es un problema de SMTP.
Esta guía está pensada para negocios que pierden consultas desde tráfico social. Si también falla fuera de esas aplicaciones, empieza por el formulario WordPress funciona en escritorio, pero falla en móvil.