Headless WordPress for a government site: when it is the right answer and when it is a career risk
Sometime in the 1990s I built a system for the U.S. House of Representatives to track inventory while they moved their offices.
The records lived in FileMaker Pro. Staff who needed to find a desk, a server, a box of files saw and updated those records through an HTML form that talked to FileMaker over an ODBC connection. The data sat in one controlled place. The thing people looked at was somewhere else entirely. Nobody on that project called it headless, because the word did not exist yet. But that is exactly what it was: a clean, governed data layer with a separate display layer, each with its own owner and its own reason to change.
I did not build it that way to be clever. I built it that way because the problem demanded it. The people moving things needed a fast, simple screen. The inventory data needed to stay accurate and protected no matter what happened to that screen. Those are two different jobs, and the honest answer was to keep them apart.
I tell you this because there is probably a proposal on your desk right now that uses the word headless as if it were new, and the agency that wrote it is selling you an architecture I have been building since before it had a name. Headless has real uses, and I will name them below. What you need first is the context the proposal leaves out.
Why I start with career risk and not architecture
Let me be plain about the position you are in, because the agency’s proposal will not be.
When you approve a headless WordPress build for a public-sector site, you are making a procurement bet, and the bet has an unfair shape. If the architecture turns out to be the right call, nobody will ever say your name. It will just work, quietly, and that is the whole reward. If it turns out to be the wrong call (a stale framework, or a year-two rebuild that costs more than the original build), the paper trail leads straight back to whoever signed off. That is you.
I am not raising this to frighten you off. I am raising it because the asymmetry is real and the people pitching to you have no incentive to mention it. The defence against that asymmetry is simple to state and harder to do: you have to actually understand what you are approving, and the reasons for it have to live in your procurement record, in language you could defend to an auditor two years from now who has never heard of React. A slide deck is not a record.
When headless is genuinely the right architecture
There are real cases where I would put my own name on a headless recommendation for a government site. They are specific, and in my experience the proposal has to show at least one of them, in writing, before the premium is worth paying.
Real-time personalization is the clearest case. WordPress can be made very fast. What it cannot easily be made into is a real-time personalization engine, where every visitor sees something computed for them in the moment. Building that on top of a monolithic install means fighting the caching that makes WordPress fast in the first place. If your service genuinely needs to show different content to different people on the fly, decoupling the front-end stops being a preference and starts being the path of least resistance.
Content with more than one destination is the other case I will sign. The same article going to a public website, a mobile app, and an open-data feed for other departments or the public to consume. When you have three destinations for one body of content, treating that content as something an interface requests (rather than something a theme renders) is precisely the problem this approach was invented to solve. One source, many channels.
A documented performance constraint from an audit or compliance configuration rounds out the list, but narrowly. Some government security postures restrict how a server is allowed to assemble and send a page in ways that leave even a well-optimized monolithic install slow. Headless can route around that constraint. I flag this carefully because it is a specific situation, and it gets stretched into a general rule. If someone tells you “compliance requires headless” as a blanket statement, they are overreaching. Ask which control, in which configuration, creates the problem.
When it is a career risk
Now the cases that produce regret.
The most common pitch by a wide margin is the marketing or communications site that needs none of the above. It does not personalize. Its content goes to the web and nowhere else. It is, in other words, a website. Headless is almost never the right answer here, and it is almost always what gets proposed, because it is the more impressive thing to sell.
Editorial access is where the real cost often hides. WordPress’s editing experience is one of the best reasons to choose it. A communications officer can write, schedule, and publish without filing a ticket. Many headless builds quietly take that away, handing editors a different and often worse admin panel, or routing them through a developer for changes they used to make themselves. Ask to see the screen your editors will actually use before you believe anything about how easy it will be.
The long procurement horizon locks the decision in ways worth naming upfront. The JavaScript framework the front-end is built in will age. Whatever is fashionable this year has a lifespan measured in a handful of years. Your content strategy has a lifespan measured in much longer. When you buy a headless build, you are tying a decade-long content commitment to a front-end technology that may be legacy before your next strategy refresh. Somebody has to keep that front-end current, and that somebody is on a meter.
| What the proposal shows | What it tells you |
|---|---|
| Every visitor sees content computed for them in the moment | Headless earns its place |
| One body of content going to a website, a mobile app, and an open-data feed | Headless earns its place |
| A named security control that leaves a tuned monolithic install slow | Headless earns its place, once you know which control |
| A communications site whose content goes to the web and nowhere else | A website. Build it the simple way |
| Editors routed through a developer for changes they used to make themselves | The cost is hiding in the editing screen |
| A front-end framework nobody is contracted to keep current | A decade of content tied to a meter |
If the architecture turns out to be the right call, nobody will ever say your name.
Five questions to ask the agency proposing headless
I ask versions of these in every one of these conversations, alongside the eight questions I bring to any government discovery call. The answers tell you more than the proposal does.
What is your reference public-sector headless deployment, and can I speak to the person who signed that contract? A name, and a phone call you can make this week.
After we accept delivery, who keeps the front-end framework updated when it needs it, and what does that cost? Get the maintenance number in writing. Headless builds carry a real premium on both implementation and ongoing upkeep, and the upkeep is the part that gets waved away in the sales meeting.
What is the rollback path if we need to change the architecture in year two? Every system needs an exit. If they cannot describe one, you are buying a one-way door.
How does an editor who is not a developer do their daily job on this system? Make them show you.
Under what circumstances would your firm recommend a monolithic build instead? This is the one that sorts the room. A firm that has never once told a client “you do not need headless, build it the simple way” is in the business of selling an architecture, and your problem is incidental to it.
The Canadian procurement context
If you are buying this for a Canadian department or agency, Treasury Board policy expects an architecture decision for a public-facing service to be justified and documented. A standard WordPress build does not invite that scrutiny; a headless build does. That is a paperwork requirement, and the only mistake is doing it late. The rationale (which of the three conditions applies, the named use case, why the simpler option was rejected) belongs in the procurement file before the contract is signed, while the reasoning is still fresh. Confirm the current directive reference with your own policy team; directives get renumbered, but the obligation itself is settled. If you want a second reader on the file before it goes in, that is the kind of audit I do, and you can ask.
One last thing worth keeping in view. The firms pitching headless have a plain financial interest in headless winning. These projects are bigger and cost more, and the framework maintenance bills for years after launch. That is a legitimate business model. But it is a fact about the person across the table from you, and weighing the proposal means weighing the incentive behind it alongside the architecture in front of it.