wordpress to headless seo
The SEO plugin stops rendering anything. Every output it used to produce — canonicals, meta robots, sitemaps, schema, redirects — is now your front end's responsibility, and most teams discover that list one item at a time.
Primary riskYoast or RankMath still shows green in the admin while producing no output at all on the live front end.
Going headless does not break SEO. It removes the thing that was quietly doing SEO for you, and the removal produces no error.
For years, a WordPress SEO plugin has been rendering canonical tags, meta robots directives, Open Graph tags, an XML sitemap, structured data and a redirect table into every response. It did this through the theme layer. In a headless architecture, the theme layer is gone.
The plugin is still installed. The admin still shows green indicators. The fields are still filled in. None of it reaches the browser, because nothing is rendering it.
This is the single most useful habit for a headless migration: check the raw HTML of the live front end for every SEO output you expect.
The admin panel reports on stored field values. It has no visibility into what your Next.js or Astro application actually renders. A page can show a perfectly configured canonical URL in wp-admin and ship without a canonical tag at all.
The table on this page is the inventory. Work through it against view-source on the new front end, one route type at a time.
Headless setups routinely leave the WordPress origin publicly reachable — at cms.example.com, or at the original domain, or behind a hosting provider’s default URL.
Once it is reachable and linked from anywhere, it can be indexed. You now have two copies of the site: a fast new front end and the old WordPress theme output, competing with each other.
Authentication or an IP allowlist is the correct fix. X-Robots-Tag: noindex on the origin host is the minimum. robots.txt alone does not prevent indexing of a URL that has been linked — that is a crawl directive, not an index directive, and the distinction matters here more than almost anywhere else.
Modern hosting platforms generate a public URL for every branch. Those URLs get pasted into tickets, chat and pull requests. Some of those surfaces are crawlable.
The result is a set of near-duplicate deployments in the index, each of which can outrank production for long-tail queries because they are functionally identical.
Set X-Robots-Tag: noindex at the platform level for every non-production hostname. It is one configuration entry, and every platform supports it.
Headless is not a compromise. Static generation and edge delivery typically produce better Core Web Vitals than a plugin-heavy WordPress theme, and the control over markup is genuinely better — you can emit exactly the structured data you want rather than what a plugin decides to produce.
The migration risk is entirely about completeness, not about the architecture. Teams who inventory the plugin’s outputs before starting tend to come through cleanly. Teams who discover the list after launch spend a quarter on it.
The general platform-migration method is on the replatform page, and the rendering verification sequence is set out on the technical scope page.
What you see Yoast or RankMath shows green indicators in wp-admin. The live front end renders none of it, because the theme layer that used to output it is gone.
What fixes it Verify by fetching the raw HTML of the live front end, not by looking at the admin. The plugin is now a field store, not an output layer.
What you see The WordPress origin or the REST API is reachable on a public host and starts appearing in search results as a duplicate of the site.
What fixes it Restrict the origin to the front end via authentication or IP allowlist, and serve X-Robots-Tag noindex on the API host.
What you see Raw HTML contains a shell. Body copy and internal links appear only after the front end fetches from the API in the browser.
What fixes it Use static generation or server-side rendering for content routes. Client-side fetching of primary content is the wrong pattern for indexable pages.
What you see Vercel, Netlify or equivalent preview deployments appear in search results, duplicating production on a public URL.
What fixes it Serve X-Robots-Tag noindex on all non-production hostnames at the platform level, and never rely on robots.txt alone to keep a linked URL out of the index.
| Output | Previously | In headless | Failure if missed |
|---|---|---|---|
| Title and meta description | Rendered by the plugin into the theme head | Front end reads the field from the API and renders it | Google generates its own titles from page content |
| Canonical tag | Plugin, automatically | Front end must construct it from the request URL | Duplicate content across paths, parameters and pagination |
| Meta robots | Plugin, per post | Front end must read and honor the per-post setting | Pages marked noindex in the admin are indexed anyway |
| XML sitemap | Plugin, at /sitemap_index.xml | Front end generates it, or the API is queried at build time | Sitemap 404s, or lists old URLs indefinitely |
| Redirects | Plugin redirect manager | Front end routing, or the edge | Every managed redirect silently stops working |
| Structured data | Plugin, from post fields | Front end builds JSON-LD | Rich results disappear over several weeks |
| Open Graph tags | Plugin | Front end renders them | Social shares lose their preview cards |
Every item here is something the plugin used to handle. The list is the migration.
Fetch the raw HTML of the current site and list everything the SEO plugin injects. That list becomes the front-end implementation backlog.
Output Plugin output inventory
Title, description, canonical, meta robots, Open Graph, Twitter card — each read from the API per route rather than hardcoded.
Output Head implementation with per-route values
Either generated at build time from the API or served dynamically. Confirm the URL matches whatever is referenced in robots.txt and submitted to Search Console.
Output Working sitemap at a stable URL
Export the plugin’s redirect rules and reimplement them in front-end routing or at the edge. These are invisible until they stop working.
Output Migrated redirect rules with test results
The WordPress host and REST API must not be publicly indexable. Authentication or an IP allowlist, plus X-Robots-Tag noindex on that host.
Output Origin access policy
Fetch raw HTML for each route type and confirm content, internal links and head tags are present without JavaScript execution.
Output Rendering verification by route
Preview deployments get linked in tickets and chat, and linked URLs get discovered. Handle it at the platform level, not in robots.txt.
Output Preview environment headers confirmed
Not inherently — a well-built headless site can outperform the theme it replaced, particularly on Core Web Vitals. The damage comes from unnoticed omission: every SEO output the plugin used to render must be rebuilt, and teams typically discover the list one missing item at a time.
As a field store, yes — it keeps the values. As an output layer, no. The plugin renders tags into the theme, and there is no theme. The front end has to read those fields over the API and render them. The admin will keep showing green regardless.
They have to move. Plugin-managed redirects stop being applied once requests no longer pass through WordPress. Export the rules and reimplement them in front-end routing or, preferably, at the edge where they survive deploys.
Server-rendered or statically generated for anything you want indexed. Client-side fetching of primary content puts your pages in the rendering queue and makes internal links slow to discover. Client-side fetching is fine for genuinely interactive, non-indexable parts.
Send the launch date and what is changing. We will tell you which parts of this page apply to your situation and which do not.