Skip to main content
WordPress Development Co.

B2B SaaS · Headless WordPress

Headless WordPress marketing site for a SaaS scale-up

The client is named under NDA. Everything below is accurate; the identifying detail has been removed.

Increase in inbound leads, quarter over quarter
22%Increase in inbound leads, quarter over quarter
Core Web Vitals at the good threshold on field data
3 / 3Core Web Vitals at the good threshold on field data
Largest Contentful Paint, down from 4.6s
1.4sLargest Contentful Paint, down from 4.6s
Ranking URLs lost through the replatform
0Ranking URLs lost through the replatform

The situation

A B2B SaaS company running a themed WordPress marketing site had reached the point where their content team could not ship without an engineer. The theme had been extended by three agencies over five years, the homepage carried 2.8MB of assets, and Largest Contentful Paint on mobile field data sat at 4.6 seconds.

Their paid acquisition team had started to see landing page experience penalties. Organic performance had plateaued despite steady content investment. The internal proposal on the table was to abandon WordPress entirely and move the marketing site into their product codebase, which would have put every content change into an engineering sprint.

What we recommended

We argued against the full rewrite. The content team knew WordPress and were productive in it; the problem was the rendering layer, not the editorial layer. Moving to a headless architecture kept the editing experience they already had and replaced only the part that was failing.

The one condition we set was that authenticated draft preview had to work from day one. Headless projects that skip preview push editors back into asking engineers for staging deploys, which recreates the exact bottleneck we were trying to remove.

What we built

WordPress stayed as the editorial backend, moved behind private networking so it no longer served public traffic. Content is exposed through WPGraphQL with a typed schema and contract tests, so a field rename fails in CI rather than silently blanking a production section.

The frontend is Next.js on the App Router with incremental static regeneration. Publishing a post triggers a targeted revalidation of the affected routes rather than a full rebuild, so editors see changes live in seconds. Draft preview authenticates against WordPress and renders through the same components as production.

Every Gutenberg block in their library was mapped to a React component, which meant the content team's existing pages migrated without re-authoring. The sitemap is generated from the content model rather than the route tree, so new post types appear without a code change.

Protecting the rankings

Before any code shipped we pulled the indexed URL set from Search Console, crawled the existing site, and built a redirect map covering every path with impressions, traffic or inbound links. Titles, descriptions, canonicals and structured data were diffed page by page between the old and new builds.

The cutover ran with a lowered DNS TTL and a rollback path that stayed available for 72 hours. We monitored index coverage and rankings daily for the first month. No ranking URL was lost.

Where it landed

Largest Contentful Paint on mobile field data moved from 4.6 seconds to 1.4. All three Core Web Vitals reached the good threshold and have stayed there. Inbound lead volume rose 22% over the following quarter against flat paid spend.

The outcome the client cares about most is less quantifiable: their content team ships landing pages without opening an engineering ticket.

Considering a replatform?

We will tell you honestly whether headless is worth it for your situation. Quite often it is not, and a well-built theme gets you the same numbers for less.