Site Migrations

TL;DR — A site migration is any big change to your website that could move your URLs or change how Google reads them — a new domain, a switch to HTTPS, a new platform, a folder reshuffle, even a redesign. The way you protect your traffic is the same every time: send each old page to its closest matching new page with a 301 redirect, and keep those redirects in place for a long time. A temporary dip in traffic is normal; if it never recovers, something broke.

What a site migration is

“Migration” sounds dramatic, and sometimes it is. But it just means a significant change to your site that could affect how search engines find, read, and rank your pages. Moving to a new domain is a migration. Switching from http:// to https:// is a migration. Moving your blog from blog.example.com to example.com/blog/ is a migration. Even a redesign that keeps every URL the same counts, because the content and templates that Google ranks are changing.

The reason they’re grouped together is that they share the same risk and the same playbook.

The one rule that matters most

When a URL changes, you have to tell browsers and search engines where the page went. You do that with a redirect — specifically a 301 (permanent) redirect, which says “this page moved here for good.” The redirects are what actually carry your rankings from the old URLs to the new ones. Google says 301 and other permanent redirects do not cause a loss in PageRank.

The most important part: map each old page to the single most relevant new page. Don’t dump everything onto the homepage. If an old product page has no real match, send it to the closest category, not the front door. Google treats a pile of old pages all redirected to the homepage as if they were 404 “page not found” errors anyway, so there’s no benefit.

Things people get wrong

• “Redirects lose my link credit.” They don’t. Permanent redirects don’t cost you PageRank. This myth has been dead for years.
• “The Change of Address tool moves my site for me.” It doesn’t. That Google Search Console tool just tells Google you moved to a new domain — the redirects do the real work. And it only works for whole-domain moves, not for switching to HTTPS or reshuffling folders.
• “My traffic dropped, the migration failed.” Usually not. A temporary wobble while Google re-figures everything out is normal. Give it a few weeks. Evidence for this claim Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Scope: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• “I can take the redirects down after a few months.” Keep them far longer — ideally for years, effectively forever where you can.

Change one thing at a time

The biggest risk in any migration is changing too many things at once. A new domain and a new platform and a new URL structure all on the same day is three migrations stacked together, and the risks multiply. If you can split a big change into stages, do it.

Want the full process — the seven phases, redirect strategy, and a tailored checklist for each migration type? Switch to the Advanced tab.

TL;DR — Risk in a migration is amount of change × how much you do at once. 301/308 redirects are the spine — they carry rankings and don’t lose PageRank; everything else (Change of Address tool, sitemaps, internal links, canonicals) is a supporting signal. Map old→new 1:1, never bulk-redirect to the homepage (soft 404), avoid chains, and keep redirects far longer than the “12 months” line. Expect a temporary fluctuation and a recovery; a permanent drop means something broke — usually a staging block left live, a removed hreflang/canonical, a stray noindex, or redirects to the wrong pages. Below: the universal 7-phase process, then each of the 7 migration types with its own gotchas.

This hub owns the classification, principles, risk model, migration-type decisions, and recovery diagnosis. Use the Website Migration Checklist for the executable task sequence, named owners, release gates, and acceptance criteria.

What a migration actually is (and the 7 types)

A site migration is any significant change to a website’s URL structure, domain, platform, protocol, or hosting that has the potential to affect how search engines crawl, index, and rank it. The label spans everything from a one-line HTTPS flip to a full rebrand moving hundreds of thousands of URLs onto a new domain across a new CMS.

The most useful thing you can do before writing a single redirect is classify the migration — and recognize that most real-world migrations are several types at once. Here are the seven types, roughly ordered by risk:

The numbers are the section order in the type-by-type breakdown further down; the table is sorted by risk so you can see where yours lands. Risk = how much you change × how much you change at once. A redesign on the same URLs is low risk. A simultaneous domain change + URL restructure + replatform is three high-risk types compounding — Google’s own advice is to change one thing at a time.

The universal migration process

This process applies to every migration type before you layer on the type-specific steps below. I’ve run a lot of these, and the through-line of every successful one is the same: a migration takes more than a checklist to be successful. A checklist keeps you from forgetting steps; process and SEO involvement at every stage is what actually makes it land.

Phase 1 — Planning

• Classify every type in play. A replatform that also restructures URLs and moves to a new domain is three migrations at once. Name them all up front so you can scope the real risk.
• Set expectations with leadership before launch, not after. Traffic will almost certainly fluctuate. Brief stakeholders that a temporary dip is normal and expected — so a routine wobble doesn’t trigger a panic rollback.
• Always have a rollback plan. You should always have a way to get back to the original state, even if you only ever plan to use it in extreme situations.
• Time the launch for low traffic. Google itself recommends timing your move to coincide with lower traffic if possible. In practice: Monday–Thursday, not Fridays, not peak sales season — so you have staff around to fix problems and less revenue at risk while it stabilizes.
• Assign an SEO project manager and use a project management system. Migrations span dev, content, analytics, and SEO; somebody has to own the dependency map.

Phase 2 — Benchmark and crawl the old site

You can’t QA a migration without a “before” picture. Capture it while the old site is still live:

• Full crawl of the old site (Screaming Frog, Ahrefs Site Audit, or equivalent). Save it. This is your baseline diff after launch.
• Capture everything per URL: status codes, titles, meta descriptions, canonical tags, hreflang, heading structure, internal link structure, and Core Web Vitals.
• Snapshot rankings for all key pages before launch.
• Export traffic benchmarks — Search Console performance data (last 3/6/12 months) and GA4 at the page/session level.
• Export top pages by backlinks (Ahrefs + the GSC Links report). These are the URLs that absolutely must redirect correctly — they’re carrying your link equity.
• Compile every existing redirect from every source: the CMS, the CDN, the .htaccess/server config, Search Console’s Page with redirect report, and analytics. Miss one source and you create redirect chains after launch.
• Audit for legacy issues before you carry them over. A new domain or CMS is not an excuse to import old canonical errors, index bloat, or crawl blocks.

Phase 3 — URL mapping

Build a one-to-one spreadsheet: every old URL → its single most relevant new URL. No exceptions — every URL maps somewhere.

• Removed pages with a close match: redirect to the closest topically relevant live page. Google is explicit: don’t redirect many old URLs to one irrelevant single destination such as the home page. Evidence for this claim Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. Scope: Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• Pages with no equivalent at all: return a proper 410 (gone) or 404. Do not redirect them to the homepage — that’s treated as a soft 404.
• Tracking the individual URLs is the most important part, so you have a clear map of what each URL was and what it should become. This map is the migration.

Phase 4 — Redirect strategy

This is the spine of the whole project.

• Use 301 (Moved Permanently) or 308 for permanent moves. Google recommends server-side permanent redirects such as 301 and 308.
• 301s pass PageRank — full stop. Google’s docs say permanent redirects don’t cause a loss in PageRank, and Gary Illyes confirmed years ago that 30x redirects don’t lose PageRank anymore. Any guide telling you permanent redirects leak link equity is out of date. Evidence for this claim Google says 301 and other permanent redirects do not cause a loss in PageRank. Scope: Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes
• Avoid redirect chains. Map old → new directly. Google says keep chains short — ideally no more than 3 and fewer than 5. Googlebot will follow up to about 10 hops, so short chains aren’t fatal, but every hop is a chance to break and a delay in consolidating signals. A common silent source of chains is trailing-slash inconsistency (/page vs /page/) — pick one canonical form and redirect the other.
• Redirect assets too — images, PDFs, and other non-HTML files, not just pages.
• Server-side only. JavaScript redirects are a last resort; Google may never process them if rendering fails.
• Don’t confuse temporary with permanent. A 302/307 doesn’t tell the indexing pipeline the target should be canonical — the old URL stays indexed and signals mostly stay put. Use temporary redirects only for genuinely temporary situations.
• Keep redirects far longer than “one year.” Google’s floor is “at least 1 year,” but Illyes has clarified that the ~12-month figure is really for Google’s benefit — your users will appreciate it if you keep the redirects effectively forever. Bing leans toward 1–2 years minimum. My rule: keep them as long as the old URLs pull any traffic or links, which in practice means indefinitely. Evidence for this claim Google recommends keeping site-move redirects as long as possible, generally for at least one year. Scope: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes

Phase 5 — Staging and pre-launch testing

• Block the staging site from indexing — noindex and/or a robots.txt Disallow on the staging host. Restrict access to your staging or dev site to prevent it being indexed in the first place. (And note this block for Phase 6 — it must come off at launch.)
• Use a temporary hostname (e.g. beta.example.com) for public testing.
• Test every redirect old → new. People frequently redirect to the wrong (non-existent) URLs — crawl the full old-URL list against staging and verify each resolves to the intended live page in a single hop.
• Diff the staging crawl against the Phase 2 baseline: titles, meta descriptions, canonical tags, hreflang, structured data, meta robots, internal links, page speed.
• Confirm canonicals point to the live site, not to staging URLs.
• Verify analytics fire (GA4, GSC verification, tag manager) and test forms, checkout, and other conversion paths.
• Make sure Googlebot isn’t blocked by a firewall or DoS protection — confirm it can reach the DNS and the host.

Phase 6 — Launch

• Remove every crawl block immediately — strip the noindex and staging robots.txt rules that were only there for the build. This is the single most common migration disaster: shipping with the staging block still live. Don’t forget to remove any noindex or robots.txt blocks that were only needed for the migration.
• Activate all 301 redirects simultaneously.
• Update and resubmit the current production XML sitemap with new canonical URLs only. If an old-URL sitemap would help with redirect discovery or monitoring, submit it as a separate, clearly temporary sitemap; never mix old and new inventories, and remove the old-URL sitemap when it no longer provides useful evidence. See Google’s site-move guidance.
• Spot-check redirects with the GSC URL Inspection tool.
• Submit the Change of Address tool — only for domain-level moves (see Type 1).
• For Bing, submit via IndexNow — the current mechanism. Bing’s old Site Move tool was deprecated around 2021, so don’t follow guides that still tell you to use it. IndexNow lets you submit all the migrated URLs at once after a migration.
• Ensure server capacity. Google will crawl the new site more heavily than usual right after the move.

Phase 7 — Post-launch monitoring

• Expect a temporary fluctuation. Google says to expect temporary fluctuation in site ranking during the move. A dip is not proof the migration failed. Martin Splitt has made the point that if you’re literally copying the entire URL structure and content to a new domain, you won’t necessarily see a drop at all.
• Know the timeline. Google says a medium-sized site can take a few weeks for most pages to move in its index; larger sites take longer. Full stabilization is often a couple of months.
• Diagnose drops that don’t recover. These are almost never caused by “the move.” Gary Illyes’ single most useful migration insight is that post-move traffic drops are usually caused by missing or rogue tags/directives on the new site — removed hreflang, an extra noindex, broken canonicals. Run down that list first.
• QA redirects in bulk — re-crawl the old URL list and confirm each returns a 301 to the correct live page (not a chain, not a 404 at the end).
• Watch canonical selection. If lots of external links — and stray internal links — still point to the old URL, Google can keep indexing the old URL instead of the new one. This is why updating internal links matters as much as the redirects, and why outreach to major linkers (fresh direct links beat redirected ones) is worth the effort.
• Monitor in GSC: the Page indexing report, Performance (clicks/impressions by page), Crawl stats, and any new manual actions. Snapshot rankings weekly for the first month. Bing’s guidance is to watch server logs for at least three months post-migration.

Did the redirect work? Measuring impact without fooling yourself

Do not judge a migration from a launch-day screenshot. Establish the old URLs, new URLs, query/page groups, and metrics before launch, then read the same cohorts through four checkpoints:

For every checkpoint, compare the post-change period with an equivalent pre-change period and exclude the change day. The launch day is a mixture of old and new states, partial deployments, cache changes, QA traffic, and tracking discontinuities; assigning it to either side contaminates the comparison. Keep the cohort and metric definitions fixed, and segment brand/non-brand, device, country, template, or migration type only when those cuts were part of the measurement plan.

Before attributing a gain or loss, annotate other changes in the window: releases, content updates, tracking changes, seasonality, campaigns, and Google’s confirmed ranking-update history. An overlapping algorithm update does not make the migration innocent or guilty; it means attribution is confounded, so report the uncertainty and rely more heavily on direct implementation evidence such as response tests, index coverage, canonical selection, and server logs.

“No change” is a valid result. A redirect’s job is often to preserve access, signals, and conversions while URLs move. Flat performance with clean one-hop responses can be success. Record that finding instead of searching for a growth story the data does not support.

The planned Before/After Impact Checker belongs at this point in the workflow: once it ships, it can standardize the excluded change day and 7/14/30/90-day comparisons. Until then, use a spreadsheet or reporting layer and save the exact date ranges, filters, cohort, and annotations with each checkpoint.

The 7 migration types

The universal process above is most of the work. What follows is what’s specific to each type — the gotchas and must-dos that catch people out.

Type 1 — Domain change / rebrand

What it is: moving all pages from oldbrand.com to newbrand.com — new domain, new GSC property, ideally with no simultaneous URL-structure changes.

Risk: Highest. Every URL changes, external links need updating, and your GSC history is split across two properties.

Gotchas and must-dos:

• Don’t combine the domain change with a redesign and URL restructure. Google’s own Change of Address documentation warns that pairing a domain move with a redesign of content and URL structure means you’ll probably see some traffic loss. Move the domain first; restructure later.
• Investigate the new domain’s history before you register it. Check archive.org — a previously-registered domain with a manual-action past can start your new brand in a hole.
• Don’t let the old domain expire. Keep renewing it and keep the redirects live; if it lapses and someone else grabs it, your redirects (and link equity) die.
• Don’t chain domain moves (A → B then immediately B → C). The Change of Address tool can’t be chained.

The Change of Address tool — what it does and doesn’t do. This is where most confusion lives. The tool tells Google to emphasize crawling and indexing the new site, forwards signals, and prefers the new site’s canonicals — for 180 days. Critically:

• It works for a domain or subdomain move with no path scope — not for moving individual pages or folders within a site.
• You must be a verified owner of qualifying old and new Search Console properties. A Domain property qualifies, and a root URL-prefix property can qualify too; a path-scoped URL-prefix property cannot. See Google’s Change of Address requirements and property eligibility guidance.
• It’s a strict 1:1 move — it cannot be used for merges or partial moves.
• It is optional, not required. It’s one extra signal; if your redirects are set up properly you’ll be fine without it. The 301s do the real work; the tool just speeds and clarifies the message. (There’s a dedicated deep dive on the Change of Address tool in the Search Engine Tools cluster.)

The 180-day window is not a redirect deadline. After 180 days Google no longer recognizes a relationship between the old and new sites through the tool — it treats the old site as unrelated. That’s exactly why your redirects must outlive the tool. Keep them at least a year (Google’s floor), and realistically far longer.

Type 2 — HTTP → HTTPS

What it is: moving from unencrypted HTTP to HTTPS (TLS/SSL). Every URL changes from http:// to https://. HTTPS has been a (lightweight) ranking signal since 2014; today being on HTTP is an active disadvantage.

Risk: Low–medium done right; high if certificate or mixed-content issues crop up.

Gotchas and must-dos:

• Do NOT use the Change of Address tool. Google explicitly says to use the site move guidelines instead for HTTP → HTTPS.
• Use per-URL 301 redirects, not a blanket rule that dumps everything onto the HTTPS homepage. The cleaner you signal that this is just a generic protocol move, the more smoothly Google switches it over.
• Fix mixed content. Any resource (image, script, stylesheet) still loaded over HTTP after the switch triggers mixed-content warnings and sends conflicting signals. Use protocol-relative or relative URLs — and a Content Security Policy of upgrade-insecure-requests is a fast way to mop up stragglers.
• Google prefers HTTPS as canonical automatically — except when there’s an invalid certificate, insecure dependencies (mixed content), a redirect back to HTTP, or other conflicting signals. So a botched certificate doesn’t just look bad, it can keep the HTTP version canonical.
• Be careful with HSTS. HSTS tells browsers to only ever connect via HTTPS for a set period. Enable it before your TLS is rock-solid and a certificate error becomes a hard fail for returning visitors. Add it after you’re confident, starting with a low max-age and increasing over time.
• Use a strong cert (2048-bit RSA or EC; aim for an A/A+ on the Qualys SSL test) and set the Secure flag on cookies.

Type 3 — Platform / CMS replatform

What it is: moving to a new CMS or tech stack (e.g. WordPress → headless, Magento → Shopify). Often drags URL changes, template changes, internal-link changes, and rendering changes along with it.

Risk: High — because multiple things change at once.

Gotchas and must-dos:

• Expect URL changes — different platforms generate different slug structures, category hierarchies, and pagination. Plan the URL map before you commit to a platform, not after.
• Redirects don’t carry over automatically. A classic mistake is older redirects in .htaccess files not getting copied to the new host. Compile redirect rules from all sources (CMS, CDN, server config, GSC’s Page with redirect report) before building the new redirect layer.
• Re-implement structured data — don’t assume schema markup transfers. Validate it after launch.
• Test JavaScript rendering if you’re moving to a headless/SPA front end — rendering changes how Googlebot processes pages. Content rendering (especially JavaScript) is one of the things I check hardest in post-migration QA.
• Benchmark page speed and mobile. New themes are often heavier; Google indexes the mobile version, so confirm the new platform isn’t slower or broken on mobile.
• Enforce trailing-slash consistency — different platforms handle it differently, and inconsistency quietly spawns redirect chains.
• Re-deploy analytics and verification tags (GA4, GSC, tag manager) on the new platform before launch.
• A serious restructure where the URLs, internal links, and templates all change at once means Google can’t just keep its old understanding of the site — so expect a longer stabilization than a like-for-like move.

Type 4 — URL structure / site restructure

What it is: changing the URL paths on the same domain — e.g. /category/post/ → /post/. Domain stays put; content may or may not change.

Risk: Medium. Domain authority stays intact, but every changed URL needs a redirect and the internal link graph needs updating.

Gotchas and must-dos:

• Internal links are the part people forget. The pattern I see constantly: you redirect the URLs but forget to update the rel=canonical, the navigation, the footer, or the in-body links. Those stale signals make it much harder for Google to pick the new URLs as canonical — even with the redirects in place.
• Canonicalization can lag. If the old URL has more backlinks and internal links still point to it, Google may keep preferring it as canonical after the 301. Updating internal links directly to the new URLs is critical.
• Do NOT use the Change of Address tool for restructures within the same domain. Google’s instruction is simply: add redirects and update your sitemaps.
• Update breadcrumbs, navigation, and sitemaps to the new paths. Sitemaps should list new URLs only.

Type 5 — Website redesign (same URLs)

What it is: a redesign where the domain and URLs stay the same, but templates, copy, navigation, images, or on-page SEO elements change. The lowest-risk type — but not zero risk.

Risk: Low, but on-page changes can still move rankings.

Gotchas and must-dos:

• On-page elements break silently. Redesigns routinely strip or alter <title> tags, meta descriptions, heading structure, and structured data. Map and verify each one against the old-site baseline.
• Watch internal linking. A navigation redesign can quietly remove high-value internal links that were passing authority to deep pages.
• Benchmark Core Web Vitals before and after. New CSS, JS, fonts, and images almost always change page speed.
• Be deliberate about content changes. “Same URL” redesigns often thin out or consolidate content — don’t assume a thinner page performs the same.
• Google’s site move without URL changes guidance is the reference here; it’s about minimizing the impact when the infrastructure or presentation changes but the URLs don’t.

Type 6 — Subdomain ↔ subfolder

What it is: moving content between a subdomain and a subfolder — most commonly blog.example.com → example.com/blog/. Consolidating merges authority that was split across two hosts into one.

Risk: Medium–high. Google treats subdomains and the root domain as separate entities for many purposes, so the consolidation causes real reindexing churn.

Gotchas and must-dos:

• Both versions are separate entities to Google — separate crawl budget, partly separate signals. Consolidating to a subfolder is often a net positive, but it takes time and behaves like a real move.
• Do NOT use the Change of Address tool for same-root subdomain → subfolder moves (it’s in the same family as the www/non-www case Google says to handle with canonicals/redirects, not the tool).
• GSC properties: you likely have separate properties for the subdomain and root. After consolidation, data flows into the root property — watch the subdomain property’s coverage decline and the root’s grow.
• Redirect every subdomain URL to its subfolder equivalent and update internal links to point directly at the new subfolder URLs (not via the redirect). The subdomain’s whole backlink profile feeds the main domain through the 301s; outreach on the top links still helps.
• Reconcile analytics — if the subdomain had its own/ cross-domain tracking, reconfigure GA4 so you don’t lose continuity.

Type 7 — Domain consolidation / merging sites

What it is: combining two or more separate sites into one — e.g. folding an acquired competitor’s content into your main domain, or merging a brand’s separate country/product sites.

Risk: Very high. This isn’t a standard migration at all — there’s no 1:1 move to signal, and the combined entity is effectively a new site to Google in many ways. As Martin Splitt has framed it, combining two sites is no longer a migration so much as creating a new site from an amalgamated version.

Gotchas and must-dos:

• You cannot use the Change of Address tool. It relies on the move being a 1:1 move from one domain to another — a merge isn’t that. This is per-URL work.
• Expect some traffic loss. Google warns that moving sites A, B, and C all to a new location D can cause confusion and traffic loss. Plan for an extended stabilization period.
• Deduplicate first. If the merging sites overlap topically, the merge creates duplicate content. Decide the canonical page for each overlapping topic before you redirect.
• Per-URL redirects to the most relevant page — never a blanket redirect of an entire acquired domain to the homepage (soft 404 for everything that isn’t the homepage). Page-level link equity transfers best when each page goes to its true equivalent.
• Keep a GSC property for each merging site and monitor coverage on each (decline expected) alongside the primary domain (growth expected).

Choose the specialized guide

Use the guide that matches the decision or failure mode you need to resolve:

• Hosting Migration SEO — for server, CDN, DNS, or hosting changes that keep URLs stable.
• CMS Migration SEO — for platform and CMS changes, including template, rendering, and data-parity risks.
• URL Structure Migration — for path, taxonomy, or folder changes on the same domain.
• Site Split / Carve-Out SEO Migration — for moving a defined section of one site into a separate property.
• Post-Acquisition SEO Integration — for deciding how acquired sites, brands, and content should be integrated.
• Post-Migration Traffic Loss — for diagnosing visibility or traffic that does not recover after launch.

Where this fits

A migration touches a lot of adjacent topics: the redirects that carry it, the canonicalization that decides which URL Google keeps, the HTTPS protocol, hreflang on international sites, and the Change of Address tool that signals a domain move. Each of those is its own deep dive — but the spine of every migration is the same: map old to new 1:1, redirect with permanent redirects, keep them, and watch the right signals afterward.

AI summary

A condensed take on the Advanced version:

• A site migration is any major change to a site’s URLs, domain, platform, protocol, or host that can affect crawling, indexing, and ranking. Risk = amount of change × how much you change at once.
• The 7 types, by risk: redesign (same URLs, low) → HTTP→HTTPS (low–med) → URL restructure (med) → subdomain↔subfolder (med–high) → CMS replatform (high) → domain change/rebrand (highest) → domain merge/consolidation (very high).
• Universal 7-phase process: plan & classify → benchmark/crawl the old site → build a 1:1 URL map → redirect strategy → staging & pre-launch testing → launch → post-launch monitoring.
• 301/308 redirects are the spine. They carry rankings and don’t lose PageRank. Everything else (Change of Address tool, sitemaps, internal links, canonicals) is a supporting signal.
• Map old→new 1:1. Never bulk-redirect to the homepage (treated as a soft 404). Avoid chains (keep under ~3–5 hops). Keep redirects far longer than “12 months” — effectively forever for users.
• Expect a temporary fluctuation and a recovery. A drop that sticks usually means something broke — staging block left live, removed hreflang/canonical, stray noindex, or redirects to the wrong pages — not the move itself.
• Change of Address tool: domain-level only, strict 1:1, optional. Not for HTTP→HTTPS, same-domain restructures, or merges.
• Bing: the old Site Move tool is deprecated (~2021); use IndexNow to submit migrated URLs. Bing leans toward keeping redirects 1–2 years.

Official documentation

Primary-source documentation from the search engines.

Google

• Site move with URL changes — the primary migration playbook: redirects, timing, expectations, keeping redirects ~1 year.
• Site move without URL changes — hosting/infrastructure and redesign moves; temporary hostnames, DNS, firewall/DoS cautions.
• Redirects and Google Search — permanent vs. temporary redirects and the JavaScript-redirect risk.
• Change of Address tool (Search Console Help) — supported move scope, property prerequisites, exclusions, and redirect guidance.
• Consolidate duplicate URLs — HTTPS canonical preference, and why a 301 is a stronger canonical signal than a temporary redirect.
• Canonicalization — how Google selects a canonical URL (a hint, not a directive).
• Enable HTTPS on your servers (web.dev) — TLS certificates, mixed content, and HSTS guidance (the old Google HTTPS docs now redirect here).

Bing / Microsoft

• Website Migration with Bing — Bing’s migration framework, redirect duration, and post-migration log monitoring.
• IndexNow — the current mechanism for submitting migrated URLs to Bing (the old Site Move tool is deprecated).

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — redirects and PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” — Search Central, Site move with URL changes. Jump to quote
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” — Search Central, Site move with URL changes. Jump to quote
• “Keep the redirects for as long as possible, generally at least 1 year.” — Search Central, Site move with URL changes. Jump to quote
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” — Search Central, Site move with URL changes. Jump to quote

Google — expectations and timing

• “Expect temporary fluctuation in site ranking during the move.” — Search Central, Site move with URL changes. Jump to quote
• “a medium-sized website can take a few weeks for most pages to move in our index” — Search Central, Site move with URL changes. Jump to quote
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” — Search Central, Site move with URL changes. Jump to quote

Google — Change of Address tool (180-day window)

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” — Search Console Help, Change of Address. Read the source
• “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.” — Search Console Help, Change of Address. Read the source

Google — HTTPS canonical and redirect signals

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” — Search Central, Consolidate duplicate URLs. Jump to quote
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (on temporary redirects) — Search Central, Redirects and Google Search. Jump to quote

Google — launch and infrastructure cautions

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” (firewall / DoS protection) — Search Central, Site move without URL changes. Jump to quote
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” (server/hosting moves) — Search Central, Site move without URL changes. Jump to quote

The master migration checklist

Run this on every migration regardless of type, then add the type-specific list below it.

Pre-launch

• Classified every migration type in play (and avoided stacking high-risk types).
• Stakeholders briefed that a temporary dip is normal; launch timed for low traffic.
• Rollback plan documented and tested.
• Full crawl of the old site saved as the QA baseline.
• Rankings, GSC performance (3/6/12 mo), GA4, and top-backlink pages exported.
• Every existing redirect compiled from CMS, CDN, server config, and GSC’s Page with redirect report.
• One-to-one old→new URL map built (every URL maps somewhere; removed pages → 410/404, not homepage).
• Redirect plan uses 301/308, single-hop (no chains), and covers images/PDFs too.
• Staging blocked from indexing (noindex and/or robots.txt) — and that block is noted for removal at launch.
• Staging crawl diffed vs. baseline: titles, metas, canonicals, hreflang, structured data, meta robots, internal links, speed.
• Canonicals on staging point to live URLs, not staging URLs.
• Every redirect tested old→new (resolves to the intended page in one hop).
• Analytics/verification tags present; forms and conversion paths tested.
• Firewall/DoS protection confirmed not to block Googlebot.

Launch day

• All staging crawl blocks (noindex, robots.txt) removed — verified live.
• All 301 redirects activated.
• Current production XML sitemaps updated to new canonical URLs only and resubmitted in GSC.
• If useful, a separate temporary old-URL sitemap submitted for redirect discovery or monitoring, with an owner and removal condition.
• Redirects spot-checked with GSC URL Inspection.
• Change of Address tool submitted (domain-level moves only).
• Migrated URLs submitted to Bing via IndexNow.
• Server capacity confirmed for the heavier post-launch crawl.

Post-launch

• Old URL list re-crawled in bulk; every URL returns a 301 to the correct live page.
• Internal links updated to point directly at new URLs (no stale links to old URLs).
• GSC monitored: Page indexing, Performance by page, Crawl stats, manual actions.
• Rankings snapshotted weekly for the first month.
• Outreach to top external linkers to update their links.
• Redirects scheduled to stay live for years (not just the tool’s 180 days).
• If traffic drops and stays down: checked for removed hreflang, stray noindex, broken canonicals, and bad redirects first.

Type-specific checklists

Type 1 — Domain change / rebrand

• New domain checked for prior-use history (archive.org); old domain renewals secured.
• Verified ownership confirmed for qualifying no-path old and new GSC properties: Domain properties or root URL-prefix properties, not path-scoped URL-prefixes.
• 301 from old homepage → new homepage in place (required for the tool).
• Canonicals, internal links, and sitemaps updated to the new domain site-wide.
• Change of Address submitted per subdomain and the www/non-www variant.
• Disavow file transferred to the new property; not combined with a redesign/restructure.

Type 2 — HTTP → HTTPS

• Valid cert (2048-bit RSA/EC), Qualys A/A+; per-URL 301s from http→https (not blanket-to-homepage).
• Mixed content scanned and fixed (relative/protocol-relative URLs; upgrade-insecure-requests CSP).
• Canonicals, sitemaps, robots.txt, hreflang all updated to HTTPS; Secure flag on cookies.
• HSTS added only after TLS is confirmed stable (low max-age first).
• Change of Address tool not used (use site-move guidelines instead).

Type 3 — Platform / CMS replatform

• Old→new URL map built before the platform is locked in.
• Redirect rules compiled from CMS + CDN + server config + GSC (don’t lose .htaccess rules).
• Trailing-slash convention enforced; structured data rebuilt and validated.
• JavaScript rendering tested (if headless/SPA); mobile rendering and page speed benchmarked.
• GA4/GSC/tag-manager re-deployed on the new platform.

Type 4 — URL structure / restructure

• Complete old→new map built; 301s implemented per URL.
• ALL internal links updated (nav, breadcrumbs, footer, body, related-posts widgets).
• rel=canonical updated to new URLs; sitemaps list new URLs only.
• Change of Address tool not used (same-domain restructure: just redirect + update sitemaps).
• New site crawled to confirm no internal links still point to redirecting old URLs.

Type 5 — Website redesign (same URLs)

• On-page elements (titles, descriptions, H1s, canonicals, structured data) saved from the old site and diffed after launch.
• High-value internal links preserved through the navigation redesign.
• Core Web Vitals benchmarked before and after.
• Content changes deliberate (no accidental thinning); analytics still firing.

Type 6 — Subdomain ↔ subfolder

• Subdomain crawled; full blog.example.com/post/ → example.com/blog/post/ map built.
• 301s from every subdomain URL to its subfolder equivalent; internal links updated to point directly at subfolder URLs.
• Change of Address tool not used for same-root moves.
• Both GSC properties monitored (subdomain coverage declines, root grows); analytics reconfigured.

Type 7 — Domain consolidation / merge

• Every merging site audited (crawl, rankings, backlinks, GSC).
• Overlapping content deduplicated; canonical page chosen per topic before redirecting.
• Per-URL 301s to the most relevant page (never a blanket redirect to the homepage).
• Change of Address tool not used (no 1:1 move to signal); extended stabilization planned.
• A GSC property kept for each merging site; coverage monitored on each plus the primary domain.

The mental models

1. Risk = amount of change × how much you change at once. Before anything else, classify which types are in play. A redesign on the same URLs is one low-risk change; a domain move + URL restructure + replatform is three high-risk types compounding. If you can stage the change, do it — change one thing at a time.

2. Redirects do the work; everything else just signals. The 301s are the machinery that carries rankings across. The Change of Address tool, sitemap submissions, internal-link updates, and canonicals are all supporting signals that help search engines process the move faster and cleaner. Build the redirects first; treat the rest as accelerants, not substitutes.

3. 1:1 mapping beats redirecting everything to the homepage. Every old URL maps to its single most relevant new URL. A pile of redirects to the homepage is treated as soft 404s — no benefit, and you lose the page-level link equity you were trying to preserve. No match? Use a proper 410/404, not the homepage.

4. The tool’s window is not the redirect’s lifespan. The Change of Address tool forwards signals for 180 days. Your redirects should outlive that by years — keep them as long as the old URLs pull any traffic or links. Two timelines, and the longer one (the redirects) is what keeps the move sticking.

5. A dip is normal; a stuck drop is a bug. Expect a temporary fluctuation and a recovery within weeks to a couple of months. If traffic doesn’t come back, don’t blame “the move” — go hunt for the usual culprits: a staging block left live, removed hreflang, a stray noindex, broken canonicals, or redirects pointed at the wrong pages.

6. Internal links matter as much as redirects for canonical selection. You can redirect everything perfectly and still have Google keep indexing the old URL if your nav, footer, and body links — and external links — still point to it. Update internal links directly to the new URLs, and do outreach on the big external links.

Migration cheat sheet

Which redirect type when

Which tool / signal for which migration

Bing equivalents

Fast facts

• 301s don’t lose PageRank — myth’s been dead since ~2016.
• Redirect chains: keep under ~3–5 hops (Googlebot follows ~10).
• 180 days = the Change of Address window, not a redirect deadline. Keep redirects effectively forever.
• Reindex timeline: “a few weeks” for a medium site; longer for large ones.
• #1 cause of a stuck drop: missing/rogue tags on the new site (hreflang, noindex, canonicals), not the move.

Which migration type is this — and does Change of Address apply?

Run the tree once for the largest change, then run it again for every additional change shipping in the same release. A replatform that also changes paths and domain is three migrations, not one.

Playbook: traffic dropped after launch and is not recovering

Use this after the expected launch fluctuation fails to settle. Work from site-wide access failures toward URL-level signal conflicts; do not blame “the move” until the implementation has been cleared.

Step 1 — Confirm the drop is real and scoped. Compare the same benchmarked pages, queries, markets, and analytics definitions captured before launch. If only reporting disappeared, repair measurement first. If the old URLs lose visibility while equivalent new URLs gain it, continue monitoring the normal crossover. If both sets lose visibility, go to Step 2.

Step 2 — Check for a launch-wide crawl or index block. Fetch production as a crawler and inspect robots.txt, meta robots, X-Robots-Tag, authentication, firewall responses, DNS, and status codes. If a staging noindex, Disallow: /, auth wall, or bot block shipped, remove it and recrawl immediately. If production is accessible and indexable, continue.

Step 3 — Re-run the complete old-to-new redirect map. Test the full old-URL inventory, starting with the most-linked and highest-traffic pages. If URLs end in 404s, irrelevant destinations, loops, or chains, fix those mappings and flatten every route to the final equivalent URL. If redirects resolve correctly in one hop, continue.

Step 4 — Diff the new pages against the baseline. Compare canonicals, hreflang, titles, headings, body content, structured data, internal links, and render-visible HTML. If a template-wide tag disappeared or points back to staging or old URLs, fix the template before individual pages. If parity is intact, continue.

Step 5 — Check consolidation signals. Confirm new URLs are self-canonical, internal links and navigation point directly to them, and current production sitemaps contain new canonical URLs only. If a separate old-URL sitemap was submitted for monitoring, confirm it remains useful and remove it when it does not. In URL Inspection, sample Google-selected canonicals. If Google keeps selecting old or unrelated URLs, remove conflicting links, canonicals, and sitemap entries; then wait for recrawl.

Step 6 — Check capacity and server evidence. Read crawl stats and access logs for Googlebot response codes and activity on the new host. If errors, latency, rate limits, or firewall challenges rise during the post-move crawl surge, restore capacity or access. If crawl is healthy, escalate the remaining page groups by migration type and template.

Step 7 — Use the rollback plan only for a proven shipped regression. Roll back when the pre-agreed trigger is met and the crawl diff ties the drop to a reversible template, platform, or configuration defect. Do not roll back solely because of day-one volatility; a second unplanned move adds another migration for search engines to process.

Migration myths that create real failures

“Permanent redirects lose link credit.” Why it is wrong: Google says permanent redirects do not lose PageRank. The practical risk is a wrong destination, chain, loop, or dead end—not the 301 itself. Do instead: map each old URL directly to its closest equivalent and test the final response.

“Change of Address moves the site for me.” Why it is wrong: the tool is an optional supporting signal for a strict whole-domain move. It does not create redirects and does not support HTTPS moves, path restructures, partial moves, or domain merges. Do instead: build the redirect map first, then use the tool only when its scope fits.

“Any traffic drop proves the migration failed.” Why it is wrong: temporary ranking, crawl, and, when a separate old-URL sitemap is used, sitemap crossover fluctuations are expected while search engines process the move. Do instead: agree on benchmarks and rollback criteria before launch, then diagnose a persistent or structurally explained drop rather than reacting to routine noise.

“Redirects can come down after a few months.” Why it is wrong: Google’s one-year guidance is a floor for its processing, not an expiration date for bookmarks, backlinks, or users. Do instead: keep redirects as long as old URLs receive traffic or links—usually indefinitely—and keep control of the old domain.

Tools for mapping and verifying a migration

• Redirect Map Builder — paste old and new URL sets to create a proposed 301 map with confidence tiers, unmatched rows, a 410 list, chain flattening, manual overrides, and platform exports. Every suggestion still needs an editorial equivalence check before launch.
• Redirect Chain Mapper — trace every hop and see status, host/path changes, meta refreshes, and cleanup rules. Use it on staging samples and post-launch failures where slash, protocol, or domain rules may be stacking.
• Redirect Checker — quickly confirm the final status, hops, and destination for a single URL or small batch. Use a full crawler for the complete old-URL inventory; spot checks cannot prove the whole map.
• A full-site crawler — saves the pre-migration baseline, tests the complete redirect list, and diffs titles, canonicals, hreflang, directives, links, schema, and rendering.
• Google Search Console — use Page Indexing, Performance, Sitemaps, Crawl Stats, URL Inspection, and—only for a qualifying whole-domain move—Change of Address.
• Server access logs — prove whether search bots reach the new host, which responses they receive, and whether old URLs are still requested before infrastructure is retired.

Prove the migration shipped as mapped

Full old-URL redirect test

• Test to run: Crawl the complete Phase 2 old-URL inventory against production and inspect failures with the Redirect Chain Mapper or Redirect Checker.
• Expected result: Every moved URL returns one server-side 301 or 308 hop to its intended equivalent; deliberately removed URLs return the planned 404 or 410.
• Failure interpretation: A 200 on an old URL, chain, loop, irrelevant destination, or unplanned 404 means the redirect map or rule ordering did not ship as approved.
• Monitoring window: Immediately after launch, then repeat as fixes deploy and during the early monitoring window while old URLs are still heavily crawled.
• Rollback trigger: A systemic mapping rule sends a material protected section to wrong destinations or makes it unreachable and cannot be safely corrected in place.

New-page indexability and canonical test

• Test to run: Crawl the new URL set for status, robots directives, and canonicals; then use URL Inspection on representative high-value pages.
• Expected result: New pages return 200, are not blocked or noindex, and declare the intended new canonical; after recrawl, Google reports the intended canonical on samples.
• Failure interpretation: A site-wide staging directive, old/staging canonical, auth challenge, or different Google-selected canonical signals a conflicting launch setup.
• Monitoring window: Technical signals are immediate; Google-selected canonical and index movement require recrawling and can take weeks on a medium site, longer at scale.
• Rollback trigger: A production-wide crawl/index block or template canonical defect affects the protected set and cannot be removed promptly without reverting the release.

Link-and-sitemap destination test

• Test to run: Crawl internal links and parse submitted sitemaps, comparing every destination with the approved new canonical URL set.
• Expected result: Navigation and internal links point directly to new URLs, and current production sitemaps list only canonical new URLs with successful responses. Any optional old-URL sitemap is separate, temporary, and tied to a removal condition.
• Failure interpretation: Old internal links, mixed old/new sitemap inventories, or an old-URL sitemap retained after it stops providing useful evidence can slow or obscure the old-to-new crossover.
• Monitoring window: Immediate in the rendered site and sitemap files; confirm the submitted sitemap is processed during the post-launch monitoring window.
• Rollback trigger: A template-wide navigation or sitemap generator regression sends crawlers back to old, staging, or non-canonical URLs and cannot be hot-fixed safely.

Resources worth your time

My related writing

• A Website Migration Takes More Than A Checklist To Be Successful — my full migration guide, with the common-mistakes list and post-launch monitoring checklist.
• Redirects for SEO: A Beginner’s Guide — redirect types, chains, and how long to keep them.
• Is It OK to Remove 301 Redirects After a Year? We Tested It — first-party experiment behind the “keep redirects long-term” point.
• Canonicalization: A Beginner’s Guide — how Google picks a canonical, which matters when old URLs compete with new ones after a move.
• The Beginner’s Guide to Technical SEO — where migrations sit in the bigger picture.

Official

• Site move with URL changes — Google’s primary migration playbook.
• Change of Address tool — Google’s supported move scope, property prerequisites, and redirect guidance.
• Website Migration with Bing — Bing’s framework and redirect-duration guidance.

From others

• r/TechSEO — where migration edge cases and post-launch drops get debugged.
• Google’s Mueller on Keys to a Successful Site Migration (Search Engine Journal) — covers Mueller’s guidance on URL mapping, internal links, and why redirects alone aren’t enough.
• Google: Clean Migration Takes Time, a Hacky Migration Just Takes Much Longer (Search Engine Roundtable) — Mueller’s advice on site merges and the cost of cutting corners.
• When Migrating From HTTP to HTTPS, Google Says to Use 301 Redirects (Search Engine Land) — Mueller recommending per-URL 301s for HTTPS moves rather than blanket redirects.
• Website Migration with Bing (Bing Webmaster Blog) — Bing’s 8-step migration framework, redirect-duration guidance (1–2 years), and post-migration log monitoring advice.
• Moving Domains: Avoiding the Pitfalls (Bing Webmaster Blog) — Bing’s guidance on checking new domain history and avoiding canonical-as-redirect substitution.
• Enable HTTPS on Your Servers (web.dev) — the canonical reference for TLS certificates, mixed content, and HSTS configuration during HTTP→HTTPS migrations.

Google recommends keeping site-move redirects as long as possible, generally for at least one year. Evidence for this claim Google recommends keeping site-move redirects as long as possible, generally for at least one year. Scope: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes It says to expect temporary ranking fluctuations and that most pages on a medium-sized site can take a few weeks to move in its index. Evidence for this claim Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Scope: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move with URL changes When possible, Google recommends changing one major thing at a time.

Test yourself: Site Migrations

Five questions on migration types, redirects, and post-launch diagnosis. Pick an answer for each, then check.

Site Migration

A site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once.

Related: Change of Address tool, Canonicalization, Redirect error, Page with redirect

Site Migration

A site migration is an umbrella term for any major change to a website that has the potential to move the URLs search engines know about — or change how they crawl, render, and index them. That covers a lot of ground: a simple HTTP-to-HTTPS flip on a single domain, a folder restructure, a CMS replatform, a full rebrand onto a new domain, or merging several sites into one. They’re all “migrations” because they all put your existing search visibility at risk during the change.

The single most useful framing is that risk equals how much you change times how much you change at once. A redesign that keeps the same URLs is low risk; a simultaneous domain change plus URL restructure plus CMS replatform is three migrations stacked on top of each other, and the risks compound.

Whatever the type, the machinery that carries your rankings across is the same: 301 (or 308) permanent redirects mapping each old URL to its closest equivalent new URL. Everything else — the Change of Address tool, updated sitemaps, internal-link updates, canonical tags — is a supporting signal that helps search engines process the move faster and more cleanly. Permanent redirects don’t lose PageRank, and you should keep them in place far longer than any tool’s window — ideally for as long as the old URLs pull any traffic or links at all.

A temporary fluctuation around the launch is normal. A drop that never recovers usually means something broke — a staging block left live, a removed hreflang or canonical, a stray noindex, or redirects pointed at the wrong pages — not the move itself.

Related: Change of Address tool, Canonicalization, Redirect error, Page with redirect

Changelog