Tu formulario tiene un campo de nombre, uno de correo y un botón que dice enviar. No manda nada a ningún lado. No falla, no muestra un error, no se rompe: la página parpadea, los campos se vacían y todo parece haber salido bien. Por eso puede llevar meses así.
Es el estado normal de un formulario en un sitio estático, y no es un descuido de quien lo hizo. La IA que escribió tu sitio escribió el formulario correctamente: lo que falta es la mitad que no es HTML.
Por qué un formulario en HTML no manda nada
Un <form> sabe hacer una sola cosa: empaquetar lo que escribió el visitante y entregarlo en una dirección. Esa dirección es el atributo action. El navegador cumple su parte siempre; lo que decide todo es qué hay del otro lado.
Y un sitio estático son archivos —HTML, CSS, imágenes, JavaScript— servidos tal cual. Del otro lado no hay nadie escuchando: ningún programa que reciba ese paquete, lo guarde y te avise. Por eso el formulario no falla. Nunca llegó a intentarlo.
Es la misma frontera que separa un sitio de una app: publicar archivos es una cosa, y recibir algo de vuelta es otra. Un formulario es lo primero que la cruza.
Cómo saber en treinta segundos si el tuyo está muerto
No necesitas herramientas. Abre tu sitio ya publicado, presiona Ctrl+U (Cmd+Option+U en Mac) para ver el código y busca la etiqueta <form>:
| Lo que dice tu código | Lo que pasa cuando alguien envía |
|---|---|
<form> sin action, o action="#" | La página se recarga sobre sí misma. El envío se pierde y no queda registro de que existió. |
action="mailto:tucorreo@…" | Se intenta abrir el programa de correo del visitante. En un celular, casi siempre no pasa nada. |
un onsubmit que muestra "¡Gracias!" | El mensaje de gracias es real; el envío no. Es el más engañoso de los tres, porque te confirma algo que no ocurrió. |
action="https://…" | Sí sale del navegador. Ahora la pregunta es a dónde llega y quién te avisa. |
Y la prueba que no admite discusión, que toma diez segundos: llénalo y mándalo desde el sitio publicado, no desde tu computadora. Si en dos minutos no te llegó nada a ningún lado, ya tienes tu respuesta.
Qué no hacer
- No lo resuelvas con
mailto:. Depende de que el visitante tenga un programa de correo configurado, y en el teléfono casi nadie lo tiene. El que sí lo tiene ve abrirse una app que no pidió, con un borrador a medio llenar, y cierra. Además deja tu dirección escrita en el HTML, que es justo donde la buscan los rastreadores de spam. - No pongas la llave de un servicio de correo en el JavaScript. Es lo que suele salir cuando le pides a la IA "que el formulario mande un correo", y esa llave queda publicada para cualquiera que abra tu sitio — qué llaves se publican y cómo revisarlo.
- No montes un backend para tres campos. Un servidor que existe sólo para recibir un formulario es una pieza que vas a tener que mantener, actualizar y pagar durante años. El trabajo no termina el día que funciona.
Las salidas que sí sirven
Todas hacen lo mismo: poner a alguien escuchando en esa dirección. Se diferencian en cuánto te cuesta mantenerlo:
- Un servicio de formularios: apuntas el
actiona una URL suya, ellos guardan el envío y te avisan. Es la de menos trabajo, y la que agrega una cuenta más. - Una función serverless propia: control total sobre qué pasa con cada envío, a cambio de código que mantener y una factura más que vigilar.
- La plataforma donde ya vive tu sitio, si lo trae incluido. Misma idea que la primera, sin la cuenta extra ni un segundo lugar donde buscar tus leads.
Cómo se hace en FluentOps
Forms viene con la plataforma. Se activa por proyecto y te devuelve una dirección propia; no hay librería que instalar ni JavaScript que escribir.
- En tu proyecto, activa Forms. Te da un endpoint con tu token:
https://api.fluentops.org/forms/TU_TOKEN. - Pon esa dirección en el
actionde tu formulario, conmethod="POST". - Publica. Los nombres de tus campos son los que ya tenías — no hay nada que declarar ni configurar.
<form action="https://api.fluentops.org/forms/TU_TOKEN" method="POST">
<input name="nombre" />
<input name="correo" type="email" />
<textarea name="mensaje"></textarea>
<!-- Trampa para bots: si la llenan, el envío se guarda marcado y no te avisa. -->
<input name="_gotcha" style="display:none" tabindex="-1" autocomplete="off" />
<!-- A dónde vuelve el visitante después de enviar. -->
<input type="hidden" name="_redirect" value="https://tusitio.com/gracias.html" />
<button type="submit">Enviar</button>
</form>Cada envío queda en la bandeja de tu proyecto en el portal y te llega por correo en el momento. Los dos campos ocultos del ejemplo son opcionales y valen la pena: _redirect manda al visitante a tu propia página de gracias (sin él vuelve a la página de donde salió), y _gotcha es una trampa para bots — un campo que una persona no ve y un robot sí llena. Si llega con algo escrito, el envío se guarda marcado como spam y no te interrumpe.
Si tienes más de un formulario en el mismo sitio, agrega form-name con el nombre que quieras y la bandeja los separa. Los límites, para que no te enteres el día que te topen: 100 envíos al mes en el plan gratis —de la cuenta completa, no por proyecto— y 1000 en Pro; 256 KB por envío, hasta 100 campos y 8000 caracteres cada uno.
Y una decisión que vale la pena conocer: pasado el límite, el envío se sigue guardando. Te avisa que lo rebasaste, pero no se tira. Un lead perdido no se recupera, y castigar al que te escribió por un tope tuyo es la peor forma posible de cobrar.
El paso que casi nadie hace
Conectarlo no es terminarlo. Mándate un envío de prueba desde el sitio publicado, desde el teléfono, como lo haría un visitante — y revisa que haya llegado a los dos lugares: la bandeja y tu correo. Es el único momento en que compruebas la cadena completa, y es exactamente el paso que faltó las primeras dos veces que tu formulario "funcionó".
Repítelo cada vez que cambies el sitio de dirección o rehagas la página de contacto. Un formulario roto se ve idéntico a uno que anda.
Y si tu sitio todavía no está en línea, aquí está cómo publicarlo — el formulario lo conectas después, sobre el mismo proyecto.