How to Test an SEO Migration Before and After Launch

When a website changes its URLs, it needs to send visitors and search engines from old pages to the right new pages without losing search visibility. This is an SEO migration. A redirect sends a request from an old URL to another URL. If redirects point to the wrong pages, or if the new pages block crawling, the migration can disrupt search visibility even when the new site loads correctly.

Test the move page by page. Check that important old URLs lead to their planned destinations and that new pages send search engines consistent signals. After launch, track whether search data shifts as expected. These checks also help separate technical failures from normal delays while search engines recrawl the site.

Build an old-to-new URL map before launch

Start by listing old URLs that matter and assigning each one a planned outcome. Collect URLs from several sources: the current sitemap, CMS (content management system), server logs, analytics, and Google Search Console, Google's tool for checking search performance and indexing. Each source can reveal URLs the others miss. For example, a page absent from the sitemap might still receive search visits or links from other websites.

For each old URL, record its new equivalent, if one exists. If several old pages are being combined, map them to the new page that best serves the same purpose. If a page has no relevant replacement, decide whether it should return a not-found response rather than sending visitors to an unrelated destination. Google’s site migration guidance recommends finding old URLs from multiple sources and mapping them to corresponding new URLs.

Prioritize URLs with search traffic, external links, conversions, or important business information. This helps you catch consequential omissions first; it does not establish a Google ranking score or guarantee that every lower-traffic URL can be ignored.

Test redirects and new pages on the prelaunch site

Use a production-like test site to check the redirect rules and new page templates before release. Keep the test site protected from public access. A noindex instruction only works when a search crawler can access the page and read it, so blocking a test site in robots.txt alone does not provide the same protection.

For each rule that redirects a type of URL, test sample old URLs. For high-priority pages, test every URL in the map. Confirm that each old URL returns a permanent redirect, such as a 301 or 308, and lands on the intended new page. Then check that the destination loads successfully and does not redirect through several intermediate URLs. Google recommends permanent redirects for permanent moves, and advises keeping redirect chains short.

A successful redirect test proves only that the tested request reached the expected destination. It does not prove that the destination can be indexed. Check the new page’s response, content, and search signals separately:

• Confirm that the page has no unintended noindex instruction or crawl block.
• Check that its canonical tag, a label that names the URL the page prefers search engines to use, points to the intended new URL.
• Check that internal links and the new sitemap use the new URLs.
• Where the site depends on JavaScript to display important content, inspect what a search crawler can render.

Google’s migration guidance also calls for updating internal links and relevant language or regional annotations. A page that passes a live inspection test can still fail to get indexed or selected as Google’s canonical, so treat each check as evidence about one part of the handoff.

Before launch, save a baseline of search performance for the old URLs, including their impressions, clicks, and key queries in Search Console. Also verify that analytics and server logging will continue to work after the URL or domain change. Without that baseline, it is harder to identify which old pages lost visibility and whether their mapped replacements gained it.

Check the live site as soon as it launches

Repeat the highest-priority tests against the production site. Check old URLs across each redirect rule, and confirm that the final destinations return successfully. Inspect representative new pages for accidental crawl blocks, incorrect canonicals, missing content, and old URLs in internal links or sitemap entries.

Check server logs and uptime monitoring for unexpected errors or timeouts. A redirect that works on the test site can fail in production if the release omits a rule or the live server handles a request differently. Also confirm that analytics still records important visits and conversions; search reports alone do not show whether business measurement survived the move.

For a domain or subdomain move, Google’s guidance includes the Search Console Change of Address tool. That tool does not apply to every URL change, such as a path change within the same domain. Submit the new sitemap after it is live and accessible, but remember that a sitemap helps Google discover URLs; it does not ensure that Google will crawl or index them.

Read post-launch evidence in stages

First use server logs, uptime monitoring, and redirect tests to find immediate problems: broken destinations, unexpected status codes, and unavailable pages. These checks can identify faults before search reporting catches up.

Next, inspect representative new URLs in Search Console. The live test checks whether Google's inspection system can access a page and read its content at the time of the test. The indexed result reports what Google last processed, including the URL Google selected as canonical. Google’s URL Inspection documentation makes clear that a successful live test does not guarantee indexing or search appearance.

Then review Search Console’s indexing and sitemap reports for patterns. A cluster of new URLs reported as blocked, excluded, or unavailable deserves investigation, especially if those URLs belong to the same template or directory. A sitemap submission or a successful fetch is evidence that Google received the sitemap, not that every listed page entered the index.

As Google recrawls the site, compare the old and new URL groups in Search Console and analytics. Look for old pages losing impressions and clicks while their intended replacements gain them. Check whether changes concentrate in a particular page type, language, or redirect rule. Google says a medium-sized site can take a few weeks or more for new URLs to replace old ones in Search, with larger sites taking longer. That is general guidance, not a recovery deadline or a promise that rankings will return to a particular level.

Search Console data also arrives with a delay, and its reports do not all list every URL. Compare equivalent dates and URL groups, and use server logs and analytics alongside Search Console rather than treating their totals as interchangeable. A gradual shift toward the new URLs, without major technical errors, is evidence that the migration is progressing, though it does not prove that every signal has transferred or that performance will settle at a specific level.

Common failures and what to check

Google recommends keeping migration redirects for as long as possible, generally at least a year. Removing them early can leave users and crawlers reaching old links without a route to the new pages.

What the migration means for Google AI Search

Google says its AI Overviews and AI Mode use the same foundational SEO practices as its other Search features. Pages must be indexed and eligible to appear with a snippet before they qualify as supporting links; that eligibility alone does not ensure inclusion. The guidance for Google AI features therefore makes the migration checks relevant to AI Search too: a page must be crawlable and indexed to qualify on this basis. Passing the checks does not guarantee an AI feature will cite or show the page.

Key Takeaways

• Map valuable old URLs to relevant outcomes: Use sitemaps, logs, analytics, CMS data, and Search Console to find URLs worth protecting.
• Test redirects and destinations separately: A working redirect does not prove that the new page is crawlable or indexable. It also does not show that search engines selected it as canonical.
• Check production immediately after launch: Confirm redirects, page responses, crawl signals, sitemap contents, server health, and analytics on the live site.
• Judge progress across URL groups and over time: Look for old URLs losing visibility as their replacements gain it, while accounting for crawl and reporting delays.
• Treat AI Search eligibility as a consequence of SEO access: Indexing eligibility is a prerequisite for Google AI feature links, not a promise of inclusion.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com