Contents7
The objection we hear most often when we propose a static site: “But we have a form, a search, a newsletter.” Adding a form or search to a static site does not mean turning the whole site into an application: each need is handled separately, page by page.
This guide reviews the most common dynamic needs and how to wire them in. It assumes the decision has been made; if it has not, start with why migrate to a static site with Astro.
Where does the code of a static site run?
A static site builds its pages at publication time. Anything that has to react to a visitor’s action (sending a message, searching for a word, signing up) is handed to a dedicated service, called from the page.
With Astro, the boundary is explicit: by default, the whole site is pre-rendered as HTML, and a specific page can be rendered on demand with a single line, export const prerender = false, provided you install an adapter for the host. The rest of the site does not change.
A webhook is a case in point: it is the address that an outside service calls to report a confirmed payment or a received message, and it has to run code on every call, which a page built in advance cannot do.
How do you add a form to a static site?
The flow
A contact form on a static site works in three steps:
The path of an enquiry, from the form to the emails
- The form
The page sends the fields to a small server function (a Netlify function, a Cloudflare Worker, a Supabase Edge Function).
- The record
The function checks the data and saves it in a database or in the CRM.
- The emails
Once it is saved, the function sends the notification email and the confirmation to the visitor.
The rule that stops you losing enquiries
The order of steps 2 and 3 is not a detail. An enquiry that exists only in an email vanishes without trace as soon as the send fails, whether because a quota has been reached or an address is misconfigured.
From the field
On Palmora Property, a failed send passed for a success
A client learned this the hard way. The enquiries of Palmora Property, a real estate site we work with, at first went through email alone, with no guarantee: a failed send was swallowed, and the visitor still received a success response. The flow now saves every enquiry in the database before sending a single email.
Hence the rule to apply everywhere: database first, email second. An email that fails can be sent again. An enquiry that was never saved is lost.
Ready-made form services
Several hosts offer built-in form handling: you add an attribute to the HTML form, and the submissions appear in an interface. It is practical for a brochure site that receives few enquiries. Three questions to ask before relying on it:
- where is the data stored, and can you export it?
- do enquiries reach the CRM, or do you have to copy them over by hand?
- what happens beyond the plan’s quota?
For a business that lives off its inbound enquiries, we prefer a function that saves the enquiry, then creates it in the CRM. It arrives there with its source, with no re-keying.
Against bots
A public form receives automated submissions. Three simple safeguards, all checked on the server side: a hidden field that only a bot fills in, a minimum time spent on the page before sending, and a limit on submissions per hour. These are the ones used for the sign-up to the Challenge Us blog newsletter, an app for group challenges that we developed, with a double opt-in on top: the address is subscribed only after a click in the confirmation email.
How do you add internal search?
An index built at publication
Internal search does not need a search server. When the site is published, a script goes through the pages and builds an index; in the browser, a small program queries that index.
Pagefind, a fully static search library, splits its index into chunks, and a search loads only a small part of it. Its authors state the total volume to transfer:
is the ceiling for a full-text search on a 10,000-page site, library included
is closer to the volume for most sites
Challenge Us wrote its own index, in two files: one for its blog and the other for its knowledge base. They are built at publication from the same lists as the pages and loaded on the first click in the search field, at about 130 KB compressed for the blog’s index in September 2026. Both approaches fit on static hosting, with no service to pay for.
What to plan for
- Search that ignores accents and capital letters: “reunion” should find “Réunion”.
- An excerpt that shows why the result appears. A title alone is not enough when the word searched for is in the body of the page.
- No address per search. If every search typed becomes a page that search engines can crawl, the site fills up with pages that have no content of their own. The search runs within the page, without a new address.
Where should a newsletter list be kept?
A newsletter sign-up follows the same flow as a form. Two choices matter:
- Where the list lives. It can live with an email service, or in your own database, then pushed to the service. Keeping the list yourself lets you hold on to the proof of consent (the wording that was ticked, the date, the page) and change service without losing anyone.
- Double opt-in. It protects against sign-ups made by bots or with someone else’s email address, and it is the simplest proof that the consent comes from the owner of the address.
What about pages that change on every visit?
Some pages cannot be built in advance: a client area, a basket, a dashboard. With Astro, they are rendered on demand, one by one, while the rest of the site stays static. The cost is that of the functions executed, something to watch with the host: we detail what is counted depending on the host.
When these pages multiply and the whole site depends on data that changes during the day (a catalogue of properties, availability), committing to server rendering, with a well-tuned cache, is simpler than a makeshift static site.
Key takeaway
Static remains the right choice as long as most pages change at the pace of publications, not of visits.
Where to start
List everything that has to react on your current site: forms, search, sign-ups, client area. Each line fits into one of the flows above, and that list will tell you what the hosting will have to run and count.
If your site currently runs on WordPress, Drupal or Joomla, our migration to a static site starts from an inventory of your pages, and compares each page with the old site before going live.
Frequently asked questions
Is a form on a static site less secure?
No, often more secure. There is no admin panel or plugin to expose: only a small function receives the data. It must validate every field on the server, limit the number of submissions and never return a detailed error to the visitor. The access keys to the CRM or the email service stay in the function, never in the code of the page.
Can the form be connected directly to the CRM?
Yes. The server function calls the CRM’s API (Twenty, Odoo, HubSpot or another) and creates the contact or the enquiry. Add the originating page, the language and the campaign parameters (UTM) to every submission: without them, there is no way to tell which channel brings the enquiries. And keep saving to the database before the CRM call, so that a CRM outage loses nothing.
Do you need a paid service for internal search?
Not for a site of a few hundred or a few thousand pages. An index built at publication is enough, and it is served like the site’s other files. A dedicated service is justified for a very large catalogue, with filters, synonyms and sorting by commercial relevance, or when the results must follow stock that changes during the day.
What happens if the form’s function goes down?
The pages stay online, since they are files: only the submission fails. Plan for a clear error message in the page, with a fallback email address, rather than a button that spins endlessly, and for an alert that warns you of the outage. If it is the email service that goes down, the enquiry already saved in the database is not lost.
How do marketing teams publish on a static site?
From an editor, not in the code. The content lives in Markdown files or in a headless CMS such as Sanity, and each publication rebuilds the site, with a preview before going live and a way back to the previous version. The right tool depends on who publishes and how often: we go into this in our article on Astro and Sanity.
Sources
- By default, the whole site is pre-rendered (new tab)docs.astro.build
Jim · founder of Brain Plus AI
Also in websites, migration and astro
Understand8 min The topic guide
Static site with Astro: why migrate, without losing your SEO
A static site generated by Astro replaces an ageing WordPress or Drupal without changing a single address: pages in plain HTML served by a CDN, no plugin to patch, and a publishing chain with rollback. What it changes, how the migration goes, and when not to do it.
Choose and price7 min
Hosting a static site: Cloudflare, Netlify or a VPS
A static site can be served from almost anywhere, but not at the same price or with the same pitfalls. What Cloudflare and Netlify count, the settings that surprise, and when a server of your own makes sense.
Choose and price6 min
Headless Astro and Sanity: who edits what, at what cost
A headless site separates content editing (Sanity) from publishing (Astro): the team writes in a tool, the site stays static and fast. When this set-up is justified, how it fits together, what it really costs, and why we unplugged our own.