A headless CMS is a content system with no website attached: editors write in it, and your site or app fetches the content through an API. Most small business sites don't need one. It earns its keep when the same content must reach several places, and when you have a developer to build and maintain the front end.
What is a headless CMS?
A headless CMS stores and manages content but has no built-in way to display it. The "head" is the website, built separately. The two talk through an API, so one content store can feed a website, an app or a screen in a shop. Strapi, an open-source example, lets you query content with REST or GraphQL.
The idea isn't exotic. WordPress can behave this way too. Its REST API handbook says you can use it to "build a brand new interactive front-end experience" or to "bring your WordPress content into completely separate applications." So "headless" describes how a system is used, not a product category you have to buy into.
Does your business need a headless CMS?
Probably not, unless you answer yes to two of three questions: does the same content appear in more than one place, does a developer own the front end long term, and is the current CMS's page templating blocking something you need? One yes means the cost is hard to justify. Zero means keep your CMS.
The usual pitch is flexibility, speed and multichannel delivery. It rarely says what you give up. A classic CMS ships with a front end that already works, with previews, menus, forms and a theme. Going headless means someone builds all of that again, and then keeps two systems alive instead of one. That is a staffing decision as much as a technical one. If your business publishes a dozen pages and a blog post a month, there is no second channel to feed, and the extra system buys you nothing visible.
The case for it is real, though. A retailer with a website, an app and in-store screens can write a product description once. A company with several brands can share a content model across sites. In those cases a headless CMS saves editors from copying text between tools, and that saving is what pays for the developer time.
What does going headless cost that nobody lists?
The biggest hidden cost is preview. Editors want to see a draft as it will look on the live site, and a headless setup doesn't provide that by default. Someone has to build it, and an editor who can't preview will ask a developer to check every change.
Next.js documents what this takes. Its Draft Mode guide says a draft preview needs a route that sets a cookie, a secret token shared between the CMS and the site, and a preview URL configured in the CMS. While an editor is in Draft Mode, cached or pre-rendered content is bypassed and fetched directly, and "other visitors continue to see the cached or pre-rendered version." That's sound engineering, and it is also a feature a classic CMS gives you on day one.
Other costs follow the same pattern. A page published in the CMS often isn't live until the front end rebuilds or its cache refreshes, so "I changed it but nothing happened" becomes a normal support question. Forms, search and menus that a classic CMS handles with plugins become code you own. None of these is a reason to avoid headless. They are line items to price before you commit, not surprises to find in month three.
Is a headless CMS better for SEO?
No, not by itself. Search engines read the page your visitors get, not the system behind it. A headless site can rank as well as any other if it serves complete HTML, and it can rank worse if important content only appears after JavaScript runs.
Google's own documentation is plain about this. It says Google renders JavaScript with a headless Chromium "once Google's resources allow," that "server-side or pre-rendering is still a great idea" because "not all bots can run JavaScript," and that "if the content isn't visible in the rendered HTML, Google won't be able to index it." The practical rule: whatever front end you choose, check that the text, headings and links are in the HTML it sends. If you want a deeper look at how page speed enters the picture, see which Core Web Vital to fix first.
What are the alternatives to going headless?
Three are worth considering. Keep a classic CMS and improve it. Use a static site, where pages are built ahead of time from content files. Or use a no-code builder that hosts both content and design. Each fits a different team, and they are compared in static site, WordPress or website builder.
If editors are happy and the only complaint is that the design is dated, you don't have a CMS problem. A redesign inside the current system, or a custom-coded front end on top of it, costs less than a migration. If the complaint is that content is trapped in one place, that is the signal to look at headless.
A fair test before you decide: write down every place your content has to appear in the next two years. If the list has one item, stay where you are. If it has three, a headless CMS starts to make sense, and a team that builds websites and systems in code can scope the preview and publishing workflow with you first.
How to decide, in one page
Pick a classic CMS if one website is your only channel and editors need previews without help. Pick headless if content goes to several channels and a developer stays involved. Whichever you choose, budget for the preview and publishing workflow, because that is where headless projects usually run over.
That is the whole decision. The technology matters less than who will run it after launch. If you'd like a second opinion on your own setup, talk to us about your project. You can read about onlyspell first if you want to know who would answer.
Frequently asked questions
Is WordPress a headless CMS?
Not by default, because it ships with its own front end. It can be used headless: its REST API lets another application read WordPress content as JSON. You then build the website separately and give up the standard theme and its previews.
Is a headless CMS more expensive than a classic CMS?
Usually, because you pay for a separate front end and for the preview and publishing workflow that a classic CMS includes. The subscription fee is often the smaller part. The larger part is developer time to build and maintain the front end.
Can non-technical editors use a headless CMS?
Yes. Editors work in the CMS's own admin panel, which Strapi, for one, provides for managing content. What they lose without extra work is the live preview of the finished page, so ask for that before launch.
Sources
If you still need additional help in developing and designing your website, our magic is here to help. Contact us today, and our wizards will help you immediately with your digital marketing needs!
