Why static? A practical guide to static websites

Most websites are read far more often than they are changed. A company page might be edited once a month and viewed thousands of times in between. A traditional WordPress setup still assembles that page from PHP code, a database and plugins — often on every request, or behind caching layers added to avoid doing exactly that.

A static website takes the opposite approach: do the work once, ahead of time, and serve the finished result. This guide explains what that means in practice, what you gain, what you give up, and when staying on WordPress is the better decision.

What is a static website?

A static website is a collection of ready-made files — HTML, CSS, JavaScript, images and fonts — that a web server or CDN sends to visitors as they are. There is no application running on the server to decide what each page should contain at the moment someone requests it.

"Static" describes how pages are delivered, not how they look or behave. Static pages can be modern, responsive and interactive. Navigation menus, image galleries, accordions and forms all work; they just don't depend on a server generating the page for each visitor.

How static generation works

Instead of writing every HTML file by hand, a static site generator builds them for you:

1. Content is stored as files, usually Markdown with a small block of metadata (title, date, description) at the top.
2. Templates define the layout: header, navigation, article styles, footer.
3. A build step combines content and templates into finished HTML pages, one file per URL.
4. The output folder is uploaded to a host or CDN, which serves the files directly.

A typical article file looks like this:

---
title: "Our new opening hours"
date: "2026-10-01"
---

From October we're open **Monday to Saturday**, 9:00–18:00.

When the content changes, the site is rebuilt and redeployed. With a Git-based workflow this happens automatically: commit a change, and a build service publishes the new version a few minutes later.

Static vs traditional WordPress

Both approaches can produce the same website for visitors. The difference is where and when the work happens.

Neither column is "better" in general. WordPress optimizes for editing flexibility and a huge plugin ecosystem. Static sites optimize for simple, predictable delivery.

Performance considerations

Serving a pre-built file is less work than generating a page, so static sites start from a strong position: there is no database query or server-side rendering in the request path, and files can be cached on a CDN close to visitors.

That said, static does not automatically mean fast. Page speed still depends on things a generator can't fix on its own:

• Large, unoptimized images.
• Heavy JavaScript bundles and third-party scripts such as chat widgets, trackers and embedded videos.
• Web fonts that block rendering.
• Layout shifts caused by content loading late.

A well-tuned WordPress site with good caching can be fast too. The practical advantage of static is that good performance is the default state, rather than something maintained through extra caching and optimization plugins.

Security considerations

A static site removes several common attack targets from the live website: there is no login page, no database to inject into, and no server-side plugin code reachable by visitors. Fewer moving parts generally means fewer things to patch.

It does not make a site invulnerable. You still need to:

• Protect the accounts that can change the site — the Git host, the deployment platform and the domain registrar — with strong, unique passwords and two-factor authentication.
• Keep build dependencies reasonably up to date.
• Secure any external services the site relies on, such as form processors.
• Configure sensible security headers on the host.

The security work moves from "patch the running server" to "protect the publishing pipeline", which is usually a smaller and more stable job.

Maintenance and hosting

A typical WordPress site needs regular core, theme and plugin updates, PHP version upgrades, database backups and periodic checks that nothing broke along the way.

A static site has a different, usually lighter routine:

• The live site itself has nothing to update — it is just files.
• Build tooling should be updated from time to time, but an outdated build tool doesn't expose your live site the way an outdated plugin can.
• Hosting is simple: static files can be served by CDN-based platforms (several offer free tiers for small sites), conventional web hosts or your own server.
• Backups are built in when content lives in Git: every version of every page is in the history.

Low maintenance is not zero maintenance. Domains renew, dependencies age, and external services change. But the list is shorter and less urgent.

Editing static content

Editing is the most common concern, and the answer depends on who edits the site:

• Developers and technical editors usually edit Markdown files directly in a code editor or on GitHub. Changes go through Git, so every edit is versioned and reversible.
• Non-technical editors can use a Git-based CMS: a web interface with a familiar editor that saves changes as commits behind the scenes.
• Occasional updates can be handled by whoever maintains the site, as a small service.

What changes is the publishing rhythm. Edits go live after a rebuild rather than the instant you click "Update". For most content sites that delay — typically a few minutes — doesn't matter, but it's worth knowing upfront.

Dynamic feature limitations

Anything that has to react to a specific visitor in real time doesn't come for free on a static site. Common examples and how they are usually handled:

• Contact forms: a small external service, such as a serverless function or a form provider, receives submissions.
• Search: a pre-built search index loaded in the browser works well for small and medium sites; large sites may need a hosted search service.
• Comments: a third-party comment service, or a moderated workflow.
• E-commerce: a hosted checkout or a headless commerce platform; a full catalogue with inventory needs real backend services.
• User accounts and memberships: an authentication provider plus dynamic APIs. At that point the site is no longer purely static.

Each of these adds a service to choose, configure and maintain. If a site needs many of them, the case for static gets weaker.

When WordPress remains the better fit

Static isn't the right answer for every website. Staying on WordPress often makes sense when:

• The site depends on WooCommerce or another full e-commerce setup with a large catalogue.
• There are logged-in users, memberships, courses or user-generated content at the core of the site.
• Many editors rely daily on WordPress-specific workflows, such as custom post types with complex admin screens or editorial approval plugins.
• Content must appear instantly after saving, many times a day.
• The site works well, is maintained by a capable team, and nobody is struggling with it.

In those cases, the honest recommendation is to improve the existing setup rather than migrate. We'd rather tell you that during the audit than sell you a project that doesn't fit.

The migration process

A careful migration preserves what you already have — content, URLs and search visibility — while replacing the machinery behind it:

1. Audit. Review the site's pages, post types, plugins, forms and integrations, and decide what each becomes after the migration.
2. Content export. Move posts, pages, media and metadata out of the database into portable files.
3. Templates. Recreate the design as static templates, usually matching the current look.
4. URLs and redirects. Keep existing URLs wherever possible and add permanent redirects where paths must change.
5. Dynamic features. Replace forms, search and other server-side features with suitable external services.
6. Verification. Compare old and new pages, check links, metadata and structured data, and test on real devices.
7. Launch. Point the domain to the new hosting, monitor for errors, and keep the old site available until everything checks out.

If you'd like to see the result of this approach, this website is built the same way.

Get a free audit

Not sure whether your site is a good candidate? Send us your website and a person will review it — no automated scanner — and tell you honestly whether a static migration makes sense, what it would involve, and what it would cost.