Website Migration SEO Checklist: What to Monitor Before and After

A website migration SEO checklist has three parts: what you record before the move, what you verify the day the new site goes live, and what you keep watching during the following month. Migrations that lose traffic often had a sensible plan. They lose it because a staging noindex or a robots.txt block survived the switch and nobody noticed for two weeks.

That holds whether the project is a domain change, a replatform, an HTTP to HTTPS move or a redesign that keeps the same URLs. Settings that made staging invisible to Google reach production, and the site stops being crawlable while looking perfectly normal in a browser.

One to two weeks before launch: build the baseline

You can't show what a migration changed without a record of what existed. Take it early enough that it reflects the normal site rather than one already frozen for launch.

1. Export every URL from the current sitemap and from a full crawl, and keep both files. Pages that get traffic but aren't in the sitemap are the ones redirect maps miss, so cross-check against top landing pages in GA4 or the Search Console Performance report for the last 12 months.
2. Record title, meta description, H1, canonical and hreflang for every URL with organic traffic. A crawler export to CSV is fine.
3. List the tracking setup with IDs: the GA4 measurement ID (G- prefix), the GTM container (GTM- prefix), the Meta Pixel ID and the cookie consent platform.
4. Note normal response times, so you can tell later whether the new stack is slower.
5. Build the redirect map, one row per old URL with its specific new destination. Every URL with traffic or backlinks needs one.

Our guide to XML sitemap best practices covers what the new sitemap should look like.

On staging: find the settings that will break production

The mechanisms that keep staging out of Google are exactly the ones you need to remove at launch. Find where each one lives on staging, then check again on production within minutes of the switch.

• robots.txt containing Disallow: /. Here is how to check robots.txt line by line.
• A noindex tag in a shared template, or an X-Robots-Tag: noindex header set at server or CDN level
• On WordPress, "Discourage search engines from indexing this site" under Settings > Reading
• Canonicals pointing at the staging hostname or the old domain
• hreflang annotations referencing old URLs, or missing the return links each language version needs
• HTTP basic authentication, which blocks Googlebot as effectively as any robots rule

Launch day

The first hours are for confirming the switch worked, not for redesigning templates.

Test redirects against the map. curl -sIL https://old.example.com/page/ prints every hop with its status code, so you can confirm a single 301 to the right destination rather than a chain or a 302. Don't redirect everything to the homepage as a shortcut; Google tends to treat those redirects as soft 404s, and the equity of the old pages is lost.

Confirm the SSL certificate is valid for both the www and the apex hostname. Then click through the main templates with GA4's Realtime report open and check that GA4 and GTM fire with the same IDs recorded in the baseline. Tracking is easy to lose in a template rebuild and nobody notices until the monthly report.

For a domain change, verify both properties in Search Console and submit the move with the Change of Address tool (Settings > Change of address) in the old property. Submit the new sitemap, and keep the old one reachable for a while so Google recrawls the old URLs and finds the redirects.

The following 30 days

Problems that appear after the first week are the ones nobody is looking for. URLs can drop out of the new sitemap as the CMS settles, a template can rewrite titles and meta descriptions across a whole section, a routine deploy can change canonicals, and response times can creep up as traffic returns. In Search Console, the Page indexing report of the new property should show indexed pages rising while the old property's count falls as redirects are processed. If the new property stalls, look at its "Why pages aren't indexed" table first.

Letting a monitor keep the baseline

Adding the client site to Deltio a week or two before launch records the before state for you. Deltio checks the sitemap and pages daily and compares each check with the previous one, so a section disappearing from the sitemap, a noindex or robots.txt change, a canonical pointing somewhere new, or a rewritten title, meta description or H1 triggers a Slack and email alert for that site. It also watches uptime, SSL and domain expiry, and whether GA4, GTM and the Meta Pixel are still on the page.

A daily cycle won't replace the manual checks in the first hour after launch. It covers the month after, when attention usually moves to the next project. The baseline can't be created retroactively, so add sites before the next migration is scheduled; the 14-day free trial comfortably covers a launch.