WordPress runs about 43 percent of all websites, according to W3Techs. Most of those sites work the traditional way: WordPress stores the content and renders every page with a PHP theme. It is a proven setup, and for most sites it is the right one.
But there is a growing category of company that hits a wall with it. The pages load slower than the business wants. Design changes mean fighting a page builder. And a newer problem has joined the list: AI coding tools are changing how development teams work, and a page builder is one of the few places they cannot follow.
This article is a case study of one company that hit all three walls and rebuilt around them. Full Scale, an offshore software development company founded in 2018 with more than 300 engineers on staff, moved its public website to a headless architecture: WordPress stayed on as the content backend, and a Next.js application took over everything visitors see. The interesting part is not the stack. It is the reason they chose it, and what the site looks like to operate now that AI tools sit inside both halves of it.
The problem: a page builder AI cannot touch
The frustrations started where they usually do. The traditional WordPress site was slow, and making it fast meant auditing a stack of plugins and a theme the team did not fully control. Design changes were painful for the same reason: every layout tweak happened inside a page builder’s interface, one click at a time.
The deciding factor was newer. The team wanted AI doing real design and development work on the site, the same way AI coding agents were already writing production code elsewhere in the company. That is where page builders became a dead end. A builder stores its layouts as shortcodes and JSON blobs inside the database. A human can click around in the visual editor; an AI coding agent has nothing it can safely read, edit, and test. There is no file to open, no diff to review, no way to know what a change will break.
Get exclusive access to all things tech-savvy, and be the first to receive
the latest updates directly in your inbox.
Code is the opposite. A React component in a git repository is exactly the thing modern AI tooling is best at working with. An agent can read the component, change it, and a developer can review the change like any other pull request.
So the decision was made on an unusual axis: not “headless is faster” but “headless turns the website into code, and code is where AI can work.” For readers who want the foundational concept first, CyberPanel’s guide to what headless WordPress is covers the architecture basics.
The architecture they landed on
The production setup splits the site into two systems with one clean interface between them.
- WordPress stays as the content backend. Blog posts, case studies, and page content live in WordPress. The marketing and SEO teams keep working in wp-admin exactly as before. Nothing about the editorial workflow changed.
- Next.js renders everything visitors see. The public site is a Next.js application that fetches content through the WordPress REST API and pre-renders pages, so no visitor request ever waits on PHP.
- Incremental Static Regeneration keeps content fresh. When an editor updates a post, a revalidation call tells Next.js to rebuild just the affected pages. Edits go live in seconds without a full site rebuild and without a developer involved.
- Redirects moved to the CDN edge. Instead of a WordPress redirect plugin, redirects resolve in the hosting platform’s edge layer before a request reaches the application.
- The WordPress origin serves the API and the admin, nothing else. It is not the domain the public interacts with, and access to it is restricted accordingly.
Where the AI actually works
This is the part that separates the case study from a standard headless writeup. AI tools now operate on both sides of the split, and each side gets a different kind of work.
On the frontend, an AI coding agent does design and development work in the Next.js codebase. The team uses Claude Code, Anthropic’s coding agent, to build and modify React components: new page sections, layout changes, component refactors. Because the site is plain code in a repository, the agent can make a change, the team can review the diff, and the deployment pipeline handles the rest. Design work that used to mean an afternoon inside a page builder is now a reviewed pull request.
On the content side, the same agent works through the WordPress REST API. The REST API is not just how Next.js reads content. It is a write interface too, and an AI agent can use it the same way any application can: drafting posts, updating existing ones, fixing internal links across hundreds of articles, and pushing metadata changes. The editorial team reviews and approves, but the mechanical work of editing at scale is automated through the same API the frontend already depends on.
That symmetry is worth pausing on. The reason both workflows exist is the same architectural decision: everything became an interface. The frontend is code with a git history. The content is structured data behind an API. Both are things software, including AI agents, can operate on safely. A traditional WordPress site with a page builder offers neither.
The results that can be measured
Performance claims in case studies deserve skepticism, so here are the specific, checkable numbers. Google’s PageSpeed Insights reports real-user Chrome data for the rebuilt site’s homepage: on desktop it passes the full Core Web Vitals assessment, with Largest Contentful Paint at 1.0 second, Interaction to Next Paint at 67 milliseconds, and a Cumulative Layout Shift of zero. Mobile real-user data shows LCP at 1.7 seconds and the same zero layout shift. Lighthouse scores the site’s SEO checks at 100.
Here is a before and after comparison from our Ahrefs site audits.
The layout shift number is the one that best illustrates why pre-rendering matters. A CLS of zero means pages arrive fully formed, with no elements jumping as scripts and styles load. That is difficult to achieve when a PHP theme and a dozen plugins each inject their own assets, and nearly automatic when pages are built ahead of time and served as static HTML from a CDN.
The operational results matter as much as the metrics. Content ships without waiting on developers. Design ships without touching WordPress. Neither team blocks the other, and the AI tooling multiplies both sides instead of being locked out of one of them.
A frontend you can build anything on
There is a quieter benefit that shows up months after the migration. Once the frontend is a real React application, custom features stop being a search for the right plugin. An interactive pricing calculator, a custom quote form, a client portal, an integration with an internal system: on a traditional WordPress site, each of these means finding a plugin that almost fits and bending it, or writing PHP against theme hooks. On a Next.js frontend, each one is ordinary application code, built and tested like any other feature.
That flexibility is only as useful as the team behind it. Companies that want custom functionality but do not have the frontend capacity in-house can hire dedicated Next.js developers to build those features while the content team keeps working in WordPress, untouched. The architecture makes the two workstreams independent, so adding development capacity to one side never disrupts the other.
The tradeoffs they accepted
Headless is not a free upgrade, and an honest case study lists the costs. These are the ones that showed up in practice.
- Plugins that render output stop working. Anything that did its job through the theme layer, such as form builders and embeds, had to be rebuilt on the React side. The data still lives in WordPress; the display work moved.
- SEO plugins only get you halfway. Titles and meta still get managed in the WordPress admin, but the Next.js frontend has to fetch that data and render the tags, the sitemaps, and the schema markup itself. That is deliberate engineering work, not a plugin install.
- Content previews need rebuilding. The classic Preview button assumes WordPress renders the page. Making previews work against a decoupled frontend takes real effort, and editors notice its absence immediately.
- The site becomes two deployments. A content change and a code change follow different paths. That is the point, but it also means two systems to monitor and configuration living in more than one place.
- The skills requirement changes. A team fluent in PHP and WordPress does not automatically have React and Next.js experience. Some companies train their existing developers, which takes months; others hire for it or bring in an outside development partner. The JavaScript expertise has to come from somewhere, and projects that skip this question tend to stall at 80 percent done.
What headless means for the hosting side
A detail that frontend-focused writeups skip: WordPress does not go away, and neither does the server running it. It changes jobs.
The WordPress instance becomes an API origin. Visitors hit the CDN and the pre-rendered frontend, so public traffic to the origin drops to almost nothing. The origin only works during content regeneration and editorial sessions in wp-admin. A modest VPS that would struggle to serve a high-traffic PHP site directly handles the origin role comfortably.
Security improves, but only if someone does the work. Since no visitor needs to reach WordPress, access to the origin can be restricted to the frontend’s requests and the editorial team, taking the login page and xmlrpc off the public internet. An origin left publicly reachable on its old domain keeps its old attack surface and gains nothing.
Caching shifts rather than disappears. Full-page caching on the origin matters less because the frontend pre-renders everything. What pays off instead is caching REST API responses so regeneration stays cheap, plus object caching to keep wp-admin fast for the editors who live in it. And uptime still matters: ISR needs the API answering whenever pages rebuild, so the origin is out of the spotlight, not out of production.
For teams already pairing WordPress with a JavaScript frontend, CyberPanel’s guide to using React with WordPress covers the integration patterns in more depth.
Is this architecture right for your site?
The honest summary is that this company’s reasons will not be everyone’s reasons. Headless WordPress tends to be worth it when the developers already work in React or want to, when performance is a business priority rather than a nice-to-have, and increasingly, when a team wants AI tooling doing real work on the site and needs the site to be made of things AI can operate on: code and APIs.
It tends to be a mistake when the site leans heavily on plugins nobody has budgeted to rebuild, when the team has no JavaScript experience and no plan to acquire it, or when a well-tuned traditional WordPress install already serves the site fast. CyberPanel’s comparison of headless CMS options versus WordPress is a good starting point for that decision.
A traditional WordPress site on a properly configured server remains a fine architecture. The companies getting real value from headless made the switch because the split matched how their teams work. In this case study, the deciding question was one most teams have not asked yet, but probably will soon: can the coding tools a team already relies on also work on its website? For a page builder, the answer is no. For a headless site, it is yes on both halves.
