What a redirect map is and when you need one

A redirect map is a simple list that pairs each old URL with the new URL it should point to. It is the single most important deliverable of any site migration, URL restructure, or platform move. Without it, the moment your old URLs change, every link, bookmark, and search result pointing at the old address breaks, and the ranking equity those pages earned over months or years evaporates. With a correct map in place, search engines and visitors follow a clean one-step redirect from the old address to the new one, and most of that equity carries over.

You need a redirect map any time URLs change in bulk: switching from one CMS to another, moving from HTTP to HTTPS, dropping or adding the www prefix, flattening a deep folder structure, changing a slug pattern across a whole section, or merging two sites into one. The hard part is rarely deciding that you need redirects; it is building the old-to-new pairing accurately for hundreds or thousands of URLs without typos, omissions, or mismatches.

What this generator actually does

This tool removes the tedious, error-prone part of building a map. You paste your list of old URLs, one per line, and supply a find/replace rule that describes how the old pattern becomes the new pattern. The generator applies that rule to every URL at once and produces a copy-ready, two-column old-to-new redirect map you can hand to a developer or drop straight into your server configuration.

The find/replace approach is powerful because most URL changes follow a pattern. If you are moving everything under /blog/ to /articles/, the rule is a single find-and-replace that the tool applies across the whole list in one pass. If you are changing your domain, swapping a slug prefix, or removing a trailing segment, the same mechanism handles it. Instead of editing thousands of lines by hand and praying you did not fat-finger a slash, you define the transformation once and the tool generates a consistent map you can review at a glance.

Why redirects preserve ranking, and what they cannot save

The reason a redirect map matters so much is that URLs accumulate value over time. A page that has ranked for years has earned backlinks, internal links, and a track record with search engines, all tied to its specific address. Change that address with no redirect and every one of those signals points at a dead URL. A 301 redirect tells search engines the page has permanently moved and instructs them to transfer that accumulated value to the new location, which is why a well-built map can carry a migration through with minimal ranking loss.

Redirects are powerful, but they are not magic. They preserve existing signals; they do not improve a page or guarantee zero impact. Migrations almost always cause a temporary dip while search engines recrawl and re-evaluate the new URLs, even with a perfect map, and the dip is larger and longer when the map has gaps or errors. Redirects also cannot rescue a page whose content you gutted during the move. The goal of the map is to make the URL change itself as invisible as possible to search engines so that whatever ranking the old pages held has the best chance of carrying forward.

How to read and verify the generated map

The output shows each old URL alongside the new URL the rule produced. Before you ship anything, scan the map for three things. First, that every new URL is a real, live destination and not a slightly wrong path the rule accidentally created. Second, that you have no accidental duplicates where several old URLs collapse onto a single new URL when they should not. Third, that protocol and host are correct: the most common silent error is a map that keeps http when the new site is https, or keeps www when the new canonical is the bare domain.

Treat the generated map as a draft you confirm, not a finished artifact you trust blindly. A find/replace rule is only as good as the pattern you gave it, and real URL sets always contain a few entries that do not fit the pattern. Spot-check a sample of redirects by opening the new URLs in a browser, and pay special attention to your highest-traffic and highest-ranking pages, where a wrong redirect does the most damage.

Always use 301, and never chain redirects

For a permanent move, use a 301 redirect, which tells search engines the change is permanent and that ranking signals should transfer to the new URL. Avoid 302 (temporary) redirects for migrations: a 302 signals the move is temporary, so engines may keep the old URL indexed and withhold equity from the new one. The whole point of a migration map is permanence, and 301 is the status code that communicates it.

Just as important: map old URLs to their final destination in a single hop, never through a chain. A redirect chain happens when old URL A redirects to B, which redirects to C. Each extra hop adds latency, dilutes the equity that survives the move, and wastes crawl budget. If a page has already been redirected once in the past, point the new map directly at the current live URL, not at the intermediate address. One clean 301 from the original URL to the final URL is always the goal.

The one-to-one mapping principle

The strongest redirect maps pair each old URL with the single most relevant new URL: the new page that covers the same topic and serves the same intent. Resist the lazy temptation to redirect everything you are unsure about to the homepage. Mass redirects to the homepage are treated by Google as soft 404s, because the destination does not match what the user asked for. They pass almost no equity and frustrate visitors who expected the specific page they clicked.

When an old page has no obvious one-to-one successor, choose the closest relevant parent: a category page, a hub, or a replacement article on the same subject. Only when truly nothing relevant exists should a page be retired with a 410 rather than redirected. A find/replace rule naturally encourages clean one-to-one mapping because it transforms each URL on its own terms, but you should still manually reassign the handful of URLs whose new home does not match the pattern.

Building a complete list of old URLs to feed in

A redirect map is only as good as the list of old URLs you start with, and the most common cause of a botched migration is feeding in an incomplete list. Pull old URLs from several sources and merge them, because no single source is exhaustive. Your old XML sitemap gives you the URLs you actively maintained. Your analytics shows the URLs that actually received traffic, including ones you forgot existed. Your server logs reveal URLs that crawlers and bots still request. And a fresh crawl of the old site catches pages linked internally that never made it into the sitemap.

Combine those four sources, deduplicate, and you have a far more complete picture than any one of them alone. Pay special attention to URLs that earned backlinks, since those are the ones whose ranking equity you most want to preserve, and to high-traffic pages where a missed redirect costs the most. Once the list is complete, this generator does the repetitive transformation work; your job is to make sure nothing valuable was left off the list before you ever apply a rule.

Common mistakes that break migrations

The most damaging mistake is an incomplete map: forgetting entire URL patterns, paginated pages, parameterized URLs, or old image and PDF paths. Anything you leave out 404s the moment the old structure goes away. Before generating, make sure your list of old URLs is complete; pull it from your sitemap, your analytics, your server logs, and a crawl of the old site combined, not from memory.

Trailing-slash inconsistency is another classic. If your old URLs end in a slash and your new ones do not, or vice versa, a careless rule produces redirects that themselves get redirected again by your server's slash-normalization, creating accidental chains. Case sensitivity, double slashes, and leftover query strings cause similar silent failures. Reviewing the generated map line by line for these patterns is far cheaper than discovering them after launch when rankings have already dropped.

Implementing and validating after you generate

Once your map is verified, hand it to whoever controls the server. Implementation lives in different places depending on your stack: server config rules, a CDN or edge layer, framework-level redirect config, or a redirect plugin. The map this tool produces is portable because it is just old-and-new pairs; how you apply those pairs is a separate, stack-specific step. For generating the exact rewrite rules for a given server, the Redirect Rule Generator turns the same pairs into ready-to-paste configuration.

After launch, validate. Trace your most important redirects to confirm each one is a single 301 to a live page with no chain or loop, using a redirect chain checker. Keep the old URLs in your monitoring for a while so you catch any that slipped through and started returning 404s. Submit the new sitemap, watch coverage and crawl reports for new errors, and resist removing redirects too early: search engines need time to transfer signals and re-index the new URLs, so leave the map in place for many months after the move, not weeks.