The homepage works. The new design looks right. Then someone opens a product guide that has earned links for years and lands on an unrelated category page.
A migration can pass its design review while failing the people arriving through search. Those visitors enter through old bookmarks, indexed URLs and links your team may not have looked at in months. AI answers can send them to those addresses too.
An SEO migration checklist needs to account for those entry points before the old site disappears. It should tell the team what each important URL becomes, how to verify the replacement and who responds if the live site behaves differently from staging.
The work does not guarantee unchanged rankings. Search engines need to process a move, and AI citations can vary independently of it. What a good migration plan gives you is a way to prevent avoidable faults and distinguish them from changes that require investigation.
This guide covers preparation, launch and the monitoring period that follows, including how to keep essential work moving when engineering time is limited.
Key takeaways
- Give every known legacy URL an intended outcome. Preserve useful addresses where possible, redirect changed ones to relevant replacements and document intentional removals.
- Define launch blockers before deployment. Broken conversion journeys and inaccessible priority pages deserve a different response from a small ranking fluctuation.
- Test content and indexing signals on the new site. A successful redirect is not enough if its destination is blocked or missing the information people came for.
- Preserve your intended search-crawler access policy. OpenAI's search crawler and training crawler serve different purposes.
- Track Google performance, AI citations and referred visits separately. They are related observations, not interchangeable measures of migration success.
Define the move before building the checklist
Start with a short statement of what is changing. A new domain creates different requirements from a redesigned site that keeps its URLs. A CMS migration can preserve addresses while changing how content renders, which makes a redirect-only checklist inadequate.
List the affected domains and page types. Include assets such as PDFs and images if their addresses will change. Identify business functions that depend on the site, including checkout, forms and account access.
Then record what should remain stable. That might include the main content of a product page, its language alternatives or the route a visitor takes to request a demo.
Where practical, separate a domain move from a substantial content rewrite. This makes testing easier and gives you fewer possible explanations if performance changes. When several changes must launch together, document them by page group so the team can investigate them separately later.
Google's guidance for site moves with URL changes is the reference for the search-specific work. Use it alongside a deployment plan owned by engineering.
Phase 1: Build the evidence you will need after launch
1. Assign owners and define what stops the launch
Give one person responsibility for the migration decision. Assign named owners for redirects, content review and measurement, with engineering responsible for infrastructure and deployment.
Agree on the meaning of priority labels before tickets start moving.
P0 means a launch blocker. Examples include widespread server errors, priority pages carrying an unintended noindex directive, missing redirects for important moved content or a broken checkout. The exact list depends on the business, but each item needs a test and a person authorized to resolve it.
P1 means an important issue with an agreed resolution deadline. Its urgency depends on the affected pages and likely impact. It should not become a category for work nobody owns.
P2 means an improvement that can safely follow the move. Updating a low-priority external reference may belong here. Restoring missing content on a major revenue page does not.
A missing AI citation baseline is a measurement limitation. It is worth preventing, but it does not have the same operational consequences as taking product pages out of search. Prioritize accordingly.
2. Capture a fixed performance baseline
Export the available history before changing the site. Include a recent comparison period and enough older data to understand seasonality where possible. A newer site can still establish a useful baseline without a full year's history.
Record Search Console clicks and impressions for important landing pages and query groups. In analytics, capture organic traffic and the business outcomes those visits produce. Keep the definitions and attribution settings with the exports.
Group the results by template, market and device where those distinctions matter. A stable site-wide total can hide a decline in product pages offset by an increase in blog traffic.
Record the reporting properties and date ranges used. For a domain move, prepare to review the old and new properties together; the old domain's decline alone will not show whether traffic has transferred successfully.
Keep a dated copy of the baseline rather than relying on a dashboard that continually changes its comparison period.
3. Build a URL inventory from more than a crawl
A crawl finds pages reachable through the links it follows. It may miss an old campaign page that still attracts search traffic or a PDF cited by another site.
Combine the crawl with sitemap URLs, CMS exports and landing-page data. Add relevant URLs from backlink reports and server logs where available. Flag pages with business value or important external links for extra testing.
For every known URL, record one outcome:
- Keep: the address remains live and serves the intended content.
- Move: the content has a new address with a permanent redirect from the old one.
- Consolidate: a relevant replacement meaningfully covers the retired page's purpose.
- Remove: there is no suitable replacement, so the old address returns an intentional removal status.
Do not send every removed page to the homepage. A destination that fails to answer the original request can confuse visitors and may be treated as a soft 404 by Google.
For consolidation, ask a content reviewer to approve the replacement. Similar wording in two page titles does not establish that they serve the same need.
4. Turn the inventory into a testable redirect map
For each moved URL, specify the final destination and expected status. Permanent server-side redirects commonly use 301 or 308. Choose the appropriate implementation with engineering and test it consistently.
Prefer a direct route to the final destination. Include older redirects in the review so a visitor does not travel through several retired addresses before reaching the new page.
Check variants that actually occur in your data, including trailing slashes, capitalization and relevant parameters. Do not strip parameters indiscriminately if they affect content or application behavior.
A redirect test should answer more than whether a response contains a new location. It should confirm that the destination loads, serves the approved content and has the intended indexing signals.
For example, an old sizing guide should reach the replacement sizing guide. A technically valid redirect to a general clothing category is not an equivalent outcome.
5. Protect staging and review content parity
Keep staging behind appropriate access controls. If you use noindex on publicly accessible test pages, remember that a crawler needs access to see the directive. Blocking crawling in robots.txt is not a substitute for preventing a URL from being indexed.
Separate staging configuration from production configuration. Add an explicit deployment check for accidental noindex directives in HTML and HTTP headers.
Review representative examples from every important template. Compare visible content and headings, then inspect titles, canonicals and structured data. Check language alternatives on multilingual sites and the links that connect related pages.
Preserve useful information, not obsolete configuration. Canonicals and hreflang references need to reflect the new URL structure. Duplicate or filtered URLs should follow the intended canonical strategy rather than receiving self-referencing tags automatically.
Structured data must match the visible content and the requirements of the relevant feature. Use Google's structured-data guidelines to validate the implementation. Markup alone does not guarantee a rich result.
6. Test rendering, performance and conversion journeys
Open pages on mobile and desktop. Confirm that essential text, product information and navigation remain available after rendering. Check whether consent banners, scripts or loading states interfere with access.
Measure the main templates before and after the change. Use available field data for real-user context and lab tests to identify regressions before launch. Core Web Vitals cover LCP, INP and CLS; they should not be presented as a universal eligibility gate for AI citations.
Run the actions the business depends on. Submit a test lead, complete an approved test purchase or verify another critical journey. Confirm that the destination system receives the result and that the expected analytics events are recorded without unintended duplication.
A tracking failure can resemble a commercial decline. Knowing that a test transaction reached the order system but not analytics immediately narrows the investigation.
7. Record AI answers and their cited URLs
Choose a stable set of buyer questions already relevant to the business. Record the engine, prompt, date and full response, including cited links. Use repeated observations for priority questions so one unusual answer does not become the baseline.
Keep brand mentions separate from citations to your own domain. A model can recommend your company while citing a review site, and a page can be cited without the brand being central to the answer.
Map owned citations to the URL inventory. These pages deserve destination testing even if they generate few measurable referral visits.
The purpose is practical: after launch, you want to know whether a previously cited address still works, whether a new address appears and whether a change persists across repeated checks. A single missing citation cannot establish that the migration caused a visibility loss.
Phase 2: Verify the live deployment
8. Run the acceptance tests against production
Staging approval does not establish that production behaves the same way. Deployment can change redirect rules, caching and security settings.
Run the approved URL tests immediately after launch. Check all priority legacy URLs and automate the wider inventory where possible. Manually inspect important destinations for relevance and usability.
Confirm that intended live pages return 200 and contain the expected content. Verify permanent redirects and intentional 404 or 410 responses. Inspect for loops, unexpected chains and destinations that load an error message with a 200 status.
Retest critical conversion journeys and analytics. Use a deployment window when the required owners are available to act on failures.
The release passes this check when priority entry points and business journeys behave as approved, with unresolved exceptions explicitly reviewed. A homepage spot check is not sufficient evidence.
9. Check indexing signals and discovery paths
Verify production robots.txt and indexing directives. Make sure the intended canonical pages can be crawled and are not carrying temporary staging restrictions.
Publish sitemaps containing the intended canonical URLs. Check that the listed pages resolve correctly, then submit the relevant sitemap in Search Console. For a URL-changing move, retain the old-to-new mapping and use the old sitemap where helpful for monitoring the transition.
Update important internal links at launch so they point directly to final destinations. This includes navigation and links within high-value content. A working redirect can preserve access, but it should not replace updating the site's own links.
Check hreflang references and structured data in production. For multilingual or product-heavy sites, these checks belong in prelaunch testing and launch verification, not automatically in a later backlog.
10. Complete the domain-move requirements where applicable
If the migration changes domains, verify ownership of the necessary Search Console properties and review Google's Change of Address requirements. Use the tool for supported moves after the required redirects are in place. It does not replace them and is not required for every migration type.
Keep control of the old domain, with working DNS and certificates where needed to serve its redirects. An expired certificate can prevent an HTTPS visitor from reaching the redirect at all.
Google recommends retaining redirects for at least a year, and longer can remain useful for visitors and external links. Set a renewal owner so the old domain does not disappear when the launch project closes.
11. Verify intended search-crawler access
Review crawler policy deliberately. Do not copy staging restrictions into production, and do not remove intentional restrictions simply because a migration is happening.
For OpenAI, distinguish OAI-SearchBot, used for search, from GPTBot, associated with potential training use. The controls are separate. Consult the official bot documentation when configuring them.
For Perplexity, use its crawler documentation to verify the relevant access requirements. Check current documentation for any other engine important to your monitoring program.
Test access beyond robots.txt. A firewall, CDN challenge or rate limit can prevent retrieval even when the file permits it. Have engineering use provider-documented verification methods and inspect relevant responses or logs. Changing a browser's user-agent string alone does not prove that a verified crawler can access the site.
Check old URLs as well as destinations. A crawler needs to be able to follow the move. Access enables retrieval; it does not guarantee that an engine selects or cites the page.
Phase 3: Monitor the transition and investigate changes
12. Separate operational checks from search reporting
In the first days, review deployment health and critical journeys frequently enough to catch failures while the launch team can respond. Look for server errors, broken destinations and tracking interruptions.
Review Search Console and analytics as data becomes available, accounting for processing delays. Then establish a regular performance review by page group. The first 90 days can serve as a planning window, not a universal deadline for completion or recovery.
Inspect unexpected indexing exclusions. An intentionally removed page returning 404 is different from a priority product page doing so. A sitemap submission is a discovery step, not confirmation that every page has been indexed.
Use URL Inspection for selected priority pages when diagnosing access or indexing. Repeated submission is not a replacement for fixing the underlying problem.
13. Diagnose the pattern before choosing the fix
If analytics traffic falls but Search Console clicks remain broadly stable, investigate measurement before concluding that visibility collapsed. Verify tag deployment and property settings, while recognizing that the two systems do not count identical things.
If the old domain declines, examine the new domain alongside it. Check whether mapped destinations are gaining visibility for the relevant query groups.
If one template falls while others remain stable, compare its rendering and indexing signals with the prelaunch version. A missing product description or incorrect canonical may be more informative than the site-wide average position.
If mobile performance diverges, inspect the mobile experience and technical implementation. Do not assume Core Web Vitals explains the difference without supporting evidence.
A gradual decline is not proof of lost metadata, just as a sudden decline is not proof of broken redirects. Use the pattern to choose the next check, not to announce a cause prematurely.
14. Revisit AI citations with comparable checks
Repeat the priority prompts using the same engine and search settings where available. Keep the observation dates and inspect the linked destinations.
An answer may still cite an old URL that redirects correctly. That is different from a broken citation. A direct citation to the replacement URL provides another useful observation, but it does not establish that every engine has processed the move.
If owned citations disappear across repeated runs, check the affected pages for access, content and redirect changes. Compare related prompts before assuming a site-wide problem.
Track referral visits separately in analytics. Some AI interactions produce no click, and referral information is not always available. Google's AI search features also should not be treated as equivalent to referrals from standalone assistants; its AI features guidance explains their relationship to Search reporting.
15. Update important external references
Fix links you control, including business profiles and paid campaign destinations. Ask the owners of valuable external references to update links where practical, especially if those links send relevant visitors.
Keep working redirects even when outreach is successful. Not every old link can be found or updated, and saved references can continue circulating long after launch.
Keep migration work moving when engineering time is scarce
A developer should not have to infer the intended outcome from a ticket titled “Fix migration SEO.” Attach the approved mapping and describe how the change will be tested.
Here is a practical ticket format, using a hypothetical product-guide move:
Task: Redirect /guides/size-chart to /help/sizing.
Owner: Web engineering, with the SEO lead approving the destination.
Reason: The legacy guide is being retired, and the new page preserves its sizing information.
Acceptance: The old URL reaches the approved destination through a permanent redirect without a loop. The destination returns 200, contains the sizing guidance and has the intended canonical and indexing settings.
Evidence: Attach the automated status check and the manual destination review.
Escalation: If the destination no longer covers the original question, return the mapping to the content owner before deployment.
For larger groups, attach a versioned file and define how exceptions will be handled. Test broad redirect patterns against edge cases; a rule that works for one directory can misroute an unrelated page with a similar path.
Some changes can be implemented at the server or CDN rather than through the CMS. They still require the appropriate access and technical owner. Plan those dependencies early instead of assuming an external SEO team can deploy them.
Decide when to fix forward and when to roll back
Agree on rollback authority before launch. Document which components can be reversed safely and what happens to orders, leads or other data created after deployment.
A known severe fault may justify rollback if it cannot be corrected within the agreed recovery window. Examples include a failed checkout or widespread inaccessible pages. An isolated redirect error may be faster and safer to fix directly.
A traffic decline on its own is insufficient evidence for reversal. Investigate immediately, but establish whether it reflects a technical fault, a measurement issue or search reprocessing before choosing the response.
Keep a record of the evidence and the decision. Do not wait several weeks to inspect an obvious launch fault, and do not reverse an otherwise functioning migration merely because early search numbers fluctuate.
Where Pixis Visibility fits
Pixis Visibility can support the measurement work around a migration through technical audits, keyword tracking and AI-answer monitoring. Use it to establish the priority pages and questions you intend to revisit after deployment.
The useful output is a comparable record: the pages that mattered before the move, their intended replacements and the changes observed afterward. Review source URLs alongside answer visibility rather than treating a single score as the verdict on the migration.
Keep deployment responsibilities explicit. A monitoring platform does not replace redirect testing, infrastructure access or approval from the people responsible for the live site. Confirm the engines and reporting capabilities available to your account before finalizing the monitoring plan.
For the broader work of making pages accessible and understandable to retrieval systems, see our guide to technical SEO for GEO. The migration checklist has a narrower job: preserving useful entry points and detecting what changed during the move.