Migration playbook
WordPress to headless CMS migration
A guide for publishers and content teams moving off monolithic WordPress to a headless architecture. Headless adds rendering complexity that can wreck indexation if URL preservation, redirects, and metadata mapping are not planned carefully.
Pre-flight
Before kickoff
- Full URL inventory: export every indexed and indexable URL from Search Console + Screaming Frog.
- Metadata mapping: which WordPress fields map to which target-CMS fields, including SEO plugin data (Yoast/Rank Math).
- Redirect plan: every URL that changes needs a 301; every URL that stays needs preserved indexation.
- Rendering decision: which routes go SSG, ISR, or SSR on the new frontend.
- Comment, tag, and category strategy: many migrations lose these silently.
If things break
Rollback plan
- Maintain DNS-level revert path for 14 days post-migration.
- Keep WordPress origin deployable but unindexed (noindex via robots.txt) for 30 days.
- Per-section rollback via reverse-proxy routing if one route family fails worse than others.
Steps
Sequenced execution
Step 1
Set up the target CMS
Configure Sanity / Contentful / Hygraph with the schema that maps to your current content model. Validate with sample content.
Step 2
Build the frontend with rendering parity in mind
Implement canonical generation, OG tags, JSON-LD, sitemap generation matching current behavior. Curl-diff against current site for 100+ URLs.
Step 3
Migrate content in stages
Bulk-import content. Validate slug uniqueness and slug history. Preserve publish dates, authors, and modification dates.
Step 4
Build the redirect map
For every URL change (slug, hierarchy, structure), create a 301 entry. Verify no chains. Deploy redirects at edge or origin proxy.
Step 5
Cutover at low-traffic window
Switch DNS or origin routing. Resubmit sitemap to Search Console immediately.
Step 6
Monitor and recover
Indexation drops 5-20% in the first 2-4 weeks are normal. Recovery to baseline typically takes 60-90 days.
Expected metrics
Concrete expectations
- Expected downtime
- < 30 min (DNS cutover)
- Typical rollback time
- ~ 1 hour (DNS TTL)
- Time to indexation recovery
- 60-90 days
- Acceptable indexation drop window
- < 20% for first 14-21 days
After cutover
Monitoring discipline
- Search Console Page indexing — daily for 30 days, weekly for 90 days.
- Search Console performance — track impressions and clicks at the URL group level.
- 404 spikes in server logs (or CDN edge logs) — investigate every spike within 24 hours.
- Sitemap status in Search Console — must show "Success" for the new sitemap within a week.
- Top-100 query rank tracking via your preferred rank tool — expect 4-8 week recovery curve.
FAQ
Common questions
Should I migrate URL structure during the same release?
Strongly discouraged. CMS migration + URL restructure compounds risk and slows recovery. Migrate the platform first with URL parity, then restructure URLs in a separate release once new-platform baseline is stable.
How do I handle WordPress redirects that rely on plugins?
Export all plugin-managed redirects (Redirection, Yoast, etc.) before cutover. Reimplement them at edge (Cloudflare/Vercel) or in the new framework's redirect config. Plugin-based redirects do not survive migration off WordPress.
What about WordPress media and attachment URLs?
Keep `/wp-content/uploads/` paths if you can — saves a major batch of 301s. Otherwise mirror the image asset paths, deploy 301s for old → new, and resubmit image sitemap.
When can I shut down the old WordPress origin?
Not before 30 days post-migration, and only after redirects are confirmed at edge level. Keep it deployable (with noindex) for an additional 30 days as a recovery option.
Last updated:
Get this scoped to your stack
Generic playbooks are useful for orientation; the actual migration plan needs your routes, your CMS, your team capacity. The scoping call is 30 minutes — bring the constraints.
Other migration guides
SSR to SSG migration on Next.js
Move from server-rendered Next.js to fully static generation without losing SEO equity, with sane fallbacks for content that still needs freshness.
SPA to prerendered architecture
Add a prerendering layer to a client-rendered SPA without rewriting it. The compromise that buys crawler reach without an SSR rebuild.
Domain migration with SEO equity preservation
Move from one domain to another (rebrand, M&A, ccTLD consolidation) without losing rankings, indexation, or backlink equity.