The short answerTest redirects and the links inside moved pages first. Then check crawl access, index status, forms and tracking in days 1 to 3, what moved inside each page in week one, AI crawler access by day 14, and watch results at 30, 60 and 90 days with brand searches split out.
The post-launch checklist at a glance
| Group | What to check | A pass looks like | By when |
|---|---|---|---|
| 1. Crawl access, redirects and index | Staging blocks, every old URL, canonicals, sitemap, URL Inspection (checks 1 to 11) | Every old URL reaches its new page in one permanent redirect, and Google fetches your key pages | Day 3 |
| 2. Forms, tracking and speed | Every form, every clickable element, conversion events, mobile speed (checks 12 to 15) | A bad entry is refused, events register from a real browser, all three speed thresholds met | Day 3 for forms and tracking, day 14 for speed |
| 3. What moved inside each page | Links in post bodies, titles, leftovers, tables, structured data (checks 16 to 22) | Every link returns 200 and every live page shows every block | Day 7 |
| 4. AI visibility | Crawler access per bot, answer blocks, a baseline question set (checks 23 to 26) | Your robots.txt says on purpose what each bot may do, and you can compare before and after | Day 14 |
| 5. The watch | Crawl, index, search clicks, AI answers | You read the right number in each window | Days 30, 60 and 90 |
Still choosing where to move? Read our guide to the best CMS for SEO first. Already moved? Start at check 1. These are failures we have seen after real client moves.
Group 1: Crawl access, redirects and index (days 1 to 3)
1. Remove every staging block. Check robots.txt for a leftover disallow rule and the page source for a noindex tag. Google's own site-move guidance lists removing temporary blocks as a step, and a disallow-all rule stops Google from crawling the whole site. Google caches robots.txt for up to 24 hours, so a fix can take a day to land.
2. Test every old URL, not a sample. Run your full redirect map. Each old address should return a permanent redirect (301 or 308). Google treats these as permanent and treats 302, 303 and 307 as temporary, which tells it to keep showing the old URL. Redirect the old URLs that earned links, too: Google uses the redirects to reassign links on other sites to your new URLs.
3. Send each URL straight to its final page. Google recommends redirecting straight to the final destination and says not to send everything to the home page. If you moved to a new domain, also submit Change of Address for every verified version of the old domain. Google says you do not need it for HTTP to HTTPS, www to non-www, or path moves inside a domain.
4. Keep redirects at least a year. Google says to keep them for as long as possible, generally at least one year. Put the date in your calendar so a later tidy-up does not remove them.
5. Check canonicals on the new pages. Each page needs one canonical tag, pointing at its own new address. If JavaScript changes the canonical, the value should match the one in the HTML. On paginated blog indexes, every page should name itself as canonical, never page one.
6. Submit the sitemap and read what you serve. Submit the new sitemap in Search Console, remove the old one, and list canonical URLs only. Google uses the last-modified date only if it is consistently and verifiably accurate. After one migration, the sitemap reported the migration date as the edit date, because the migration had overwritten the real dates. We have also seen a sitemap route that was cached at the edge and stayed frozen across deploys for days. Fetch the live file and read its dates. If a sitemap fetch fails, Google retries for a few days and then stops, so fix the cause and submit again.
7. Run URL Inspection on a spread of pages. Test the live URL for your home page, a top post, a service page and a deep page. Confirm the fetch succeeds, then check whether Google has ever seen your newest pages. A page Google has never seen cannot be fixed by rewriting it.
8. Look for soft 404s, and retire pages properly. A page that returns a 200 status but looks like an error or is empty counts as missing to Google, and Search Console flags it. Pages you removed on purpose should return a 404 or 410, which Google treats the same way.
9. Let Googlebot in. Google's move guidance says to make sure firewall or DoS protection does not block Googlebot on the new infrastructure. Its AI features guidance adds that crawling should be allowed in robots.txt and on any CDN or host. Test it with a live URL inspection, not a guess.
10. If the new site is code-based, read the rendered HTML. Google can only see content that is visible in the rendered HTML, and not every bot runs JavaScript at all. For one client, only a small share of the blog was indexed until the blog index was rendered on the server. Open the page source and find your content and links in it.
11. Expect the crawl rate to move, and watch for real errors. What Google does depends on the kind of move. If only your hosting changed and the URLs stayed the same, Google says a temporary drop in Googlebot's crawl rate is normal, followed by a steady increase over the next few days. If your URLs changed, Google says it will temporarily crawl the new site more heavily than usual, so make sure the new server has room for that load. Serious errors or slowdowns are the real concern, so watch your server logs on the old and new hosts until the old host sees no traffic.
Group 2: tracking, forms and speed (days 1 to 3, speed by day 14)
12. Break every form on purpose. Submit each one with a mistyped email address, with sending blocked. On one launch, a form accepted a mistyped email and the server checked only that a phone or an email was present. Then submit a real test and confirm the message reaches the inbox or CRM that should receive it.
13. Click everything that looks clickable. Press every carousel arrow, every menu item and every footer link on desktop and on a phone, and compare your header and footer links against the home page. Layout and link checks did not flag dead arrows, a menu link pointing at two different pages and missing footer links on one project. Real people found them.
14. Confirm your analytics and conversion events fire. Open each template type and check that page views and conversion events register from a real browser. A template that moved may have lost the tag a plugin used to add. A broken event costs you leads and baseline data from day one.
15. Check speed on a phone. Google's Core Web Vitals thresholds, measured at the 75th percentile of page loads, are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less and Cumulative Layout Shift at 0.1 or less. A page passes only if it meets all three. Test on a mid-range phone, and read the Core Web Vitals report in Search Console once real visits arrive.
Group 3: What moved inside each page (week one)
16. Test every link inside every moved post. Checking that old URLs map to new ones proves pages moved. It does not test the links inside them. On one move to a new CMS, several posts still carried dead links a month after launch: a call to action pointing at a path the new site never served, internal links to slugs that never existed, and a citation linking to a URL that never existed. A pass looks like this: every link in every body returns 200 with redirects followed.
17. Fix internal links that pass through redirects. After a move, links in old articles often point at addresses that now redirect, and a single audit found them across dozens of articles. If your site is code-based, one fix in the code can send every link through the redirect list when the page builds.
18. Check titles and descriptions. Read every title and description against working budgets of about 60 characters for titles and 160 for descriptions. One client's migration carried old metadata over unchanged, which left a minority of titles and descriptions over those budgets. Watch for a brand name added twice, too.
19. Strip leftover debris from the old platform. Search your stored body text for the old platform's markup. After a move away from the old CMS, we found old footer blocks sitting inside migrated articles, hidden when the page rendered but still in the stored content.
20. Check the live page, not the CMS. On one project, the CMS held every row of a table while the live template silently dropped table blocks. The CMS check passed and the page was wrong. Open the live page for every content type: tables, embeds, galleries, FAQs.
21. Match structured data to what readers see. Google says markup must describe content visible to readers. The Rich Results Test and URL Inspection catch most technical errors, though not a mismatch in content. Read each schema block next to the page text.
22. If you run several languages, open each one. Compare each URL's title with the live English page, because a localized document can overwrite the English record. For one client it did so on a number of URLs, and the title there was the localized one.
Group 4: AI visibility (by day 14)
23. Decide crawler access bot by bot, and take a position. Each AI company runs more than one crawler. Our view: allow the search bots if you want to appear in answers, and decide on the training bots separately.
| Bot | Run by | Purpose | If you block it |
|---|---|---|---|
| OAI-SearchBot | OpenAI | Surfaces sites in ChatGPT search | You are excluded from ChatGPT search answers, though you may still appear as navigational links |
| GPTBot | OpenAI | Collects content that may train models | Signals your content should not train models |
| ChatGPT-User | OpenAI | Fetches a page when a user asks | robots.txt rules may not apply |
| Claude-SearchBot | Anthropic | Indexes content for Claude's search | May reduce visibility in Claude's search results |
| Claude-User | Anthropic | Retrieves pages when a user asks | May reduce visibility in user-directed search |
| ClaudeBot | Anthropic | Collects content that may train models | Signals your content should not train models |
| PerplexityBot | Perplexity | Surfaces and links sites in Perplexity search | Perplexity recommends allowing it so your site appears in its search results |
| Perplexity-User | Perplexity | Supports a user's request | It generally ignores robots.txt |
OpenAI says its systems can take about 24 hours to adjust after a robots.txt update, and Perplexity says changes may take up to 24 hours to show in its systems.
24. Do not expect robots.txt to control every fetch. OpenAI says ChatGPT-User may not follow robots.txt, and Perplexity says Perplexity-User generally ignores it. Anthropic says its three bots all honor robots.txt, including Claude-User. So you cannot rely on robots.txt to control the user-triggered fetchers from OpenAI and Perplexity. A page that must stay private belongs behind a login.
25. Check that your answer blocks survived as text. Open the live page and read the short answer, the tables and the FAQ as text. If the migration turned a table into an image or dropped a block, the content is harder for an engine to lift. Google lists key content in text as a recommendation for AI features.
26. Set a baseline you can compare against. Before launch, export your Search Console data and crawl the old site. If the site is already live, use Search Console history for the search baseline. Then pick a fixed set of buyer questions (10 to 20 is a workable size), run them before launch and weekly after, and compare windows made only of ordinary days. One engine returned about twice its usual number of sources per answer for four days in September 2026, so a window that includes those days is not an ordinary one. For how to read the results, see our AI visibility audit guide. To see which bots already visit, read how to read your server logs for AI-bot traffic.
Two optional items, neither a check. First, skip llms.txt as a migration task: Google says you do not need new machine-readable files or AI text files to appear in Google Search, and Chrome's Lighthouse calls llms.txt an optional emerging convention. We cover who actually reads it in our llms.txt post. Second, you can tell participating search engines about moved URLs with IndexNow, a protocol for reporting URLs that were added, updated or deleted, where engines share the submissions with each other.
Group 5: The 30, 60 and 90-day watch
Google gives no ranking recovery time after a move. For small and medium sites it says most pages move over a few weeks, and larger sites take longer. Any agency that promises you a recovery date is guessing. The normal wobble for week one and day 30 comes from Google's statements. The other cells are our judgment.
| Window | Read this | A normal wobble | Act when |
|---|---|---|---|
| Week one | Index coverage graphs, server logs, redirect tests | Crawl rate shifts: a temporary dip if your URLs stayed the same, heavier crawling if they changed | Errors rise or Googlebot cannot reach your pages |
| Day 30 | Index status, sitemap read date, old URLs in results | Old URLs still showing for a while | Key pages are unknown to Google |
| Day 60 | Non-brand clicks, impressions and average position | Short dips on pages that moved | A whole section loses impressions |
| Day 90 | AI answers on your baseline questions, per engine, read weekly from day 14 | Results swing from week to week as engines change | One engine falls across ordinary days |
Split brand searches from the rest before you judge a month. In one case, all of a near-halving in clicks came from searches for the client's own name, and searches without the name stayed flat. Count plain-word brand names as brand searches too.
When it is worth bringing in help
Bring in help when nobody on your team can read the new site's rendered HTML, or when a migration has already cost you search traffic and you cannot tell why. Our list of headless CMS SEO agencies for B2B SaaS shows who does this work and how they compare.
Book a 30-minute intro call to talk through your migration.
