When you start a new website, the question comes up early: should I use a CMS such as WordPress or a static site generator? The honest answer is that it depends less on the technology and more on who will update the site, how often, and with what resources it will be maintained over time. This article offers a structured way to decide.
The three architectures
Traditional (monolithic) CMS
The CMS handles everything: database, admin panel, templates and page generation on every request. WordPress, Joomla and Drupal are the best-known examples. You install it, pick a theme, add plugins, and the editor works from a visual interface.
Static generator
Content in files (often Markdown) and templates are turned into HTML at build time. In production there are only files. There is no admin panel unless you add one.
Headless CMS
A middle ground: a CMS provides the editing interface and stores the content, but does not generate pages. It exposes content through an API, and a static generator or an application turns it into the public site. Editing stays comfortable, and the public site can remain static.
The criteria that really matter
Who writes the content
If content is managed by a technical person used to a text editor and Git, a static generator is natural. If it is managed by a marketing team, an office administrator or a client with no technical skills, you need a visual interface: a traditional or headless CMS.
How often it changes
Pages that change a few times a month fit a build workflow very well. Content published by several people, several times a day, with previews and approval flows, pushes towards a CMS, possibly headless.
Required features
List the features before choosing the technology: private area, e-commerce, bookings, multiple languages, search, newsletter. For some of them a CMS offers ready-made plugins; with a static site you will have to integrate external services. That is not necessarily bad, but it is work to account for.
Long-term maintenance
This is the most underrated criterion. A traditional CMS needs regular updates to the core, the theme and the plugins, compatibility checks against the language version on the server, and database backups. Every plugin is third-party code running on your server. A static site in production has nothing to update; maintenance shifts to build dependencies, which are not exposed to the internet.
Security
In my digital forensics work, the compromised sites I analyse often share the same origin: an outdated CMS or plugin, or weak admin credentials. A CMS can be run securely, but it takes constant discipline. A static site removes much of the server-side risk by design.
A summary comparison
| Aspect | Traditional CMS | Headless + static | Static only |
|---|---|---|---|
| Editing for non-technical users | excellent | good | limited |
| Ready-made features (plugins) | very many | depends on the CMS | few, external services |
| Server maintenance | high | low on the public site | minimal |
| Attack surface | large | reduced | minimal |
| Performance without tuning | variable | high | high |
| Start-up cost | low | medium | low for technical users |
Typical scenarios
- A developer's personal blog or portfolio: static generator. Write in Markdown, publish with a commit.
- A small business site updated rarely, managed by an outside professional: static, possibly with a small Git-based CMS for the owner's simple edits.
- A newsroom with several authors and daily publishing: CMS, traditional or headless depending on performance requirements and development budget.
- An online shop with catalogue and inventory: a dedicated e-commerce platform or a CMS with an e-commerce extension; pure static is not enough.
- Documentation for a software product: static, with the content in the same repository as the code.
Questions to ask before deciding
- Who will be updating the site a year from now, and with what skills?
- Who will apply security updates, and how often?
- Which features are essential today and which are only hypothetical?
- Must the content be easy to migrate to another platform?
- What is the budget, not just for building the site but for maintaining it?
The fourth question deserves attention: content in Markdown is portable almost anywhere; content scattered across a database, theme shortcodes and plugin custom fields can require a laborious migration.
Migrating from a CMS to a static site
If you already have a CMS-based site and want to move to static, the typical steps are:
- export the content (many CMSs offer an XML export or an API);
- convert it to Markdown with a script or a dedicated tool, checking images and internal links;
- recreate the templates in the generator;
- keep the same URLs, or set up permanent 301 redirects for those that change;
- remove the old CMS from the server once the new site is verified, rather than leaving it forgotten online.
The last point is crucial: an abandoned, unpatched installation is a risk even if nobody visits it any more.
In short
- The choice depends on who writes, how often, and with what resources the site is maintained.
- A traditional CMS offers comfortable editing and many plugins, but needs constant maintenance.
- A static site is fast and secure, ideal for content managed by technical people.
- A headless CMS combines visual editing with a static public site.
- When migrating, keep the URLs or use 301 redirects, and remove the old CMS.
