Post-migration SEO checks: redirects, sitemaps, canonicals and Search Console

Same-domain move or URL change?

Google treats these as different projects. A hosting move without URL changes only changes the servers behind your domain. A site move with URL changes includes moving from HTTP to HTTPS, changing domain name, or changing URL paths. Many migrations quietly include one of these, such as switching permalink structure or dropping www on the new host, which turns a simple move into a URL change with different requirements.

Before cutover: make sure Google can reach the new host

Google's checklist for a hosting move starts before DNS changes. Test the full copy on a temporary hostname or IP-restricted environment, and make sure firewalls and denial-of-service protection do not block Googlebot from reaching DNS or the server. Lower DNS TTL to a few hours about a week ahead. Copy your Search Console verification file to the new site so verification does not break. Google suggests a noindex rule on any public test copy; make sure that rule does not come across when you switch.

That last step is where managed hosts differ. Kinsta, for example, sends an X-Robots-Tag noindex header on staging hostnames, and WP Engine environments have default wpenginepowered.com addresses. If the site was built or tested under a temporary hostname, check that canonicals, sitemap URLs and internal links were rewritten to the real domain.

A sampling method for course sites

You cannot check every URL by hand, and you do not need to. Pick a fixed sample by page type, record what the old host returns for each URL before cutover, and run the same checks against the new host using a hosts-file override or a resolve test. A course site has page types a blog does not, and lesson pages often redirect logged-out visitors to a login or sales page. That is fine, as long as the new host returns the same response the old one did.

Canonicals, robots.txt and sitemaps

Google ranks canonical signals by strength: redirects and rel=canonical are strong signals, and sitemap inclusion is a weak one. Use absolute URLs in rel=canonical, and do not use robots.txt for canonicalisation. After a move, the most common canonical fault is a canonical pointing at a temporary or staging hostname, which tells Google the real page is a duplicate of a URL it should never index.

robots.txt deserves its own check. It must sit at the root of the site, and Google generally caches it for up to 24 hours. If Google cannot fetch it because of a 5xx error, it stops crawling the site for the first 12 hours while it retries, then may fall back to a cached copy for up to 30 days. A misconfigured new server that errors on /robots.txt can therefore pause crawling even when pages load.

Sitemaps must use fully qualified absolute URLs, should include the URLs you want shown in search (your canonical ones), and are limited to 50 MB uncompressed or 50,000 URLs per file. Google uses lastmod only when it is consistently and verifiably accurate and should reflect the last significant update, so a migration that resets every lastmod to the cutover date gives Google a misleading signal.

After cutover: what to watch in Search Console

URL Inspection shows Google's indexed version of a page, including the last crawl time, the user-declared canonical and the Google-selected canonical. It is not a live test unless you run the live test, and Google sets daily per-property limits on inspection requests and live tests, so spend them on your sample pages rather than on the whole site.

The Page indexing report groups problems by reason. After a host move, these are the ones that matter, and validation of a fix typically takes up to about two weeks.

• Crawl Stats host status: no new robots.txt, DNS or server connectivity problems. The report needs a root-level property.
• A temporary dip in crawl rate after launch is normal according to Google; a dip lasting weeks is not.

Checklist

• Confirmed whether the move changes domain, protocol or paths; if it does, follow the URL-change process instead.
• Search Console verification file copied to the new server.
• DNS TTL lowered about a week before cutover.
• Sample URLs recorded on the old host and matched on the new host for status, final URL, canonical and robots directives.
• No staging hostname appears in canonicals, sitemaps or internal links.
• robots.txt returns 200 at the root with the expected contents.
• Sitemap index returns 200 and lists only canonical, absolute URLs.
• Crawl Stats and Page indexing checked weekly for the first month.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. Google Search Central: Site moves without URL changes Accessed 30 Oct 2026
2. Google Search Central: Site moves with URL changes Accessed 30 Oct 2026
3. Google Search Central: Consolidate duplicate URLs Accessed 30 Oct 2026
4. Google Search Central: Build and submit a sitemap Accessed 30 Oct 2026
5. Google Search Central: How Google interprets the robots.txt specification Accessed 30 Oct 2026
6. Google Search Console Help: URL Inspection tool Accessed 30 Oct 2026
7. Google Search Console Help: Page indexing report Accessed 30 Oct 2026
8. Google Search Console Help: Crawl Stats report Accessed 30 Oct 2026
9. Kinsta Docs: Staging environment Accessed 30 Oct 2026
10. WP Engine Support: Environments Accessed 30 Oct 2026