Redirect Strategy for Site Migrations

A site migration rarely fails because of the new site. It fails because of the map — or the lack of one. When domains change, URL structures are rebuilt, or a site moves platform, every old address needs a deliberate new home. Get the redirect strategy right and Google transfers your visibility to the new URLs; get it wrong and your old pages quietly vanish from the index.

This guide covers the whole job: building a 1:1 URL map, choosing the right status codes, avoiding chains and loops, updating everything that points at the old URLs, rolling out safely, and monitoring until the move settles — with technical claims based on Google’s own migration guidance, linked throughout.

Key Takeaways

• Map every old URL to its single closest new equivalent before launch — never redirect everything to the homepage, which Google can treat as a soft 404.
• Use permanent server-side redirects (301 or 308). Google confirms they do not lose PageRank, and they signal that the target should become canonical.
• Keep every redirect to one hop. Googlebot can follow up to 10 hops, but chains add latency and risk.
• Update internal links, canonicals and sitemaps to the new URLs — redirects are a safety net for links you cannot control, not a substitute for fixing your own.
• Keep redirects in place for at least a year, and monitor Search Console until old-URL traffic fades.

Why Do Redirects Decide Whether a Migration Succeeds?

Redirects decide migrations because they are the only mechanism connecting an old URL’s accumulated signals — links, history, relevance — to its replacement. Without one, the old URL returns a 404 and everything it earned is stranded. With a well-matched permanent redirect, Google treats the target as the page’s new canonical home and shows it in results instead.

Google’s site move documentation is honest about the process: expect ranking fluctuations while Google recrawls and reindexes, and for a medium-sized site it can take a few weeks or more before new URLs replace old ones in results; larger sites take longer. That is processing time, not a penalty, and it varies with URL volume and server speed. A careful plan keeps the wobble temporary.

One discipline matters above the rest: change one thing at a time. Google advises sequencing big changes — domain first, then CMS, then design — rather than stacking them into one launch, when you cannot tell which change caused a drop.

How Do You Build a 1:1 URL Map?

You build the map by inventorying every old URL, then pairing each with the single new URL that serves the same intent. Draw the inventory from several sources so nothing is missed: XML sitemaps, a full crawl, Search Console’s pages and links reports, analytics top pages, and server logs. Include images and PDFs — they earn links and traffic too.

Then decide each page’s fate:

• Same content, new address: pair it directly. /blog/seo-guide becomes /guides/seo-guide — one row, one redirect.
• Merged content: if two old pages become one, redirect both to the combined page.
• Genuinely retired content: if a page has no equivalent, let it return a proper 404 or 410 on the new site — Google’s guidance explicitly supports errors for content that is not moving.
• Never bulk-redirect to the homepage. Google may treat hundreds of unrelated URLs sent to one page as soft 404s, discarding the signals you were trying to save.

Record the map in a spreadsheet — old URL, new URL, status code per row — as the single source of truth for implementation and testing. If your site earns visibility in AI answers, protect it the same way: stable, well-mapped URLs are what let citations follow you, as we covered in our guide to tracking AI Overviews citations.

Which Redirect Status Code Should You Use — 301, 308, 302 or 307?

Use 301 or 308 for anything that has permanently moved — in a migration, almost everything. As Google’s redirects documentation explains, for permanent redirects the indexing pipeline treats the target as canonical and shows it in search results. The difference between them is technical, not strategic: 308 preserves the request method (a POST stays a POST), while 301 historically allows a POST to become a GET. For ordinary page moves, either works.

Reserve the other codes for their proper jobs:

• 302 (Found) and 307 (Temporary Redirect) say the move is not permanent. Google follows them but does not treat the target as canonical, so the old URL stays in search results. Using a 302 for a permanent migration is one of the most damaging mistakes you can make — you are telling Google the old site is coming back. (307 preserves the request method; 302 does not guarantee it.)
• 410 (Gone) suits content deliberately removed with no successor; it is typically processed faster than a 404.
• 404 (Not Found) is correct for URLs that never existed, or retired content where 410 is impractical.

Two reassurances from Google are worth internalising. First, permanent redirects do not cost link equity: Google states plainly that 301 and other permanent redirects “don’t cause a loss in PageRank.” Second, implement redirects server-side wherever possible — server configuration, .htaccess, or your CMS redirect manager — because server-side redirects are the type Google interprets most reliably.

How Do You Avoid Redirect Chains and Loops?

You avoid chains by pointing every redirect directly at the final live URL — one hop, never a sequence. A chain (A → B → C) forms when a new migration is layered over redirects from a previous redesign. Googlebot can follow up to 10 hops, but Google advises redirecting to the final destination directly and keeping unavoidable chains under three to five hops: each hop adds latency, and some crawlers abandon long chains.

Loops are worse — A redirects to B and B back to A, so browsers error out and crawlers get nothing. They usually come from conflicting rules, such as a wildcard fighting a specific rule. Safeguards:

• Flatten before launch. Run the map through a crawler or redirect checker and rewrite any row whose target itself redirects — the map should contain only final destinations.
• Test for loops explicitly. Crawl the old URL list and flag anything that does not resolve to a 200 in a single hop.
• Order rules carefully. One broad wildcard can override dozens of specific rules. Order from most specific to most general.
• Re-check after launch. Chains creep back when someone adds “one quick redirect” months later. A periodic crawl keeps the map honest — the same auditing habit we recommend for internal linking tools and workflows.

What Else Must Change Besides the Redirects Themselves?

Your internal links, canonical tags, hreflang annotations and sitemaps must all point at the new URLs from day one. Google’s migration guide treats this as a core step, not a tidy-up: internal links go straight to the new addresses, each new page carries a self-referencing canonical, and you submit a fresh sitemap of new URLs only. Redirects are the safety net for links you do not control — bookmarks, other people’s articles. Every internal click travelling through a redirect wastes crawl effort for no benefit.

Work through these updates as part of the launch:

• Internal links: find-and-replace old URLs across content, navigation and footers, using your map as the reference.
• Canonicals and hreflang: annotations referencing old URLs send Google contradictory signals. Update them all.
• Sitemaps: generate a new sitemap of live new URLs and submit it. Keep the old sitemap available during the transition — Google suggests submitting both so you can watch indexed counts cross over.
• Robots and noindex: staging blocks must come off at launch; a leftover noindex is among the most common migration disasters in Google’s own troubleshooting list.
• External touchpoints: update social profiles, ad campaigns, email signatures and business listings, and ask your most valuable linking sites to update theirs.
• Search Console settings: verify old and new properties (all variants); re-upload any disavow file under the new property.

Do You Need the Change of Address Tool?

Only if the domain or subdomain itself changes. The Change of Address tool in Search Console tells Google a site has moved between domains or subdomains — example.com to example.net, say. Google is explicit about what it does not cover: HTTP-to-HTTPS moves, switching between www and non-www on the same domain, or moving paths within a domain.

You must be a verified owner of both properties, with the 301 redirects already in place before you submit. The tool supplements redirects; it never replaces them. And once the move is underway, Search Console is also where you will watch AI-era visibility settle, as our guide to Search Console for AI search explains.

Should You Migrate Everything at Once or in Stages?

It depends on site size. For small and medium sites, Google recommends moving everything simultaneously: users get a consistent site, and Google’s systems detect the move and update the index faster. For large sites, moving one section at a time is legitimate — it contains the blast radius, so a problem means fixing one section, not the whole domain.

If you stage it, choose a test section that changes infrequently and is not driven by seasonal traffic, so results reflect the migration rather than the market — and note Google’s caveat that a smooth small test does not guarantee the full move behaves identically. Either way, time the launch for a natural traffic dip if you can: fewer users are affected, and more server capacity is free for the heavy crawling that follows.

What Should You Check Before Launch? A Pre-Migration Checklist

Run through this list before a single redirect goes live:

• Old-URL inventory compiled from sitemaps, a crawl, Search Console, analytics and server logs — including images and PDFs
• 1:1 URL map completed: every old URL has a destination, a merge target, or an explicit 404/410 decision
• No catch-all redirects to the homepage; no target irrelevant to its source page
• All redirects server-side and permanent (301/308) — no temporary codes on permanent moves
• Every redirect resolves in one hop; no chains or loops, verified with a crawler
• New site tested end-to-end on staging; staging’s robots/noindex blocks scheduled for removal at launch
• Internal links, canonicals and hreflang updated to new URLs site-wide
• New XML sitemap generated with new URLs only; old sitemap saved for transition monitoring
• Old and new sites verified in Search Console (all variants); disavow file ready to carry over
• Baseline recorded — rankings, traffic and indexed counts — so changes are measurable
• Server capacity checked; expect heavier-than-usual Googlebot crawling after launch
• Change of Address prepared if, and only if, the domain or subdomain is changing
• Rollback plan agreed: how redirects and DNS changes get reverted if launch goes wrong

How Do You Monitor a Migration After Launch?

Monitor on three fronts — Search Console, server logs and analytics — from day one until old-site traffic fades to a trickle. In Search Console, submit both sitemaps and watch the crossover: the old sitemap’s indexed count should fall towards zero while the new one climbs. Use the Page Indexing report to catch crawl errors, the URL Inspection tool to spot-check key redirects, and the Performance report to confirm new URLs are earning the impressions the old ones did.

In logs and analytics, look for:

• 404 spikes: old URLs returning errors instead of redirecting mean gaps in the map. Add the redirect and find where the traffic comes from.
• Wrong targets: Google’s troubleshooting notes flag redirects pointing at non-existent or incorrect new URLs as a frequent failure, usually visible as a surge in “Not found” errors.
• Stubborn old-URL traffic: persistent hits on one old URL usually mean an important external link or internal system still points there. Update it at the source where you can.
• Direction, not noise: rankings will fluctuate. Judge by movement over weeks, not day-to-day swings.

Keep the redirects in place for at least a year — Google recommends this so signals, including links from other sites, fully transfer — and ideally indefinitely. Keep recovery expectations humble: Google offers no fixed timeline. If traffic has not substantially recovered once the crossover completes, the cause is usually a specific defect — a chain, a missing section, a leftover noindex — not the calendar. Go back to the diagnostics rather than waiting.

Frequently Asked Questions

Do 301 redirects lose PageRank or ranking power?

No. Google confirms that 301 and other permanent redirects do not cause a loss in PageRank; the old “a 301 loses 15%” claim is a persistent myth. What costs you is a badly matched target — redirecting to an irrelevant page can be treated as a soft 404, discarding the signal.

How long should redirects stay in place after a migration?

At least a year, per Google’s guidance, and ideally indefinitely. The year gives Google time to recrawl and reassign links pointing at your old URLs — and bookmarks and citations will keep arriving at the old addresses for far longer.

Should I redirect removed pages to the homepage?

No. Redirecting unrelated pages to the homepage is treated by Google as a soft 404 in many cases: no signal transfer, and a confusing landing for the visitor. Redirect to the closest equivalent page, or return an honest 404 or 410 if nothing fits.

What is the difference between 301 and 308?

Both are permanent, and Google treats them the same way for search — the target becomes canonical. The difference is the request method: 308 guarantees the method and body are preserved (a POST stays a POST), while 301 permits browsers to change a POST to GET. For standard migrations either works; 308 is stricter for forms and APIs.

The Bottom Line

A migration succeeds or fails on the quality of its redirect map. Build the map before anything else, pair every old URL with its closest living equivalent, implement permanent server-side redirects in a single hop, and update your own links and sitemaps so nothing important depends on a redirect at all. Then keep the redirects up for at least a year and watch Search Console until the crossover completes — and the move becomes what it should be: a change of address, not a loss of identity.