Mapping Redirects For A Migration Without Breaking SEO

A redirect map is one of the least glamorous parts of a site migration. It is also one of the places where a rebuild can quietly lose years of search equity.

The work looks simple: old URL on the left, new URL on the right. In practice, a strong redirect map is a set of editorial, SEO, technical, and business decisions. It decides which pages keep value, which pages merge, which pages retire, and which new destinations deserve inherited signals.

Google's guidance on site moves is clear that URL mapping matters when existing URLs change. For business leaders, the practical translation is simpler: if people or search engines knew where something lived yesterday, the new site needs to guide them somewhere useful tomorrow.

Start With A Complete URL Inventory

A redirect map is only as good as the inventory behind it. Many teams export the current sitemap and assume they have all important URLs. That is a start, not a complete view.

Use several sources:

• Current XML sitemaps
• A crawl of the live site
• Search Console landing pages, clicks, impressions, and indexed URLs
• Analytics landing pages and conversion paths
• Server logs when available
• Backlink data from SEO tools
• Paid campaign URLs
• Sales enablement links
• Old campaign landing pages
• PDFs, images, and downloadable assets
• URLs found in email templates, partner pages, ads, QR codes, and offline materials

This matters because valuable URLs are often outside the main navigation. A five-year-old article may still attract high-intent organic traffic. A PDF may have backlinks from partners. A retired webinar page may still receive branded search visits. A paid landing page may be paused now but needed again next quarter.

The inventory should separate URL existence from URL value. Not every URL deserves a careful one-to-one redirect. But the team should make that decision with data, not by accident.

Map By Intent, Not By Convenience

The best redirect destination is not always the closest page in the new sitemap. It is the page that best satisfies the same user intent.

Imagine an old URL that ranks for "managed IT onboarding checklist." During the redesign, that content is folded into a broad "IT Services" page. Redirecting to the broad page is convenient, but it may disappoint both users and search engines. The visitor expected a checklist. The new page gives a sales overview.

Better options might be:

• Keep the checklist as a refreshed article.
• Merge it into a stronger onboarding resource.
• Create a new section on the service page that genuinely answers the same query.
• Redirect to a closely related guide if the old page is outdated but the intent remains valuable.

Google's redirect documentation treats permanent server-side redirects as a strong canonical signal when a page has moved. That signal is strongest when the destination makes sense.

For each important URL, assign a redirect type:

1. Keep the same URL because it already works.
2. Redirect one-to-one to an equivalent page.
3. Redirect many-to-one because several weak pages are being consolidated into a stronger page.
4. Create a new destination because the old intent still has value.
5. Return a true 404 or 410 because the content has no useful replacement.

This is where migration planning becomes strategy. A good modernization process does not preserve clutter blindly. It preserves earned value and removes what no longer serves the business.

Decide What Should Not Redirect

Not every old URL deserves a redirect. Over-redirecting can make a migration look tidy while creating a poor user experience.

Avoid redirecting everything to the homepage. It may reduce visible 404s, but it does not help the visitor who wanted a specific resource. It also makes post-launch diagnosis harder because bad mappings are hidden behind a generic destination.

Be careful with outdated, thin, or irrelevant content. If an old page has no traffic, no backlinks, no business value, and no close replacement, a clean 404 may be more honest than a weak redirect. If the content was intentionally removed for legal, brand, or product reasons, a 410 may be appropriate.

Also watch for system-generated URLs:

• Tag archives
• Author archives
• Search result pages
• Attachment pages
• Paginated category pages
• Filter URLs
• Tracking parameter variants
• Staging URLs that were accidentally indexed

Some of these need rules. Some need noindex cleanup before migration. Some should not be carried into the new architecture at all.

The redirect map should include a notes column for decisions. Future teams should be able to see why a page was merged, retired, preserved, or rebuilt. That small bit of context prevents the same debate from returning after launch.

Test Redirects Like A Product Feature

A redirect map is not done when the spreadsheet is approved. It is done when the implemented redirects behave correctly in the environment that will serve real users.

Test in layers.

First, test high-value URLs one by one. These include top organic landing pages, pages with backlinks, conversion pages, paid campaign URLs, and executive-sensitive pages. Confirm status codes, destinations, trailing slash behavior, query parameters, and canonical output.

Second, test representative batches. Pull samples from each content type, directory, language, subdomain, and URL pattern. A migration can handle service pages correctly while breaking article pagination, case study URLs, or asset paths.

Third, check for redirect chains. An old URL should not travel through several hops before landing on the final destination. Chains slow users, waste crawl attention, and make future maintenance harder.

Fourth, test internal links on the new site. A successful migration should not rely on public users clicking old links and being redirected forever. The new site should link directly to the new canonical URLs.

The launch team should also know where redirects live. Are they in the hosting layer, framework config, CDN, CMS, edge middleware, or a redirect service? Who can change them quickly after launch? How will changes be reviewed?

These operational questions matter because redirect mistakes are often discovered under pressure.

Keep Monitoring After Launch

The first month after launch tells you whether the redirect strategy held up.

Monitor:

• 404s by frequency and source
• Redirect chains and loops
• Organic landing page changes
• Search Console indexing and coverage signals
• Crawled old URLs that did not redirect correctly
• Backlink destinations
• Paid campaign URLs
• Conversion paths and lead source attribution
• Sitemap discovery and canonical selection

Look for patterns before chasing noise. One missing redirect is a task. A whole directory producing 404s is a rule problem. A cluster of high-impression pages losing clicks may indicate weak destination matching. Stable traffic but lower leads may point to conversion or tracking issues instead of redirect logic.

Keep the redirect map alive after launch. Add fixes with dates and rationale. Do not let emergency changes become invisible. The map is not only a launch artifact. It is part of the site's technical history.

Redstone Foundry's modernization work treats redirect planning as a core migration deliverable because redirects sit at the intersection of SEO, content, analytics, and user trust. A polished new site should not ask search engines or prospects to guess where the value went.

The best redirect maps are calm, specific, and evidence-led. They respect what the old site earned, make deliberate choices about what changes, and give the new site a clean path to inherit the right signals.