Why Marketing Sites Are Migrating From WordPress to Next.js

Marketing leads at growing service businesses keep arriving at the same conclusion: 'We need to leave WordPress.' The reasons rhyme. Plugin updates that broke staging at 11pm Friday. A security plugin alert about another Elementor CVE. A campaign that needed a landing page yesterday and shipped three days late because the theme fought the form. A Lighthouse report from the CMO showing a Performance score in the 40s.

This is the migration playbook we recommend. It is opinionated because the failure modes are predictable. For the head-to-head, see Next.js vs WordPress; for the broader Next.js context, see the marketing sites pillar.

What is driving the migration momentum?

The drivers are operational pain that compounds month over month, and two of them are measurable rather than anecdotal. Patchstack's State of WordPress Security report counted 7,966 new vulnerabilities across the WordPress ecosystem in 2024 — 96% in plugins, 4% in themes, and only seven in core. And Google's page experience documentation confirms that 'Core Web Vitals are used by our ranking systems,' which turns a page-builder site stuck at a Lighthouse 45 into a standing tax rather than a cosmetic complaint.

Neither fact says 'rebuild on Next.js.' What they say is that the thing generating your pain is the plugin layer and the render-time bloat it drags in — so any fix that does not remove that layer is a delay, not a solution. That is the actual case for migrating, and it is worth being precise about it, because 'WordPress is insecure' is a lazy claim that a competent WordPress engineer will correctly tear apart.

• Core Web Vitals failures — with CWV as a Google ranking factor, WordPress sites' typical 40-70 Lighthouse scores become a measurable traffic problem
• Plugin sprawl — a typical WP marketing site accumulates dozens of active plugins; each one is a maintenance and security surface
• Security incidents — 96% of 2024's 7,966 WordPress-ecosystem vulnerabilities were in plugins (Patchstack), and the risk scales with how many you have installed
• Editorial bottlenecks — page builders (Elementor, Divi) trap content in proprietary blocks that do not export cleanly
• Hosting cost creep — managed WP hosts (WP Engine, Kinsta) have raised prices in recent years while serverless/edge pricing has trended down
• AI citation readiness — clean, well-structured HTML is easier for AI answer engines to parse and cite than markup bloated by page-builder wrappers

What are the specific pain points that trigger a rebuild?

Marketing leaders rarely migrate because of a single incident. The decision point is when three or more of the patterns below show up in the same quarter. Below is a diagnostic you can run against your own site.

• Last security incident was less than 12 months ago
• Lighthouse Performance score is below 70 on the home page or top 3 traffic pages
• Landing page ship time exceeds 2 business days for a designer + developer pair
• Plugin count exceeds 20 active plugins
• Page builder lock-in (Elementor, Divi, WPBakery) — content is wrapped in proprietary shortcodes
• Editorial team has bypassed the CMS to send Word docs to a developer for 'pages the CMS cannot build'
• Monthly WP managed hosting + plugin licenses + maintenance retainer exceeds $400
• Marketing has stopped requesting new pages because 'it takes too long'

How risky is the migration?

The migration risk is concentrated in one area: redirects. Everything else (rebuilding pages, moving content, training editors) is plain project work with predictable outcomes. The redirect map is what determines whether you keep your organic traffic or lose a large share of it for months.

Every WordPress URL that has earned a backlink, ranks for a keyword, or is in your sitemap needs a 301 redirect to its Next.js equivalent. The mapping is rarely 1:1 — WP archives, category pages, attachment URLs, and date-based blog permalinks all need policy decisions. A 25-page-plus-blog site can easily surface well over a thousand URLs once you count attachments and faceted archives.

Google's site move documentation is unusually specific here, and it contains the instruction almost every team gets wrong. Google says to 'use server side permanent redirects if technically possible' — 301 or 308 — and then: 'keep the redirects for as long as possible, generally at least 1 year.' Not one month. A year. That is how long Google needs 'to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs.'

This kills the most common post-migration mistake: ripping out the redirect layer at the 90-day mark because the traffic looks fine and the next.config.js file has gotten ugly. Those redirects are still carrying link equity from third-party sites that have not recrawled you yet. Leave them. On timing, Google's stated expectation is that 'a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer' — so plan your post-launch monitoring window around weeks, not days, and do not panic-revert on day three.

• Pull every URL from Google Search Console (Performance > Pages, last 16 months)
• Pull every URL from Ahrefs/Semrush with at least 1 referring domain
• Pull every URL from your existing sitemap.xml
• Deduplicate, then map each URL to a Next.js path (1:1, 1:many, or 410 Gone for retired pages)
• Implement redirects in next.config.js or middleware.ts — verify with curl -I before cutover
• Monitor Search Console 'Pages with redirect' and 'Not Found (404)' weekly for 90 days post-launch

What is a realistic timeline?

For a 25-page marketing site with a 100-post blog, the realistic timeline is 8-12 weeks end-to-end with one senior developer plus a designer at 50% capacity. Larger sites scale roughly linearly with page count until you hit ~500 pages, at which point parallel work and a content migration script start mattering more than developer count.

• Weeks 1-2 — Discovery: URL inventory, content audit, redirect map, design system audit
• Weeks 3-6 — Rebuild: Next.js scaffolding, design system, page templates, CMS schema, content migration
• Week 7 — Integration: headless CMS connection, analytics, conversion tracking, structured data
• Week 8 — Redirects: implement, test every URL with curl, verify in staging
• Weeks 9-10 — Parallel staging: side-by-side QA, content review, accessibility check, Lighthouse runs
• Week 11 — Cutover: DNS swap, monitor Search Console + analytics hourly for the first 24 hours
• Week 12 — Post-launch: fix any 404s, finalize editor training, hand off documentation

Should you redesign or replatform?

The biggest scope-creep risk in a WordPress-to-Next.js migration is bundling a redesign with the replatform. Doing both at once doubles timeline, triples coordination overhead, and triples the post-launch risk surface. We push hard for a 'lift and shift' replatform — same visual design, same URLs, same content — followed by an iterative redesign over the next 1-2 quarters.

Exceptions: if your current site is fundamentally broken (mobile-unusable, accessibility-failing, off-brand), then replatform + minimum-viable-redesign together. But the default should be 'replatform first, redesign second.' This isolates the risk: if traffic drops post-launch, you know it is the replatform (redirects, indexing) and not the design. See our website design service for how we structure phased engagements.

What does side-by-side staging look like?

The cutover risk drops dramatically if you run the Next.js site in parallel with the WordPress site for 1-2 weeks before flipping DNS. The pattern: deploy Next.js to a subdomain (next.yourdomain.com), share the staging URL with stakeholders, run Lighthouse + accessibility tests, run a crawl with Screaming Frog to find broken links, and verify the redirect map by curl-ing every old URL.

• Staging URL — next.yourdomain.com with basic auth or IP allowlist
• Crawler — Screaming Frog or Sitebulb crawls staging, reports broken internal links
• Redirect verification — script that curl-Is every old URL against next.yourdomain.com, expects 301 to correct path
• Lighthouse — automated CI Lighthouse runs on staging, fail build if any page <90 Performance
• Visual regression — Percy or Chromatic compares old WP screenshots to new Next.js for design parity
• Analytics dry run — fire test conversion events on staging to verify GA4/CAPI integration

What happens to SEO equity during the migration?

Done correctly, the common pattern is a small dip in the first few weeks post-launch as Google recrawls and re-evaluates, followed by recovery to baseline or slightly above within roughly 90 days. Any lift typically comes from Core Web Vitals improvements being a ranking factor. The recovery curve is most predictable when the redirect map is clean and complete.

Done incorrectly — missing redirects, changed URL patterns without 301s, lost JSON-LD — traffic can drop sharply and take many months to recover, if it recovers at all. The downside is almost entirely preventable. The investment in the redirect map is the single highest-ROI hour of work in the migration. See the Next.js Metadata API guide for preserving structured data and canonicals.

What is the SEO-equity preservation checklist?

SEO equity survives a replatform when you deliberately preserve the signals Google already trusts. Ranking dips during migrations almost always trace to missed redirects or dropped on-page signals, not the framework change itself. Run this checklist before cutover and again in the first week after, and pair it with hitting 100/100 Core Web Vitals on Next.js, since the speed gain is the one place a clean migration can actually lift rankings.

• 301-map every old URL that has a ranking, a backlink, or a sitemap entry to its exact new path — the single highest-ROI task in the migration.
• Keep those redirects live for at least a year — Google's site-move guidance says 'generally at least 1 year' so it can reassign links from sites that have not recrawled you yet.
• Regenerate and resubmit your XML sitemap in Search Console so Google recrawls the new structure quickly.
• Preserve title tags, meta descriptions, and H1/heading structure page-for-page; do not 'improve' copy during the move.
• Keep canonical tags pointing to the new self-referencing URLs, and verify no stray canonicals point back to the old host.
• Carry over structured data (Organization, LocalBusiness, Article, FAQPage) so rich-result eligibility does not lapse.
• Confirm robots.txt and noindex rules match intent — an accidental sitewide noindex on launch is a catastrophic, common mistake.
• After launch, monitor Search Console 'Pages with redirect,' '404 Not Found,' and coverage counts weekly for 90 days.

When should you NOT migrate?

Four scenarios where staying on WordPress is the right call. We will tell you to stay — migration is not free, and not every site benefits.

• Site has zero active marketing — no new pages, no campaigns, no growth ambition — the dev velocity advantage of Next.js does not pay back
• Site is built on WooCommerce and the storefront drives revenue — moving WooCommerce is a separate $80k+ project; keep WP for now
• Editorial team is 10+ writers using deep WP workflows (custom post types, multi-author flows, internal commenting) — switching cost is too high
• No developer access of any kind (in-house, agency, freelance) — Next.js requires devs for structural changes; without them, stay on WP or move to a hosted builder

Headless WordPress vs a full Next.js rebuild: which path fits you?

A full rebuild is not the only way off WordPress's front-end problems. A middle path — headless WordPress — keeps WordPress as the content editor behind the scenes and renders the public site with Next.js via the WP REST API or WPGraphQL. Your writers keep the WordPress admin they know, you drop the slow PHP theme and the render-time plugin bloat, and you still get static or incrementally-regenerated pages with strong Core Web Vitals. The trade is real: you now run and secure two systems (a WordPress host and a Next.js host), and you inherit WordPress's update and vulnerability surface on the CMS side even though visitors never touch it.

A full rebuild instead moves content into a purpose-built headless CMS (Sanity, Payload, Contentful) and retires WordPress entirely. You lose the familiar WP editor and any plugins your team relied on, and the content move takes more up-front work, but you end with one system to maintain, a cleaner security posture, and a schema that enforces brand-consistent content blocks. Rough rule: choose headless WordPress when the editorial team genuinely refuses to leave WP and you need the win fast; choose a full rebuild when you want the lowest long-term maintenance and are willing to invest in the content migration once. Sites that are almost entirely blog articles are the best headless candidates; sites with heavy custom functionality usually justify the full rebuild.

How much does a migration cost?

For a 25-page site with a 100-post blog, expect $25,000-$60,000 for a competent agency migration in 2026. The range depends on design refresh scope, CMS choice (Sanity Studio is faster than Payload's setup), integration complexity (CRM, marketing automation, calculators), and how clean the existing WP content is.

The payback period is typically 12-24 months when you factor in the operating-cost gap between WP managed hosting + plugins (~$2,400-$8,400 over 3 years) and Vercel + headless CMS (~$1,500-$4,300 over 3 years), plus materially faster landing-page shipping, plus the avoided cost of one security incident. See our pricing for how we structure these engagements, or book a strategy call to scope your specific site.