For years, "static site" brought to mind hand-written HTML pages updated over FTP. Today the term means something different: sites generated automatically by a program from content in Markdown or another data source, and published as plain files. The result is a site the server does not have to "build" on every request, because it is already ready.
How a modern static site works
The typical workflow is this:
- Content lives in Markdown, JSON or YAML files, or in an external CMS that exposes it through an API.
- A static site generator combines content and templates and produces a folder of HTML, CSS, JavaScript and image files.
- The folder is published on a static hosting service or a CDN.
- Whenever content changes, the build runs again, often automatically on every commit to the repository.
An article in Markdown with its front matter is already everything the generator needs:
---
title: "My article"
date: 2025-01-10
---
Article text with **bold** and a list:
- first point
- second point
The generator turns it into /my-article/index.html, applying the page template.
The concrete advantages
Performance
Serving a ready-made file is the simplest operation a server can perform. There are no database queries and no code to execute. Distributed through a CDN, the site comes from a node close to the user, with very low response times.
Security
A huge share of attacks on websites target server-side code: exposed admin panels, vulnerable plugins, database injections. A static site in production has none of this. The attack surface shrinks dramatically: what remains is the security of the hosting account, the repository and the build process, which still need careful protection.
Cost and reliability
Many static hosting services have free or very cheap plans for small and medium sites. There are no servers to patch, language versions to migrate or databases to tune. Sudden traffic spikes are absorbed by the CDN without the site going down.
Versioning
If content sits in a Git repository, you have the complete history of every change. Going back to yesterday's version is a single command, and every change can go through a review before publication.
The real limits
A static site is not suitable for everything. Here is where you run into friction:
- Per-user personalised content: private areas, shopping carts and dashboards require server-side logic or calls to external services.
- Very frequent updates: if content changes every minute, regenerating the site on every change becomes awkward.
- Very large sites: with tens of thousands of pages, build times grow. Many generators offer incremental builds, but it remains a factor to weigh.
- Non-technical editors: writing in Markdown and using Git is not for everyone. There are headless or Git-based CMSs that offer a visual interface, but they need to be set up.
Dynamic features without your own server
Many needs that seem to call for a backend can be met with specialised services or small functions:
| Need | Typical solution |
|---|---|
| Contact form | form-handling service or serverless function |
| Site search | index generated at build time and searched in the browser |
| Comments | external service or repository-based system |
| Fresh content | scheduled build or one triggered by a webhook |
| Payments | checkout hosted by the payment provider |
For search, for instance, the generator can produce a JSON file with the titles and summaries of all pages; a small script in the browser loads it and filters results as the user types. For sites with a few hundred pages it works very well.
Every external service, however, brings back a dependency: consider where user data ends up, what happens if the service shuts down and how much JavaScript it adds to the page.
When to choose it
A static site is an excellent choice for:
- personal sites, portfolios and blogs;
- technical documentation;
- corporate sites and business brochure sites;
- landing pages and event sites;
- informational sites updated daily or weekly.
It is less suitable for complex e-commerce with real-time inventory, social networks and applications with many personalised interactions. In those cases a hybrid approach often makes sense: static public pages and a separate application part.
Some practical tips
- Choose a generator with an active community and clear documentation: you will change your mind about templates, not about content, so keep content in portable formats such as Markdown.
- Automate publishing: a continuous integration system that runs the build and deploys it on every commit removes manual errors.
- Check for broken links and HTML validity during the build, so errors surface before publication.
- Configure HTTP headers (caching, security) through your host's configuration files: a static site needs them too.
In short
- A modern static site is generated from content and templates and published as plain files.
- It is fast, cheap and has a very small attack surface.
- It is not suited to per-user personalised content or content that changes constantly.
- Forms, search and comments are handled with external services or serverless functions.
- Keep content in portable formats and automate build and deployment.
