Site migration SEO checks with AI

The checklist splits into free checks that test your server and metered checks that ask Google.

1. Redirects, URL by URL. check_redirects follows each old URL the way a crawler would, hop by hop, and reports every status code and Location header until it lands. It catches the classic migration mistakes: temporary redirects (302, 307) where you meant permanent ones (301, 308), chains through an intermediate URL, loops, and old URLs that all point at the home page. It is a live test of your server, so it reflects what you deployed a minute ago. It is free and does not count as a data pull.
2. Crawlability of the destination. check_robots fetches the new site's robots.txt and tests each final URL against Googlebot's rules. A staging Disallow: / that slipped into production is one of the most common ways a migration loses everything at once. Also free.
3. Google's view of the new pages. inspect_url runs the URL Inspection API on the final URLs: is the page indexed, when was it last crawled, which canonical did Google pick? This is the only metered step, one data pull per URL, which is why the prompt limits it to your 10 most important pages.

A full run on 30 old URLs is 60 free checks plus 10 data pulls. On the free plan (15 pulls a day, 40 a month), that fits in a day. If you want to inspect every migrated URL, the cost is one pull per URL; run it in daily batches or use Solo for unlimited pulls.

Run the checks twice: the day you switch, to catch broken redirects while the fix is cheap, and again two to four weeks later, when Google has recrawled and the index state means something.

mcpsearchconsole.com has not moved domains, so for an honest example we ran the checklist on 2 October 2026 against the moves every site makes: http to https and www to the bare domain. The redirect and robots checks are live; index results are Google's at the time.

What the agent found:

• http to https works. Each http URL moves to https in a single permanent 308 redirect and lands on a 200. robots.txt allows the destinations and declares the sitemap.
• The www host is broken. www.mcpsearchconsole.com resolves, and plain http redirects to https on www, but the TLS handshake on www fails, so the visitor or crawler never reaches the bare domain. Any link anyone made to a www address is lost. The fix is a certificate that covers www and a single redirect from www to the bare domain.
• Trailing slash duplicates. /blog and /blog/ both return 200 rather than one redirecting to the other. Google picked /blog as canonical, as declared, so this is low priority, but a redirect would make it unambiguous.

Cost of this run: 2 data pulls for the inspections; the redirect and robots checks were free.

The question is whether the migration lost any pages or links. Each failure type answers it differently:

• Old URL ends on a 404 or 5xx. A lost page and every link pointing at it. Add a permanent redirect to the closest matching new page. Fix these first, starting with pages that had the most clicks before the move.
• Old URL redirects to the home page. Google tends to treat mass redirects to the home page like a 404. Map each one to its real equivalent. If a page truly has no replacement, a 404 or 410 is more honest.
• 302 or 307 instead of 301 or 308. Change it to permanent. Temporary redirects tell Google the old URL may come back, which slows the transfer.
• Chain of two or more hops. Point the old URL straight at the final one. Chains usually appear when a migration stacks on an older one (http to https, then old domain to new).
• TLS or connection error. Nothing reaches the redirect. Fix the certificate or the host configuration before anything else on that host.
• Final URL blocked by robots.txt. Remove the rule. If it is a staging rule, check every template and environment for it.
• New URL not indexed, two or more weeks after the move. Check it is in the submitted sitemap, linked internally and not marked noindex. Then request indexing in Search Console.
• Google-selected canonical is still the old URL. Google has not accepted the move for that page yet. Make sure the redirect is permanent, the new page declares itself as canonical, and internal links and the sitemap use only new URLs.
• Every row passes. The migration kept its pages. Save the date with a note so later traffic reports can account for the move, and re-run the inspections in a month.

• You supply the old URL list. Search Console cannot list every URL your old site had. Use a crawl export, your old sitemap or your top pages by clicks from before the move.
• Index state lags. Inspection shows Google's last crawl. A redirect fixed today shows as fixed in check_redirects immediately, but in inspect_url only after Google recrawls.
• No backlink data. Search Console MCP does not list which external sites link to your old URLs. Use a backlink tool to find the pages that matter most for links.
• Change of Address is out of scope. If you moved domains, file the move in Search Console's Change of Address tool yourself. It is not exposed through the API.
• Content parity is your call. The checks prove an old URL reaches a live new page, not that the new page says the same thing. A page that lost half its content may rank worse even with a perfect redirect.