The WordPress Migration Checklist

How to use this checklist

The checklist applies whether you are moving from WordPress to Next.js, Webflow or Shopify, rebuilding on a new WordPress theme, or changing hosts. Not every item applies to every project; a theme rebuild that keeps all URLs can skip most of the redirect work, while a platform change with a new URL structure needs all of it.

Copy the items into your project tool, assign an owner to each and set a deadline relative to launch day. Most migration problems are not technical failures; they are items that everyone assumed someone else was handling.

Inventory and baselines

You cannot protect what you have not recorded. Do this before any build work starts, and before anything changes on the live site.

Content and URLs

• Crawl the full site and export every URL with status code, title, meta description, H1, canonical and indexability.
• Merge in URLs from the XML sitemap, the Search Console page indexing report, and analytics landing pages from the last 12 months.
• Identify the pages with the most organic traffic, conversions and inbound links; these get extra attention in every later step.
• List content types, templates, taxonomies (categories, tags, custom taxonomies) and authors.
• Export existing redirects from redirect plugins, .htaccess or server configuration; they must be carried over too.
• Decide for each URL: migrate as is, merge, redirect or retire.

Functionality

• List every active plugin and what it does, then mark each function as rebuild, replace with a service, or drop.
• Document every form: fields, recipients, integrations, confirmation messages and spam protection.
• List third-party scripts: analytics, tag manager, advertising pixels, chat widgets, consent tool, embeds.
• Look for hidden functionality: scheduled tasks, automated emails, webhooks, user accounts and admin workflows.

Baselines

• Organic sessions and conversions per landing page, ideally by week for the last few months.
• Search Console clicks, impressions and top queries. Export them; Search Console only keeps about 16 months of performance data.
• Number of indexed pages and any existing indexing or crawl errors.
• Core Web Vitals field data where available, and PageSpeed lab scores for each key template.
• Save every export with a date. You will need them to tell real changes from seasonal noise after launch.

A SiteRefactor analysis can be a useful snapshot here: detected technologies and plugins, PageSpeed results, SEO basics and an estimate of page volume from your sitemap. It inspects up to 20 pages, so it complements a full crawl rather than replacing it.

Backups and staging

• Take a full backup of files and database, store a copy off the server, and test that it can actually be restored.
• Export content in a portable format as well (WordPress XML export, CSV or API dump).
• Keep backups for several months after launch; problems sometimes surface weeks later.
• Protect staging with a password or IP restriction, not only with noindex or robots.txt, so it cannot be indexed or leaked.
• Agree on a content freeze or a plan for syncing content edited on the live site during the build.
• List every account and who has access: domain registrar, DNS, hosting, CDN, email (MX records), Search Console, analytics, tag manager and any platform subscriptions.

URL mapping and 301 redirects

Redirects are the single most important protection for search visibility and inbound links.

Building the map

• Keep existing URLs wherever the new platform allows it. Every URL you keep is a redirect you do not need.
• Map every changed URL one to one to its closest equivalent. Do not send everything to the homepage.
• For content deliberately removed without a replacement, let it return 404 or 410 rather than redirecting to an unrelated page.
• Include the easily forgotten URLs: category, tag and author archives, pagination such as /page/2/, attachment pages, feeds, PDFs and images under /wp-content/uploads/ with inbound links, and parameter URLs that receive traffic.
• Update old redirects to point straight to the final destination, avoiding chains.

Implementing and testing

• Use permanent redirects (301 or 308), not temporary ones (302 or 307).
• Normalize protocol, host and trailing slashes: HTTP to HTTPS, one of www or non-www, one trailing-slash convention.
• Test the whole map automatically on staging: every old URL should reach a 200 page in a single hop.
• Update internal links, menus and buttons to the new URLs instead of relying on redirects.

Metadata, canonicals and hreflang

Metadata

• Carry over page titles and meta descriptions, including those stored by Yoast, Rank Math or similar plugins.
• Avoid rewriting all titles at the same time as the migration; changing one variable at a time makes problems easier to diagnose.
• Check heading structure: one clear H1 per page and a logical hierarchy.
• Recreate Open Graph and social sharing tags, including share images.

Canonicals and indexing

• Each indexable page has a self-referencing canonical with the absolute production URL.
• No staging domain appears anywhere in canonicals, sitemaps, Open Graph URLs or internal links.
• Robots meta tags and robots.txt allow crawling of everything that should be indexed, including CSS and JavaScript files.
• The XML sitemap lists only canonical, indexable URLs that return 200, and is referenced in robots.txt.
• Decisions on archive, tag and pagination indexing match the old site, unless you change them deliberately.

hreflang (multilingual sites)

• Every language version lists all alternates including itself, and the annotations are reciprocal.
• Use absolute URLs that match the canonical URLs, plus x-default where you have a language selector or fallback page.
• Map every language URL individually in the redirect plan; multilingual structures are a frequent source of errors.

Structured data and media

Structured data

• Inventory existing structured data: Organization, WebSite, BreadcrumbList, Article, Product, LocalBusiness and others. SEO plugins add much of it automatically, which makes it easy to lose.
• Recreate it on the new site and validate it with the Rich Results Test or the Schema Markup Validator.
• Make sure the structured data matches the content visible on the page.

Media

• Migrate all images, documents and videos, and keep or redirect the URLs of files with inbound links.
• Keep alt text and captions; they are often stored separately from the files themselves.
• Serve responsive sizes and modern formats, set image dimensions to avoid layout shift, and lazy-load images below the fold.
• Search the new site for images still loaded from the old domain or from staging.

Forms, analytics and consent

Forms

• Rebuild every form and test it end to end: validation, spam protection, notification emails, CRM or newsletter sync, and the confirmation message.
• Check that notification emails are delivered, with sending domains correctly authenticated (SPF, DKIM, DMARC).
• Confirm that conversion tracking still fires after a successful submission.

Analytics

• Install analytics or the tag manager container on every template, and verify that key events and conversions are recorded.
• Exclude staging traffic and add an annotation for the launch date.
• Verify Search Console ownership in a way that survives the migration; a DNS-verified domain property is the most robust.

Consent and privacy

• Where consent is required, for example in the EU and UK, confirm that non-essential scripts do not load before consent is given.
• Check that the consent banner records choices and that visitors can change them later.
• Update the privacy policy and cookie information if tools or data flows change.

Performance

• Compare each key template against the baseline using PageSpeed Insights, and against field data once enough real traffic exists.
• Check caching headers, compression, CDN configuration and font loading.
• Set a budget for third-party scripts; tag managers and widgets often undo the gains of a rebuild.
• Test on a mid-range mobile device over a throttled connection, not only on a fast laptop.
• Do not launch a site that is slower than the one it replaces without a documented reason and a plan to fix it.

Pre-launch QA

• Crawl staging for broken links, missing or duplicate titles, unintended noindex tags, canonical errors and mixed content.
• Review every template on mobile, tablet and desktop in the major browsers.
• Compare the top 20–50 pages by traffic side by side with the old site: content, headings, images, links and calls to action.
• Check accessibility basics: keyboard navigation, visible focus, color contrast, alt text and form labels.
• Confirm the custom 404 page returns an actual 404 status code.
• Check HTTPS, security headers and that no admin, staging or debug endpoints are publicly exposed.
• For stores: complete test purchases with each payment method, and check taxes, shipping, order emails and refunds.
• Walk editors through publishing, previewing and scheduling content on the new system.

Launch day

24–48 hours before

• Lower the DNS TTL of the records you will change, for example to 300 seconds. Do it at least as long in advance as the current TTL, so resolvers pick up the shorter value before the switch.
• Pick a low-traffic window early in the week, when the whole team is available. Avoid Friday afternoons and peak sales periods.
• Write down the rollback plan: what triggers it, who decides, and how to point DNS back.

During the switch

• Run the final content sync if content changed during the freeze.
• Change only the DNS records you intend to change; leave MX and other email-related records untouched.
• Confirm a valid TLS certificate for every hostname, including both www and the apex domain.
• Remove staging protection and noindex settings from production, and check robots.txt and meta robots on live pages.
• Run the redirect test against production.
• Submit the new XML sitemap in Search Console and inspect a few key URLs.
• Submit every form and, for stores, complete a real purchase.
• Confirm analytics is recording live visits.

After the switch

• Keep the old site and hosting available, but not publicly indexable, until the new site is stable.
• Raise the DNS TTL back to its normal value once everything has been stable for a few days.

Post-launch monitoring (4–8 weeks)

First week, daily

• Check 404 and server error logs, and add redirects for missing URLs that receive traffic or have inbound links.
• Watch the Search Console page indexing report and crawl statistics for sudden changes.
• Confirm that forms, conversions and, for stores, orders are coming in at normal levels.

Weeks two to eight, weekly

• Compare organic clicks, impressions and conversions with the baseline, using the same weekdays and accounting for seasonality.
• Track rankings and landing pages for your most important queries.
• Review Core Web Vitals as field data accumulates.
• Ask partners who link to your most important old URLs to update those links.

Some fluctuation in search traffic is normal while search engines re-crawl the site. If a drop persists for several weeks, work through the redirect map, indexing reports and template differences systematically. Keep redirects in place for at least a year, and preferably permanently.

Common mistakes

• Launching with staging settings: a sitewide noindex tag or a robots.txt Disallow: / carried over to production.
• Redirecting everything to the homepage instead of mapping URLs to their real equivalents.
• Forgetting non-page URLs: images, PDFs, feeds and archive pages with inbound links.
• Redirect chains created by stacking new redirects on top of old ones.
• Changing everything at once: domain, URLs, design and content in one release, which makes any drop hard to diagnose.
• No baseline: without saved exports, nobody can tell whether traffic really changed.
• Broken tracking mistaken for lost traffic: a missing analytics tag can look like a traffic collapse.
• Breaking email during the DNS switch by overwriting MX records.
• Canceling the old hosting the day after launch, before backups and rollback are no longer needed.

Still deciding whether to migrate at all? Our guides to WordPress to Next.js, WordPress to Webflow and website migration costs cover the trade-offs, including when improving the existing site is the better choice.