How to Map URLs for a Website Migration

A website migration can change domains, URL paths, or both. A careful URL map connects valuable old pages to the most relevant new destinations, helps visitors avoid dead ends, and gives search engines clear signals about moved content. This workflow covers building the inventory, choosing destinations, testing redirects, and monitoring the launch.

Key Takeaways

• Build the old-URL inventory from several sources: a site crawl, analytics, Search Console, backlinks, sitemaps, and server logs where available.
• Match each old URL to its closest relevant new page. Do not send every unmatched URL to the homepage.
• Use a permanent redirect for content that has genuinely moved; leave removed content without a suitable replacement as an intentional not-found response.
• Test old URLs and redirect chains before launch, then monitor traffic, indexing, and errors after launch.

1. Build a complete inventory of old URLs

Start with a crawl of the live site, but do not treat the crawl as a complete list. Crawlers can miss pages that are orphaned, blocked, linked only from external sites, or no longer present in navigation.

Combine multiple sources:

• A site crawl: Collect indexable pages, status codes, canonical URLs, and internal links.
• Analytics: Export landing pages with meaningful visits or conversions over a representative period.
• Search Console: Review pages receiving search impressions and clicks, as well as indexing and crawl reports.
• Backlink data: Include URLs with external links, especially links to pages that are not prominent internally.
• XML sitemaps and CMS exports: Use these to find published pages, including pages a crawl may miss.
• Server logs: If available, use them to identify URLs requested by users or crawlers. Treat tracking parameters and other query strings carefully; they may or may not represent distinct content.

Record the source of each URL and retain the original URL exactly as requested where practical. For each row, useful fields include:

Deduplicate carefully. URLs that differ only by tracking parameters may lead to the same page, while parameters that select a product, language, or other real content may need distinct handling. Do not strip query parameters automatically without checking what they do.

2. Assign each old URL a relevant destination

Map pages by content and user intent, not by similar-looking path names alone. A new page is a good destination when it answers substantially the same need as the old page. A changed slug can still be a direct match; an identical slug can be a poor match if the content has changed.

For each old URL, choose one of these outcomes:

1. Direct replacement: Redirect to the equivalent new page. For example, an old product guide should lead to the new version of that guide, not a general products page.
2. Relevant consolidation: If several genuinely overlapping pages are replaced by one stronger page, redirect them to that page only when it serves the same underlying need.
3. No suitable replacement: If the content is intentionally removed and there is no relevant alternative, return an appropriate not-found response, commonly 404 or 410. Keep any useful removal explanation or navigation on the site, but do not present an unrelated page as the replacement.
4. Unchanged URL: If the page remains at the same URL, it usually does not need a redirect. Verify that it still returns the expected content and status.

Redirecting every old URL to the homepage is not a reliable fallback. A visitor looking for a specific article or product arrives somewhere that may not answer their question. Search engines may also treat an irrelevant redirect as a soft 404 rather than as a useful replacement. Use a homepage destination only when it is genuinely the relevant successor, not simply because a mapping is missing.

A simple mapping might look like this:

Before implementation, review rows with no destination, many-to-one mappings, and broad pattern rules. These are common places for accidental homepage redirects or irrelevant matches.

3. Implement redirects to the final destination

For content that has permanently moved, configure a permanent server-side redirect, typically HTTP 301 or 308, from the old URL to its selected destination. The exact configuration depends on your server, CDN, CMS, or hosting platform; test the actual deployed behavior rather than assuming a rule works because it looks correct in a configuration file.

Where possible, make each old URL reach its final destination directly. If the path changes more than once, update the redirect so the original URL does not pass through a chain of intermediate URLs. Keep redirects for old URLs that still receive visits or links, and ensure internal links, canonical tags, and XML sitemaps use the new URLs rather than relying on redirects indefinitely.

Avoid broad rules that transform every path in the same way unless the old and new structures truly correspond. For example, a rule that blindly adds a new directory prefix can send removed pages to unrelated destinations. Check how your platform treats capitalization, trailing slashes, encoded characters, and query strings, and include representative examples in testing.

4. Verify redirect paths before launch

Create a test set that includes high-traffic pages, pages with backlinks, pages from every URL pattern, URLs with query strings, unchanged URLs, and intentionally removed pages. Check both the HTTP status and the final URL. Confirm that redirects land on the expected content, not merely on a page that returns status 200.

A redirect checker can help inspect individual URLs or batches. For a command-line spot check, curl follows redirects with -L and prints the response headers along the way:

curl -sS -D - -o /dev/null -L --max-redirs 10 \
  'https://old.example.com/guides/old-camera-review'

Review each response status and Location header. The first response should point toward the intended new URL; subsequent responses, if any, reveal extra hops. A loop or a chain that exceeds the redirect limit will fail rather than reaching the expected page. This command is a spot-check, not a substitute for testing the full mapping or checking page relevance.

Look specifically for:

• Loops: A URL redirects back to itself, or two or more URLs redirect to each other.
• Unnecessary hops: An old URL redirects to an intermediate URL before reaching the final page.
• Wrong destinations: The final page is unrelated, missing, or itself an error page.
• Unexpected status codes: A moved page does not return the intended permanent redirect, or a removed page incorrectly redirects.
• Rule collisions: A general redirect rule overrides a more specific mapping.

5. Monitor the migration after launch

Keep the mapping and test results available to the people responsible for the site. After launch, compare performance with a pre-migration baseline and investigate changes by page group, not just sitewide totals.

Monitor:

• Analytics: Landing-page visits, conversions, and referral traffic for important old and new URLs. Annotate the launch date so comparisons have context.
• Search Console: Indexing and crawl reports, search impressions and clicks, and any submitted sitemaps. For a domain change, use the appropriate site-move process in the current Search Console guidance when applicable.
• Server and platform errors: 404 and 5xx responses, redirect loops, and requests to old URLs that have no valid mapping.
• New-site signals: Check that important new pages are crawlable, return the expected status, and use the intended canonical URL.

Expect search engines to need time to recrawl and process a migration. Do not diagnose success from one early report or assume that submitting a sitemap alone proves every URL has been processed. Investigate persistent losses or unexpected errors URL by URL, starting with pages that had meaningful traffic, conversions, or external links. Keep the old domain and redirect configuration available while users and crawlers may still request old URLs.

Common Mistakes

• Using only a crawl: It can miss orphaned pages, external-link targets, and URLs visible in analytics or logs.
• Matching by slug alone: Similar paths do not guarantee equivalent content or intent.
• Redirecting everything to the homepage: This can frustrate visitors and fail to provide a meaningful replacement.
• Leaving redirect chains in place: Each hop adds complexity and makes troubleshooting harder.
• Testing only the homepage: URL patterns, query strings, and one-off pages can behave differently.
• Confusing a successful HTTP response with a good mapping: A destination can return 200 and still be the wrong page.
• Stopping monitoring immediately: Errors and traffic changes may become visible only after launch as users and crawlers follow old links.

Best Practices

• Keep one reviewed source of truth for the mapping, implementation, and test results.
• Prioritize URLs with traffic, conversions, search visibility, or valuable backlinks, while still accounting for the full URL inventory.
• Review unmatched URLs and many-to-one mappings with someone who understands the content.
• Test representative examples before launch and automate checks across the full mapping where your tools allow.
• Update internal links, canonical references, and sitemaps to point directly to the new URLs.
• Treat a migration as a monitored change: record a baseline, watch error reports, and investigate anomalies after deployment.

Conclusion

A useful migration map is more than a list of redirects: it records what each old URL represents, where its content belongs, and how the result was verified. Build the inventory from multiple sources, send moved pages to relevant destinations, leave pages without a true replacement intentionally removed, and continue monitoring after launch.

References

• Google Search Central: Site moves with URL changes — Official guidance on site moves and URL changes. Search-engine documentation can change; confirm the current instructions and applicable Search Console steps before your migration. This draft was not live-checked against current documentation.