Site Migration Redirect Map: From Old→New URL Pairs to .htaccess and Nginx Rules

Build a clean old→new URL map for a site migration, remove chains and loops, then turn it into Apache and Nginx 301 rules you can test before launch.

A redirect map is the one document that decides whether a site move keeps its search history. The server rules are the easy part. The hard part is the list behind them: every old URL, one correct destination for each, no chains, no loops, no typos in a trailing slash. This page walks through building that list as a spreadsheet first and only then turning it into Apache or Nginx configuration.

A redirect map starts as a spreadsheet of old→new URL pairs

1. Collect every old URL worth redirecting

Start wider than you think you need. A migration usually breaks URLs that nobody remembers exist, and those are often the ones with old backlinks.

Pull old URLs from several sources and merge them into one column:

• The current XML sitemap — the URLs you officially publish today.
• A full crawl of the live site — catches pages that are linked but missing from the sitemap.
• Search Console exports — pages that get impressions or appear in the Page indexing report. Search Console exports are capped at 1,000 rows of representative examples, so on a large site this is a sample, not the full list.
• Your backlink tool export — target URLs of external links, including ones that already return 404.
• Analytics landing pages — URLs that still receive visits.

De-duplicate the merged column. Keep the original form of each URL for now; normalising comes later, once you can see the variants side by side.

2. Give each old URL exactly one destination

Add a second column: the new URL. The rule is one old URL → one final destination, and that destination should be the closest equivalent page, not just “somewhere on the new site”.

A few decisions come up on every project:

• Merged pages. If three old articles became one new guide, all three point to that guide.
• Removed pages with no equivalent. Point them to the nearest relevant category, or let them return 404 or 410. Sending large groups of unrelated URLs to the homepage is a common shortcut, and Google can treat redirects to an irrelevant page as soft 404s, so the redirect brings little benefit.
• Parameters. Decide whether tracking parameters (utm_*, session IDs) should be dropped or preserved. Usually you map the clean URL and let the parameter version follow the same rule.

3. Normalise the pairs before writing any rules

Most broken redirect maps fail on formatting, not logic. Before generating configuration, clean both columns:

• Protocol and host. Old paths can stay relative (/blog/old-post/), but destinations should be absolute (https://example.com/guides/new-post/) so there is no doubt about the final host.
• Trailing slashes. /pricing and /pricing/ are different paths to a server. Map the form that was actually live, and add a separate pair if both versions received links.
• Case. Paths are case-sensitive on most servers. /About-Us/ and /about-us/ need either two pairs or a deliberate lowercase rule.
• Encoded characters. Non-ASCII slugs may appear both encoded (%D0%...) and decoded in your sources. Pick one form per server and stay consistent.
• Conflicts. The same old URL with two different destinations is a mistake to resolve now, not in production.

4. Remove chains and loops

A chain happens when an old URL redirects to another URL that also redirects: A → B → C. Chains appear naturally when a site has moved before and the old rules are still in place.

Collapse every chain so each source points straight to its final destination: A → C and B → C. Google’s crawlers follow up to 10 redirect hops, but every extra hop is another request, another place for an error, and slower pages for users. Treat any chain longer than one hop as a bug.

Loops are worse: A → B → A never resolves. Check every destination against the source column. If a destination also appears as a source, follow it until you reach a URL that is not redirected; if you come back to the start, you have a loop.

From URL inventory to tested 301 rules in seven steps

5. Choose the status code

For a permanent move, use a permanent server-side redirect: 301 or 308. Google’s indexing pipeline uses a permanent redirect as a signal that the target should become the canonical URL. Temporary codes — 302, 303, 307 — tell Google the old URL may come back, so the source can stay canonical.

Use temporary redirects only for things that really are temporary, like a short campaign or maintenance page. Meta refresh and JavaScript redirects are fallbacks for hosting where you cannot touch the server; Google’s redirects documentation recommends server-side permanent redirects whenever possible.

6. Turn the map into server rules

Apache (.htaccess)

For a handful of exact matches, mod_alias is the simplest option:

Redirect permanent "/old-page/" "https://example.com/new-page/"
RedirectMatch 301 "^/blog/2019/spring-sale/?$" "https://example.com/offers/"

Be careful with plain Redirect: it matches by prefix, so Redirect permanent "/old" also catches /old-archive/ and /old/anything. When you need an exact match, use RedirectMatch with ^ and $ anchors.

Nginx

A few lines of location = /path blocks work for small lists. For hundreds or thousands of pairs, a map is easier to maintain and keeps the server block short:

map $uri $redirect_target {
    default        "";
    /old-page/     https://example.com/new-page/;
    /old-pricing/  https://example.com/pricing/;
}

server {
    # ...
    if ($redirect_target) {
        return 301 $redirect_target;
    }
}

$uri holds the path without the query string. If your map needs to match parameters too, use $request_uri instead and write the keys with their query strings.

Writing hundreds of these lines by hand is where typos creep in. If your pairs are already in a spreadsheet, you can paste them into a browser tool and generate 301 rules for Apache and Nginx, then review the output before it goes into your configuration.

7. Test before and after launch

Run the full list of old URLs through a status-code check on staging, and again right after the switch:

1. Every old URL returns a single 301 or 308.
2. The Location header matches the destination in your map exactly.
3. The destination returns 200 — not another redirect, not 404.
4. No old URL returns 200 by accident (a leftover page that was supposed to move).

Then update everything you control so that it points to new URLs directly: internal links, canonical tags, hreflang, and the XML sitemap. A sitemap full of redirected URLs sends mixed signals. For the wider list of checks after a move — Search Console properties, sitemaps, internal links — use this post-migration SEO checklist.

How long to keep the redirects

Keep them for as long as you can. Google has recommended keeping redirects in place for at least one year so that the change is seen several times, and there is no harm in leaving them longer. Old backlinks and bookmarks keep sending visitors to the old URLs for years, so removing the rules later mostly creates 404s.

Keep the final redirect map in version control next to the server configuration. When the next migration comes, it is the starting point that prevents a new round of chains.