Designing and validating redirect maps

Keep source evidence before normalising addresses

Combine the old CMS export, a linked crawl, sitemaps and available landing-page or request records. Record how each address entered the inventory. An old PDF seen only in requests may still serve customers; a filter URL found only by a crawler may be an unintended combination. Do not decide their fate from the source alone.

Keep the raw URL and create a separate comparison key. Scheme and host normalisation can help grouping, but indiscriminately lowercasing paths or discarding queries can join distinct resources. Identify which parameters control content, which support attribution and which should be rejected. Retain encoded characters until their server interpretation is understood.

Exclude fragments from server-side matching decisions because they are not sent in the HTTP request. Where old fragment links jump to important sections, consider whether the new page can preserve those section identifiers. The page may arrive correctly while the visitor loses the precise passage they expected.

Design a map that engineers can implement

Use one row per distinct source decision. Include raw source, normalised key, source evidence, old page purpose, approved destination, disposition, expected status, matching method, reviewer and exception notes. Keep implementation rules alongside the map, but do not replace individual decisions with an opaque regular expression.

Separate URL retention from movement. A retained URL needs content checks, not a redirect to itself. A retired page with no appropriate replacement needs an agreed error response. A merged page needs an explanation of what content survives at its destination. These distinctions prevent a blanket routing rule from silently redefining editorial policy.

Version the reviewed map with the release. If new content appears after approval, process the additions as a visible delta. Otherwise developers may implement one export while reviewers sign off another. For the wider release dependencies, use the migration checklist.

Choose the replacement by information and user need

Read the old page and ask what someone following a specific external reference expects. A repair manual, a product page and a troubleshooting article can share the same product name without being interchangeable. Prefer a direct successor that retains the useful answer. Slug similarity is a way to find candidates, not a reason to approve them.

Where several old pages merge, list the distinct needs they served. The receiving page should make the corresponding information findable, not bury it behind an unrelated overview. A narrower page can sometimes move to a broader one, but the destination must still satisfy the actual old request. Avoid treating every category page as an acceptable fallback.

Escalate uncertain mappings to somebody responsible for the content. Do not fabricate replacements just to remove blank cells. A reviewed removal is more defensible than a wrong redirect. Record language, geography and product availability where they affect equivalence, particularly when similar names describe different local services.

Use patterns only after checking their boundaries

A pattern works when the relationship is consistent. If every old article under a date prefix has an unchanged unique slug, a rule may avoid thousands of individual entries. Test whether exceptions exist: duplicate slugs from different years, renamed articles, removed content and paths that resemble articles but are actually archives.

Establish rule precedence explicitly. Usually the most specific exceptions need to be evaluated before broad families, but the actual platform behaviour must be tested. Check that a generic host redirect does not bypass an application mapping, and that a trailing-slash rule does not send a destination back to its source.

Define query behaviour rather than inheriting a default accidentally. Preserve parameters that the destination needs, translate changed identifiers and remove irrelevant values only under an approved policy. Test reserved characters and repeated parameters. See URL parameter diagnosis when the old system mixes content controls with tracking data.

Validate the map as both data and live behaviour

Start with static checks: duplicate sources, conflicting destinations, self-redirects, malformed addresses, targets outside approved hosts and targets that are themselves mapped sources. Detect cycles in the proposed graph before deployment. Then request the sources through the actual delivery stack and compare the observed destination with the approved destination.

• Retain the requested address, each status and Location value, and final response.
• Confirm destination content, language and canonical against the approved purpose.
• Check that ordinary internal links point directly to the final public URL.
• Inspect failed and unclassified rows rather than averaging them away.
• Retest a genuine missing URL to expose blanket successful fallbacks.

A HEAD-only test may miss behaviour that differs for GET. Use representative GET checks and browser review for important journeys. The automated validation workflow helps repeat these comparisons without mistaking a reachable destination for a correct one.

Illustrative example: map a discontinued model carefully

Illustrative example: an equipment supplier retires a drill model. The old model page, its safety sheet and a battery compatibility article all contain the model identifier. A name-based matcher proposes sending all three to the latest drill's sales page. That would lose two distinct information needs.

The content reviewer chooses a successor product page for the old sales page only after confirming that it clearly explains the replacement. The safety sheet remains available at a maintained document address because existing owners still need it. The compatibility article moves to an updated support guide that preserves the old battery details.

Acceptance tests therefore require three different outcomes, even though the source strings look similar. Review includes following an old PDF reference and checking that the expected safety information actually loads. The destination status alone cannot establish that. This is an illustrative mapping decision, not a claim that a particular commercial site achieved a result.

Give developers precise acceptance criteria

Every approved moved source must produce the agreed permanent redirect behaviour and end at the reviewed final address. Reject loops, wrong-language targets, unrelated homepages and destinations blocked from intended access. Aim for direct old-to-final routing; identify any infrastructure constraint that temporarily adds a hop rather than concealing it in a pass count.

Require test fixtures for rule boundaries, including a non-matching path, an exception, a meaningful query, a mixed-case path and an encoded path where relevant. Approved destinations should return substantive content with consistent canonical references. Removed URLs must return the agreed not-found or gone response rather than the same successful shell as working pages.

For non-GET application routes, involve the application owner before choosing a status. A 308 preserves the request method and body; that matters for form and API behaviour. Do not apply a broad SEO redirect rule to transaction endpoints without a separate functional review.

Diagnose apparent failures and control rollback risk

If live results disagree with the map, consider three explanations: the map was wrong, the deployed rule differs, or another layer intercepts the request. Compare the approved row with routing configuration, response headers and the observed hop sequence. An old cached permanent redirect can make a fixed server appear broken in a returning browser.

A redirect checker cannot judge equivalence reliably. A 200 destination may be a soft error, a login wall or an empty template. A missing target during staging may simply reflect unpublished content, but that dependency must be resolved before launch. Treat these as limits of the test, not as reasons to ignore failures.

Rollback the smallest faulty rule set where possible. Restore a versioned configuration and purge relevant caches with the infrastructure owner. Reverting every redirect can strand correctly moved pages and create contradictory routes. If tracing shows extra hops or a repeated address, continue with redirect chain and loop diagnosis rather than repeatedly changing target cells.