TL;DR: Most WordPress to Next.js migrations lose 20–40% of organic traffic in the first 60 days because the SEO side was rushed. A migration done right does not lose rankings. The playbook: full URL inventory before touching anything, a complete one-to-one redirect map (every old URL points somewhere meaningful), preserve title tags and H1s on the destination, full content export with no shortened sections, schema parity, a sitemap submitted day one, and Search Console monitoring for 90 days post-launch. Do not change content and structure in the same migration. Move first, optimize later. Migration cost: $5–25k. Post-launch monitoring: 60–90 days minimum.
Most "WordPress to Next.js migration" projects lose 20–40% of organic traffic in the first 60 days because the migration was rushed on the SEO side. The site gets faster, the design gets better, and the rankings collapse, because the redirect map was incomplete or the content export shortened key sections.
A migration done right doesn't lose rankings. Some lift them. Here is the playbook.
Why migrate at all
Three reasons we see most often.
1. Performance is structurally bad. Lighthouse 50–70 on mobile, third-party plugins everywhere, hostgator-class hosting that can't be tuned to fix it.
2. The cost of maintenance crossed the cost of rebuild. Yearly major version migrations, plugin compatibility, security patches, and the "WordPress designer" hourly rate all add up. After 4–6 years, a rebuild is often cheaper.
3. The team has changed. The agency that built it is gone. The internal developer who maintained it left. Nobody understands the theme.
If none of these are true, fix WordPress instead of migrating. Caching, image optimization, plugin auditing, and a real host (Kinsta, WP Engine) can rescue most aging WordPress sites for $1–3k. Migration is $5–25k.
The migration framework
Five phases. Skipping any of them creates the SEO loss most migrations experience.
Phase 1: SEO inventory
Before anything else, build an inventory of what's currently working.
- Search Console export of all queries the site ranks for in the last 12 months, with impressions and clicks.
- List of every URL on the current site. Crawl with Screaming Frog or similar.
- Top 50 pages by organic traffic. These are the pages you can't lose.
- Top 20 backlinks. External sites linking to specific URLs. These need redirects to maintain authority.
- Current schema and meta tags per top-50 page. So you can preserve them.
- Current page speed scores as a baseline.
Without this inventory you're flying blind. Most "lost SEO" migrations skipped this step.
Phase 2: Content export, lossless
WordPress content lives in WP Admin posts and pages, with metadata in wp_postmeta, custom fields, and ACF.
The mistake people make: exporting just the post content (the body) and losing:
- Meta descriptions.
- Custom field values that drive page sections.
- Image alt text.
- Featured images and their relationships to posts.
- Custom URLs and slugs.
- Author info.
- Publication and update dates.
A correct export captures all of these. The Next.js side then has to honor them: meta descriptions become metadata, alt text stays on images, dates stay on posts.
We use the WordPress REST API or a custom plugin export to get a clean JSON of every post with all fields preserved.
Phase 3: URL mapping and redirects
The single most important deliverable in a migration.
For every URL on the old site, decide:
- Same URL on new site. Most posts and pages can keep their URL. /about → /about. /blog/post-slug → /blog/post-slug.
- Redirected to a new URL. /services/web-design → /services. /old-product → /products/new-product.
- 410 (gone). A page that's no longer relevant and shouldn't be redirected. Use sparingly.
Every old URL needs a row in the redirect map. No exceptions.
The redirect type matters:
- 301 (permanent). Use for almost every redirect. Passes 90%+ of authority.
- 302 (temporary). Don't use unless you genuinely will reverse the redirect.
- 410 (gone). Tells Google to drop the URL from the index.
In Next.js, redirects live in next.config.ts:
async redirects() {
return [
{
source: "/services/web-design",
destination: "/services",
permanent: true,
},
// hundreds more
];
}
For a typical mid-size site, the redirect map is 50–500 rows. We've never shipped a migration with fewer than 30.
Phase 4: Schema and metadata transfer
Most WordPress sites have basic schema via Yoast or RankMath. The new site needs equivalent or better.
Minimum to preserve:
- Organization schema on every page.
- Article / BlogPosting on every post, with the original
datePublished. - BreadcrumbList on every nested page.
- Per-page meta title and description. Match or improve, never shorten without thought.
- Canonical URLs. Point to the new URL.
- Open Graph and Twitter Card images, titles, descriptions.
What to add that WordPress probably didn't have:
/llms.txtat the root.- Sitemap with proper priorities.
- Robots.txt with crawler-specific rules if you have them.
Phase 5: Launch and monitoring
Pre-launch:
- Full crawl of the staging site to confirm no broken internal links.
- Lighthouse on staging — should be meaningfully better than the WordPress baseline.
- Schema validator on staging — every page passes.
- Manual click-through of top 20 ranking pages on staging.
Launch:
- DNS cutover during low-traffic hours.
- Monitor 404s closely for 48 hours. Anything trending should get a redirect added.
- Submit new sitemap to Search Console immediately.
- Watch Search Console for indexing status of key pages.
Post-launch (first 30 days):
- Daily Search Console check. Are impressions stable? Clicks stable?
- Watch for any URL that drops out of impressions completely. That's a redirect or rendering issue.
- Watch Core Web Vitals. They should improve.
- Watch crawl errors. Fix immediately.
The teams that lose SEO during migrations usually lost it in the first week post-launch and didn't catch it until month two.
What can actually go wrong
Five real failures we've debugged.
1. The redirect map missed 40 URLs. Those 40 became 404s. Search Console showed crawl errors. Rankings dropped on those pages. Fix: an exhaustive crawl before launch.
2. The content export shortened key pages. WordPress's "the_content()" filter applies plugins that the new site doesn't run. Meta-only exports lose those. Fix: export the rendered HTML, not just the raw markup.
3. Schema didn't carry over. New site shipped without Article schema. Pages dropped out of rich results. Fix: schema audit pre-launch.
4. Image URLs broke. WP-Content media URLs went 404 on the new site. Fix: copy the media library to the new site OR set up redirects from /wp-content/uploads/ to the new media location.
5. The new site indexed slower than expected. Google took 8 weeks to fully reindex. Fix: submit the new sitemap, request indexing on top 50 pages individually, and link to new pages from existing high-authority pages.
What we ship for migrations
A typical Webdimonia WordPress migration includes:
- SEO inventory and audit: $1k–$2k.
- Content export and Next.js scaffolding: $2k–$5k.
- Design refresh (or full redesign): $3k–$15k depending on scope.
- Redirect map (50–500 rows) and
next.config.tssetup: $1k–$2k. - Schema, metadata, and AEO setup: $1k–$2k.
- Pre-launch QA, launch, and 30-day monitoring: $1k–$3k.
Total: $9k–$30k for a migration done right. Less than that and a corner is being cut. More than that and someone's padding.
Three questions to decide this week
- Why migrate? If the answer isn't "performance is structurally bad" or "maintenance cost has crossed rebuild cost," consider fixing WordPress instead.
- Do you have Search Console access for the existing site? Without it, the SEO inventory is incomplete and you're flying blind.
- Is anyone going to be on call for the first 30 days post-launch? If no, delay the migration. The first month is when problems surface and need fast fixes.
If you're considering a WordPress to Next.js migration and want a written scope with a phased plan and a redirect strategy, send us the URL and Search Console access. We send a tiered proposal back within three business days.