WordPress → Headless CMS + Next.js · Updated
WordPress to Headless CMS Migration
A WordPress to headless CMS migration takes the posts, pages and custom fields from the WordPress export, remodels them as typed content in a headless CMS such as Sanity, and serves them through a Next.js frontend. Editors keep a real editing interface; the public site becomes server-rendered, structured and fast.
Who this migration is for
- Editorial teams that publish often and need an editor, previews and roles, but not the WordPress plugin stack.
- Sites whose content should feed more than one surface: web pages, structured data, llms.txt, feeds or an app.
- Businesses that want entity-clear content for AI search, where the same fact is stored once and reused everywhere.
What WordPress lets you export
Taken from the vendor’s own documentation, linked below. We do not promise an export the platform does not provide.
Documented export
- WordPress documents that the export file contains posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies and users.
- Custom fields from ACF or similar plugins are included in the export and map naturally onto typed CMS fields.
Not exported or stops working
- Theme and builder layouts do not travel; the content model is designed fresh around what the pages actually contain.
- Plugin-generated data (SEO plugin settings, redirects, form entries) is exported separately through each plugin or its database tables, not through WXR.
Source: WordPress.org, Tools Export screen. Accessed October 2026.
What we rebuild rather than import
- A content model: document types for services, locations, people, case studies and articles, with references between them instead of copy-pasted text.
- Design and templates. A migration is a rebuild of the presentation layer; we do not try to convert a theme or builder output into React.
- Forms, lead routing and spam protection, wired to your CRM or inbox and tested end to end.
- Structured data: one Organization node, Service and FAQ markup that mirrors the visible page, validated before launch.
- Analytics, consent and conversion events, so the first month after cutover is measurable.
Want to know what your WordPress site would keep?
The free audit inventories your URLs and traffic and tells you what a migration would have to preserve.
How rankings are preserved
WordPress-specific notes first, then the eight steps every migration follows.
- Post and page slugs are preserved as CMS fields so URLs do not change; where they must change, the old slug is kept as a redirect source on the document.
- Titles and meta descriptions from the SEO plugin become first-class CMS fields with length validation.
- Author and organization become referenced documents, so every article carries the same Person and Organization identity in its schema.
- 1
Inventory every URL that exists and every URL that earns
Crawl the live site, pull the sitemap, and export the Search Console Pages and Performance reports. The union is the redirect map input; the Performance rows decide what must be preserved exactly.
- 2
Decide the new URL structure before building
Keep paths where they are sane. Change them only where the old structure was a liability, and record the change in a one-to-one map. No wildcard redirects to the homepage.
- 3
Carry metadata field by field
Titles, descriptions, canonicals, Open Graph and existing structured data are exported with the content and loaded into the new pages, then diffed against the live site.
- 4
Rebuild structured data from one identity
One Organization node with the real address, phone and founder; Service, Article and FAQ markup that mirrors the visible page; validated before launch.
- 5
Preserve internal links and images
In-body links are rewritten to the new paths rather than left to bounce through redirects. Images are self-hosted so nothing depends on the old platform staying up.
- 6
Test the redirect map against the inventory
Every old URL is requested and must return one 301 to a 200 page. Chains, loops and 404s fail the launch.
- 7
Cut over and submit
DNS switch, new sitemap submitted, IndexNow ping, and a full crawl of the new site within the first day.
- 8
Monitor index coverage for a month
Indexed versus submitted, crawl errors, redirect-reported URLs and the top earning queries are checked weekly. A migration is done when coverage matches or beats the old site, not when the new one is live.
Why coverage is the finish line: our index coverage research. How AI agents read the result: which AI crawlers visit your site.
Why businesses make this move
- One source of truth. The address, phone, service list and founder facts live in one document and are referenced, so pages, schema and llms.txt cannot disagree.
- Server-rendered HTML. Search engines and the search-type AI agents read the page as delivered, not after a browser runs scripts.
- No plugin or app layer to patch, which removes a class of security and performance regressions.
- Content modeled as data, so the same facts feed pages, schema and llms.txt without drifting apart.
How the engagement runs
| Phase | What happens |
|---|---|
| Discovery | Goals, constraints, what the current platform does well, what it blocks. Access to analytics, Search Console and the admin. |
| Inventory | URL list, content audit, export of everything the platform allows, capture of everything it does not. |
| Content model and design | Document types and fields, page templates, components. Approval before build. |
| Build | Next.js frontend, CMS setup, content load, forms, schema, analytics and consent. |
| Redirect map and QA | Old to new URL map, automated redirect test, page-by-page content diff, accessibility and performance checks. |
| Cutover | DNS switch, sitemap and IndexNow submission, first crawl, old platform kept read-only until coverage is confirmed. |
| Monitoring | Weekly index coverage, crawl errors and query checks for a month; fixes shipped as found. |
Common questions
Which headless CMS does Webvello use?
Sanity for most editorial and marketing sites because of its structured content model and real-time editing. Strapi, Directus and Craft are used when a client has an existing investment or hosting requirement. The migration approach is the same.
Is a headless CMS harder for editors than WordPress?
It is different rather than harder. Editors lose drag-and-drop page building and gain structured fields, references and previews. Most teams find that writing a service page becomes filling in a form rather than arranging blocks.
Do I lose my WordPress SEO plugin data?
No. Titles, descriptions, canonicals and social metadata are exported from the plugin and loaded into equivalent CMS fields, then checked page by page against the live site.
Why not keep WordPress as a headless backend?
That is possible and we sometimes do it as a first step. It keeps the editor familiar but also keeps the plugin, update and security surface. A dedicated headless CMS removes that surface and gives a cleaner content model.
Related
- Headless CMS development
- Sanity development
- Headless CMS and SEO: what changes
- Headless vs traditional CMS
Other migration paths
Planning a WordPress move?
Tell us the page count and what the site has to keep doing. We will come back with what can be exported, what has to be rebuilt, and a dated plan.
Book a Free Call