Website Migration URL Mapping: A Practical Checklist

A website migration can leave valuable pages behind when old URLs are missed, mapped to the wrong destinations, or redirected through unnecessary hops. This website migration URL mapping checklist helps you inventory URLs, choose relevant destinations, test redirects, and monitor the move after launch.

Key Takeaways

• Build your URL inventory from multiple sources, not just the current sitemap.
• Map each important old URL to the closest equivalent new page; do not send unrelated pages to the homepage.
• Decide how query parameters, trailing slashes, and letter case will behave, then test those rules.
• Test redirects for the final destination, page intent, chains, and loops before and after launch.
• Monitor search indexing, organic traffic, errors, and important landing pages after migration.

1. Inventory the URLs that matter

Start collecting URLs before the new site is finalized. No single source is complete: crawlers can miss orphaned pages, analytics may omit pages with little traffic, and a sitemap may not include every URL that has earned links.

Combine sources such as:

• A crawl of the live site, including internal links and canonical URLs.
• Current and historical XML sitemaps.
• Analytics and server logs, especially landing pages with visits or search traffic.
• Search Console performance and indexing reports.
• Backlink reports and known external links to important pages.
• CMS exports, product or category feeds, and campaign landing-page lists.

Normalize the inventory carefully. Keep the full URL, including meaningful query parameters, and record the source of each URL. Deduplicate exact repeats, but do not collapse URLs that may produce different content. Flag URLs that need manual review, such as parameterized pages, language variants, pagination, and pages with valuable external links.

A useful mapping sheet can include these columns:

For example, map an old product page to its replacement product page, not automatically to the new catalog. If the product is discontinued and no genuine substitute exists, a helpful category page may be appropriate; otherwise, let the removed page return a not-found response.

2. Map by page intent, not by URL similarity

For every important old URL, ask: what task or information did this page provide, and where can a visitor find the closest equivalent now? URL slugs can be similar while the content has changed substantially, so compare page purpose and content—not just strings.

Use a direct one-to-one mapping whenever a relevant replacement exists. If several old pages have been intentionally consolidated, direct them to the single new page that covers their subject. Avoid redirecting an entire old site to the homepage: that usually fails to meet visitors' expectations and can make it harder to understand which content was actually preserved.

A page without a suitable replacement should not receive an arbitrary redirect simply to avoid a 404. Return a not-found response for removed content with no equivalent. A gone response may also be appropriate when removal is intentional and permanent, depending on the site's requirements. Keep a useful custom error page, but make sure the underlying HTTP status accurately reports that the requested page is unavailable.

3. Set rules for URL edge cases

Document URL handling before writing redirect rules. Rules that seem convenient can accidentally merge distinct pages or create redirect loops.

Query parameters

Decide which parameters affect page content and which are only for tracking. Preserve parameters needed for the destination to show the right content, such as a product variant or a meaningful filter. Tracking parameters may be retained or removed according to your analytics and canonicalization plan, but do not assume every parameter is disposable.

Test representative URLs both with and without parameters. Check that a redirect does not duplicate parameters, drop a content-selection parameter, or create a sequence of redirects as different rules rewrite the query string.

Trailing slashes

Choose the canonical form for each kind of path and redirect the alternate form directly to it. Check both /page and /page/ where either form has been used. Do not add a slash rule that conflicts with a separate migration rule or causes the same URL to alternate between forms.

Letter case

Hostnames are case-insensitive, but path handling can depend on the server and application. Do not assume /Guide and /guide are interchangeable. Inventory observed case variants, test how the old and new systems handle them, and redirect a variant only when it represents the same resource. Lowercasing paths indiscriminately can break valid case-sensitive routes.

Removed pages and error responses

Keep URLs that still represent valid pages working. Redirect pages with relevant replacements. Return a not-found response for removed pages without one rather than sending them all to the homepage. Test the actual HTTP status, not just whether the browser displays an error template.

4. Test the redirect plan

Test the mapping in a staging environment when possible, then repeat the checks against the production site immediately after launch. Include high-priority URLs and a representative sample of each rule type: old and new path patterns, parameter variants, slash variants, case variants, and removed pages.

For each test, verify:

1. The old URL returns the intended redirect or error status.
2. The final destination loads successfully and is the page a visitor expects.
3. The destination still matches the original page's intent.
4. The redirect reaches its destination directly, without unnecessary intermediate URLs.
5. The chain does not loop or end at an error page.

A command-line check with curl can show the sequence of response headers and follow redirects:

curl -sS -D - -o /dev/null -L --max-redirs 10 \
  'https://old.example.com/old-page?ref=campaign'

Review each response header block. A series of Location headers indicates intermediate redirects; the final response should be the expected destination and a successful status for a page that should exist. If curl stops after the redirect limit, investigate a loop or an overly long chain. Some sites handle HEAD requests differently, so use a normal GET request for representative checks as above.

For a larger mapping file, automate checks against every row and save the old URL, each redirect hop, final URL, final status, and test time. Include assertions for expected destinations, not just a check that the final response is successful. A redirect to the wrong but functioning page is still a mapping failure.

5. Monitor the migration after launch

Treat launch as the start of verification, not the end. Compare results with a pre-migration baseline and investigate unexpected changes at the individual-page level as well as across the whole site.

• Check search-engine webmaster tools for crawl, indexing, and sitemap issues. Inspect important new URLs and review whether old URLs are being replaced by their intended destinations.
• Submit the new sitemap through the site's normal search-engine workflows, and ensure it lists the new canonical URLs rather than old redirecting URLs.
• Monitor organic landing-page traffic, conversions, and server logs. Segment by page and look for important old URLs that continue to receive requests, new pages that are missing expected visits, and spikes in not-found responses.
• Crawl the launched site to find internal links that still point to old URLs, redirect chains, broken destinations, and canonical tags that refer to the wrong version.
• Keep the redirect mapping and rules available for maintenance. Recheck them when content is consolidated, removed, or moved again.

Search-engine reporting and interfaces can change. Current official migration guidance could not be retrieved while preparing this article, so verify the latest instructions from the relevant search engines before launch. The monitoring steps above are general operational checks, not a substitute for current platform-specific guidance.

Common Mistakes

• Using only the sitemap as the inventory: It may omit linked, orphaned, or historically important URLs.
• Redirecting every old URL to the homepage: This ignores page intent and can frustrate visitors looking for specific content.
• Checking only the first response: A redirect can end at the wrong page, pass through multiple hops, or loop.
• Assuming query parameters are all disposable: Some parameters select meaningful content.
• Forcing lowercase or slash changes without testing: Path behavior varies, and a blanket rule can change resource identity or conflict with other rules.
• Treating a custom 404 page as a successful destination: Confirm the HTTP response status as well as the page users see.
• Stopping checks after launch day: Crawl and traffic issues may appear as search engines and visitors encounter more URLs.

Best Practices

• Assign an owner and review status to each high-value mapping.
• Prioritize URLs with search visits, backlinks, conversions, or important internal links.
• Prefer a single direct redirect to the most relevant replacement.
• Test rules with real old URLs and representative parameter and path variants.
• Keep a record of test results and compare post-launch data with a baseline.
• Preserve a helpful not-found experience while returning the correct not-found status for unavailable pages.

Conclusion

A reliable migration mapping connects each important old URL to a relevant destination—or deliberately leaves it unavailable when no equivalent exists. Inventory broadly, document URL edge cases, test complete redirect paths, and monitor the new site after launch so mapping problems can be found and corrected.