Redirects and site migrations: how to move a site without losing traffic

What a redirect is and why it matters for SEO

A redirect is the server's answer “this content now lives at another address”. Instead of the page, the server returns a status code and a Location header with the new URL, and the browser or Googlebot requests that URL instead. Users never see the old address fail, and links that point to the old URL keep working.

For search, a redirect does two jobs. It moves visitors who arrive from old links, bookmarks and search results. And it tells Google which URL should now represent the content. With a permanent redirect, Google gradually replaces the old URL with the new one in its index and consolidates signals such as links on the new URL. Google is explicit that this does not cost you: “301 and other permanent redirects don't cause a loss in PageRank.”

Without a redirect, an old URL simply returns 404. Links to it stop counting for your site, visitors land on an error page, and Google has to discover the new URL on its own as if it were a brand-new page.

What Google officially says

Permanent vs temporary redirects

Google splits every redirect into one of two groups, and the group decides which URL appears in search. For permanent redirects Google says they “Show the new redirect target in search results”, and “the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.” For temporary redirects they “Show the source page in search results”, and “the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical.”

301 and 308

301 is the redirect to use for almost every permanent change: a new URL structure, a new domain, http to https, merged pages. 308 means the same thing but tells the client to repeat the request with the same method, so a POST stays a POST. For ordinary pages that are requested with GET, the two behave the same in search. Google's site-move guide names both: “we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.”

302, 303 and 307

Temporary redirects keep the old URL as the one Google shows. That is exactly what you want for a page that is down for a short maintenance window, a seasonal promotion that will end, or a test where traffic is sent to a variant for a while. 307 is the method-preserving twin of 302, and 303 is mainly used after form submissions.

A temporary redirect does not guarantee that the target stays out of the index: “The target page might still be indexed if other canonicalization signals are present.” The opposite mistake is more common. A 302 used for a move that is in fact permanent leaves Google showing the old URL. If the change is permanent, switch to 301 rather than waiting for Google to guess.

Server-side, meta refresh and JavaScript redirects

The status code is only part of the story. Where the redirect happens decides how reliably Google sees it. In order of preference: server-side, instant meta refresh, JavaScript, and a plain “we moved” link as a last fallback.

Server-side redirects

The server answers with a 3xx status before any page content is sent. Googlebot sees it on the first request, nothing needs to render, and it works for every user agent. This is the method Google asks for in migrations: use server-side permanent redirects if technically possible. On Apache, in .htaccess or the server config:

# one page
Redirect 301 /old-page/ https://example.com/new-page/
# a whole folder, keeping the rest of the path
RedirectMatch 301 ^/blog/(.*)$ https://example.com/news/$1

On nginx:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}
location ^~ /blog/ {
    rewrite ^/blog/(.*)$ https://example.com/news/$1 permanent;
}

CMS redirect plugins and CDN redirect rules are also server-side from Google's point of view, as long as the response itself carries the 3xx status.

Meta refresh and HTTP refresh

When you cannot change server responses, for example on some hosted platforms, a meta refresh in the page's <head> is the next option:

<meta http-equiv="refresh" content="0; url=https://example.com/new-page/">

The number before the URL is the delay in seconds, and it changes how Google classifies the redirect. “Google Search interprets instant meta refresh redirects as permanent redirects.” And: “Google Search interprets delayed meta refresh redirects as temporary redirects.” The same applies to the equivalent Refresh HTTP header. For a move, always use 0.

JavaScript redirects

A script such as window.location.replace("https://example.com/new-page/") only runs when the page is rendered. Google's advice is clear: “Only use JavaScript redirects if you can't do server-side or meta refresh redirects.” The reason: “if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” If you have to use one, put it early in the page and make sure the page still makes sense without it.

“We moved” links (crypto redirects)

If no real redirect is possible at all, the old page can show a short note with a link to the new location. Google calls this a crypto redirect and warns: “Don't rely on crypto redirects for letting search engines know that your content has moved”. It helps users, but treat it as a stopgap until you can set up a proper redirect.

Redirect chains and loops

A redirect chain is a series of redirects one after another: URL A redirects to B, B redirects to C. Each hop is an extra request for users and for Googlebot, and each hop is another place where something can break. Google's guidance is short: “we advise redirecting to the final destination directly.” If you cannot avoid a chain, “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.”

Chains usually build up by accident. Separate rules for the protocol, the host and the trailing slash each fire one after another, and every migration adds another layer on top of the last one.

To flatten chains:

1. Combine rules so that protocol, host and slash are fixed in one redirect to the final URL.
2. Update old redirect rules after each migration: if /a/ redirected to /b/ and /b/ now moves to /c/, change the first rule to point at /c/.
3. Fix internal links, canonicals, hreflang and sitemaps so they use final URLs and never hit a redirect at all.

A redirect loop is a chain that never ends: A redirects to B and B redirects back to A, often because two rules (for example one in the CMS and one on the server or CDN) disagree about the preferred format. Browsers stop with a “too many redirects” error, and Googlebot cannot reach any content, so the page cannot be indexed. Loops are easy to find with a crawler or by following the URL with curl -I -L, and the fix is always to remove one of the conflicting rules.

Where to redirect: relevance and soft 404s

A redirect only carries value when the target is a real replacement for the old page. Redirect each URL to its closest equivalent: the same product on the new site, the same article under its new path, the category that now holds a discontinued product's successors.

The tempting shortcut is to send everything that has no obvious match to the home page. Google warns against exactly that: “Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site.” The visitor looking for a specific page does not find it, and Google may treat the redirect as a soft 404, which means the old URL is handled like a missing page anyway.

• Equivalent page exists: 301 to it.
• Content merged into one page: 301 every old URL to the merged page. Google describes this case directly: you can redirect the older URLs to the new, consolidated page.
• Close substitute exists (a newer model, the parent category with similar items): a 301 is reasonable, as long as a visitor would see it as a good answer.
• Nothing comparable exists: let the URL return 404 or 410. For removed content Google asks that the URLs “correctly return an HTTP 404 or 410 error response code”.

How long to keep redirects

Google's minimum is a year: “Keep the redirects for as long as possible, generally at least 1 year.” In practice, keep them for as long as the old URLs still receive visits or have links pointing to them, which for an established site is usually indefinitely. Old links on other sites, in emails, in PDFs and in bookmarks do not update themselves.

Removing redirects saves almost nothing. A list of redirect rules costs the server very little, while every removed rule turns a working link into a 404. If you moved domains, also keep the old domain registered and pointing to the redirects; letting it expire throws away every link that still points there.

The Change of Address tool, covered below, works for 180 days. That is the period Google actively forwards signals, not a deadline for removing redirects.

Types of site migration

Google's site-move guidance separates moves that change URLs from moves that do not. Within the first group, the risk grows with the number of URLs that change and the number of things you change at the same time.

Domain change

Moving example.com to example.net, or a rebrand to a new name. Every URL changes host, so every URL needs a redirect to the same path (or its mapped path) on the new domain. This is the move where the Change of Address tool applies.

HTTP to HTTPS

Every URL changes protocol, but the structure stays the same, so one site-wide rule usually covers it. Update canonicals, internal links, hreflang and sitemaps to https, and do not use the Change of Address tool for it.

Subdomain or www changes

Moving www.example.com to example.com, or blog.example.com to example.com/blog/. Technically these are host changes too. A move between www and non-www is handled with redirects and canonicals alone; a move of a separate subdomain can use the Change of Address tool.

URL structure change

New paths on the same domain: /blog/ to /news/, removing .html extensions, replacing query-string URLs like ?id=123 with readable paths. Often thousands of URLs change, so the URL map is the core of the project.

CMS or platform change

A new CMS or e-commerce platform usually brings its own URL patterns, templates, pagination and internal linking. Even if you keep the URLs, compare titles, content, canonicals, structured data and internal links template by template, because a platform change can silently remove things Google relied on.

Merging sites or sections

Two sites or two blogs become one. Map each page of both sources to its best target, merge overlapping articles into one stronger page, and redirect both originals to it.

Hosting move without URL changes

A new server, host or CDN with the same URLs is the lowest-risk move, and it needs no redirects. Google has a separate guide for it: “This guide is only for migrations that don't affect the user-visible URL.” Lower the DNS TTL beforehand, and “Check that Googlebot can access your new infrastructure using the URL Inspection Tool in Search Console.” Afterwards, “it's normal to see a temporary drop in Googlebot's crawl rate immediately after the launch.” Shut the old hosting down only when it no longer receives traffic.

Whatever the type, avoid stacking changes. A new domain, a new URL structure, a new design and a new CMS on the same day make it nearly impossible to tell which change caused a drop. Google suggests splitting the move into smaller steps where that makes sense for your site.

URL mapping

The URL map is a spreadsheet with one row per old URL and the place it goes on the new site. Start by collecting every old URL that matters, from several sources, because no single one is complete:

• A full crawl of the old site.
• The old XML sitemaps.
• Search Console: pages from the Performance report and the Page indexing report.
• Analytics: landing pages that received traffic.
• A backlink tool: old URLs that other sites link to, including ones that already return 404.
• Server logs: URLs that Googlebot and users still request.

Map the pages that carry traffic or links one by one. For large groups that move in a regular way, a pattern rule is safer than thousands of hand-written lines, but check a sample of real URLs against it. Record the planned status for every row, so that a missing row is a decision and not an oversight.

Before launch, test the map on staging: run a crawler on the list of old URLs and check that every one returns 301 to a URL that returns 200, in a single hop, and that the target is the one in the sheet.

Site migration checklist

Before the move

1. Benchmark. Export clicks and impressions per page and per query from Search Console, landing-page traffic from analytics, rankings for key queries, and the number of indexed pages. You will compare against this later.
2. Crawl the old site and save the result: URLs, status codes, titles, canonicals and internal links.
3. Build and test the URL map as described above.
4. Prepare the new site on staging, protected by a password (or at least noindex) so it does not get indexed early.
5. Check the new site's robots.txt so that it blocks only what you really want blocked.
6. Update on-site references: internal links, canonicals, hreflang and structured data must use the new URLs. Google: “Change the internal links on the new site from the old URLs to the new URLs.”
7. Verify the new property in Search Console and make sure you still own the old one.
8. Prepare a new XML sitemap with the new URLs, and keep the old sitemap so Google can recrawl the old URLs and see the redirects.
9. Check capacity and tracking. Google crawls a moved site more heavily, so “Ensure that your server has enough computing resources”. Make sure analytics tags are on every new template.
10. Pick the timing. A period of lower traffic is the safest. For small and medium sites, Google recommends moving everything at once: “We recommend moving all URLs on your site simultaneously instead of moving one section at a time.” Large sites can move one section at a time.

Launch day

1. Deploy the redirects together with the new site.
2. Remove the staging blocks. “Don't forget to remove any noindex or robots.txt blocks that were only needed for the migration.” A leftover noindex is one of the most damaging launch mistakes.
3. Crawl the old URL list and confirm every row: 301, one hop, the right target, target returns 200.
4. Spot-check key pages with URL Inspection in Search Console: the live test should fetch the new page and see the content.
5. Submit the new sitemap. “Submit the new sitemap in Search Console.”
6. Submit a Change of Address if the domain or subdomain changed.
7. Update what you control outside the site: ad campaigns, email templates, social profiles, business listings, and the most valuable backlinks where you can ask the site owner.

After the move

1. Monitor Search Console daily at first: Page indexing for both properties, sitemaps, Crawl stats.
2. Find missed redirects: 404s on old URLs in logs, crawl reports and Search Console, then add rules for them.
3. Read server logs on both servers to see what Googlebot requests and what it gets back.
4. Compare traffic page by page against the benchmark, not just in total, so you notice the pages that did not transfer.
5. Keep redirects and the old domain for at least a year, and longer while they still get traffic.

The Change of Address tool

The Change of Address tool in Search Console tells Google that a whole site has moved to a new domain, so it can prioritise crawling the new site and forward signals from the old one. Google's rule for when to use it: “Use the Change of Address tool when you move your website from one domain or subdomain to another.” Submit it after the redirects are live.

Prerequisites:

• Redirects first. “Implement a 301 redirect from your old homepage to your new homepage.” All other important pages should 301 to their new equivalents as well.
• Ownership. “You must be an owner of both the old and new properties in Search Console.”
• Every variant. “The tool does not move any subdomains below the specified domain (including www).” If you had several subdomains, submit a move for each one.

Do not use it for http to https moves, www to non-www changes, path changes within the same domain, or hosting moves without URL changes. Those are handled by redirects, canonicals and sitemaps alone.

How long it lasts: “These actions continue for 180 days after you start migration in Search Console.” Keep the redirects well beyond that.

Monitoring after the move

Some turbulence is normal. Google notes that visibility may fluctuate temporarily during the move and that “a small to medium-sized website can take a few weeks for most pages to move”. Larger sites take longer. What you want to see is a clear handover: “Ideally the traffic on the old site will go down, while on the new site the traffic goes up.”

• Search Console, new property: indexed pages rising in Page indexing, the new sitemap being processed, clicks growing in Performance.
• Search Console, old property: indexed pages and clicks falling. Pages in the old sitemap reported as redirects are expected.
• Crawl stats: a high share of 301 responses on the old host, 200 responses on the new one, and no spike in server errors.
• Server logs: Googlebot requests to old URLs that return 404, and redirects that send it somewhere unexpected.
• Analytics: landing-page traffic compared with the benchmark, page by page.

If traffic is still clearly lower than before after several weeks, look for causes in this order: missing or wrong redirects, leftover noindex or robots.txt blocks, internal links and canonicals still pointing to old URLs, content or templates that lost text, and pages redirected to irrelevant targets.

Common mistakes

• ✕302 for a permanent moveGoogle keeps showing the old URL. Use 301 or 308.
• ✕Everything redirected to the home pageIrrelevant targets may be treated as soft 404s.
• ✕Chains from old migrationsEach new move adds a hop. Point every rule at the final URL.
• ✕Conflicting rules that create loopsUsually a CMS rule and a server or CDN rule that disagree.
• ✕Leftover noindex or robots.txt blockThe staging protection goes live with the new site.
• ✕Internal links still on old URLsEvery click and every crawl goes through a redirect.
• ✕No URL mapPages with traffic or links are discovered only after they return 404.
• ✕JavaScript redirects as the main methodGoogle may never see them if rendering fails.
• ✕Removing redirects or letting the old domain expireEvery old link and bookmark stops working.
• ✕Changing everything at onceNew domain, structure, design and CMS together make problems hard to trace.

FAQ

Sources

• Google Search Central — Redirects and Google Search
• Google Search Central — Site moves with URL changes
• Google Search Central — Site moves without URL changes
• Search Console Help — Change of Address tool

Quotes checked against the official pages on 30 October 2026.