Static websites: when a business site does not need a server at all
A static website is built once and served as finished files: faster, cheaper to run, harder to hack. What it is, what it cannot do, and how forms still work.
The short answer
A static website is one where every page is finished before anyone visits it. A build step takes your content and your design, produces the final HTML, CSS and images, and copies those files to a content delivery network. When a visitor arrives, the nearest location hands over the file. No database query, no template rendering, no waiting.
Compare that with a traditional setup, where a server assembles each page on request: fetch from the database, run the theme, run every plugin, then send. That works, but every visitor costs computing time, every plugin is a risk, and every spike in traffic is a test the server may fail.
Why we make it the default
| Static site | Server-rendered site | |
|---|---|---|
| Speed for the visitor | Nearest copy, milliseconds | Depends on server load and distance |
| Traffic spike from a campaign | Absorbed by the network | Server slows down or falls over |
| Security surface | Files only; no admin login on the public site | Database, admin, plugins, all reachable |
| Monthly running cost | Low and predictable | Server plus maintenance, grows with traffic |
| Patching on a Sunday | Nothing running to patch | Yes, and someone has to do it |
| Downtime during a deploy | None, new files replace old ones | Possible |
The security point deserves a second look. A large share of hacked small business websites are hacked through an outdated plugin on a public admin. A static site has no public admin and no plugin running in front of visitors. The attack surface is smaller by design, not by effort.
”But my site needs to do things”
It does, and static sites do them. The trick is that the interactive parts run only when they are used, and nowhere else.
- Forms. Plain HTML in the page. On submit, a small function validates the input, applies spam filters and sends the message. It runs for milliseconds, only when someone submits.
- Search. The index is built together with the pages and downloaded by the browser only when someone starts typing. This knowledge base works that way.
- Personalised bits. A logged-in name, a cart count, live stock: small islands of script that fetch what they need after the page has already rendered.
- Content updates. Editors publish in a content system; a build runs automatically and the new pages are live within minutes.
When static is the wrong answer
We build applications too, and we do not build them static. If most of what a visitor sees depends on who they are, if data changes by the second and must be shown live, or if the product is a portal, a dashboard or a booking engine, then you need a server or an app framework. Forcing that into a static model makes it slower and more fragile, not faster.
What this means for you
Ask whoever builds your next website one question: “When a visitor opens the homepage, is anything computed, or is a finished file served?” If the honest answer is “computed”, ask why. For a business site there is no good reason, and every month of running that server is a cost and a risk you did not need to take.
Frequently asked questions
If the site is static, how do I edit content?
Through a content system or a set of files, exactly as before. The difference is what happens after you press publish: a build produces new pages and copies them to the network. Editors do not notice; visitors get a faster site.
Can a static site have a contact form?
Yes. The form itself is plain HTML. Submitting it calls a small function or a form service that validates the input, filters spam and sends the email. That function runs for a fraction of a second and only when someone submits. The rest of the site stays static.
Is static the same as old-fashioned?
The opposite. The pages are produced by a modern build with current tooling, and can be updated hundreds of times a day. What is old-fashioned is a server that rebuilds the same page for every visitor and can be taken down by a traffic spike.
When is a static site the wrong choice?
When most pages differ per logged-in user, when data changes every second and must be shown live, or when the site is really an application: a portal, a dashboard, a booking engine. Those need a server or an app framework, and we build them that way.
Sources
- Astro documentation: Why Astro? (accessed 2026-09-11)
- Cloudflare Learning Center: What is a CDN? (accessed 2026-09-11)