Choosing
Static site or WordPress for a business website
Neither is better in general. The real question is who will change the pages, how often, and who will keep the software up to date. This note sets out the trade-offs honestly.
Two words come up when you ask for a business website: “static” and “WordPress”. They describe different ways of making a site, and most comparisons are written by someone who sells one of them. Here is the comparison without a product to sell, and then where I stand.
What each one is
A static site is a set of finished pages. When a visitor asks for a page, the server sends the file as it is. There is no database and no program running on the server to build the page. MDN describes the difference: server-side code runs on the server and decides what to send, while a static site returns the same file to everyone.
A WordPress site is built by a program on the server, using a database. You log in to an admin area and edit pages, add posts or products, and install plugins that add features. Each visit runs code to assemble the page.
The trade-offs
| Question | Static site | WordPress |
|---|---|---|
| Who changes the text? | A developer, unless a separate editing tool is added | You or your staff, through the admin area |
| Speed | Fast by default, because pages are finished files | Can be fast, but needs care with hosting, plugins and images |
| Upkeep | Few moving parts; the host and the files | The core software, themes and plugins need regular updates |
| Attack surface | Small: no login page and no plugins on the live site | Larger: an admin login and third-party code |
| Features such as shop, membership, bookings | Not built in | Available through plugins, with their own upkeep |
| Cost over time | Often lower hosting; changes cost developer time | Hosting and plugin costs; changes can be done in-house |
WordPress’s own hardening guide says to keep the core, plugins and themes updated, remove unused plugins and keep backups somewhere trusted. That is not a criticism: it is what running a system with moving parts takes. A static site has less to maintain, and less you can do yourself.
The question that decides it
Who will change the pages, and how often?
- If you will publish news, add products weekly or have staff who edit pages, you want an editing system. WordPress, or another content system, is a good fit.
- If your pages change a few times a year, a static site is simple, fast and cheap to run, and you ask a developer when something changes.
Where my packages sit
My packages build hand-coded pages: a frontend, with responsive layouts and reusable templates. They do not include a content-management system, an admin area, a backend, accounts or online payments unless a proposal agrees otherwise. That has a clear consequence: after the support period in your package, changes to the site are agreed with me as separate work. For a manufacturer with a catalogue that changes occasionally, that is often fine. For a business that wants to post updates every week, it is the wrong arrangement, and a content system or a different provider suits you better. I would rather tell you that now.
A worked example
A supplier has 60 products, sells to repeat customers and changes the range a few times a year. The pages need to be fast on a phone, and the supplier does not want to manage plugin updates. A static site fits. A news-led trade magazine publishing daily, with several writers, needs a content system and an editor workflow: a static site would be the wrong tool.
What to ask any provider
- Who edits the site after launch, and how?
- What does it cost to change a page, a price or a product?
- If the site uses a content system, who updates it, how often and at what cost?
- Where are the backups, and who restores them?
- If I want to move to another provider, what do I receive?
The next step is a short conversation about how often your pages change: message or call Harman.