URL Inventory and Redirect Mapping for SaaS Migrations

A redirect map is a file with two columns and a disposition for every row. A redirect map fails when the inventory is incomplete, or when approved mappings are implemented incorrectly. The first task is therefore to prove which public URLs exist and whether they will remain stable - rather than assuming the platform change leaves them untouched.

This page covers phase 2: building the inventory, deciding dispositions, handling parameters, implementing and testing redirects, and - for domain moves specifically - the Search Console procedure that goes with them. If your URLs are genuinely not changing, you can skip to rendering and indexability. Confirm that claim against the inventory before you act on it.

Step 1: Build the Inventory

No single source is complete. A crawl only finds what is linked. Sitemaps only contain what the CMS decided to include. Analytics only shows what got traffic. Combine all of them, then deduplicate.

Normalize to Group, Never to Delete

Decide and record a grouping rule for each of these:

• Case. Google is explicit that this matters: Google Search's URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content). If your old platform was case-insensitive and your new one is not, that difference is a migration issue in its own right.
• Trailing slash. /pricing and /pricing/ are different URLs to a server. Pick one form, redirect the other, and check which form your existing internal links and backlinks actually use.
• Protocol and host. http versus https, www versus non-www. Every combination that resolves is a URL in your inventory.
• Encoding. Google's guidance is to use percent encoding "in your links's href attributes as necessary" and that "characters in the non-ASCII range should be percent encoded." A map that mixes encoded and unencoded forms of the same path will produce duplicate or missing rules.
• Parameters. Order, casing and presence of tracking parameters all create distinct strings. See step 4 for what to do with them.
• Fragments. Everything after a # never reaches the server - it is resolved in the browser - so fragments do not become redirect-map rows. Google's position is separate and also worth knowing: Don't use fragments to change the content of a page, as Google Search generally doesn't support URL fragments. If your old site used hash routing to serve distinct content, that is not a mapping problem, it is a rendering and URL-design problem, and it needs handling in its own right.

Deliverable and pass rule: one file, under version control, holding every raw URL observed, its grouping key, the equivalence rule behind any merge, and a recorded count. If someone asks "how many URLs are we migrating," there is one number and one file it came from.

Step 2: Give Every URL a Disposition

Six outcomes. Every row gets exactly one, and the disposition is what the acceptance test in step 10 validates against - so this column is not documentation, it is the specification.

Rule-handled does not mean absent from the inventory. Every observed raw URL remains an individual row. Rows governed by the same rule may share a rule_id, but each stays independently testable - otherwise a rule with an edge case fails silently on the URLs it was supposed to cover.

"Already redirecting" is a current-state flag, not a disposition. Assign one of the six above to the URL, and let that decide what happens to the existing redirect:

• Mapped or consolidated - repoint so the URL redirects directly to its final destination rather than through the old hop.
• Retired or no equivalent - remove the existing redirect and return 404/410.
• Unchanged - the URL should resolve directly, with no redirect at all.

The common error is assuming a currently-redirecting URL must keep redirecting somewhere. It is exactly as eligible for retirement as any other row.

Google's site-move guidance covers the second and third under the heading "Provide errors for deleted or merged content": if you're not moving to the new site all your old content, make sure those URLs correctly return an HTTP 404 or 410 error response code on the new site.

Step 3: Map to the Closest Equivalent; Document Genuine Consolidation

"Closest equivalent" means the page that answers the same question for the same reader. Not the nearest category, not the parent section, not a page with a similar title.

One-to-one is the safest default, but it is not a rule, and Google says so explicitly: However, if you have consolidated content previously hosted on multiple pages to a new single page, you can redirect the older URLs to that new, consolidated page. That matters for SaaS replatforms in particular, where overlapping feature, solution, integration and documentation pages are routinely merged. Returning 404 for those rows throws away a real successor.

The line is whether the destination genuinely replaces the source:

• Legitimate consolidation. Two or more old URLs redirect to one new page that materially contains or replaces their content. Record the consolidation group, and check relevance by hand rather than by rule - this is the disposition most likely to be applied too generously under deadline pressure.
• Not legitimate. A many-to-one redirect where the destination is merely broad or convenient. The homepage is the obvious case; a general features page standing in for a decommissioned product is the same mistake at smaller scale if that page does not actually replace the product content. If it does, it is consolidation and it is fine.
• No equivalent and no consolidated successor - the disposition is 404/410, not a redirect to something adjacent.
• Record the decision, not just the destination. A column saying "consolidated into X with Y and Z, relevance confirmed by [name]" is what lets you answer questions after launch without re-deriving the reasoning.

Step 4: Decide What Happens to Parameterized URLs

Parameters are where redirect maps get enormous for no benefit. The question is not "how do I redirect these" but "which of these should exist as crawlable URLs at all."

Google's URL-structure guidance names the patterns that cause problems: additive filtering that creates rapidly multiplying URL combinations; irrelevant parameters such as referral tracking, shopping sorts and session IDs; calendar links that generate effectively infinite date URLs with no start or end restriction; and broken relative links that create bogus URLs when a server returns the wrong HTTP status. Any of these in your inventory is a candidate for elimination during the migration rather than replication.

The Practical Sort

1. Parameters that change content meaningfully and have traffic, links or indexed status - treat as real URLs and map them.
2. Parameters that change presentation only - sorts, view modes, pagination display - usually do not need individual redirects. Decide how the new site handles them and make sure the handling is consistent.
3. Tracking and session parameters - should not be generating indexable URLs on either side. If they are, the migration is a good moment to stop that.
4. Faceted combinations - the explosive case. Decide the crawlable set deliberately.

For that last group, Google documents three levers and each has a caveat worth knowing before you pick:

• Using rel="canonical" to specify which URL is the canonical version of a faceted navigation URL may, over time, decrease the crawl volume of non-canonical versions of those URLs. Note "may" and "over time" - this is not an immediate control.
• Use robots.txt to disallow crawling of faceted navigation URLs. Oftentimes there's no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit.
• Using rel="nofollow" attributes on anchors pointing to filtered results pages may be beneficial, however keep in mind that every anchor pointing to a specific URL must have the rel="nofollow" attribute in order for it to be effective. That last clause is the one that trips teams up - a single un-attributed link elsewhere on the site undoes it.

Pass rule: every parameter pattern in the inventory has a named disposition - mapped, handled by rule, or deliberately made non-crawlable - and nothing is left to "whatever the new platform does by default."

Step 5: Implement

Which Redirect

Google's site-move guidance: Although Googlebot supports several kinds of redirects, we recommend that you use HTTP permanent redirects if possible, such as 301 and 308. Its redirect documentation orders methods by how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance of being interpreted correctly by Google).

Chains

Ten is a technical ceiling, not a target. Google's site-move guidance gives both the capability and the recommendation, and the second half is the part that gets dropped in summaries:

While Googlebot can follow up to 10 hops in a "chain" of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5. Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.

So: redirect old URLs straight to the final destination. Where a chain genuinely cannot be avoided - a legacy rule you do not control, an edge redirect ahead of an origin redirect - aim for no more than three hops, and require fewer than five. Google's status-code documentation adds that specific products' crawlers may have different limits, which is a statement that limits vary, not that ten is the most generous of them. Do not assume Googlebot's ceiling applies to other crawlers, browsers or user agents. Note too that Google's stated reasons here are user latency and user-agent support, not a ranking effect.

Any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead. So an intermediate hop that returns a useful page is still invisible; the chain is not a way to keep anything alive.

Loops

A loop is a rule set where A points to B and B points back to A, usually created by combining a trailing-slash rule, a protocol rule and a path rule that each look correct alone. Google does not document loop behavior specifically, so treat this as engineering hygiene rather than a documented search rule: a loop is a broken page for users and a request that terminates without content for anything else. Catch them by testing the rule set as a set, not rule by rule (step 10).

Redirect Equity, and a Piece of Folklore to Retire

The claim that a 301 costs you a percentage of link equity has no current support. Google's site-move guidance states it directly, under the heading "Don't worry about link credit": 301 and other permanent redirects don't cause a loss in PageRank.

That is Google describing its own systems, and PageRank is not externally observable, so nobody outside Google has measured it either way. But it is a first-party statement in current documentation, which is a stronger basis than the collection of conference remarks the claim is usually argued over.

Step 6: Canonicals

Google describes its canonicalization inputs and their relative weight plainly: a redirect is A strong signal that the target of the redirect should become canonical; a rel="canonical" annotation is A strong signal that the specified URL should become canonical; sitemap inclusion is A weak signal that helps the URLs that are included in a sitemap become canonical. None is a directive - Google notes that none of them are required; your site will likely do just fine without specifying a canonical preference.

The migration-specific risk is contradiction, and Google names it: Don't specify different URLs as canonical for the same page using different canonicalization techniques (for example, don't specify one URL in a sitemap, but a different URL for that same page using rel="canonical").

Pass rule, scoped to destinations you intend to index: for each mapped or consolidated destination, confirm that the redirect ends on the final URL, the page self-canonicalizes to that URL, internal links use it, and - if the URL is included in the new sitemap - the sitemap uses the same form. Check it as one comparison, not four separate ones.

Two exclusions, because the rule is otherwise wrong. Sitemap inclusion is optional and a page is not defective for being absent from one, so "missing from the sitemap" is not a failure. And the old-URL sitemap described in step 7 deliberately contains redirecting legacy URLs for the duration of the observation window - that is a migration exception, not a contradiction to fix. Keep retired URLs and non-canonical variants out of the new sitemap entirely.

Step 7: Internal Links, Sitemaps and On-Site References

Redirects are a safety net for external requests. They are not how your own site should link to itself. Google: Change the internal links on the new site from the old URLs to the new URLs, and Immediately after the site move is started, try to update as many links as possible to improve the user experience and reduce your server load.

Internal references live in more places than the navigation: body-copy links, hard-coded CTAs, canonical tags, hreflang annotations, structured-data URL properties, image and asset paths, email templates, in-app links, and any documentation that points at the marketing site. The crawl comparison in staging QA catches the first few; the rest need a code search.

Step 8: Hreflang, if the Site Is International

Hreflang breaks silently when URLs change, because the annotations are a graph and moving one node invalidates every edge pointing at it. Google's requirement is reciprocity: If two pages don't both point to each other, the tags will be ignored. And self-reference: Each language version must list itself as well as all other language versions. The x-default value is used when no other language/region matches the user's browser setting.

Google documents three delivery methods - HTML, HTTP Headers, Sitemap - and the migration question is which one your new platform uses, because teams frequently change method without noticing that the old method is still emitting annotations too.

Update every annotation to the final, canonical, directly reachable locale URL in the same release. Pointing an annotation at a URL that then redirects adds a hop to a reciprocity graph that has to resolve in both directions - the localized-versions page does not address that case, so treat this as an engineering conclusion from the reciprocity rule rather than a quoted instruction.

And do not let locale redirects do the routing. This one Google does address, in its multi-regional guidance: Avoid automatically redirecting users from one language version of a site to a different language version of a site. For example, don't redirect based on what you think the user's language may be. The stated consequence: These redirections could prevent users (and search engines) from viewing all the versions of your site. Google's recommendation is separate URLs per version - Google recommends using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page.

Migrations are where this breaks, because a new platform often introduces locale detection that the old one did not have. Test each locale URL three ways: with no cookies and no Accept-Language header, with the header set to a non-matching language, and along the path a real user from that locale would take. If the first two do not return that locale's page at that URL, the annotations are pointing at something a crawler cannot reach.

Step 9: Backlinked Legacy URLs

These are the highest-value rows in the map, because they are the ones where a redirect error costs something you cannot rebuild. Sort the inventory by referring domains and treat the top of that list as a separate, manually checked set.

Redirects carry the requests, but Google's own guidance is to also pursue the links themselves: Try to contact the sites in the saved list of sites linking to your current content, asking them to update their links to your new site. Realistically you will get a fraction of them updated - prioritize by referring-domain value and by how likely the publisher is to still be reachable.

Pass rule: every URL in the top-200-by-referring-domains set has a manually confirmed disposition, and is tested against that disposition. Mapped or consolidated URLs redirect directly to an approved 200 destination; unchanged URLs return 200 with no redirect; retired or no-equivalent URLs return 404/410 with no redirect. A heavily linked URL is not automatically a mapped one - some of them are legitimately retired, and forcing a destination onto those rows is how the homepage-redirect mistake gets in through the back door.

Step 10: Test the Map

Google names the two approaches: You can use the URL Inspection Tool for testing individual URLs, or command line tools or scripts to test large numbers of URLs. For a migration you need both - the script for coverage, the URL Inspection Tool for the pages you cannot afford to be wrong about.

Test against each row's disposition, not against a universal expectation. A test that requires every row to end in a 200 will fail your approved removals and push the team to invent irrelevant redirect targets to make the report green.

A mapped row has two statuses that both matter - the redirect it issues and the status of what it lands on - so a single expected-status column cannot express it. Carry four columns:

Validate per disposition:

Fail any row whose observed outcome differs from its approved disposition - in either direction. A retired URL that redirects is as much a defect as a mapped URL that 404s.

For each tested URL, record four things rather than a bare pass/fail:

1. Initial status - does it match expected_initial_status?
2. Hop count and the full chain - not just the endpoint. Against expected_max_hops: treat four hops as a warning that needs written justification, and five or more as a failure.
3. Final destination - is it expected_final_url, character for character, including trailing slash and case?
4. Final status - does it match expected_final_status? For mapped and consolidated rows specifically, confirm the 200 is real and not a soft 404 rendering a "not found" message with a 200 header.

Step 11: Sites With Tens of Thousands of URLs

Google gives a size-dependent recommendation that is easy to miss and directly relevant here. Under the label "Small or medium sites": We recommend moving all URLs on your site simultaneously instead of moving one section at a time. Under "Large sites": You can choose to move larger sites one section at a time.

That is a genuine decision point, not a formality. Phasing a small site adds coordination risk for no benefit; phasing a large one lets you observe the first section's behavior before committing the rest. Google does not define the size boundary, so make the call on your own operational grounds - how much of the map you can meaningfully test in one window, and whether you can hold a rollback decision open across multiple releases - and record the reasoning.

Working at Scale Without Hand-Mapping Every Row

• Pattern rules first, exceptions second. Most of a large map is a handful of path transformations. Write those as rules, then hand-map only what the rules cannot express.
• Test the rules against the inventory, not against examples. Generate the full predicted output and diff it against the intended destinations. A rule that works on the five URLs you tried is not a tested rule.
• Sample the rule output deliberately. Every template, every path depth, every parameter pattern, plus the top URLs by traffic and by links - rather than a random percentage.
• State your coverage. "We tested 4,000 of 62,000 URLs, selected as follows" is auditable. "We spot-checked the redirects" is not.
• Keep the map as data. A spreadsheet a person edits by hand is a source of errors at this scale; the map should be generated, versioned and diffable.

Step 12: Domain and Subdomain Moves - the Search Console Procedure

Everything above applies to any URL change. This section applies only when the hostname changes.

When the Change of Address Tool Applies

Google: Use the Change of Address tool when you move your website from one domain or subdomain to another: for instance, from example.com to example.org or example2.com. Its documented exclusions are moving from http to https, Moving some pages from one location to another within your site, Moving between www and non-www in the same domain, and Moving a site without any user-visible URL changes.

Prerequisites: You must be an owner of both the old and new properties in Search Console, and The Change of Address tool can be used only on properties at the domain level - You cannot move properties at the path level.

What the Tool Does, and for How Long

When you file a change of address request using Search Console, it tells Google to emphasize crawling and indexing your new site over crawling your old site. It also forwards various signals from the old site to the new site, and tells Google to prefer the new site over the old when determining canonical pages. These actions continue for 180 days after you start migration in Search Console.

And when the window closes: After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site, if still present and crawlable.

Merges - and Google's Caution About Doing Them All at Once

Google's list of URL-changing moves includes merging multiple domains or hostnames. The tool operates per property pair and requires ownership of both, so a merge means filing a request for each old domain - and, following the subdomain-variant rule above, for each of its variants.

The sequencing matters more than the filing, and Google is explicit: Try not to combine multiple moves to a single location. Moving sites A, B, and C all to new location D can cause some confusion and traffic loss. Its suggested approach: You might want to move sites one at a time to the new, combined location and wait till traffic stabilizes before moving the next site.

Note Google's own hedging - "try not to" and "you might want to", not a prohibition. Stage the source domains one at a time where it is practical, waiting for traffic to stabilize before starting the next. Where operational constraints genuinely require simultaneous moves, document the additional confusion and traffic-loss risk explicitly rather than absorbing it silently. Either way: record the order, keep each source domain's redirect set and monitoring separate, and define what "stabilized" means before you start - otherwise the wait becomes indefinite and the second move never gets scheduled.

Step 13: How Long the Redirects Live

This is one of the few genuinely settled points in migration guidance. Google's documentation: Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs. It adds: From users' perspective, consider keeping redirects indefinitely.

The same figure has come from Google's Search Relations team repeatedly. Mueller in March 2022: I would recommend keeping the old domain name for longer, and definitely keeping the redirects in place for at least a year. 3 months is too short for a site-move.

What has to survive that year is the redirects, not the old application. Budget for the old domain's registration, its DNS, a TLS certificate where the old URLs were served over HTTPS, and enough infrastructure to serve the redirect rules - which can be a CDN, an edge worker or a minimal redirect service rather than the legacy stack. Once nothing depends on the old application's own content or logic, it can be retired. This is a line item that gets cut precisely because nothing visibly depends on it, so name it in the budget explicitly.

What Comes Next

The map is an input to three later phases. Staging QA tests it against the built site before launch. The launch-day sequence activates it and verifies the top URLs immediately. And if something goes wrong afterward, redirect failures are the first branch in diagnosing migration traffic drops.

Sources

Sources: Google Search Central, Site moves with URL changes (page currently carries a "Last updated 2026-08-20" stamp, though Google's documentation-updates log has no matching August 2026 entry - cited for its current wording, not a confirmed change date) - the recommendation to use 301 or 308; the redirect-chain passage including the ten-hop capability and the three-and-under-five recommendation; the statement that permanent redirects don't cause a loss in PageRank; the permission to redirect older URLs to a consolidated page; the homepage-redirect warning and its soft-404 clause; the 404/410 instruction for content not being moved; internal-link updating; the two-sitemap monitoring method and the old-sitemap cleanup step; redirect testing tools; the small/medium versus large phasing recommendation; contacting linking sites; and redirect retention. Google Search Central, HTTP status codes, network and DNS errors - signal strength for 301, 302, 307 and 308; the ten-hop default and the products caveat; content from the redirecting URL being ignored; identical treatment of 4xx errors other than 429. Google Search Central, Redirects and Google Search - redirect methods ordered by how reliably Google can interpret them. Google Search Central, How to specify a canonical URL - the relative strength of redirects, rel="canonical" and sitemap inclusion, and the warning against contradictory canonicalization signals. Google Search Central, Keep a simple URL structure - URL case sensitivity, percent encoding, and the patterns of parameterized URLs that cause crawling problems. Google Search Central, Faceted navigation best practices - canonical, robots.txt and nofollow options for filtered URLs, with their stated caveats. Google Search Central, Localized versions of your pages - the three annotation methods, the reciprocity requirement, self-reference, and x-default; and Managing multi-regional and multilingual sites - the warning against automatic language-based redirects and the recommendation to use different URLs per language version. Google Search Console Help, Sitemaps report - that a URL discovered in a sitemap carries no guarantee of crawling or indexing, and that the Page Indexing report can be filtered by sitemap to read indexed counts. Reviewed 27 August 2026; no publication date shown. Google Search Central, Search documentation updates - the 17 June 2026 entry adding subdomain-variant guidance to the site move guide. Google Search Console Help, Change of Address tool - scope and exclusions, prerequisites, the subdomain-variant instruction, the multi-domain-merge sequencing guidance, the 180-day window and what follows it, and redirect maintenance. Reviewed 27 August 2026; the page carries no publication date. Google Search Console Help, Page Indexing report - the soft 404 definition. Reviewed 27 August 2026; no publication date shown. John Mueller on redirect-chain auditing, Reddit, February 2026, as reported by Search Engine Roundtable; on redirect hops, Reddit, January 2020, as reported by Search Engine Journal; on redirect retention, X, March 2022, as reported by Search Engine Roundtable. Gary Illyes on the users-but-not-Googlebot redirect, Search Off the Record, episode 56, Google Search Relations, 23 February 2023, checked directly against the episode transcript.

---