Website Migration URL Mapping: Build a Redirect List You Can Test

A website migration is easier to test when every important old URL has an intentional outcome. “Redirect the old site” is not detailed enough. A business may need to preserve service pages, consolidate several guides, and retire an outdated campaign without sending all three audiences to the same destination.

Build a URL map before the launch date becomes urgent. It becomes the shared record for the developer implementing redirects and the person checking whether the content still serves its purpose.

Gather URLs from more than one place

Start with the current sitemap and CMS export, then add important landing pages, known external links, and URLs your support or sales team still shares. The sitemap alone may omit older addresses that continue to receive visitors.

Keep the source of each entry. An address found in an active email campaign may need attention even if it has little recent organic traffic. Remove exact duplicates, but do not merge URLs merely because they look similar; parameters or language paths may have a real purpose.

This inventory is a working list, not a promise that every historical URL can be discovered. Note the sources used and any gaps so the team understands the coverage.

Give each row a decision

Use these fields in a spreadsheet or version-controlled file:

• Old URL.
• Intended new URL, if one exists.
• Decision: unchanged, moved, consolidated, or removed.
• Reason and content owner.
• Expected response and verification result.

Consider a fictional site moving from /services/site-care to /website-maintenance. That is a clear one-to-one mapping. Three overlapping legacy guides may point to one genuinely consolidated guide. An expired recruitment campaign may have no suitable replacement and should be handled accordingly.

The map should explain the content relationship, not just pair strings that happen to contain the same word.

Review destinations before writing rules

Open the proposed new pages. Confirm that their content is ready, that public visitors can access them, and that their canonical and indexing settings fit the new site. A technically valid redirect to an unfinished preview page is still a failed migration outcome.

Google recommends accurate mappings, relevant destinations, and checking canonical and robots settings during URL moves. It cautions against sending many unrelated old pages to one irrelevant destination. Google's site-move documentation provides the underlying guidance.

Have someone other than the rule author review the highest-value rows. Editorial mistakes are easier to catch when the reviewer reads the old and new page titles side by side.

Test the map as a set

After implementation, request each important old URL and record the full outcome. Confirm that the final host and path match the map and that the destination returns the intended page. Identify loops, unnecessary hops, and rules that accidentally match unrelated paths.

Include representative edge cases: a trailing slash, an uppercase legacy path if relevant, a known query parameter, and a URL that should remain missing. Do not silently discard parameters required for the page's function just because the simplified address looks cleaner.

Test internal links separately. Updating them to the new destinations reduces dependence on redirects for ordinary navigation.

Assign a launch owner and a follow-up owner

The launch owner confirms the mapping works when the release becomes public. The follow-up owner reviews newly reported missing URLs and search observations after launch. These can be the same person, but the responsibility should be explicit.

Preserve the original map, the tested version, and the release time. When an unexpected redirect is reported later, this record distinguishes an approved migration decision from a regression.

Ambastly can contribute public integrity checks around the move. Keep a dedicated URL-map test for migration coverage: a check of one monitored entry point does not validate every legacy address in your migration.

If a destination appears outside the approved map, use the unexpected redirect guide to investigate its source. Planned mappings and unexplained redirects should have separate work records.