WordPress vs headless for SEO: what changes and what doesn't

The most common way a headless migration goes wrong is boring. The site looks perfect in a browser, but the HTML Googlebot downloads is nearly empty, because the content only appears after JavaScript runs.

That’s the whole debate in one picture. WordPress hands the crawler finished HTML by default. A headless setup can do the same, but you have to build that part yourself, and it’s easy to miss until traffic drops. If you’re picking a stack for a new site, or a developer is pitching you a rebuild, this explainer covers what changes for SEO and what doesn’t. Short version: the CMS matters less than how the pages get delivered.

what it is

WordPress is a content management system where the editing tool and the website are one program. You write a post in the admin, a theme turns it into HTML on the server (PHP and MySQL underneath), and whoever requests the URL gets a finished page. W3Techs has had it above 40 percent of all websites for several years. SEO plugins such as Yoast SEO and Rank Math handle title tags, meta descriptions, XML sitemaps and schema without you writing code.

Headless splits that program in two. The CMS only stores content and serves it through an API. It has no theme and no public pages. A separate front end, usually built with Next.js, Astro or Nuxt, fetches the content and produces the pages. Contentful, Sanity, Strapi and Payload are headless from day one.

WordPress can run headless too. Its REST API is documented in the WordPress developer handbook, and the WPGraphQL plugin covers the GraphQL route. So the real comparison isn’t “WordPress or something else”. It’s WordPress with its own theme against any CMS with a custom front end, and that second option is a software project, not a plugin install.

how it works

Google handles a page in stages. Googlebot fetches the raw HTML first, then queues the page for rendering in a recent version of Chromium. Google’s JavaScript SEO basics says a page can sit in that queue for a few seconds or longer. Content that’s already in the raw HTML doesn’t depend on that second step. Content that only exists after scripts run does.

WordPress builds the HTML on the server for each request. Put a page cache in front of it (WP Rocket is a popular plugin, and many hosts include their own) and the finished page goes out immediately, with the content in the first response.

A headless front end can produce pages in four ways, and they aren’t equal for SEO:

client-side rendering: the server sends a near-empty shell and the browser’s JavaScript builds the page. This is the risky one.
server-side rendering: the server builds the HTML on each request, the same idea as WordPress.
static generation: the HTML is built once at deploy time and served from a CDN. Fast, and about as safe as it gets.
incremental regeneration: static pages that the framework rebuilds in the background on a timer or when content changes. Next.js calls it ISR.

Google once documented dynamic rendering as an option, where bots get a pre-rendered copy and people get the JavaScript version. Its dynamic rendering documentation now calls it a workaround and recommends server-side rendering, static rendering or hydration instead.

Headless also means losing things WordPress did quietly. You have to rebuild or wire up:

title and meta description templates
canonical tags, which decide the version Google picks when URLs overlap
an XML sitemap with honest lastmod dates
301 redirects when a slug changes
structured data for articles, breadcrumbs and the organization
hreflang tags if you run more than one language
image resizing and lazy loading
a draft preview so editors can check a post before it goes live

A quick test for any site: open a page, right-click, choose view source (not inspect element), and search for a sentence from the body. If it’s there, the crawler gets the content in the first response. If it isn’t, the page depends on rendering. The URL Inspection tool in Google Search Console then shows you the rendered HTML Google sees.

why it matters

There are four places this choice shows up.

The first is indexing. A client-rendered page can get indexed, but you’re now relying on the render step finishing, your scripts not erroring, and your API answering when Google’s renderer calls it. When one of those fails, Google can end up with a blank shell for that URL. Our piece on JavaScript rendering and the half Googlebot never sees goes deeper on how that plays out.

The second is speed. Static pages on Cloudflare Pages, Netlify or Vercel come from a CDN edge close to the visitor, which helps Largest Contentful Paint a lot. The Core Web Vitals targets are LCP at 2.5 seconds or faster, INP at 200 milliseconds or lower and CLS at 0.1 or lower. WordPress can hit all three with decent hosting, a light theme and a cache, and a headless site that ships a heavy JavaScript bundle can miss INP. Measure both before believing either, using something from the site speed testing tools list.

The third is who does the work and what it costs. In WordPress an editor can publish without a developer, and the SEO plugin deals with the fiddly parts. In headless, every change to metadata or schema becomes a developer task, and things like bylines and author pages are yours to build (see author bios and whether anyone trusts them). The bills add up differently too. Cloudflare Pages has a free tier, Vercel Pro has been listed at $20 per seat per month, and Sanity and Contentful both offer free plans, but prices move, so check the pricing pages before you budget. Managed WordPress hosts such as Kinsta and WP Engine run to tens of dollars a month per site. The real cost in headless is developer time. If you’re thinking of letting AI coding tools build the front end, the sister site AI Tool Gazette covers AI tools, and I’d still want a human reading the output before it ships.

The fourth is migration risk. Rankings get lost in the details of any rebuild: URLs that change, redirects that miss, templates that quietly drop internal links or schema. A rebuild that keeps every URL identical is lower risk. One that also tidies the URL structure is where traffic tends to go missing. Before switching, crawl the old site and the staging site and diff the two.

Here’s my view, and you’re welcome to argue with it. For a content site under a few hundred pages, headless is mostly extra cost. WordPress with a good cache, or plain static files, can rank just as well with less to break. Headless earns its keep when a real product front end, several channels reading one content source, or a team that already lives in React justifies the extra build. I haven’t run a headless build at enterprise scale, so anything I’d say about 100,000 URLs is second-hand. This site is markdown files with no database, which tells you which way I lean.

common misconceptions

“Headless is faster, so it ranks higher.” Core Web Vitals are a ranking signal, but a small one next to relevance and links. A fast page that doesn’t answer the query usually loses to a slower one that does. And headless isn’t automatically fast, as the INP point above shows.

“Google can’t read JavaScript.” It can. Google’s documentation says Googlebot renders pages with a recent Chromium. The trouble is delay, errors and everything that isn’t Googlebot. Bots that build link previews in chat and social apps generally don’t run scripts, so if your title and description are also injected by JavaScript, a shared link can show a blank card.

“Headless WordPress keeps my Yoast setup.” Not by itself. Yoast can expose its title, description and schema data through the REST API, but your front end has to read that data and print it into the page head. If it doesn’t, the settings sit in the API and never reach the page.

“WordPress can’t handle serious traffic.” It can. Automattic runs WordPress VIP, an enterprise host aimed at large publishers, and the usual recipe is a page cache plus a CDN in front of the server. Slow WordPress sites are usually slow because of cheap hosting, heavy themes, a pile of plugins and no caching.

where to go from here

Next reads, in the order I’d take them:

JavaScript rendering and the half Googlebot never sees: the rendering side of this in more depth
what are Core Web Vitals in 2026: the three metrics behind the speed argument
technical SEO that actually matters: a filter for which checks are worth your time before any rebuild
the best SEO tools in 2026, tested: options for crawling the old and new versions of a site side by side

The full list of guides is on the blog index.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-27.