How to Compare URLs During a Website Migration

Comparing old and new URLs during a website migration helps catch mismatched destinations, unintended query-string changes, and routing mistakes before they affect visitors. This workflow shows how to compare URL components, choose representative URL pairs, and verify the live result separately from the comparison itself.

Key Takeaways

• Compare scheme, hostname, path, and query string as separate components; a URL diff is a diagnostic, not an approval signal.
• Map each important old URL to its intended new destination, including URLs with meaningful query parameters.
• Test redirects and final-page behavior on the live environment. A syntactically correct URL does not prove that it works, contains the right content, or is indexed.
• Check canonical tags and indexing independently; they answer different questions from a URL comparison.

What to Compare in a URL Pair

A URL has several components that may change during a migration. For example:

Old: http://www.example.com/blog/guide?ref=email&utm_source=newsletter
New: https://example.com/resources/guide?utm_source=newsletter&ref=email

The order of query parameters differs in this example, but order can matter to an application. Parameter names, values, duplicates, and encoding can also affect behavior. Do not sort or remove query parameters automatically unless you know the site treats the resulting URLs as equivalent.

A URL comparison tool can highlight textual differences, but it may not know which changes are expected. Document the intended mapping first, then classify each difference as expected, acceptable, or a problem.

Build a Representative URL Set

Start with a mapping file that pairs each old URL with exactly one intended new destination. Include URLs from different page types and routing patterns, not just a handful of home pages.

Choose representative examples such as:

• The home page and key category or landing pages.
• High-traffic and high-value organic landing pages.
• Product, article, support, and other important templates.
• URLs with trailing slashes, uppercase or lowercase paths, or encoded characters if the site uses them.
• URLs with query parameters that affect content, filtering, pagination, or tracking.
• URLs known to have backlinks or appear in important internal links.
• URLs expected to be removed, consolidated, or redirected to a different resource.

For a large site, use URL inventories from the existing sitemap, analytics, server logs, crawl data, and migration mapping. A representative sample is useful for early checks, but it does not replace a full mapping and automated validation when you have many URLs.

A Repeatable Migration Comparison Workflow

Before launch

1. Define the target rules. Record planned changes to protocol, hostname, path structure, and query handling. Note exceptions, such as pages being consolidated or retired.
2. Create old-to-new pairs. Include the full URL where query parameters are relevant. Flag any old URL without a confirmed destination.
3. Compare components. Use a URL diff or spreadsheet to identify differences in scheme, hostname, path, and query string. Review each difference against the migration plan.
4. Check one-to-one mapping. Look for multiple unrelated old pages sent to one destination, loops, and mappings to the wrong page type. If consolidation is intentional, record that decision.
5. Test the staging or preview site. Confirm the intended destination loads and displays the expected page. Staging authentication, robots rules, and hostnames can differ from production, so treat this as an early check rather than final validation.

After launch

1. Request each old URL and inspect the redirect. Confirm it reaches the mapped destination, uses the expected permanent redirect behavior, and does not pass through unnecessary hops.
2. Check the final response and page. Verify that the destination loads successfully and presents the intended content, not an error, empty page, or unrelated fallback.
3. Inspect canonical tags. Check that the destination page's canonical URL is appropriate for that page and aligns with the migration plan. A canonical tag is a signal about a preferred URL; it is not a replacement for a correct redirect.
4. Check internal links and sitemaps. Update them to point directly to the new URLs rather than relying on redirects. Ensure submitted sitemap URLs reflect the intended canonical destinations.
5. Monitor search and traffic signals. Use available Search Console reports, crawl data, analytics, and server logs to identify unexpected errors, redirect patterns, or loss of important landing pages. Indexing changes can take time and must be assessed separately from URL differences.

You can inspect a redirect chain with curl using a GET request:

curl -sS -D - -o /dev/null -L --max-redirs 10 'http://www.example.com/blog/guide?ref=email'

The response headers show the requests and responses encountered while following redirects. Check the Location values and final status, then open the destination in a browser or crawler to verify its content. A command-line response alone does not establish that the page is useful or indexed.

Why URL Comparison Is Not Enough

A text comparison answers, “How do these URL strings differ?” It does not answer:

• Does the destination respond? The URL could return an error, redirect somewhere unexpected, or fail only under certain conditions.
• Is the content correct? A working destination might show the wrong article, a generic page, or content unrelated to the old URL.
• Is the redirect appropriate? A redirect can reach a valid page and still send users to an unsuitable destination. Review the mapping and the final content.
• Is the page indexable or indexed? Robots directives, authentication, canonical signals, site availability, and search-engine processing all matter. A URL diff cannot confirm indexing.
• Does the canonical point where intended? The page's declared canonical is page-level information that must be inspected separately.

Treat URL comparison, HTTP testing, content review, canonical inspection, and indexing checks as distinct validation steps. They complement one another; none alone proves that a migration is fully successful.

Common Mistakes

• Comparing only the homepage. This misses errors in deeper paths, templates, and parameter handling.
• Assuming a changed URL is automatically wrong. A hostname or path change may be planned; verify it against the mapping rather than rejecting every difference.
• Assuming similar-looking query strings are equivalent. Parameter order, duplicate keys, encoding, and application behavior can change the result.
• Redirecting every missing page to the homepage. That can create a poor user experience and obscure missing or incorrectly mapped pages. Choose a relevant destination or handle the retired URL deliberately.
• Treating a redirect as a content check. A successful redirect can still land on the wrong page.
• Treating a canonical as a redirect. A canonical declaration does not send visitors from the old URL to the new one.
• Checking only staging. Production DNS, redirects, certificates, caching, and access rules may differ. Repeat critical checks after launch.

Best Practices

• Keep a migration mapping that records the old URL, intended destination, reason for the change, and validation result.
• Compare URL components separately and preserve query behavior that the site relies on.
• Prioritize critical pages, but use automated checks for the broader URL set when practical.
• Prefer direct, relevant mappings and avoid redirect chains and loops.
• Check the final destination's status, content, canonical, and indexability independently.
• Keep monitoring after launch; a successful initial spot check does not reveal every crawl, user, or edge-case failure.

Research limitation: Current Google Search Central documentation could not be retrieved in this drafting environment. The migration workflow above is practical guidance, not a claim that current Google documentation was consulted. Before launch, verify Google's current guidance on site moves, redirects, and canonical URLs.

Conclusion

Use URL comparisons to find and explain migration differences, then validate redirects, destination content, canonicals, and indexing as separate checks. A documented mapping and repeatable pre- and post-launch review make mistakes easier to find and fix.