"The migration went fine" is the most dangerous sentence in WordPress SEO. The site loads, the homepage looks right, and everyone moves on. Three weeks later organic traffic is down 30% and nobody can point to what changed, because the regression was invisible on launch day and only became visible once Google re-crawled and re-evaluated the site. The verification you do in the first 48 hours is what separates a clean migration from a slow-motion ranking loss.

The mistake most checklists make is treating "migration" as a single generic event. It isn't. A host move, a domain change, an HTTP-to-HTTPS switch, and a permalink restructure each break SEO in completely different ways, and they need different verification. Match the checks below to what you actually did.

First, the one check every migration needs

Before anything else, open Settings → Reading and confirm "Discourage search engines from indexing this site" is unchecked. This single checkbox sets the blog_public flag, which adds a site-wide noindex directive. Staging environments ship with it enabled by default, and the number-one silent migration killer is pushing a staging build live with that box still ticked. Within hours Google starts dropping pages. There is no error message and the site looks perfectly normal to a human visitor.

While you are there, fetch yoursite.com/robots.txt in a browser. A leftover Disallow: / from the staging server does the same damage. These two checks take 90 seconds and prevent the most catastrophic and most common failure.

If you changed hosts (same URLs)

A pure host move — Bluehost to Kinsta, or a shared host to Cloudways or Rocket.net — keeps every URL identical, so there are no redirects to worry about. The risk is entirely performance and infrastructure, and the regression is usually subtle enough that "it loads" hides it.

TTFB. Measure Time To First Byte on the homepage and a couple of cornerstone posts. Under 200ms is good, under 600ms is tolerable; if your new "faster" host is serving 1.2s TTFB, something is misconfigured — usually a page cache that didn't carry over. WP Rocket, the host's built-in cache (Kinsta, WP Engine), or your CDN config almost always needs to be re-enabled on the new box.
Core Web Vitals. Run PageSpeed Insights and confirm LCP under 2.5s, INP under 200ms, and CLS under 0.1. Note that INP replaced FID as a Core Web Vital in March 2024, so any old benchmark you are comparing against may have measured the wrong metric — re-baseline rather than trusting historical numbers.
SSL and protocol. Confirm HTTPS resolves with a valid certificate and that the non-www and www variants both terminate at the same canonical host. A fresh server frequently ships a default Let's Encrypt cert that covers only one variant.
DNS propagation and email. If you moved DNS, the site can resolve for you while still pointing at the old IP for parts of the world. And if MX records were not copied, transactional and contact-form email silently dies — not strictly SEO, but it is the regression clients notice fastest.

If you changed domains

This is the highest-risk migration type and the one generic checklists handle worst. You are asking Google to transfer every signal it has accumulated from old.com to new.com, and the mechanism is redirects plus an explicit notification.

Map every old URL to a new one, 1:1. Crawl the old site with Screaming Frog or Sitebulb before you tear it down, export the full URL list, and make sure each one points to its true equivalent on the new domain — not a blanket redirect to the homepage. Bulk redirects to the root are read by Google as soft 404s and pass almost no equity.
Use 301s, not 302s. Only a permanent (301) redirect transfers ranking signals. Spot-check 20–30 representative old URLs with curl -I or httpstatus.io and confirm each returns a single 301 hop, not a 302 and not a chain of three redirects burning crawl budget.
File the Change of Address. In Google Search Console, verify the new domain as its own property and submit the Change of Address tool from the old property's settings. This is the step people forget. The redirects alone work eventually, but the Change of Address tells Google explicitly that the move is intentional and dramatically speeds consolidation.
Update internal links and the sitemap. Redirects are a safety net, not a substitute. Search-replace internal links in the database (Better Search Replace handles this safely with a dry run first) so they point directly at new URLs, and submit the fresh sitemap so it contains only live new.com URLs.

If you switched HTTP to HTTPS

Most sites did this years ago, but it still happens during consolidations and rebuilds. The failure mode here is mixed content: the page itself loads over HTTPS while individual images, scripts, or stylesheets still reference http:// URLs. Browsers flag this, and crawlers see an inconsistent security posture.

Run the site through Screaming Frog and check for insecure resource references, or watch the browser console for mixed-content warnings on key templates. Then confirm two things: every canonical tag emits the https:// version of the URL, and a server-level 301 forces HTTP requests to HTTPS. Treat HTTP-to-HTTPS as a domain change for Search Console purposes — the HTTPS site is a separate property and should be verified and have its sitemap submitted independently.

If you restructured permalinks

Moving from /?p=123 or /2026/06/post-name/ to a clean /post-name/ structure changes every URL on the site without touching the domain. WordPress will not create the old-to-new redirects for you, and the default behavior is a hard 404 on every legacy link.

Build the redirect map before flipping the permalink setting. The Redirection plugin or Rank Math's redirect module can import a CSV of old-to-new pairs; for predictable patterns, a regex rule in your server config is cleaner and faster than a database lookup per request.
Check that pretty permalinks are actually working, not just configured. On Nginx and some hosts, the rewrite rules need to be present at the server level or every clean URL returns a 404 despite the setting being saved. Hit a few permalinks directly to confirm.
Re-test internal anchors and any hardcoded links in widgets, menus, and theme templates, which the permalink change does not rewrite.

The 30-day watch in Search Console

Verification on day one catches the obvious breakage. The quieter regressions only surface as Google re-crawls, so the real discipline is watching Search Console for the first month. The signal-to-cause mapping is reliable:

A spike in "Excluded by 'noindex' tag" almost always means the blog_public flag or a plugin checkbox slipped through.
A jump in "Discovered – currently not indexed" or "Page with redirect" points at broken or soft-404 redirects.
Core Web Vitals sliding from "Good" to "Needs improvement" is the caching or CDN config that didn't transfer.
New errors in the Enhancements / structured data reports mean your schema-emitting plugin or theme function got reset — re-validate a sample page with the Rich Results Test.

Catching any of these while they affect a handful of URLs is trivial. Catching them after they have spread to hundreds, with rankings already adjusted, is a recovery project measured in months. The unglamorous hour of structured verification right after launch is the single highest-leverage SEO work you will do all quarter.

WordPress SEO After A Site Migration: What To Verify