Migrating WordPress to Headless: What to Expect

Migrating WordPress to headless means keeping or exporting your content, rebuilding the front end as a separate fast site, and pointing your old URLs at the new pages. Done carefully, rankings hold, because search engines care about URLs, content and redirects rather than what runs behind them. The traffic dips people report almost always come from skipped redirects and dropped metadata.

Quick links

• What actually changes when you migrate WordPress to headless?
• Should you keep WordPress or move the content out?
• How does your SEO carry over?
• What does the migration process look like?
• How long does it take and what can go wrong?
• How do you avoid a traffic dip?
• FAQ

What actually changes when you migrate WordPress to headless?

Your editors lose the theme and gain a separate front end. Your content, your URLs and your search presence should stay broadly as they are.

On a standard WordPress site, one system does everything: it stores content, runs the admin, and builds each page with a theme and a stack of plugins. Headless splits that. Content lives in a CMS and is delivered through an API. A separate front end, often built in a framework like Astro or Next.js, fetches it and builds the pages. WordPress itself has a REST API that exposes posts, pages and taxonomies as JSON, which is why it can play the content role without much fuss.

What this means in practice:

• The theme goes. Every template, layout and page-builder block is rebuilt in code.
• Plugins that shape the page go too. Sliders, builders, and plugin-generated SEO output no longer render anything, so each job needs a replacement.
• Hosting splits in two. The front end and the content system are hosted separately, and the front end is usually far lighter.
• Editing changes shape. Day-to-day writing is much the same. New layouts and page types become developer work.

If you are still deciding whether this is the right move, is a headless website worth it covers the honest case for and against. This post assumes you have decided and want to know how it goes.

Should you keep WordPress or move the content out?

You have two routes: keep WordPress purely as the editor, or move content into a dedicated headless CMS. Neither is wrong, and the choice mostly comes down to your editors.

Keep WordPress as the back end

The content stays where it is. Your team keeps the admin they know, and the migration is mostly a front-end rebuild. It is the lower-risk path, because there is no content move to get wrong. The cost is that you still maintain WordPress, its updates and its security, just with a much smaller exposure. We go through that trade-off in headless WordPress.

Move to a dedicated headless CMS

Content is exported from WordPress, reshaped and imported into something built for the job. You shed the WordPress maintenance burden entirely, and the content model can be far cleaner than years of accumulated custom fields. The price is real work on the content migration, plus retraining editors. Our rundown of headless CMS versus WordPress lays out how the two compare, and the best headless CMS post covers the options.

My view: if the editors are happy and the site is mostly the problem, keep WordPress behind the scenes. If the admin itself is the headache, move out.

How does your SEO carry over?

It carries over if you preserve four things: URLs, content, metadata and redirects. Lose any one carelessly and you will see it in the numbers.

Google is clear on the most important of these. For any move where URLs change, it recommends server-side permanent redirects from old URLs to new ones, and states that permanent redirects do not cause a loss in PageRank. It also says to keep them for as long as possible, generally at least a year, so that signals can transfer fully.

Here is what needs to travel with the content:

1. URLs. Keep them identical wherever you can. A headless front end can reproduce your WordPress permalink structure exactly, and this single decision removes most of the risk.
2. Titles and meta descriptions. These often live in an SEO plugin. Export them and load them into the new site’s fields, page by page.
3. Headings and body copy. Do not “tidy up” on the way through. Rewrite after the dust settles, not during.
4. Structured data. Whatever schema your plugin was producing needs generating again by the new front end.
5. Canonical tags, sitemaps and robots rules. All rebuilt, all checked.
6. Internal links and image alt text. They are easy to lose in an export, and easy to check for.

The upside is that the new site tends to be better for search on the technical side. Pages are built ahead of time or on the server, so the content is in the HTML on arrival. That matters more than it used to, because most AI crawlers read the initial HTML and do not run JavaScript, according to Vercel’s analysis. Done properly, the migration makes you easier for AI engines to read, not just for Google.

What does the migration process look like?

It runs in a fixed order: audit, model, build, map, test, launch, watch. Skipping the first and fourth is where most trouble starts.

Audit what you have

Crawl the live site and list every URL, then pull the top landing pages and the pages that attract links from Search Console and your analytics. These are the pages you must not damage. Note every plugin and what it does, including the quiet ones: redirects, schema, forms, cookie banners, tracking.

Model the content

Decide how posts, pages, case studies, authors and categories will be structured in the new system. This is the part that feels like admin and is actually the foundation. A tidy content model is also what makes the site easy for machines to read later.

Build the front end and move the content

The new templates are built against real content, not placeholders. Content is imported by script rather than copied by hand, then spot-checked. Scripts are fast and consistent. Humans copying and pasting 300 pages are neither.

Map every redirect

Build a spreadsheet of old URL to new URL. If the URLs match, great, there is little to do. If anything changes, each change gets a permanent redirect to its final destination, not a chain of hops. Google specifically advises redirecting to the final destination directly.

Test on a staging site

Crawl the staging site and compare it against the old crawl. You are looking for missing pages, changed titles, lost canonicals, broken images and redirect loops. This is dull work and it is the best use of the whole project’s time.

Launch, then watch

Switch over, submit the new sitemap in Search Console, and keep an eye on both the old and new URLs. Google recommends monitoring through Search Console and your server logs to confirm traffic moves across as expected.

How long does it take and what can go wrong?

The timeline depends on how many pages, how much custom functionality and how many integrations you have, and it is driven more by content work than by the build. Anyone quoting a fixed duration before seeing your site is guessing.

A small marketing site with standard page types is a modest job. A site with custom post types, member areas, a WooCommerce shop or a web of third-party syncs is a different project entirely. That is where cost climbs as well, and our guides to headless website cost and website redesign cost cover the money side properly.

The risks that actually bite:

• Redirect gaps. One missing mapping on a page with strong links, and that equity goes nowhere.
• Forgotten plugin jobs. The redirect plugin, the schema plugin, the form handler. Nobody remembers them until they stop.
• Metadata left behind. Titles reset to defaults across the whole site on launch day.
• Noindex left on. A staging setting carried into production. It is a classic, and a brutal one.
• Editor friction. The team can write, but cannot change a layout without a developer. Agree how requests are handled before launch, not after the first complaint.
• Scope creep. A migration quietly becoming a redesign, a rebrand and a copy rewrite. Do those afterwards, so you can tell what caused any change in traffic.

How do you avoid a traffic dip?

Change as little as possible that search engines can see, and verify everything before and after launch. A migration is not the moment to be clever.

A short list of what works:

• Keep URLs identical unless there is a genuine reason not to.
• Freeze content on the old site shortly before launch, so nothing is edited in one place and missed in the other.
• Launch at a quiet time, with someone watching, not on a Friday afternoon.
• Check indexing straight away. Confirm the live site can be crawled and that no noindex tag survived.
• Compare against a baseline. Record rankings, clicks and indexed pages beforehand, so you know what a normal week looks like.
• Keep the redirects for a year at the very least.

We recently rebuilt the site for Hoc Paid Media, a UK PPC agency that had outgrown its old Elementor build. Mobile PageSpeed went from 34 to 86 and desktop from 55 to 99, and an inbound lead arrived within a day of launch. That was a full rebrand and rebuild rather than a like-for-like move, but it shows what the front end can do once the page builder is out of the way. The full write-up is in the Hoc Paid Media case study.

A well-run migration is, frankly, undramatic. Nothing breaks, rankings sit where they were, and the site gets faster. If yours is exciting, something was missed.