Building a Redirect Map: Inventory, Chain Detection, and Format Selection

A redirect map looks manageable until 40 entries point to destinations that are themselves redirected — creating chains that slow crawlers and bleed equity. Here's the four-source URL inventory methodology (crawl + logs + GSC + sitemap), the three redirect types (one-to-one, pattern-based, 410 Gone), pre-implementation chain and loop detection algorithms, and why a CSV master reference generating server-specific formats is more maintainable than writing .htaccess directly.

A redirect map with 200 entries looks manageable — until you realize that 40 of those entries point to destinations that are themselves redirected, creating chains that slow down crawlers, bleed equity across extra hops, and occasionally loop back on themselves in ways that lock out crawlers entirely

The previous articles on this site covered redirect planning for site migrations, JavaScript redirect SEO pitfalls, how redirect chains accumulate over migrations, and how long 301s take to process. This article addresses building a redirect map from scratch — the methodology for auditing current URLs, matching them to destinations, and structuring the map to avoid the chain and loop problems before they exist.

The audit phase: knowing what you have before deciding where it goes

Before mapping a single redirect, you need an inventory of all current live URLs. Sources for this inventory:

Crawl the existing site: tools like Screaming Frog, Sitebulb, or a custom crawler (wget, httrack) discover linked URLs. Limitation: crawlers only find URLs that are linked from somewhere — orphaned pages, parameter variations, and API endpoints may not appear.

Server access logs: every URL that received a real request in the past 6-12 months. This is the most complete picture of what's actually being used — it includes direct-access URLs, API calls, and pages that haven't been linked from anywhere in a while but still receive traffic.

Google Search Console coverage report: all URLs Google has indexed for the domain. These are URLs with existing search presence — losing them without redirecting is a direct ranking loss.

Existing XML sitemap: the URLs the site owner intends to be indexed. Cross-referencing the sitemap against the crawl reveals which intended URLs don't have internal links.

Combining all four gives a URL inventory that's more complete than any single source alone.

The matching phase: three types of redirect

Once you have the inventory, each URL needs a destination or a decision:

One-to-one exact matches: old URL maps to a specific new URL. The simplest case: /old-page/ → /new-page/. Most of the inventory for a typical site.

Pattern-based redirects: a URL pattern maps to a new pattern. /blog/2019/[slug]/ → /articles/[slug]/. Captured groups in the pattern fill the destination. These are more efficient to implement (one rule handles hundreds of URLs) and less error-prone than individual rules for each URL.

Gone / no equivalent: some old pages have no appropriate equivalent. Options:

Redirect to the category or parent section that's closest in topic
Redirect to the homepage (last resort — passes no topical signal)
Return 410 Gone (explicitly signals the content is intentionally removed, not just missing)

The 410 option is underused: returning 410 tells Google "this page is gone and won't come back" — Google removes it from the index faster than a 404. For pages that you're definitively removing (discontinued products, deleted categories), 410 is more accurate than redirecting to an unrelated destination.

Detecting chains before they go live

A chain occurs when the destination of a redirect is itself a redirect. Before implementing your redirect map, validate that no destination URL in the map is a source URL in the same map:

# Pseudocode: detect chains in a redirect map
redirects = {
    "/old-a": "/mid-b",
    "/mid-b": "/new-c",   # /old-a → /mid-b → /new-c = chain of 2
}

for source, dest in redirects.items():
    if dest in redirects:
        print(f"Chain detected: {source} → {dest} → {redirects[dest]}")

For each detected chain: update the source to point directly to the final destination. /old-a → /new-c (skipping /mid-b).

Pre-existing redirects on the server complicate this: your new redirect map may point to a destination that already has a redirect from a previous migration. The new chain only becomes visible when you combine the new map with the existing server configuration — which is why testing in staging before production is essential.

Detecting loops before they go live

A loop occurs when a chain of redirects eventually points back to a source in the same chain. Simple loops are obvious (/a → /b → /a); longer loops are harder to spot:

/page-a → /page-b
/page-b → /page-c
/page-c → /page-a   ← closes the loop

Detection: for each redirect, follow the chain to its end. If you encounter a URL you've already visited in the current chain, you've found a loop.

Impact: a crawler or browser encountering a redirect loop follows the chain for a configured maximum number of hops (typically 10-20), then gives up with an error. The page becomes completely inaccessible. Loops also don't appear as errors in redirect tools that check single redirects — they require chain-following logic to detect.

Export formats: .htaccess, Nginx, CSV

A redirect mapper's output needs to be in a format compatible with the web server:

Apache .htaccess:

RewriteRule ^old-page/?$ /new-page/ [R=301,L]

Nginx:

rewrite ^/old-page/?$ /new-page/ permanent;

Or using a map file (more efficient for large redirect sets):

map $uri $redirect_uri {
    /old-a /new-a;
    /old-b /new-b;
}

CDN-level redirects (Cloudflare Rules, AWS CloudFront Functions): increasingly common as CDNs offer redirect rule engines — these evaluate before the request reaches the origin server, reducing server load. Syntax varies by provider.

The most maintainable approach for large redirect sets: a structured CSV (source, destination, status code) as the source of truth, with scripts generating the server-specific format from the CSV. This keeps the redirect logic in a version-controlled, human-readable format separate from server configuration.

How to use the Redirect Mapper on sadiqbd.com

Build your URL inventory first from crawl + GSC + logs before opening the mapper — the quality of the redirect map depends on the completeness of the inventory
Use the tool to build and validate the map: enter source-destination pairs and use any chain/loop detection features to validate before exporting
Export in the format matching your server: the tool supports .htaccess, Nginx, and CSV — use the server-specific export for direct implementation, and keep the CSV as the master reference

Frequently Asked Questions

How many redirects are too many for a site migration? There's no absolute upper limit, but manageability matters. Large e-commerce migrations can produce tens of thousands of redirects — entirely manageable if they're implemented at the server/CDN level with map files rather than evaluated one-by-one per request. What causes performance problems isn't the total count but the evaluation method: a linear list of RewriteRule entries in .htaccess evaluated sequentially is slow at scale; a hashed map file lookup is O(1) regardless of count. Modern redirect managers and CDN redirect rules handle large counts without performance impact. The real limit is human manageability — a 50,000-entry redirect map needs tooling and version control, not just a text file.

Is the Redirect Mapper free? Yes — completely free, no sign-up required.

Try the Redirect Mapper free at sadiqbd.com — plan, validate, and export redirect maps for any site migration.