The short answer to "WordPress vs headless CMS": WordPress when the marketing team wants to assemble new pages from ready-made blocks on its own and the starting budget is small. A headless CMS or a static site when the page layout is settled, speed and a small attack surface matter, and changes are mostly about swapping text and images and adding posts. What decides it is not the technology but three questions: who edits the content, how often the page layouts themselves change, and who will be responsible for updates over the coming years.
We compare three models, not two, because "a site without WordPress" can mean either a headless CMS with a separate frontend or a static site with its content in files. We set out the criteria before any tool names come up, and for each model we say when it is the wrong choice.
- Classic WordPress builds the page from PHP and a database on every request, unless there is a cache. It has the largest plugin ecosystem and an editor many marketing people already know.
- A headless CMS is used only for editing content and delivers it through an API. The site itself is built by a separate frontend, most often into ready-made HTML.
- A static site is a set of ready-made HTML files on a server or CDN, with no database and no application code executed when someone visits the page.
- In the WordPress ecosystem the risk lies in plugins: according to Patchstack, 91% of new vulnerabilities in 2025 affected plugins, and 6 were found in core.
- Calculate the cost over three years: build, hosting, licences, updates and every layout change. The ranking of the offers often flips when you do.
WordPress vs headless CMS: three architectures, not two
"WordPress vs headless CMS" sounds like a choice between two products. In practice it is a choice between three ways of dividing up the work: where the content lives, what turns it into HTML, and what sits on the server the visitor connects to.
The three models at a glance
| Model | Where the content lives | Who builds the HTML, and when | What the visitor connects to |
|---|---|---|---|
| Classic WordPress | MySQL or MariaDB database | PHP on every request, or a cache after the first visit | A server with PHP, the database and the admin panel |
| Headless CMS + frontend | The CMS database, self-hosted or at a SaaS provider | The frontend at build time, or a server on request | A CDN with files or a frontend server, no panel |
| Static site | Markdown, JSON or YAML files in a repository | A generator on every deployment | A CDN or a plain file server |
Classic WordPress combines everything in one application: the editing panel, the database, the theme responsible for the look, and the code that assembles the HTML when someone visits the page. That is its greatest strength, because one installation does everything, and its greatest limitation, because the panel, the database and the public site all sit on the same server.
A headless CMS separates those roles. "Headless" means a content management system without a presentation layer: the editor enters content in the panel, and the CMS makes it available through an API. The look of the site is built by a separate application, for example in Astro, Next.js or Nuxt, which fetches the content and generates HTML from it. The same CMS can feed a website, a mobile app and an information screen in a showroom.
A static site goes a step further and does away with the database. The content lives in text files in the code repository, a generator turns them into ready-made HTML files on every deployment, and the server simply sends them out. For editing you can add a panel that saves changes straight to the repository, for example the open source Decap CMS, formerly known as Netlify CMS.
There is also a hybrid model: WordPress as a headless CMS. Since version 4.7, released in December 2016, WordPress has had a REST API in core with endpoints for posts, comments, categories, users and settings, so editors stay with the panel they know while a separate frontend builds the public site. This makes sense when the team is attached to the WordPress panel, but plugins that change how the site looks stop working.
Criteria first, before anyone names a tool
It is easy to set up a comparison so that a favourite chosen in advance wins, which is why the criteria come first. These questions are worth answering in writing before anyone proposes a technology:
- Who edits the content and how well they know the tools. One person from marketing, several editors with different permissions, or a developer who works in the repository anyway.
- What changes. Text and images in existing sections, new blog posts, or whole new pages with a new layout, assembled without a developer.
- How often. A few changes a year or a few a day, including posts scheduled for a specific time.
- Features beyond content. An online store, bookings, a customer area with login, search, multiple language versions.
- Who is responsible for updates over the coming years. Someone in the company, a developer on a maintenance plan, or nobody.
- How much speed and availability matter. Whether the site is a business card or a sales channel in which every second of load time and every day of downtime has a price.
A company where marketing builds new campaign landing pages every week has different needs from one that adds a blog post once a month and changes the rest of the site once every few years.
Security: where the attack surface is
WordPress is the most popular CMS in the world. According to W3Techs, it runs about 40% of all websites and nearly 60% of those whose content management system can be identified. Scale cuts both ways: flaws in core are patched quickly and the community is huge, but automated scanners check millions of addresses every day for known vulnerabilities in popular plugins.
Where the risk actually lies is shown well by the Patchstack "State of WordPress Security in 2026" report. In 2025, 11,334 new vulnerabilities were recorded in the WordPress ecosystem, 42% more than the year before. 91% affected plugins and 9% themes, while 6 were found in core itself, all of them low risk. For 46% of the vulnerabilities, the author had not yet released a fix at the time of public disclosure.
Two practical things follow from these numbers. First, the security of a WordPress site depends mainly on the number and quality of its plugins, not on WordPress itself. A site with five well-maintained plugins is in a different risk category from one with forty, half of which have not been updated for two years. Second, updating alone is not enough. When there is no fix, the only protection is disabling the plugin or adding a web application firewall rule, and that requires someone who follows vulnerability announcements.
WordPress helps here with automatic updates, which were introduced in version 3.7. Since version 5.6, new installations also update themselves to major versions by default. Plugins and themes only update themselves by default in special cases, which for critical vulnerabilities are decided by the WordPress.org security team. Day to day, automatic updates have to be switched on for each plugin separately, or the plugins have to be updated by hand. An untested update can in turn break the site's layout, so in practice you still need someone who checks the site after changes.
In the headless model the CMS panel does not have to be available at the same address as the site. It can sit on a separate subdomain with restricted access, or with a SaaS provider responsible for keeping it updated. The visitor connects only to the frontend, and if that is built into static files, no application code runs on the public server at all. Guessing the panel password or attacking a vulnerable plugin then has nothing to latch onto on the site the customer sees.
That does not mean headless and static sites are secure by definition. A contact form still needs a backend and spam protection. A server-rendered frontend has its own dependencies to keep updated. An API key with write access to the CMS, pasted into code that runs in the browser, opens the content up to anyone who looks at the page source. The attack surface is smaller and more predictable, but it does not disappear.
A static site has no database and no panel on the public server, so typical attacks on company websites, such as guessing the panel password, SQL injection or uploading a file through a vulnerable plugin, have nothing to attack. The keys to the site then become the hosting provider account, the domain registrar, DNS and the repository, so those are what you need to protect with strong passwords and two-factor authentication.
Performance: HTML that is ready before anyone asks for it
Classic WordPress without a cache runs PHP, queries the database and assembles the page from scratch on every visit. On cheap shared hosting, under traffic from a campaign, this translates into a long wait for the first byte of the response, and that is the first part of the LCP metric. A cache at plugin or server level stores ready-made HTML and solves most of the problem, but only for pages that look the same for everyone. The basket, the customer area and search still go through PHP and the database.
The second source of problems is on the browser side. Popular page builders give editors freedom over the layout, but that freedom is paid for in code: extra stylesheets, scripts and deeply nested elements, often loaded on every page, including those where a given module does not even appear. The PageSpeed score then drops however fast the server is.
Headless and static sites start from a different place. The HTML is created at build time, and the server sends a ready-made file, often from a CDN node close to the visitor. The frontend code is written for the specific project, so it does not contain modules the site does not use. The techniques that let us show a 95+ PageSpeed score on websites before handover are described in our post on Core Web Vitals in practice.
There is a catch here too. A headless CMS with a frontend rendered on every request, with no cache, can be slower than a well-configured WordPress, because the response has to wait for a query to an external API. Speed comes from pre-generation or caching, not from the word "headless" in the offer.
With pre-generated sites you also have to solve refreshing. After a content change the CMS sends a signal (a webhook) to the build server, which regenerates the whole site or only the changed pages. Frameworks such as Next.js also let you refresh individual pages on demand. Ask the developer how long after clicking "publish" a change will be visible to visitors, because WordPress editors are used to seeing the effect instantly.
Content editing: what the marketing person will see
This criterion most often decides how satisfied people are after launch, and it is the one most often skipped in conversations with the developer, because developers judge a system from the code side, not the panel side.
WordPress has a block editor in which content is made up of paragraphs, headings, images and ready-made sections, and you see the result immediately in a layout close to the public site. On top of that come drafts, scheduled publishing, revision history and built-in user roles: administrator, editor, author, contributor and subscriber. Someone who has worked with WordPress before needs no training.
A headless CMS usually turns a page into a form with fields: title, lead, main image, a list of sections of fixed types. Structured content like this has real advantages. The editor cannot break the layout, because they have no access to it, the same content goes out to several channels, and language versions are fields of the same record. The drawback is just as concrete: the editor sees fields, not the page. A preview has to be built separately, by connecting the CMS to the frontend in draft mode. Some SaaS services, for example Storyblok, offer a visual editor that shows the page next to the fields. If the quote for a headless build has no preview in it, ask about it directly.
A static site with content in files is the most convenient option for a team that works in the repository anyway, and the least convenient for everyone else. A panel like Decap CMS gives you a form for editing, but every change is a commit to the repository, and publishing requires rebuilding and deploying the site, so the result does not appear the second you save.
Typical editorial tasks in the three models
| Task | Classic WordPress | Headless CMS | Static site |
|---|---|---|---|
| Fixing a typo | Straight away, visible immediately | Straight away, visible after a rebuild or cache refresh | Editing a file or a form, visible after a rebuild |
| New blog post | Block editor with preview | Form with fields, preview only if one was built | A Markdown file, or the form of a panel that saves to the repository |
| New page from existing sections | The editor assembles it on their own | The editor assembles it from prepared section types | Usually a developer |
| New page with a new layout | An editor in a page builder, or a developer | A developer adds a new section type | A developer |
| Publishing at a specific time | Built-in scheduling | Depends on the CMS, plus an automatic rebuild | A scheduled deployment |
| Several editors with different permissions | Built-in roles | Roles in the CMS, on SaaS services often depending on the plan | Repository permissions |
The table shows something that technical comparisons miss: the main difference concerns new page layouts. If the marketing team assembles campaign landing pages every week and does not want to wait for a developer each time, WordPress with a well-prepared set of blocks or a headless CMS with a rich library of sections will work better than a static site. If the layout changes once a year, the freedom to assemble pages is not worth what it costs in performance and maintenance.
Costs: launch, maintenance and every layout change
Comparing build prices alone leads to bad decisions here, because the three models spread their costs over time in completely different ways. We gave indicative market ranges for websites and their maintenance in our post on how much a website costs. What matters more here is the structure of the costs.
Where the money goes in each model
| Item | Classic WordPress | Headless CMS + frontend | Static site |
|---|---|---|---|
| Build | Cheapest on a ready-made theme, more expensive with every change outside the theme | Higher, because the frontend and the content model are built for the project | Similar to headless, without the CMS integration |
| Hosting | A server with PHP and a database; requirements grow with traffic and the number of plugins | Frontend hosting plus a server for the CMS, or a SaaS subscription | The simplest: a file server or a CDN |
| Licences | Paid plugins and themes, usually on annual subscriptions | A SaaS subscription, or no fees with an open source CMS on your own server | Usually none |
| Updates | Core, theme, every plugin and PHP, regularly | The CMS and frontend dependencies, in a controlled way | Generator dependencies, with no time pressure |
| Changing a page layout | Cheap in a page builder, expensive when working around the theme | Developer work, predictable pricing | Developer work, predictable pricing |
With headless CMSs offered as SaaS, the price usually depends on several limits at once: the number of panel users, the number of documents or language versions, API requests and bandwidth. Storyblok and Sanity, for example, charge this way. Free plans are enough to start with, but before you choose, check which limit you will hit first and what the next tier costs.
Open source systems installed on your own server, such as Strapi or Payload, have no licence fees in their basic version: Strapi Community Edition and Payload are released under the MIT licence. They do, however, need a server, backups and updates, which means someone to look after them. It is also worth checking what the free version lacks. In Strapi, content history, SSO login and audit logs are available on paid plans, and for some companies content history is a basic requirement.
The most common mistake in the calculation concerns WordPress on a ready-made theme. The build is cheap, but every request along the lines of "here we want it different" means overriding someone else's code, which may break with the next theme update. After two years of such tweaks the site can end up more expensive than the same site written for the project from the start.
Plugins: WordPress's biggest strength and its biggest debt
The WordPress plugin directory is an argument no headless CMS can beat. Forms, multilingual support, SEO, bookings, newsletters, an online store: most typical features can be added without a developer. For a business with a small budget and typical needs, that is a real saving.
But every plugin is code that nobody in the company has read, with its own update schedule, its own licensing policy and its own risk of being abandoned by its author. Plugins also clash with each other: two adding code to the page head, three loading the same library in different versions. A well-maintained WordPress site has a short list of plugins, and for each one you know why it is there, who maintains it and what to replace it with.
When choosing a plugin, check four things in the WordPress.org directory: the date of the last update, the number of active installations, compatibility with the current version of WordPress, and whether the author responds to reports on the support forum. A plugin with no updates for two years is a candidate for replacement before someone finds a vulnerability in it, not after.
Content portability and vendor lock-in
How you will get out of a given solution is a question worth asking before you get in.
WordPress is open source software under the GPL licence and runs on any server with PHP and a database. Content is exported to an XML file with a built-in tool, but the layout of pages built in a page builder is stored in that builder's own format. When you move to another system, the text can be carried over, but the layouts have to be rebuilt.
A SaaS headless CMS stores your content with the provider. Exporting it through the API is usually possible, but the content model, meaning the field types and the relationships between them, has to be rebuilt from scratch in the new system. Before you choose, check what format you can export everything in, including media, and what happens to the data when the contract ends.
A static site with content in files is the most portable, because any text editor can open Markdown files, and the generator can be swapped without touching the content. This blog works exactly like that: every post is a Markdown file in the repository, from which a static HTML page is built on deployment. For us that is a good choice, because the people who write the posts work in the repository anyway. For a marketing department that wants nothing to do with git, it would be a bad one.
Whatever the model, changing the architecture of an existing site is a migration: the templates change, and often the URLs and heading structure too. How to get through it without losing Google traffic is described in our post on website migration without losing rankings.
SEO: every model can handle it, but not every one out of the box
Google does not favour any CMS. What counts is what reaches the browser and the crawler: content in the HTML, correct headings, titles and descriptions, a sitemap, redirects, structured data and loading speed.
In WordPress, one of the popular SEO plugins takes care of most of this: fields for the title and description, a sitemap, canonical tags. A plugin will not, however, fix duplicate content from tag archives, or a page that takes several seconds to load.
In the headless and static models all of this has to be designed and programmed: SEO fields in the content model, sitemap generation, redirect handling when a post's URL changes. Once it is done it works predictably, but if these items are not in the quote, do not assume they will appear. One question to the developer, "what happens when an editor changes the URL of an existing post?", shows whether the subject has been thought through.
When to choose WordPress, a headless CMS or a static site
No model always wins. The table lists typical situations and the first choice for each of them.
Which model for which situation
| Situation | Usually the best choice | Why |
|---|---|---|
| A business card site, a few pages, changes a few times a year | Static site | Lowest maintenance cost, no panel to attack |
| A company website with a blog, content edited by marketing, fixed layout | Headless CMS, or a static site with a panel | Convenient content editing without the risk of breaking the layout, speed |
| Marketing builds new campaign landing pages every week | WordPress with a prepared set of blocks, or headless with a section library | New pages without waiting for a developer |
| Small budget, typical features, someone in the company to handle updates | WordPress on a proven theme with a short list of plugins | Cheapest start and ready-made features |
| The same content on the website, in an app and in other channels | Headless CMS | Structured content available through an API |
| Unusual features, integrations, demanding speed requirements | Headless, or custom code written for the project | Every feature written for the need, without working around limitations |
| Nobody will update the site | Static site | The fewest parts that can go out of date |
The last row is the most important one and the one least often said out loud. WordPress without updates is a site that becomes an easier target every month. If there is nobody in the company to keep an eye on it and no budget for a maintenance plan, a static site is the safer choice, even if editing is less convenient. What happens to a site in the months after launch, and who should be responsible for it, is described in our post on monitoring and maintenance after launch.
There is also the opposite situation, in which moving from WordPress to headless makes no sense. If the current site is fast and kept up to date, the team works in it efficiently, and the only complaint is that "WordPress is outdated", a rebuild costs a lot and fixes nothing. That budget is better spent on cleaning up the plugins, better hosting and content.
Questions to ask the developer before you choose
A developer who works in one technology will propose it whatever the project. These questions help you check whether the proposal fits your situation:
Ask to be shown the panel on a working example before you sign the contract.
Also ask how long after clicking "publish" a change will be visible on the site.
Also ask how much such a change costs once the project has been handed over.
Ask for the annual cost of each item.
Agree how often that happens and what happens when an update breaks something.
Check who can reach it from the internet.
In case you change system or developer a few years from now.
Especially when the URL of an existing page changes.
Also agree which pages it will be measured on.
Frequently asked questions
Is WordPress secure?
WordPress core itself has very few vulnerabilities: according to Patchstack, 6 were found in it in 2025, all of them low risk. The risk lies in plugins and themes, and in a lack of updates. A site with a short list of maintained plugins, a supported PHP version and someone who keeps an eye on updates can be secure. A site abandoned after launch is not.
What is a headless CMS, in simple terms?
It is a content management panel without a site design of its own. The editor enters content in forms, and the CMS makes it available through an API. The site that displays this content is built by a separate application, so the design and the content are kept apart.
Is a headless CMS better for SEO than WordPress?
Not in principle. Google assesses what reaches the browser, not the system the content was created in. Headless makes it easier to build a fast site with clean HTML, but titles, the sitemap and redirects have to be programmed, whereas in WordPress a plugin provides them.
Can a static site have a contact form and a blog?
Yes. A blog is a set of pages generated from content files, and a form sends its data to a small function on a server or to a form-handling service. What is static is the page the visitor receives, not everything that happens after they click "send".
Can you move from WordPress to headless without losing Google rankings?
Yes, if the migration is planned: a map of old and new URLs, 301 redirects, titles and descriptions carried over, traffic measured before and after the change. The safest approach is to keep the existing URLs wherever possible.
Can I keep the WordPress panel and change only the public site?
Yes, that is the WordPress-as-a-headless-CMS model. Editors work in the panel they know, and the site is built by a separate frontend that fetches the content through the REST API. Plugins that change how the site looks will not work on the new frontend, and WordPress itself still needs updating, so it is worth hiding the panel from the outside world.
Choose the model based on editing, not technology
Before you ask for a quote, write down three things: who in the company will edit the site, what exactly they will change and how often, and who will be responsible for updates. With that note in hand, every conversation with a developer, including us, is about your project rather than the developer's favourite tool.
If you would like us to take a look at it, send it through the contact form. Quotes are free, and if plain WordPress turns out to be the best fit for your situation, we will tell you so directly. You will find the scope and starting prices of our services on the offer page, and how the collaboration works on the How we work page. After the project is handed over you get full rights to the code and the documentation, so your choice of architecture does not tie you to us for good.
