Static sites are back. Forms were the missing piece.

The web started static. A directory of HTML files, a server that handed them out, nothing to patch and nothing to crash. Then came the database-backed era: content management systems, templating engines, admin panels, and a decade of security bulletins. Around the mid-2010s the pendulum swung back under the Jamstack banner, and it has kept swinging. In 2026 the default advice for a marketing site, a portfolio, a documentation site, or a landing page is once again: generate files, put them on a CDN, walk away.

This is not nostalgia. The second static era is built on tooling the first one never had - static site generators, git-based deploys, edge networks - and it wins on three measurable axes: cost, speed, and security. But it inherited the first era's one structural gap, and the story of how that gap got filled is the story of a small, useful product category.

The case is boringly practical. A static site is a set of files, so serving it is a solved problem: replicate the files to a few hundred edge locations and let the nearest one answer. Time to first byte is whatever the CDN can do, which is very little. There is no origin server to size, no runtime to keep patched, no database connection pool to tune at 2 a.m.

Security is the quieter win. A dynamic site's attack surface is its code plus its dependencies plus its plugins plus its admin login. A static site's attack surface is, to a first approximation, the hosting provider's. There is no server-side code of yours to exploit because there is no server-side code of yours. Entire vulnerability classes - SQL injection, remote code execution in a template engine, a forgotten admin account - simply do not apply to a folder of HTML.

Then there is the price, which is frequently zero. GitHub Pages hosts static sites free. Cloudflare Pages and Netlify both have free tiers generous enough that a typical small site never leaves them. Because static files are cheap to serve, providers can afford to give hosting away and monetize elsewhere - which means the marginal cost of publishing a site has collapsed to the price of a domain name.

That economic fact shapes behavior. Side projects, event pages, product waitlists, one-page tools: things that once required justifying a monthly server bill now cost nothing to keep online indefinitely. We wrote a whole guide on wiring forms into this world - the static site contact form guide - because the pattern comes up constantly, on every host: GitHub Pages, Cloudflare Pages, Netlify.

A static site can show anything and accept nothing. HTTP GET is its whole vocabulary. The moment a visitor wants to send something back - a question, an email address, an RSVP - you need something on the other end of a POST request, and a CDN full of files has no other end.

This is not a small gap. The form is how a site stops being a brochure and starts being a channel. A portfolio without a contact form is a monologue; a landing page without a waitlist form is a poster. The single most common reason people historically reached for a dynamic stack was not rendering - it was that one <form> tag with nowhere to point its action.

The first static era improvised. mailto: form actions handed the problem to the visitor's email client, which worked badly in 1998 and works worse now that many people have no desktop mail client configured at all. Embedded third-party forms in iframes worked but looked like what they were: someone else's page inside yours, unstylable and off-brand. Shared-hosting CGI scripts - the FormMail era - technically solved it, at the cost of maintaining exactly the kind of server-side code the static site was supposed to eliminate, with a security record that made the point for you.

None of these were solutions. They were evidence of demand.

The real solution was almost embarrassingly direct: a hosted URL that accepts POST requests. You keep your own HTML, your own styling, your own domain; the form's action points at the endpoint; the service receives the submission and delivers it somewhere useful. No iframe, no server, no CGI script. The category has a name now - the form endpoint - and a healthy roster of providers, which we survey honestly in our roundup of form backends.

The minimal integration is one attribute:

<form action="https://sheetlinkforms.com/f/YOUR_TOKEN" method="POST">
  <input type="email" name="email" required>
  <input name="_slhp" tabindex="-1" autocomplete="off" style="position:absolute;left:-9999px">
  <button>Join</button>
</form>

That hidden _slhp field is a honeypot for spam bots - a category concern we will come back to. The point is the shape of the trade: the ninety-five percent of the site that is static stays static, and the five percent that needs a server borrows one.

Static site generators are the natural home of this pattern because they give you full control of the markup. Hugo, Jekyll, Eleventy, and Astro all emit plain HTML, so a form endpoint drops in as an action attribute in a template partial and works on every page that includes it. There is nothing framework-specific to learn, because there is nothing framework-specific happening - it is a form submitting to a URL, the way forms have worked since 1995.

The framework-flavored SSGs and meta-frameworks - Gatsby, Next, Nuxt, SvelteKit - fit too, though they tend to submit via JavaScript rather than a full page navigation. A good endpoint supports both: HTML posts get a redirect to a thank-you page, JSON posts get a JSON reply.

Visual builders are the other half of the static resurgence, and they hit the same wall from a different angle. Webflow and Framer publish fast, CDN-served sites, and both have native form UIs - but the submissions land in the builder's own dashboard, which is rarely where a team actually works. The escape hatch is the webhook: Webflow can send every form submission on a site to one webhook URL, and Framer's form component takes a webhook as its submission destination. Simpler builders like Carrd let a form post to a custom endpoint directly.

Either way the architecture converges: a static or builder-hosted front end, and a small hosted service catching what visitors send.

The first generation of form endpoints mostly forwarded submissions to email, and stopping at the inbox increasingly looks like half a product. An inbox is where submissions go to be read once; a spreadsheet is where they become a working list - sortable, filterable, shareable with whoever owns the follow-up. That conviction is why we built SheetLink Forms the way we did: rows land directly in a Google Sheet or an Excel Online table you pick, via each platform's own API, with no automation middleware in between. How it works is a two-minute read.

The other lessons of two decades: spam handling should never silently drop a real lead (suspicious submissions get quarantined for review, not deleted), delivery should survive a destination hiccup (an asynchronous worker retries at 5 minutes, 30 minutes, and 2 hours), and if you run paid traffic, the endpoint should capture the click IDs and UTM parameters your ad platform will later ask for. Details live in the docs.

Betting on static is betting that most of a site's complexity was never load-bearing. Twenty years of evidence backs it: pages are files, files are cheap, and cheap plus fast plus unhackable is a hard combination to argue with. Forms were the honest exception - the one interaction that genuinely needs a server - and the form-endpoint category exists precisely so that one exception does not drag the whole architecture back to a runtime you have to babysit.

If you want to see the pattern end to end, the live demo is a static page posting into a public Google Sheet. SheetLink Forms is free to start, no invite required - start free.

Is a static site really more secure than a dynamic one?

Do I need a backend to put a contact form on a static site?

What exactly is a form endpoint?

How do static site forms deal with spam?

Can a form endpoint handle file uploads?

My host has built-in forms. Why use an endpoint instead?

Does this work with single-page apps, not just classic static sites?

Which static site generator is best for forms?