Sitios, migración y Astro 7 min

Formulario y búsqueda en un sitio estático: cómo hacerlo

En un sitio estático, cada función dinámica se conecta por separado: un formulario envía sus datos a una pequeña función de servidor que los guarda en una base de datos y después avisa por correo, la búsqueda interna consulta un índice creado en la publicación, y las pocas páginas que cambian en cada visita se renderizan bajo demanda.

Índice7
  1. 01¿Dónde se ejecuta el código de un sitio estático?
  2. 02¿Cómo añadir un formulario a un sitio estático?
  3. 03¿Cómo añadir una búsqueda interna?
  4. 04¿Dónde guardar la lista de un boletín?
  5. 05¿Y las páginas que cambian en cada visita?
  6. 06Por dónde empezar
  7. 07Preguntas frecuentes

La objeción que más se oye cuando se propone un sitio estático: «Pero tenemos un formulario, una búsqueda, un boletín». Añadir un formulario o una búsqueda a un sitio estático no exige convertir todo el sitio en una aplicación: cada necesidad se trata por separado, página a página.

Esta guía repasa las necesidades dinámicas más habituales y la forma de conectarlas. Da por tomada la decisión; si aún no lo está, empiece por por qué migrar a un sitio estático con Astro.

¿Dónde se ejecuta el código de un sitio estático?

Un sitio estático genera sus páginas en el momento de la publicación. Lo que debe reaccionar a una acción del visitante (enviar un mensaje, buscar una palabra, suscribirse) se confía a un servicio dedicado, llamado desde la página.

Con Astro, la frontera es explícita: por defecto, todo el sitio se prerrenderiza en HTML, y una página concreta puede renderizarse bajo demanda con una sola línea, export const prerender = false, siempre que se instale un adaptador para el proveedor de alojamiento. El resto del sitio no cambia.

Es el caso de un webhook, la dirección a la que llama un servicio externo para avisar de un pago confirmado o de un mensaje recibido: debe ejecutar código en cada llamada, algo que ninguna página generada de antemano sabe hacer.

¿Cómo añadir un formulario a un sitio estático?

El circuito

Un formulario de contacto en un sitio estático funciona en tres tiempos:

El recorrido de una solicitud, del formulario a los correos

  1. El formulario

    La página envía los campos a una pequeña función de servidor (una función de Netlify, un Worker de Cloudflare, una Edge Function de Supabase).

  2. El registro

    La función comprueba los datos y los guarda en una base de datos o en el CRM.

  3. Los correos

    Una vez hecho el registro, la función envía el correo de notificación y la confirmación al visitante.

La regla que evita perder solicitudes

El orden de las etapas 2 y 3 no es un detalle. Una solicitud que solo existe en un correo desaparece sin dejar rastro en cuanto falla el envío, por un cupo alcanzado o una dirección mal configurada.

Sobre el terreno

En Palmora Property, un envío fallido pasaba por un éxito

Un cliente lo aprendió por las malas. Las solicitudes de Palmora Property, un sitio inmobiliario al que acompañamos, pasaban al principio solo por el correo, sin garantía: un envío fallido se perdía sin aviso, y el visitante recibía igualmente una respuesta de éxito. El circuito guarda ahora cada solicitud en la base de datos antes de enviar el menor correo.

De ahí la regla que hay que aplicar en todas partes: primero la base de datos, después el correo. Un correo que falla se vuelve a enviar. Una solicitud nunca registrada se pierde.

Los servicios de formularios listos para usar

Varios proveedores de alojamiento ofrecen una gestión de formularios integrada: se añade un atributo al formulario HTML y los envíos aparecen en una interfaz. Es práctico para un sitio corporativo que recibe pocas solicitudes. Tres preguntas que hay que hacerse antes de confiar en ello:

  • ¿dónde se almacenan los datos, y se pueden exportar?
  • ¿llegan las solicitudes al CRM, o hay que copiarlas a mano?
  • ¿qué ocurre por encima del cupo de la oferta?

Para una empresa que vive de sus solicitudes entrantes, preferimos una función que guarde la solicitud y después la cree en el CRM. Llega allí con su origen, sin volver a teclearla.

Contra los robots

Un formulario público recibe envíos automáticos. Tres redes sencillas, todas verificadas en el servidor: un campo oculto que solo rellena un robot, un tiempo mínimo en la página antes del envío y un límite de envíos por hora. Son las de la suscripción al boletín del blog de Challenge Us, una aplicación de retos en grupo que hemos desarrollado, con además un doble opt-in: la dirección solo se inscribe tras un clic en el correo de confirmación.

¿Cómo añadir una búsqueda interna?

Un índice creado en la publicación

Una búsqueda interna no necesita un servidor de búsqueda. En el momento de la publicación, un script recorre las páginas y crea un índice; en el navegador, un pequeño programa consulta ese índice.

Pagefind, una biblioteca de búsqueda totalmente estática, divide su índice en fragmentos, y una búsqueda solo carga una pequeña parte. Sus autores indican el volumen total que hay que transferir:

300 KB

es el techo para una búsqueda de texto completo en un sitio de 10 000 páginas, biblioteca incluida

100 KB

es más bien el volumen para la mayoría de los sitios

Fuente: Pagefind, página de presentación de la biblioteca

Challenge Us escribió su propio índice, en dos archivos: uno para su blog y otro para su base de conocimientos, creados en la publicación a partir de las mismas listas que las páginas y cargados con la primera pulsación en el campo, unos 130 KB comprimidos para el del blog en septiembre de 2026. Ambos enfoques funcionan en un alojamiento estático, sin servicio de pago.

Lo que hay que prever

  • Acentos y mayúsculas indiferentes: «reunion» debe encontrar «Réunion».
  • Un extracto que muestre por qué aparece el resultado. Un título solo no basta cuando la palabra buscada está en el cuerpo de la página.
  • Ninguna dirección por búsqueda. Si cada búsqueda tecleada se convierte en una página que los buscadores pueden rastrear, el sitio se llena de páginas sin contenido propio. La búsqueda se hace dentro de la página, sin nueva dirección.

¿Dónde guardar la lista de un boletín?

La suscripción a un boletín sigue el circuito del formulario. Dos decisiones cuentan:

  • Dónde vive la lista. Puede vivir en un servicio de envío de correos, o en su base de datos, enviada después al servicio. Conservar la lista en casa permite guardar la prueba del consentimiento (la frase marcada, la fecha, la página) y cambiar de servicio sin perder a nadie.
  • El doble opt-in. Protege de las suscripciones hechas por robots o con la dirección de otra persona, y es la prueba más sencilla de que el consentimiento procede del titular de la dirección.

¿Y las páginas que cambian en cada visita?

Algunas páginas no pueden generarse de antemano: un área de clientes, un carrito, un panel de control. Con Astro, se renderizan bajo demanda, una a una, mientras el resto del sitio sigue siendo estático. El coste es el de las funciones ejecutadas, un punto que hay que vigilar en el proveedor de alojamiento: detallamos lo que se cobra según el proveedor.

Cuando esas páginas se vuelven numerosas y todo el sitio depende de datos que cambian a lo largo del día (un catálogo de inmuebles, disponibilidades), un renderizado en servidor asumido, con una caché bien ajustada, es más sencillo que un sitio estático improvisado.

Lo esencial

Lo estático sigue siendo la buena elección mientras la mayoría de las páginas cambie al ritmo de las publicaciones, no de las visitas.

Por dónde empezar

Haga la lista de todo lo que debe reaccionar en su sitio actual: formularios, búsqueda, suscripciones, área de clientes. Cada línea encuentra su sitio en uno de los circuitos anteriores, y es esa lista la que dirá lo que el alojamiento tendrá que ejecutar y cobrar.

Si su sitio funciona hoy con WordPress, Drupal o Joomla, nuestra migración a un sitio estático parte de un inventario de sus páginas y compara cada página con el sitio antiguo antes de la puesta en línea.

Preguntas frecuentes

¿Es menos seguro un formulario en un sitio estático?

No, a menudo lo es más. No hay panel de administración ni extensiones expuestas: solo una pequeña función recibe los datos. Debe validar cada campo en el servidor, limitar el número de envíos y no devolver nunca un error detallado al visitante. Las claves de acceso al CRM o al servicio de correo permanecen en la función, nunca en el código de la página.

¿Se puede conectar el formulario directamente al CRM?

Sí. La función de servidor llama a la API del CRM (Twenty, Odoo, HubSpot u otro) y crea el contacto o la solicitud. Añada a cada envío la página de origen, el idioma y los parámetros de campaña (UTM): sin ellos, es imposible saber qué canal trae las solicitudes. Y mantenga el registro en la base de datos antes de la llamada al CRM, para que una caída de este no haga perder nada.

¿Hace falta un servicio de pago para la búsqueda interna?

No para un sitio de unos cientos o miles de páginas. Basta un índice creado en la publicación, que se sirve como los demás archivos del sitio. Un servicio dedicado se justifica para un catálogo muy voluminoso, con filtros, sinónimos y ordenación por relevancia comercial, o cuando los resultados deben seguir un stock que cambia a lo largo del día.

¿Qué pasa si la función del formulario se cae?

Las páginas siguen en línea, ya que son archivos: solo falla el envío. Prevea en la página un mensaje de error claro, con una dirección de correo alternativa, en lugar de un botón que gira sin fin, y una alerta que le avise de la caída. Si lo que cae es el servicio de correo, la solicitud ya guardada en la base de datos no se pierde.

¿Cómo publican los equipos de marketing en un sitio estático?

Desde un editor, no en el código. El contenido vive en archivos Markdown o en un CMS headless como Sanity, y cada publicación reconstruye el sitio, con una vista previa antes de la puesta en línea y la posibilidad de volver a la versión anterior. La herramienta adecuada depende de quién publica y con qué ritmo: lo detallamos en nuestro artículo sobre Astro y Sanity.

Fuentes

  1. Por defecto, todo el sitio se prerrenderiza (nueva pestaña)docs.astro.build
Fuente 1

Por defecto, todo el sitio se prerrenderiza

Leer en docs.astro.build(nueva pestaña)

Jim · fundador de Brain Plus AI

Más artículos sobre sitios, migración y astro

  • Entender9 min La guía del tema

    Migrar a un sitio estático con Astro sin perder el SEO

    Un sitio estático generado con Astro sustituye a un WordPress o un Drupal envejecido sin cambiar de direcciones: páginas en HTML puro servidas por una CDN, ningún plugin que parchear y una cadena de publicación con vuelta atrás. Lo que cambia, cómo se migra y cuándo no hay que hacerlo.

  • Elegir y presupuestar7 min

    Alojar un sitio estático: Cloudflare, Netlify o un VPS

    Un sitio estático puede servirse casi desde cualquier lugar, pero no al mismo precio ni con las mismas trampas. Lo que se contabiliza en Cloudflare y en Netlify, los ajustes que sorprenden y los casos en que se justifica un servidor propio.

  • Elegir y presupuestar7 min

    Cuánto cuesta la web de una empresa en 2026

    La web de una empresa se paga dos veces: al crearla y después cada año. Qué hace variar el primer precio, qué infla el segundo y las preguntas que por fin hacen comparables dos presupuestos.

WhatsApp