URL Migration Redirect Mapping: Build a Testable One-to-One Matrix

01

Preconditions

A redirect matrix records what should happen to every old URL when a site changes domains, paths, platforms, or information architecture.

The minimum useful row is:

Old URL → intended final state

A production-grade row should usually include:

Old URL
Source of discovery
Page type
Historical status
Traffic or priority
Inbound-link evidence
New URL or retirement state
Redirect class
Expected status
Observed first status
Observed final URL
Hop count
Final status
Final canonical
Final robots state
Owner
Review status
Notes

Google recommends preparing a URL mapping before a move, starting with important URLs from sitemaps, logs, analytics, Search Console link data, and the CMS, while also including hosted images, videos, JavaScript, CSS, and downloads. ^[1]

Do not normalize the evidence so aggressively that distinct old URLs disappear. The following may represent different historical resources:

/page
/page/
/Page
/page?print=1
/page?id=17
/http://example.com/page
/https://www.example.com/page

They may ultimately share one destination, but they should remain separate input rows until their behavior is understood.

Before mapping begins, define the allowed terminal states:

Permanent redirect to relevant replacement
Permanent redirect to consolidated replacement
Retire with 404
Retire with 410
Remain unchanged
Temporary redirect
Manual investigation

“Homepage” is not a terminal class. It is a destination that must independently pass the relevance test.

02

Ordered process

1. Assemble the old-URL inventory.

Combine:

• every submitted sitemap
• CMS and database exports
• internal crawl results
• server access logs
• analytics landing pages
• Search Console pages and link reports
• backlink exports
• paid campaign URLs
• profile and directory URLs
• media and download paths
• feeds and API routes used publicly
• archived route lists from prior migrations
• customer support documents
• browser bookmarks or app deep links where available

Record the source for each URL. A URL found in logs and external-link data deserves different review priority from a URL generated only by an obsolete crawler trap.

1. Capture the current behavior.

Before changing anything, request each old URL and store:

Status
Location header
Final destination
Hop count
Canonical
Robots directive
Content fingerprint
Title

This baseline reveals existing redirects and errors that would otherwise be mistaken for migration defects.

A previous path may already redirect:

/old-a → /old-b → /current-c

The new rule should usually send /old-a, /old-b, and /current-c directly to the final new-domain URL.

1. Normalize for analysis, not deletion.

Create normalized helper fields:

• lowercase hostname
• standardized scheme
• decoded or encoded path
• trailing-slash class
• parameter names
• fragment removed
• content identifier
• template family

Keep the original raw URL. Normalization supports grouping; it should not erase the ability to configure a redirect for the exact request users still make.

1. Match by page purpose.

Use the closest relevant destination.

A mapping decision should compare:

• subject
• user intent
• product or entity identity
• language
• region
• transaction state
• content depth
• replacement availability
• legal or historical continuity

A retired product may map to a successor model when the page clearly explains the relationship. It should not map to the store homepage merely because both belong to the same company.

Google says redirects are useful for moved or merged content but warns against redirecting many old URLs to one irrelevant destination. ^{[1] [2]}

1. Separate exact moves from consolidations.

Mark:

Exact equivalent
Near equivalent
Consolidation
No replacement

Exact equivalents can usually be approved programmatically after template and identifier checks.

Near equivalents and consolidations need editorial review. The destination should satisfy the old intent and ideally explain what changed.

No-replacement pages should return 404 or 410. Forcing them into weak destinations damages users, pollutes metrics, and can produce soft 404 classifications.

1. Choose the correct redirect class.

For a permanent move, use a server-side 301 or 308 where possible. Google treats permanent redirects as canonicalization signals. Temporary 302, 303, and 307 redirects indicate that the source may return and generally do not tell Google to replace it with the target as canonical. ^[2]

HTTP semantics distinguish method handling. RFC 9110 defines 307 and 308 as method-preserving redirects, while historical handling of 301 and 302 may allow a POST to be changed to GET. ^[3]

For ordinary GET-based page migrations, 301 is widely supported and appropriate. For endpoints where preserving the request method matters, application engineers should select status behavior deliberately rather than treating all 3xx responses as interchangeable.

1. Generate rules from the matrix.

Where the mapping follows a safe, exact pattern, generate rules:

old host + unchanged path
→ new host + unchanged path

Where paths changed irregularly, use explicit rows.

Do not let a broad wildcard rule override exceptions. Apply specific rules before general patterns and include automated tests for precedence.

1. Test the prelaunch candidate.

Against the new configuration, verify every row:

Observed first status = expected redirect status
Observed final URL = mapped destination
Hop count = 1 where possible
Final status = 200 for live replacements
Final canonical = final URL
Final robots = indexable when intended
No loop
No unexpected hostname
No staging domain
No authentication wall

For retirement rows:

Final status = 404 or 410
No redirect to irrelevant page
Custom error page still returns error status

1. Run semantic spot checks.

Automated URL equality cannot determine relevance. Review samples by:

• highest traffic
• strongest external links
• revenue
• major template
• consolidation group
• language and region
• media type
• historical errors
• wildcard rule
• retirement state

Open the old archived content beside the new destination. Ask whether a user following the old link would regard the result as a continuation rather than a bait-and-switch.

1. Launch the matrix as a versioned artifact.

Store:

• version
• generation time
• source exports
• reviewer
• rule build
• test results
• exceptions
• checksum
• rollback version

The mapping is not a disposable spreadsheet. It is the migration’s routing specification and should survive staff turnover, platform changes, and later audits.

1. Retest production continuously.

Immediately after launch, test the full matrix again. Then retest:

• after configuration changes
• after CDN changes
• after CMS updates
• after certificate or hostname changes
• after old-host decommissioning
• after new redirects are added

Monitor logs for unmapped old URLs. Append discovered URLs to the matrix and route them according to the same review policy.

1. Update links so redirects become a compatibility layer.

Change internal links, high-volume external links, advertising destinations, profiles, feeds, and documents to use the final URLs.

Redirects should preserve old references. The current site should not route its own users through the old host on every click.

03

Failure cases

The sitemap is treated as the complete inventory. Orphaned, linked, and historical URLs are missed.

Normalization destroys distinct inputs. Case, scheme, parameters, and trailing-slash variants vanish before rules are created.

Automated keyword matching chooses destinations. Similar words conceal different user intent.

Every retired page maps to a category or homepage. No-replacement content is forced into irrelevant destinations.

The matrix contains intermediate URLs. New rules preserve old redirect chains.

Testing checks only the first status. A 301 can still lead to a 404, noindex, wrong canonical, or staging page.

A wildcard shadows specific rules. High-value exceptions are captured by a broad pattern.

The spreadsheet is edited after rules are deployed. The planning artifact and production behavior diverge.

Method-sensitive endpoints use an arbitrary redirect. POST, upload, or API behavior changes unexpectedly.

No one monitors unmapped requests. Long-tail old URLs continue failing after launch.

04

Completion criteria

The matrix is complete when every known old URL has an approved destination or explicit retirement state, no unresolved rows remain, and the production rules are generated or reviewed against the same versioned dataset.

Every live mapping should reach its final relevant URL without loops and preferably in one hop. Final pages should return successful responses, self-canonicalize correctly, and remain indexable when intended. Retired URLs should return accurate 404 or 410 responses.

The matrix should be reproducible from stored source inventories and should function as an automated regression suite. New old-URL requests discovered in logs should enter the same process rather than being patched with improvised homepage redirects at three in the morning, the traditional hour of infrastructure folklore.

Continue with Search Console Change of Address after domain redirects are active and Domain Migration SEO for the full launch sequence.

References

Sources behind this record

1. How to move a site — Google Search Central (accessed August 2, 2026)
2. Redirects and Google Search — Google Search Central (accessed August 2, 2026)
3. RFC 9110: HTTP Semantics — RFC Editor / IETF (accessed August 2, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.