Headless WordPress in plain words
Headless WordPress means you keep WordPress only as the place where your team writes and stores content, and a separate front end, built with a JavaScript framework, fetches that content and shows it to visitors. The "head" is the public website. Cut it off, and WordPress becomes a content database with an editor attached.
For most Bangkok businesses, a hotel, a clinic, a shop or a B2B firm with 10 to 50 pages, headless is the wrong trade. It costs more to build, more to host and more to change, and it breaks many of the plugin features that make WordPress practical. It earns its cost when the same content must feed a website, a mobile app and other screens, or when a large in-house development team wants full control of the front end.
If you are still at the stage of deciding what the site should contain and who builds it, start with our guide on how to build a website for your business, then come back here if someone pitches you a headless build. WordPress itself needs no introduction here: it is the open-source content management system behind a large share of the web, and the rest of this article assumes you know roughly what it does.
Traditional, decoupled and headless compared
People use these three terms loosely, so it helps to pin them down. In a traditional setup, WordPress stores the content and also renders every page through its theme. In a decoupled setup, WordPress still renders some pages, while other parts of the site, or another app, pull content through an API. In a fully headless setup, WordPress renders nothing public at all.
The table shows what changes for the people who run the site day to day, not only for developers.
| Question | Traditional (theme) | Decoupled | Headless |
|---|---|---|---|
| Who renders the public pages? | WordPress theme | Mostly WordPress, some parts elsewhere | A separate front-end app |
| Codebases to maintain | One | One plus extras | Two |
| Hosting | One server | One server plus services | WordPress host plus a front-end host |
| Plugins that change the front end | Work as designed | Work on WordPress-rendered pages | Mostly need rebuilding |
| Editor preview | Built in | Built in for theme pages | Needs custom work |
| Typical fit | Most business sites | Sites adding an app or widget | Multi-channel publishers, large teams |
How the pieces talk: REST API and GraphQL
A headless front end needs a way to ask WordPress for content. There are two common routes.
The WordPress REST API
WordPress ships with a REST API built into core. The front end requests an address such as the posts endpoint under /wp-json/ and receives the posts as JSON, a plain data format that any programming language can read. It works out of the box, but each request returns a fixed set of fields, so a page that needs posts, categories, an author and a menu may need several round trips.
GraphQL through WPGraphQL
WPGraphQL is a free plugin that adds a GraphQL endpoint to WordPress. The front end writes one query naming exactly the fields it wants, and gets them back in one response. Developers building headless sites often prefer it for that reason. It is still a plugin you must keep updated, and custom fields or other plugins need matching extensions before their data appears in the query.
The front end
On the other side sits a JavaScript framework, usually React based or Vue based, often with a static site generator or server rendering layer on top. It turns the JSON into HTML, handles routing and builds the pages. That app is a full software project in its own right, with its own dependencies, updates and deployment pipeline.
What do you gain from headless WordPress?
Headless has real advantages. They are narrower than a sales pitch usually suggests.
- Performance potential. A front end that is pre-built into static files and served from a CDN can be very quick. Note the word potential: a badly built JavaScript front end can be slower than a lean WordPress theme, and a well built theme with good caching is already fast on a Thai 4G connection. If a classic site feels slow, our guide on why a WordPress site is slow lists the usual causes.
- One content source, many channels. If your product catalogue or articles must appear on a website, in a mobile app, on in-store screens and in a partner portal, publishing once and delivering everywhere through an API saves duplicate work.
- Developer freedom. A team fluent in a modern framework can build interactive interfaces without fighting a PHP theme. That matters when you already employ such a team.
- A smaller public attack surface. If the WordPress admin sits on a private address and visitors only reach static files, there is less of WordPress exposed to the internet. Good hosting and updates close most of that gap on a normal site anyway.
What you pay and what breaks
Headless WordPress costs more in three ways: you build, host and maintain two codebases instead of one; editors lose a working Preview button until a developer builds one; and plugins that add their output through the theme, such as forms, SEO, cookie consent and caching, stop working and must be rebuilt.
Two of everything
You pay to build and maintain two codebases: WordPress with its content model, and the front-end app. You pay two hosting bills, one for WordPress and one for the front end. Every change to how a page looks becomes a developer job and a deployment, where a theme change on a classic site is often a smaller edit.
Preview and editing friction
Editors are used to pressing Preview and seeing the page. On a headless site that button shows nothing useful until a developer wires up a preview route in the front end. Drafts, scheduled posts and page layouts all need the same attention. Marketing teams feel this most, because they cannot quickly check a promotion page before Songkran or a year-end sale goes live.
Plugins that stop working
Many plugins do their work by adding output to the theme. Without a theme, that output never reaches visitors. The usual casualties:
- form plugins, whose form markup and validation must be rebuilt in the front end;
- SEO plugins, whose titles, meta descriptions, canonical tags and schema must be fetched and printed by the app;
- cookie consent banners for PDPA, which must be re-implemented and wired to your analytics;
- page caching and image optimisation plugins, which have nothing to cache;
- page builders, which assume they control the rendered page.
The plugins in our list of essential WordPress plugins for business sites mostly fall into these groups, which shows how much of the value of WordPress sits in the front end you would be replacing.
SEO on a headless site
Headless sites can rank well, but nothing about search comes for free. On a classic theme, an SEO plugin covers most of the list below, as our WordPress SEO guide explains.
- Rendering. Google can process JavaScript, but its own guidance describes rendering as a separate step that can happen after crawling. Pages that arrive as complete HTML, through server rendering or static generation, are the safer choice. A front end that builds everything in the browser adds risk.
- Metadata. Titles, descriptions, canonical URLs, hreflang tags for Thai and English versions, and structured data all have to be pulled from WordPress and printed by the app on every route. Miss one template and a whole section of the site loses its tags.
- Sitemaps and redirects. The XML sitemap WordPress generates lists WordPress URLs, which may not match the front end's URLs. Redirects set in a WordPress plugin do nothing unless the front end reads and applies them.
- Status codes. A missing page must return a real 404, not a friendly page with a 200 status. Frameworks get this wrong by default more often than themes do.
None of this is hard for an experienced team. It is simply work a classic theme already does, rebuilt and then tested again after every release.
Who should go headless, and who should not?
Run through the checklist below. If you cannot tick at least three, a headless build will probably cost you more than it returns. Most Thai small and mid-sized firms would tick none, and the local picture in our article on how businesses use WordPress in Thailand points the same way: the need is usually a fast bilingual site that staff can edit, not a content platform for five channels.
Budget matters too. Before comparing quotes, read WordPress pricing explained so you can see which costs are one-time and which recur. A headless quote should show both codebases and both hosting bills.
- Content feeds several channelsThe same articles or products must appear in a website, a mobile app or other screens.
- You have an in-house dev teamPeople who will own the front-end app for years, not a one-off contractor.
- Front-end needs are unusualHeavy interactivity that a theme genuinely cannot deliver.
- Editors accept a longer workflowYour marketing team is fine with developer help for layout changes and previews.
- Budget covers two systemsYou can fund two codebases, two hosts and ongoing testing.
- SEO is handled in the appSomeone owns metadata, sitemaps, redirects and status codes on the front end.
What is the simpler alternative to headless?
For a business site, the better answer is usually a lean, custom-built theme. You keep the editor, the preview button, forms, SEO output and consent banners working as designed, and you still get quick pages if the theme is written without a heavy page builder and the images and caching are set up properly.
That is the route we take. Our custom WordPress development uses a hand-built theme with no page builder, so the site stays fast without splitting it into two systems. We do not build headless front ends. The Business package starts from THB 30,000 as an indicative one-time price and covers up to 15 pages in English and Thai, blog, forms, booking or enquiry flows, keyword mapping and schema markup, with two revision rounds. The final figure is set in your written quote, and our breakdown of what a WordPress website costs shows how the packages compare.
If you want to see the build steps in order, our walkthrough on building a WordPress website step by step covers them. And if your current site sits on a hosted builder and you are weighing a move, read our guide to moving from Wix to WordPress before anyone quotes you a headless rebuild.
More WordPress guides
Sources
Builds and ranks the websites: the systems behind the 17 client sites whose Search Console numbers we publish. This guide was written by the Website Development Bangkok team. More about us