Skip to content
SEOParity

The 47-Point WordPress Migration Checklist

The full SEO-safe migration checklist is readable below. Use it to protect redirects, canonicals, metadata, schema, tracking, Core Web Vitals, QA, and post-launch monitoring.

Want a copy for your project file?

Just the checklist. No spam. Unsubscribe anytime.

Built from real migration QA work. Rated 4.8 on Clutch.

What this checklist covers

Before migration

Baseline and URL inventory

  • Export every crawlable WordPress URL with status code, title, meta description, canonical, word count, and indexability.
  • Export Google Search Console pages with clicks, impressions, average position, and indexed/not-indexed state.
  • Export GA4 landing pages and conversions so high-value URLs are not treated like low-value archive pages.
  • 5 more checks in this section

Before migration

Redirects and URL architecture

  • Map every old URL to a final destination, not to a temporary placeholder or homepage catch-all.
  • Use permanent 301 redirects for migrated URLs unless there is a documented technical reason for another status.
  • Resolve slash/no-slash, uppercase/lowercase, www/non-www, and HTTP/HTTPS variants into one canonical convention.
  • 5 more checks in this section

During migration

Content, metadata, and schema parity

  • Export title tags, meta descriptions, canonical URLs, headings, and body copy from the old site.
  • Compare every new template against the old template for missing sections, FAQs, tables, images, and internal links.
  • Move the important content, not only the visible design. Tabs, accordions, and archive copy often get lost.
  • 5 more checks in this section

Use this resource as the operating checklist

This page is the action list. Keep it open while you build the URL inventory, redirect map, canonical worksheet, sitemap, QA crawl, and post-launch monitoring log.

Use the blog guide for the explanation

The WordPress to Next.js SEO checklist article explains why the steps matter. This resource is the implementation version for teams already doing the work.

Read the explanatory guide

Citation-ready answer

WordPress migration answers to extract before launch

What is an SEO-safe WordPress migration?

An SEO-safe WordPress migration preserves the URLs, redirects, canonicals, metadata, structured data, content, internal links, speed signals, and tracking paths that search engines and users already rely on.

When it breaks

It breaks when design, CMS, hosting, and URL changes ship together without a frozen URL inventory, redirect map, raw-HTML parity checks, or a post-launch monitoring log.

Inspect first

Inspect old GSC pages, GA4 landing pages, crawl exports, backlinks, old sitemaps, new sitemaps, template HTML, and launch-day redirects before DNS or CMS cutover.

Source: Google site move guidanceRelated: Redirect map template

What should happen before launch?

Before launch, the team should freeze the URL inventory, map old URLs to final destinations, rebuild metadata and schema intentionally, generate a clean sitemap, and test priority pages in raw HTML and a browser.

When it breaks

Launch risk increases when staging noindex, copied WordPress canonicals, missing content blocks, redirect chains, untested forms, or tracking changes are discovered only after traffic moves.

Inspect first

Inspect P0 pages first: status code, canonical, title, description, H1, schema, body content, internal links, sitemap row, Core Web Vitals, and lead events.

Source: Google canonical guidanceRelated: Canonical checker

What should happen after launch?

After launch, the team should monitor GSC pages, queries, sitemap reads, crawl stats, URL Inspection samples, GA4 organic landing pages, lead events, and Core Web Vitals for at least 30 days.

When it breaks

Recovery slows down when teams request indexing without fixing noindex, robots, redirect, canonical, sitemap, internal-link, or soft-404 problems first.

Inspect first

Inspect GSC Page Indexing, URL Inspection, sitemap read state, crawl stats, GA4 landing-page trends, and the post-launch fix log before asking for recrawl.

Source: URL Inspection helpRelated: GSC monitoring runbook
Diagnostic stepQuestion to answerAction when it fails
URL inventoryDo all old traffic, backlink, and sitemap URLs have a planned destination?Freeze the inventory and mark P0 rows before implementation.
Signal parityDo titles, canonicals, schema, content, and internal links survive the rebuild?Fix template parity before launch-day crawl QA.
Launch QADo old URLs redirect once to final 200 pages and do new sitemap URLs return clean indexable pages?Fix redirects, noindex, robots, canonical, and sitemap failures before submission.
MonitoringAre GSC, GA4, lead events, and Core Web Vitals being checked against baseline?Use the runbook and record each fix, deployment date, and recrawl state.

The full 47-point checklist

Work through this in order. Do not treat launch day as the starting point. The first two phases should be completed before DNS, deployment, or CMS cutover.

Before migration

Baseline and URL inventory

8 checks

  • 01Export every crawlable WordPress URL with status code, title, meta description, canonical, word count, and indexability.
  • 02Export Google Search Console pages with clicks, impressions, average position, and indexed/not-indexed state.
  • 03Export GA4 landing pages and conversions so high-value URLs are not treated like low-value archive pages.
  • 04Pull backlink and top-page data from Ahrefs, Semrush, or the closest available backlink source.
  • 05Group URLs by template: homepage, service, blog post, category, tag, author, product, product category, and utility pages.
  • 06Mark P0 URLs that have traffic, backlinks, revenue, leads, or active internal links.
  • 07Identify URL patterns that will disappear, merge, or change paths in the new build.
  • 08Freeze the URL inventory before implementation so late content changes are tracked instead of guessed.

Before migration

Redirects and URL architecture

8 checks

  • 09Map every old URL to a final destination, not to a temporary placeholder or homepage catch-all.
  • 10Use permanent 301 redirects for migrated URLs unless there is a documented technical reason for another status.
  • 11Resolve slash/no-slash, uppercase/lowercase, www/non-www, and HTTP/HTTPS variants into one canonical convention.
  • 12Keep query parameters only when they represent meaningful content or tracking that must survive.
  • 13Add explicit rows for deleted pages: relevant replacement, useful archival page, or deliberate 410.
  • 14Test for redirect chains before launch. Old URL should go directly to final 200 URL.
  • 15Test for redirect loops and pattern collisions across CMS, CDN, server, and framework routes.
  • 16Load the highest-traffic old URLs in a browser and confirm the destination content satisfies the same intent.

During migration

Content, metadata, and schema parity

8 checks

  • 17Export title tags, meta descriptions, canonical URLs, headings, and body copy from the old site.
  • 18Compare every new template against the old template for missing sections, FAQs, tables, images, and internal links.
  • 19Move the important content, not only the visible design. Tabs, accordions, and archive copy often get lost.
  • 20Implement self-referencing canonicals on every indexable destination page.
  • 21Make sure canonical targets return 200, are indexable, and match sitemap/internal-link targets.
  • 22Inventory JSON-LD schema from WordPress plugins and rebuild it intentionally in the new stack.
  • 23Validate structured data for breadcrumbs, articles, products, reviews, FAQs, organization, and local profiles where applicable.
  • 24Check Open Graph and social images so shared pages do not fall back to generic assets.

During migration

Indexability, rendering, and performance

8 checks

  • 25Confirm production robots.txt allows the sections that should be crawled.
  • 26Remove staging noindex, password walls, basic auth, and temporary blocks before launch.
  • 27Generate an XML sitemap from the new route list and include only 200-status, canonical, indexable URLs.
  • 28Fetch priority pages with curl and confirm canonical, robots, title, description, and JSON-LD appear in raw HTML.
  • 29Render priority pages in a browser and confirm no important content depends on delayed client-only code.
  • 30Run mobile PageSpeed or Lighthouse on homepage, service pages, high-traffic posts, and conversion pages.
  • 31Record Core Web Vitals baselines for LCP, INP, CLS, TTFB, and total blocking time before launch.
  • 32Check image dimensions, font loading, third-party scripts, and above-fold content before launch day.

Launch day

QA, tracking, and submissions

7 checks

  • 33Deploy redirects before or at the same time as the new routes. Never after traffic has already moved.
  • 34Crawl the old URL list against production and export status, final URL, redirect hops, and target status.
  • 35Crawl the new sitemap and confirm every URL returns 200, self-canonical, indexable, and internally linked.
  • 36Submit the new sitemap in Google Search Console and Bing Webmaster Tools when the platform shows stale or missing sitemap state.
  • 37Request indexing for critical pages only after live tests show they are indexable.
  • 38Verify GA4, GTM, lead events, form success states, and attribution parameters on production.
  • 39Test contact forms, report requests, checkout/product flows, and thank-you states with marked test submissions.

After launch

First 30 days of monitoring

8 checks

  • 40Check Search Console daily for indexing drops, crawl errors, soft 404s, alternate canonical selections, and sitemap processing.
  • 41Compare top landing pages, queries, and conversions against the pre-launch baseline.
  • 42Inspect any URL where Google-selected canonical differs from user-declared canonical.
  • 43Watch server logs or crawl stats for old URLs that still receive requests but lack a clean redirect.
  • 44Re-crawl the site after fixes so redirects, canonicals, sitemaps, internal links, and schema stay aligned.
  • 45Rerun mobile performance checks after traffic and third-party scripts settle.
  • 46Record every fix with URL, issue, owner, deployment date, and follow-up recrawl state.
  • 47Hold 30, 60, and 90 day checkpoints for traffic, rankings, key events, and remaining technical debt.

A migration audit should leave the development team with URLs, evidence, owners, and a fix order. This checklist follows that sequence: inventory first, implementation second, launch QA third, monitoring last.

“The combination of technical skills and SEO awareness is not something you find often. He felt more like part of our internal team.”, Ali Rezaiyan, DullesGlass (2-year engagement)

Send me a copy of the checklist

The full checklist is already on this page. Use the form if you want it in your inbox for the migration folder.

Just the checklist. No spam. Unsubscribe anytime.

© 2026 SEOParity

seoparity.com