Headless WordPress keeps WordPress as the content back end and replaces its front end with a separate JavaScript application. Standard WordPress renders pages from a theme on the same server. For most Canadian businesses the honest answer is that standard WordPress is still the right call, and headless earns its cost only when you have a developer on retainer and a specific technical reason the theme layer cannot satisfy.
Summary
- Headless splits one system into two: WordPress serving content as data, and a separate front end application rendering it.
- The data layer is standard. WordPress ships a REST API in core, and WPGraphQL adds a GraphQL layer as a plugin.
- You lose more than you expect. Live preview, the block editor’s visual output, page builders, most front-end plugins and the one-click edit workflow all stop working as shipped.
- Headless is not automatically faster. A well-built standard WordPress site on good hosting with proper caching passes Core Web Vitals, and a badly built headless site fails them.
- Core Web Vitals thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, measured at the 75th percentile of page loads.
- The decision rule: choose headless when you have a front end requirement WordPress genuinely cannot serve, you have ongoing developer capacity, and your content team does not depend on visual editing.
Table of Contents
- What headless WordPress actually is
- What you give up when you go headless
- Does headless actually make your site faster?
- Headless and SEO, including AI search
- What each architecture costs to build and run in Canada
- The decision framework
- Seven mistakes businesses make going headless
- The middle options most people never consider
- Frequently asked questions
What Is Headless WordPress, Exactly?
Headless WordPress means WordPress stores and manages your content, but does not render the pages your visitors see. A separate application, commonly built with Next.js, Nuxt or Astro, requests that content as structured data and renders the front end itself. The “head” being removed is the theme layer.
How the content actually gets out
Two mechanisms, both well established. The WordPress REST API ships in core and exposes posts, pages, taxonomies and other site data as JSON. WordPress’s own handbook describes it as “the foundation of the WordPress Block Editor” and notes it can support custom admin interfaces, front ends and separate applications. The second is WPGraphQL, a community plugin that exposes the same data through a GraphQL schema, which most teams prefer because it lets the front end request exactly the fields it needs in one query instead of stitching several REST calls together.
One caveat the handbook states directly and that surprises people mid-build: the REST API follows the same access rules as the site. Public content is generally accessible, but private content, password-protected content, custom post types and metadata require authentication or explicit opt-in. Custom fields in particular do not appear in the API unless registered to.
The two architectures side by side
| Standard WordPress | Headless WordPress | |
|---|---|---|
| Systems to run | One | Two, plus the API between them |
| Front end built by | A theme | A JavaScript application you own |
| Hosting | Managed WordPress host | WordPress host plus a Node or edge host |
| Content edit to live | Publish | Publish, then a build or revalidation step |
| Live preview | Works out of the box | Must be built, and is the first thing to break |
| Plugin front-end output | Works | Mostly does not, must be reimplemented |
| Who can change the design | An editor, or a designer | A developer |
| Ongoing maintenance | WordPress core, theme, plugins | All of that, plus the front end’s dependency tree |
What Do You Give Up When You Go Headless?
This is the section most vendor comparisons skip, and it is the section that decides the project. Going headless does not subtract a theme, it subtracts an entire layer of WordPress’s product behaviour that your team is quietly relying on.
- Live preview. WordPress previews by rendering the theme. With no theme, preview has to be rebuilt against the front end application, including draft authentication. It is buildable and it is never free.
- Block editor output. The block editor stores markup and relies on WordPress and the theme for front-end styling. In a headless build you receive block markup as HTML or as a parsed block tree, and you reimplement the styling for every block type your editors use.
- Page builders. Elementor, Divi, Beaver Builder and similar tools render on the WordPress front end. In a headless build they effectively stop existing. If your team builds pages visually today, headless removes that ability.
- Front-end plugins. Forms, popups, sliders, cookie banners, booking widgets, review displays and anything else that outputs markup need a replacement in the new front end.
- SEO plugin output. Yoast and Rank Math compute meta tags and schema for the WordPress front end. Headless builds need a bridge to pull that output through the API and render it in the new head, and a lot of headless sites quietly ship without schema because nobody wired it.
- The one-click mental model. Edit, publish, refresh, done. In headless, publish triggers a build or a cache revalidation, which means a delay and one more thing that can fail silently.
None of these are arguments against headless in the abstract. They are the real scope of the project, and they are the reason headless rebuilds routinely cost multiples of what the quote implied.
Does Headless Actually Make Your Site Faster?
Not inherently. Headless changes where rendering happens, not whether your site is well built. A static or edge-rendered front end can deliver an excellent Largest Contentful Paint, and a headless site shipping a large JavaScript bundle can deliver a worse Interaction to Next Paint than the standard WordPress site it replaced.
The thresholds you are actually being measured against
| Metric | Measures | Good |
|---|---|---|
| LCP, Largest Contentful Paint | Loading | 2.5 seconds or less |
| INP, Interaction to Next Paint | Interactivity | 200 milliseconds or less |
| CLS, Cumulative Layout Shift | Visual stability | 0.1 or less |
Google assesses these at the 75th percentile of page loads, segmented across mobile and desktop. INP replaced First Input Delay as a stable Core Web Vital in 2024, which matters here because INP punishes heavy client-side JavaScript, and heavy client-side JavaScript is the most common way a headless build goes wrong.
What usually causes the slowness people blame on WordPress
- Shared hosting with no object cache and no page cache
- A page builder loading its entire CSS and JS payload on every page
- Uncompressed images served at full resolution
- Thirty plugins where eight would do
- Render-blocking third-party scripts, usually tag managers and chat widgets
Every one of those is fixable without changing architecture, and fixing them is dramatically cheaper than a rebuild. Before anyone quotes you a headless migration on performance grounds, get a real diagnosis. Our guide to whether PageSpeed Insights is reliable and what your score actually means covers how to read the data properly, because lab scores and field data disagree constantly and most migration arguments are built on the wrong one.
Headless and SEO, Including AI Search
Headless is SEO-neutral when built correctly and SEO-damaging when built carelessly. The determining factor is whether your HTML arrives complete in the initial server response.
The rendering rule
Use static generation or server-side rendering. A client-side rendered front end that delivers an empty shell and fills it with JavaScript puts your content behind a rendering step, and that is a risk you are taking for no benefit. It is a larger risk in 2026 than it was five years ago, because many AI crawlers and answer engines do a far less thorough job of executing JavaScript than Googlebot does. Content that only exists after hydration may simply not be seen by the systems increasingly deciding whether your brand gets cited.
The headless SEO checklist
- Server-render or statically generate every indexable route
- Bridge your SEO plugin’s title, description and canonical output through the API into the new head
- Reimplement structured data, and validate it with the Rich Results Test rather than assuming it carried over
- Generate a real XML sitemap from the front end, not the orphaned WordPress one
- Keep the WordPress back end on a separate hostname and block it from indexing
- Map every old URL to the new one before launch, with no redirect chains
- Confirm Search Console’s URL Inspection renders the page with content present
Item five is the one that bites. A headless build leaves the WordPress install publicly reachable, and if it is not blocked from indexing you end up with a complete duplicate of your site on a second hostname.
What Does Each Architecture Cost to Build and Run?
Headless costs more to build and more to run, and the running cost is the one people underestimate. Treat the figures below as structural rather than as quotes, and note where each one lands in your own currency and market.
| Cost line | Standard WordPress | Headless WordPress |
|---|---|---|
| Build | Theme or design system, content, launch | All of that, plus a front end application and every plugin feature reimplemented |
| Hosting, monthly | One managed WordPress plan | A WordPress plan plus a Node or edge platform plan |
| Routine content change | An editor does it | An editor does it, if the component already exists |
| New page layout | An editor or designer | A developer ticket |
| Maintenance | Core, theme and plugin updates | The same, plus framework and npm dependency upgrades |
| Bus factor | Any WordPress developer can take over | Whoever can read your specific front end codebase |
That last row is the one that decides projects after the fact. A standard WordPress site can be handed to almost any agency in Canada. A bespoke headless front end can be handed to the people willing to learn your codebase, which is a much smaller market and a much higher hourly rate. For the general shape of website budgets in this market, see our 2026 website cost guide for Canada, and our website packages for how we scope builds.
The Decision Framework
Answer these six questions honestly. If you answer no to any of the first three, standard WordPress is your answer and the conversation is over.
- Do you have a front end requirement WordPress genuinely cannot meet? Not “we want it faster.” Something specific: an app-like interactive product, a single front end serving several content sources, a design system shared with a native app.
- Do you have ongoing developer capacity? Not for the build. For the next three years of framework upgrades and dependency maintenance.
- Can your content team work without visual page building? If marketing lays out landing pages today without filing a ticket, headless takes that away.
- Is your traffic or scale large enough that edge rendering pays for itself? Below serious traffic, good caching on good hosting delivers the same user-visible result.
- Have you already fixed hosting, images, plugins and scripts? If not, you have not yet established that WordPress is the constraint.
- Can you carry two systems’ security and update burden? The attack surface does not shrink, it moves and then doubles.
Who headless is genuinely right for
- Software companies whose marketing site and product share one design system and one front end codebase
- Publishers at a scale where edge rendering is a material cost and performance advantage
- Organizations syndicating one content set to a website, a mobile app and partner surfaces
- Teams that already employ front end developers and treat the website as product rather than as marketing collateral
Who should stay on standard WordPress
- Service businesses, professional practices, trades and local operators
- Any business whose site is primarily pages, posts, forms and conversion paths
- Marketing teams that need to ship a landing page this week without a developer
- Anyone whose actual complaint is speed, which is a hosting and build-quality problem far more often than an architecture problem
Seven Mistakes Businesses Make Going Headless
- Choosing it for speed without diagnosing the slowness. Fix hosting, images and plugin bloat first, then re-measure.
- Not scoping preview. It is the first thing editors ask for and the first thing missing.
- Leaving schema behind. The SEO plugin’s structured data does not follow you across the API by itself.
- Leaving the WordPress host indexable. A full duplicate site on a second hostname.
- Client-side rendering indexable routes. Fine for a dashboard, wrong for marketing pages, and increasingly wrong for AI crawlers.
- Underestimating plugin replacement. Every form, popup and widget becomes a development ticket.
- No maintenance budget for the front end. A JavaScript dependency tree left untouched for two years is a security and upgrade problem, not a stable system.
The Middle Options Most People Never Consider
Headless and standard are not the only two choices, and the middle is where most of the real performance wins sit.
- Standard WordPress with full page caching at the edge. Delivers cached HTML from a CDN close to the visitor. Most of the delivery benefit, none of the architectural cost.
- Static generation from WordPress. Plugins publish your WordPress site as static HTML. Very fast and very secure, at the cost of dynamic features.
- A block theme built properly. Modern block themes with no page builder produce lean HTML and minimal CSS. A large share of the sites considering headless would be fixed by this alone.
- Selective hydration. Keep WordPress rendering the site, and build only the genuinely interactive components, such as a configurator or calculator, as isolated JavaScript.
The fourth option solves the real requirement behind most headless requests, which is usually one interactive feature rather than an entire site.
Frequently Asked Questions
Is headless WordPress faster than regular WordPress?
Not automatically. A statically generated or edge-rendered headless front end can load very quickly, but a headless site shipping a heavy JavaScript bundle often scores worse on INP than a well-cached standard WordPress site. Architecture sets the ceiling, build quality determines where you land under it.
Does headless WordPress hurt SEO?
Not if every indexable route is server-rendered or statically generated, redirects are mapped, and your titles, canonicals and structured data are bridged into the new front end. It hurts SEO when routes are client-side rendered, when schema is dropped, or when the WordPress hostname is left indexable.
Can I still use Elementor or the block editor with headless WordPress?
Page builders such as Elementor render on the WordPress front end and do not carry over to a headless build. The block editor still works for writing, but your front end has to implement the styling for every block type your editors use, because WordPress and the theme are no longer doing it.
What does headless WordPress need for hosting?
Two environments. A host for WordPress itself, and a platform that can run or deploy your front end application, typically a Node or edge hosting platform. You are paying for and maintaining both.
Is WPGraphQL better than the WordPress REST API for headless?
Most teams prefer WPGraphQL because a single GraphQL query can return exactly the fields a page needs, which reduces round trips and over-fetching. The REST API has the advantage of shipping in WordPress core with nothing extra to install or maintain. Either works. The REST API’s access rules apply to both, so custom fields and private content still need explicit opt-in.
Can I switch back from headless to standard WordPress?
Yes, and it is easier than the reverse because your content never left WordPress. You build or buy a theme, remap URLs if they changed, and retire the front end application. The cost is the work spent on the headless build, not the content.
The Recommendation
Stay on standard WordPress and build it properly. Good hosting, a lean block theme instead of a page builder, compressed images, a disciplined plugin list and edge caching will put most Canadian business sites inside the Core Web Vitals thresholds without taking visual editing away from your marketing team or adding a second system to maintain.
Go headless when you have a specific front end requirement WordPress cannot serve, a developer who will still be available in three years, and a content team that does not need to lay out pages visually. Those three conditions together are uncommon, and when they are all true headless is clearly correct.
If someone has quoted you a headless rebuild and you are not certain which of these describes you, get the diagnosis before you sign. Wise Media audits the existing build, identifies whether the constraint is architecture or execution, and scopes the version that actually fixes it. Tell us what you are working with through our intake form and we will come back with a straight answer, including the answer that your current site is fine.
Related reading: website packages, website growth packages for ongoing performance and search work, and how to choose between WordPress and a custom coded website.
Sources consulted: WordPress Developer Resources, REST API Handbook; web.dev, Web Vitals; Google Search Central, structured data documentation.
Written by Cody Wise, founder of Wise Media. Wise Media builds websites and search systems for Canadian businesses and runs its own platform on the same stack it recommends. This article is general technical guidance, not a recommendation for a specific build.