Website migration SEO checklist: 30 days before launch to day 90

Most migration traffic losses come from small, checkable mistakes: a redirect family nobody mapped, a noindex left over from staging, metadata that did not carry across.

This website migration SEO checklist turns the move into dated tasks, from a month before launch to three months after, with rollback triggers agreed in advance. It is written for WordPress to Next.js moves but works for most replatforming projects. The background for each phase is in our WordPress to Next.js migration guide.

How to use this checklist

Copy it into your project tracker and give every item an owner. Items are ordered by deadline, not importance; anything marked (blocker) must pass before you continue.

Two facts from Google frame the timeline. A move is processed page by page: “Googlebot will have to visit every URL on your old and new site at least once.” And it takes time: for a medium-sized site, Google says it can take a few weeks or more before the new URLs show in results.

30 days before launch: inventory and baseline

• Build the complete old-URL inventory from a crawl, WordPress’s own data, Search Console (16 months of URLs with impressions, through the API or bulk export: the interface stops at 1,000 rows), a backlink export and server logs.
• Include the URL families WordPress generates automatically: archives, pagination, attachment pages, feeds and ?p= ID URLs.
• Decide keep, merge or retire for every URL, and record the destination.
• Export the baseline: clicks, impressions and top queries per URL; Page indexing report counts; Core Web Vitals status (LCP, INP, CLS); conversions per landing page. Save raw files.
• Note seasonality, so you compare post-launch traffic with the same period last year, not just the previous month.
• Choose a quiet launch window. Google’s advice: “Time your move to coincide with lower traffic, if possible.”
• Confirm Search Console verification will survive the change. Google: “Make sure your Search Console verification will continue to work after the site move.”
• Protect staging with authentication and noindex, and list both protections in the launch-day removal steps.

14 days before launch: staging QA

Redirects

• (blocker) Generate the redirect map from exported data, not by hand. How to build it.
• (blocker) The automated test passes: every old URL returns a single 301 or 308 to the expected destination, which returns 200.
• Test each URL with and without a trailing slash: the published form in one hop, the other in at most two.
• Test old URLs on every protocol and host variant (http and https, www and apex): each should reach its destination without a chain.
• No chains: no destination is itself redirected.
• Retired URLs return 404 or 410, not a homepage redirect.

Metadata and indexing signals

• Titles, meta descriptions and canonical tags match the approved values for the top 100 URLs by traffic.
• Pages that were noindex on WordPress are still noindex.
• Canonicals use the production domain, not the staging or CMS hostname.
• Structured data validates in Google’s Rich Results Test. Do not count on FAQ markup: Google stopped showing FAQ rich results on 7 May 2026.
• The production sitemap lists only canonical, indexable URLs that return 200, with accurate lastmod dates. Leave out priority and changefreq, which Google ignores.
• The production robots.txt is drafted and reviewed, and does not disallow old URLs.
• hreflang annotations are present and reciprocal (multilingual sites only).

Content and links

• Converted content passes a parity check against the original (word, heading, link and image counts). Conversion and validation pipeline.
• Internal links point directly at final URLs; a staging crawl shows zero internal 3xx responses.
• Images load from the expected paths, and alt text is present.
• The RSS feed works at its old address.

Measurement and functionality

• Analytics, consent banner and conversion events fire correctly on every template.
• Every form submits end to end and reaches its destination (CRM, inbox).
• Lab performance checks pass on key templates, with particular attention to interactions that affect INP.

7 days before launch: rehearse the cutover

• Run a full, timed dry run of the cutover on staging with the people who will do it on the day.
• If DNS is changing, lower the TTL on affected records so the switch propagates quickly.
• Write the rollback plan: who decides, how long it takes, and what restores the old site.
• Agree the rollback triggers (see the table below) with stakeholders.
• Brief editors on the content freeze window.

1 day before launch

• Freeze publishing on WordPress, or log every change for a final sync.
• Take a full backup of WordPress files and database.
• Re-run the redirect test and the staging crawl after the final content sync.

Launch day

Cutover

• Deploy the production build.
• (blocker) Remove staging protections. In Google’s words: “Don’t forget to remove any noindex or robots.txt blocks that were only needed for the migration.”
• Switch traffic or DNS.
• (blocker) Run the redirect test against production.
• Confirm old URLs are not blocked in robots.txt. A crawler has to fetch an old URL to see its redirect.

Verification

• Spot-check the top 50 URLs by traffic in a browser: content, title, canonical, images.
• Submit the new sitemap in Search Console. Keeping a temporary sitemap of the old URLs as well helps you watch them drop out; remove it once they have.
• Use URL Inspection on the top 20 pages to confirm Google sees the right canonical and rendered HTML.
• Watch real-time analytics for traffic and conversion events.
• Submit a test entry through every form.

Only if the domain changed

• Use Search Console’s Change of Address tool, which only works for domain-level moves. Google also suggests keeping the old domain registered for at least a year so nobody else can buy it.

Rollback triggers to agree before launch

Agree these in advance, so nobody has to argue about them at 2am.

Some ranking movement is expected and is not a reason to roll back. Google tells site owners to “expect temporary fluctuation in site ranking during the move”.

Want someone to sanity-check your plan before the date is set? In a free 15-minute audit we review your site with you on a live screen-share and tell you what we would fix first.

Days 1 to 7: catch breakage fast

• Review 404s daily in server logs and Search Console; add missing redirect patterns.
• Re-run the redirect test daily.
• Confirm the sitemap shows as processed without errors.
• Check the Crawl stats report for spikes in errors or response time.
• Watch 5xx rates and response times as Googlebot recrawls.
• Re-check that no staging-only noindex or authentication crept back in with a later deploy.

Weeks 2 to 4: confirm signals are moving

• Compare clicks and impressions per URL against the baseline; impressions should shift from old URLs to their new equivalents.
• Review Page indexing reasons. “Page with redirect” is expected for old URLs; spikes in “Not found (404)”, “Duplicate without user-selected canonical” or “Crawled - currently not indexed” are not.
• Track rankings for the top queries from your baseline.
• Investigate any page that lost traffic while similar pages held steady: a wrong redirect target, cut content and lost internal links are the usual causes.

Day 30: the first report

• Compare organic clicks and conversions with the baseline, adjusted for seasonality.
• Check Core Web Vitals field data. Chrome UX Report figures cover a trailing 28-day window, so day 30 is about the first point where the window is all post-launch visits.
• List every open issue with an owner and a date.

Days 60 to 90: stabilise and clean up

• Confirm old URLs are dropping out of the index and new URLs have taken over their queries.
• Ask the owners of your most valuable backlinks to update them to the new URLs. Redirects pass signals, but direct links remove the dependency.
• Remove temporary migration code (debug logging, staging allowlists) but keep every redirect. Google says to keep them “for as long as possible, generally at least 1 year”; for URLs with backlinks, keep them indefinitely.
• Write the final report and archive the baseline and post-launch exports together.

Read the ProEd migration case study for the redirect plan and what happened to traffic week by week.

A simple migration reporting template

More in this series

• WordPress to Next.js migration: the complete guide
• Next.js redirects for WordPress URLs: 308s, query strings and scale
• Export WordPress to MDX: blocks, shortcodes and ACF fields
• Headless WordPress with Next.js vs a full migration
• Best CMS for Next.js: seven options compared

Launching a migration soon?

Do one thing this week: put the rollback triggers in front of whoever signs off the launch, and get a yes on each threshold.

Lunova Labs plans, builds and launches website migrations. Tell us about yours.