Migrating from WordPress to headless without losing SEO
The 11-step plan we use when migrating a site with 1,800+ URLs without losing rankings.
WordPress migrations almost always fail in SEO for the same 4 reasons: poorly mapped 301 redirects, changed slugs, lost schema markup, and inflated initial load caused by moving PHP plugins to JavaScript without optimizing. This guide is the real checklist we use when migrating a retail site with 1,800 SKUs and 9 categories without losing Google positions.
Why migrate (only migrate if one of these is true)
- Mobile LCP > 3s and you cannot lower it inside WordPress.
- Accumulated plugins overwriting core functions, impossible to audit.
- You want UX WordPress does not support (3D configurator, custom builder, complex integrations).
- Maintenance cost (hosting + WP dev) exceeds US$1,200/month.
- Security has been compromised repeatedly.
If none applies, optimize WordPress (caching, CDN, image optimization, plugin cleanup) before migrating. Migration costs US$18k-60k depending on size.
The 11 steps we execute
1. Complete URL inventory
Crawl with Screaming Frog or Sitebulb. Export current URL, status code, title, meta description, H1, canonical, structured data, last modified. This is your source of truth. Without it, you will lose URLs.
2. URL -> new URL mapping (1 to 1)
Spreadsheet with columns: old_url, new_url, status (301 / 410 / keep). Default is direct 301 to equivalent. Anything without a clear equivalent becomes explicit 410, not implicit 404.
3. Analysis of top organic traffic pages
Search Console: top 50 URLs by traffic. Those URLs do not change slug. The rest can change if there is a reason. Rule: if a URL ranks, do not touch anything except speed.
4. Schema markup inventory
Document all schemas present (Product, Organization, BreadcrumbList, Article, FAQPage). Each one must reappear on the new site with the same JSON-LD structure. Stricter: same properties, same values.
5. Target stack
For e-commerce: Shopify Hydrogen + Next.js, or Shopify Storefront API + custom Next.js. For content sites: Sanity / Contentful / Strapi as CMS + Next.js. Critical: SSG or ISR, not pure SSR; Google crawlers read HTML, they do not wait for JS.
6. Edge redirects (not application redirects)
Vercel/Cloudflare redirect rules, or Nginx if self-hosted. Redirects in Next.js middleware work but add 80-200ms per request. Edge redirects are instant.
7. Clean URL structure
Remove /?page_id=, persistent tracking parameters, /index.php. Cleaner new URLs are much better for CTR.
8. Regenerated sitemap.xml
New auto-generated sitemap (Next.js sitemap.ts) with all new URLs, correct lastmod and reasonable priority. Submit to Search Console the day of the switch.
9. Pre-launch: staging accessible but not indexable
robots.txt with Disallow: / on staging. X-Robots-Tag: noindex headers. If Google indexes staging before launch, you get a month of duplicate content.
10. Pre-launch validation
- Google Rich Results Test for every schema type.
- Lighthouse mobile: LCP < 2.5s, INP < 200ms, CLS < 0.05.
- 404 check: crawl the entire staging site, 0 404 errors.
- Redirect test: 30 random URLs from the old site, confirm 301 to the correct destination.
11. Switch + intensive monitoring (week 1)
DNS to the new site. Search Console: submit sitemap, "Request indexing" on the top 50 URLs. Monitor GSC errors daily for 14 days. If unexpected 404s appear, add them to the redirect mapping.
Expensive mistakes we see often
- Redirects pointing to other redirects (chains). Google only follows 5 jumps. Every redirect should go directly to the final destination.
- Inconsistent trailing slash. Define one rule (with or without slash) and apply it to every URL and redirect.
- Broken canonical tags. Every page must have canonical pointing to its new URL, not the old one.
- Images with old URLs (WordPress CDN). Migrate images with redirects or re-upload them with new URLs.
- Forgetting discontinued products. If a product page had organic traffic, redirect it to the category; do not kill it with 404.
Performance targets (mobile, 4G)
| Metric | Typical WordPress | Well-built headless |
|---|---|---|
| LCP | 3.5-6.5s | 1.2-2.2s |
| INP | 250-450ms | 80-180ms |
| CLS | 0.12-0.35 | 0.02-0.06 |
| Total JS | 800kb-1.4Mb | 120-260kb |
| Total images | 1.5-4Mb | 200-500kb (AVIF + lazy) |
How long it takes
Content site (~200 URLs): 6-8 weeks. Medium e-commerce (~1,000 SKUs): 9-14 weeks. Large e-commerce (5,000+ SKUs, configurables): 16-24 weeks. The pessimistic estimate includes dev + QA + post-launch SEO adjustment. Fast migrations are the ones that lose traffic later.
What if I lose positions anyway?
A temporary 2-4 week drop is normal while Google reindexes. If after 6 weeks you have not recovered 90%+ of traffic, there was an implementation error. Audit + fixes can take 4 additional weeks. That is why the plan matters.
Do I keep the CMS so marketing can still publish?
Yes. Headless means the CMS remains friendly (Sanity, Contentful, Strapi). Marketing publishes in the CMS, Next.js consumes the API. Editor UX can be equal or better than WordPress.
Is it worth it for small sites?
If your site has < 50 URLs and < 5k visits/month, probably not. WordPress with a decent theme and caching is fine. Migration makes sense once traffic is meaningful or problems are concrete.
What we recommend
Before migrating, optimize WordPress as much as possible: CDN, image optimization, plugin audit, aggressive caching. If after 4 weeks of optimization you still do not reach green CWV, migrate.
For migration: hire an agency that has done 5+ migrations with verifiable cases. Ask to see the URL-mapping spreadsheet from a previous migration. If they do not have one, do not sign.