A URL Comparison Workflow for Website Migrations

When you migrate a website, a URL that looks similar to its replacement may still lead to the wrong page—or fail to redirect at all. Compare old and new URLs component by component, then test the live redirects and confirm that important destinations contain the content visitors need.

This workflow helps SEO specialists and developers build a migration mapping, review URL changes, and prioritize post-launch checks. Comparing URLs is a planning step, not proof that a redirect or migration is working.

Key Takeaways

• Match each important old URL to its intended new destination before launch.
• Compare scheme, hostname, path, and query string separately; decide deliberately which differences matter.
• Test actual HTTP responses after deployment. A URL comparison cannot verify a redirect, its status code, or its destination.
• Use analytics and crawl data to prioritize high-value URLs and review them again after launch.

Compare URL Components, Not Just the Full Strings

A URL can be broken into parts that often change independently:

https://www.example.com/products/widget?color=blue#details
└scheme┘ └────── hostname ──────┘└── path ────┘└ query ┘└fragment┘

For a migration, record the old URL and proposed new URL, then compare:

A fragment such as #details is not sent to the server in an HTTP request. It can still matter to client-side navigation, but it is not normally a separate redirect target the server can inspect.

Differences in capitalization, trailing slashes, percent-encoding, and query-parameter order can also matter. Their effect depends on how the site handles URLs. Do not assume two different strings are equivalent—or that a server treats them as different—without checking the application and its routing rules.

Use a comparison tool, spreadsheet, or script to spot component changes. TidyURLs' URL Diff can help compare two URL strings, but the comparison itself does not test a live page or its redirect.

Build a Migration Mapping for Important Pages

Start with a mapping that connects each source URL to one intended destination. For example:

Choose destinations based on the old page's purpose and content, not just on which new URL is easiest to use. If a page has no suitable replacement, decide explicitly what should happen rather than sending every retired URL to the homepage.

Migration review checklist

For every high-value old URL, confirm that:

• It is included in the source list and has an intentional destination or retirement decision.
• The destination is the closest relevant replacement, not merely a page that happens to exist.
• Scheme and hostname changes are expected and consistent.
• The path maps to the intended page, including any changed language, category, or content structure.
• Query parameters are preserved, transformed, or intentionally dropped. Check parameters used for product variants, pagination, filters, campaigns, or application behavior individually.
• The destination URL is itself the preferred URL rather than an avoidable intermediate redirect.
• Important URLs from analytics, search data, backlinks, and existing crawls have not been missed.

Avoid mechanically keeping every old query parameter. Some are necessary for content or functionality; others are tracking parameters or obsolete controls. Make that decision based on how the destination works and what reporting needs to retain.

Test Redirect Behavior Separately

A proposed mapping only says what should happen. After the redirect rules are deployed, request the old URL and inspect the real response. Check the HTTP status, any Location header, the final URL, and whether the chain ends at the intended destination.

For a single URL, curl can show the response headers at each redirect hop while following redirects:

curl -sS -L --max-redirs 10 -D - -o /dev/null \
  -w '\nFinal URL: %{url_effective}\nFinal status: %{http_code}\n' \
  'https://www.example.com/guides/setup'

Review the printed headers for each response, especially the status and Location value. Confirm that the final URL matches the mapping and that the final status is appropriate for a page that should be available. A redirect can point somewhere unexpected, stop at an error, loop, or pass through unnecessary hops even when the proposed URLs look correct.

Use a normal GET request for this check. HEAD requests can be handled differently from GET requests by some servers or application stacks, so a HEAD-only check may not reflect what a browser receives. This command checks one URL at a time; for a large migration, automate requests carefully and report failures against the mapping rather than treating a successful HTTP response as proof of correct content.

Also check representative variants where relevant: HTTP versus HTTPS, www versus non-www, trailing slash behavior, and URLs with meaningful query parameters. Test from outside the deployment environment if internal routing or preview configuration could produce different results for visitors.

Verify the Destination, Not Just the Redirect

A redirect can work at the HTTP level and still send visitors to an irrelevant, incomplete, or broken page. Open or crawl the final destination and compare its purpose and key content with the old page. Check that important assets and page functionality work, and review the destination's canonical and indexing directives as part of the migration.

URL comparison alone cannot establish content equivalence, confirm that search engines have processed a migration, or prove that analytics attribution is correct. Those require separate content, technical, and measurement checks.

Use Crawl and Analytics Data to Prioritize Checks

A migration may involve too many URLs for equal manual review. Use existing crawl exports and analytics or search-performance data to identify pages that deserve closer attention: pages with substantial visits, conversions, search visibility, or valuable external links. Include important URLs found in the old site's sitemap and internal links, not only pages with recent traffic.

After launch, crawl the old URL list and inspect the resulting status codes and destinations. Review new-site crawl results for errors, unexpected canonical URLs, and pages that are unavailable to crawlers. Compare post-launch analytics and search data with a suitable baseline, allowing for normal reporting delays and changes in demand. Investigate affected high-value pages first; a traffic change by itself does not identify the cause.

Common Mistakes

• Treating string similarity as proof of a correct mapping. A small path change can lead to a different page, while a hostname change may be an intentional site-wide change.
• Assuming a matching URL means a working redirect. The response must be tested after the rules are deployed.
• Redirecting unrelated retired pages to the homepage. Prefer a relevant replacement where one exists, and make retirement decisions deliberately.
• Dropping all query strings—or preserving all of them—by default. Check which parameters affect content, functionality, or measurement.
• Checking only the first response or only the final page. Review the redirect chain and confirm both the destination and its response.
• Using a successful status code as the only quality check. The page can load and still be the wrong replacement.
• Ignoring high-value URLs that are absent from a prepared mapping. Use analytics, search data, backlinks, sitemaps, and crawls to find important sources.

Best Practices

1. Keep one auditable source-to-destination mapping, with a reason and priority for each important URL.
2. Review scheme, hostname, path, and query behavior separately; document intentional changes.
3. Test deployed redirects with GET requests and check status, Location, final URL, and chain length.
4. Verify the new page's relevance and availability independently of redirect behavior.
5. Re-crawl and monitor high-value URLs after launch, then fix issues based on evidence.

Conclusion

A dependable migration review connects each important old URL to a relevant destination, compares the URL components, and verifies the deployed behavior separately. Use crawl and analytics data to focus review effort where mistakes would matter most.

References

No external sources were consulted for this workflow.