Site migration SEO monitoring: the launch-day and 90-day playbook

A migration is a checklist of specific things that break, and most are known before launch: staging directives promoted, robots.txt overwritten, canonicals pointing at the old host, redirect maps with gaps, sitemaps still listing old URLs. Order the checks on launch day, then verify the first 90 days weekly. Each failure mode is mechanical, and each one is checkable on the live page.

What specifically breaks during migrations?

The same list breaks in most migrations:

• Staging noindex in a meta tag or X-Robots-Tag, promoted with the new code.
• robots.txt overwritten by the staging copy or a build step, blocking the migration paths.
• Canonicals pointing at the old host instead of the new one.
• Redirect maps with gaps, where some old URLs 301 and others 404.
• Sitemaps still listing old URLs, so discovery points at the old host.

Each one makes the new pages unfindable or the old ones dead. None of them shows up in the traffic until after the pages stop ranking.

What order do I check on launch day?

Check in this order, on the new live host:

1. HTTPS is valid and the certificate serves on the new host.
2. robots.txt serves the live copy and does not block the migration paths.
3. No noindex in the meta tag or the X-Robots-Tag header on the new pages.
4. Old URLs return 301 to their new equivalent, not 404.
5. Canonicals point at the new host, not the old one.
6. The sitemap serves from the new host and lists new URLs only.
7. The new host is verified in Search Console.

The indexability checker reads the meta robots, the X-Robots-Tag header, the robots.txt permission, the canonical, and the final status in one request. The X-Robots-Tag checker reads the header alone, the canonical checker checks the canonical target, and the redirect checker shows every old URL’s destination. Use the bulk checker to sample up to 20 URLs in one run.

What do I watch in the first 90 days?

Daily, re-run the launch checklist for regressions: a staging push that reintroduces noindex, a rule that flips robots.txt back, a canonical that starts pointing at the old host. These regressions are the same failures as launch, only quieter.

Weekly, check the redirect map for gaps by looking for 404s on old URLs, confirm coverage on the new pages, confirm the canonicals stay on the new host across templates, and check whether the new URLs actually enter the index. The failure modes do not change after launch; they just slow down.

How do I keep watching for 90 days without a spreadsheet?

You can run the checks manually on a schedule, but the point of a migration is that the failures are known and repeatable. Monitoring removes the schedule: it runs the checks on your pages and alerts you when one of the migration failure modes appears.

A staging push can reintroduce noindex at 4am and the chart only shows it days later. stillindexed.com checks your pages’ directives and alerts you when something changes. Starter checks every 30 minutes, Agency every 15: https://app.stillindexed.com/auth/request