How to Migrate WordPress to Next.js Without Losing SEO

Step 1

Audit Your WordPress Site

Crawl every URL using Screaming Frog or Sitebulb. Export the URL, title tag, meta description, H1, canonical URL, indexability, and HTTP status. This becomes the SEO migration source of truth. Each indexable WordPress URL should remain at the same path, receive a validated 301 redirect to a relevant replacement, or be intentionally retired with the decision documented.

Also pull your top pages from Google Search Console sorted by clicks. These get the most scrutiny during QA. A broken redirect on your top landing page can cost you significant traffic.

Step 2

Export Your WordPress Content

Go to WordPress Admin → Tools → Export → All Content. Download the XML file: it contains every post, page, category, tag, and custom field. For images, download your full wp-content/uploads folder via FTP or your host's file manager.

Before importing images into Next.js, convert them to WebP format and compress them to under 150KB where possible. Tools like Squoosh or ImageOptim work well for batch conversion. Next.js's next/image component will handle responsive sizing automatically, but starting with well-optimized source images gives you the best PageSpeed baseline.

Step 3

Set Up Your Next.js Project

Scaffold your project with npx create-next-app@latest --typescript. Install Tailwind CSS for styling. Deploy an empty shell to Vercel immediately. This sets up your CI/CD pipeline so every commit deploys automatically. You will use preview URLs for QA throughout the build.

If you need a content management interface for blog posts or frequently updated pages, define the fields, relationships, roles, preview workflow, localization, and publishing approvals before choosing a headless CMS. Sanity and Contentful are established options, but plan eligibility, included usage, editor seats, and operating cost should be checked against the current project requirements.

Step 4

Build Your Pages and Migrate Content

Build each page as a React Server Component in Next.js. Replicate your navigation structure, internal linking, and page hierarchy exactly. Import your WordPress XML content into your CMS or convert blog posts to MDX files. Use next/image for every image: this automatically serves WebP, handles lazy loading, and generates responsive sizes.

For each WordPress plugin, implement the equivalent native solution:

• ✓
  Contact Form 7 / Gravity Forms → API route + Resend or Nodemailer
• ✓
  Yoast SEO → Next.js metadata API + JSON-LD schema in each page
• ✓
  Analytics and advertising tags → consent-gated loading through the site's approved consent flow, with regional behavior and event delivery verified before launch
• ✓
  WooCommerce → Shopify headless or custom Stripe integration
• ✓
  Social sharing buttons → lightweight custom component (no plugin needed)

Step 5. Critical

Set Up 301 Redirects

Redirect decisions are a critical part of SEO preservation. Each changed URL with a relevant successor should normally receive a server-side permanent redirect. An intentionally removed URL with no useful replacement can return 404 or 410 instead of sending users to an unrelated page. Record that decision for every URL in the inventory. In next.config.js, add a redirects array:

async redirects() {
  return [
    {
      source: '/old-wordpress-slug',
      destination: '/new-nextjs-path',
      permanent: true, // 301
    },
  ]
}

Common URL changes that may need redirects include WordPress /category/ archives, date-based post URLs (/2024/03/post-name), and tag pages. Map useful old URLs to the closest relevant equivalent, avoid redirecting many unrelated pages to the homepage, and keep the migration redirects in place for at least one year under Google's current site-move guidance.

Step 6

Migrate All SEO Metadata

Transfer every title tag, meta description, Open Graph tag, and canonical URL from WordPress (via Yoast or RankMath) to Next.js. In Next.js 14+, use the metadata API in each page.tsx:

export const metadata = {
  title: "Your Page Title",
  description: "Your meta description",
  alternates: { canonical: "https://yoursite.com/page" },
  openGraph: { title, description, type: "website" },
}

Recreate only the JSON-LD structured data that accurately describes the page and was previously generated by WordPress or its SEO plugin. Common types include Organization, WebSite, BreadcrumbList, WebPage, and Article where eligible. Keeping schema in the codebase makes it version-controlled and testable, but it does not guarantee a rich result.

Generate a new sitemap.xml with Next.js metadata routes or next-sitemap. Include the canonical, indexable URLs you want search engines to discover, exclude application and API routes, and compare the output with the approved URL inventory.

Step 7

QA and Pre-Launch Testing

Do not go live until all of these pass:

• ✓
  If the signed scope includes a 90+ mobile PageSpeed acceptance target, run three tests on each agreed representative page and record the URL, device profile, date, and environment
• ✓
  Every URL assigned a redirect tested for the expected permanent status, relevant destination, and final 200 response without a chain; every intentional retirement tested for its documented 404 or 410 response
• ✓
  All forms submitting correctly with confirmation emails firing
• ✓
  All images loading with correct alt text and dimensions
• ✓
  Google's Rich Results Test passing on key schema pages
• ✓
  sitemap.xml rendering all expected URLs at /sitemap.xml
• ✓
  robots.txt and page-level robots directives match the approved indexation plan; sensitive API routes use authentication and authorization because robots.txt is not access control
• ✓
  No console errors in Chrome DevTools on any page
• ✓
  Mobile layout tested on actual devices (not just browser devtools)

QA duration follows the number of templates, URLs, forms, integrations, devices, redirect exceptions, and acceptance rounds in scope. Do not compress it into a universal one- or two-day promise. A broken form or missing redirect discovered after launch costs more time to fix than finding it in staging.

Step 8

DNS Cutover and Post-Launch Monitoring

When QA is complete and everything passes, update your domain DNS to point to Vercel. In your domain registrar, update the A record to Vercel's IP or add a CNAME pointing to your Vercel project URL. Vercel provisions an SSL certificate automatically within minutes.

Immediately after DNS propagates and your new site is live:

• ✓
  Submit your new sitemap.xml in Google Search Console → Sitemaps
• ✓
  Use Google Search Console's URL Inspection tool to request indexing on your top 10 pages
• ✓
  Verify your old WordPress site is fully offline or returning 301s (not serving duplicate content)
• ✓
  Use Search Console's URL Inspection and Page indexing reports to check how Google sees the production URLs
• ✓
  Monitor Search Console daily for crawl errors in the first 2 weeks

Ranking volatility can occur while Google recrawls URLs, follows redirects, and reprocesses canonical signals. There is no fixed recovery window and no agency can guarantee that rankings will rise. Compare clicks, impressions, average position, indexed URLs, crawl errors, and conversions with the pre-launch baseline. Core Web Vitals field data can update only after enough eligible Chrome user data is collected, so use lab tests for immediate debugging and Search Console for longer-term monitoring.