Site Migration Guide

A site migration is any significant change to a website’s URL structure, domain, protocol, CMS, or hosting that affects how search engines crawl and index the site. The term covers a wide range of changes: from switching HTTP to HTTPS on a single domain, to a full rebrand involving a new domain and a redesigned site architecture.

Migrations are high-risk. Done well, they are largely invisible to search engines. Done badly, they can cost months or years of ranking recovery.

Types of migration

Domain migration. Moving from one domain to another: a rebrand, a consolidation of multiple domains, or a market expansion. The highest-risk migration type.

Entity migration. A brand rename that involves moving to a new domain. Carries all the risks of a domain migration plus a separate problem: Knowledge Graph entries, Wikidata, third-party profiles, and backlink anchor text all reference the old brand name. Updating those external entity signals is a distinct workstream from the technical migration, and recovery timelines are typically longer.

Protocol migration. Moving from HTTP to HTTPS. Now standard, but still requires a complete redirect map and verification.

Subdomain to subfolder. Moving content from blog.example.com to example.com/blog/. Google lists subdomains versus subdirectories among the things it believes you shouldn’t focus on,¹ so make this move for maintenance or business reasons, and treat any traffic gain as possible rather than expected.

CMS migration. Switching platforms (WordPress to Webflow, Magento to Shopify, etc.) while keeping the same domain. Lower risk if URLs are preserved; high risk if they change. Pay particular attention to rendering: moving from a server-rendered framework to client-side JavaScript introduces a two-stage crawl process where Googlebot must queue pages for rendering, which can delay indexing across the site.

URL restructure. Reorganising the URL hierarchy without changing domain. Common during information architecture overhauls.

Full rebuild. Domain change, CMS change, URL restructure, and redesign simultaneously. The highest-risk scenario. Avoid combining multiple migration types where possible.

Pre-migration

Baseline your current state

Before changing anything, document where you are:

• Export all indexed URLs from Google Search Console (Page Indexing report)
• Crawl the existing site with Screaming Frog or Sitebulb
• Export current rankings for target keywords (Ahrefs, Semrush, or Search Console)
• Document organic traffic by page in GA4
• Record Core Web Vitals scores
• Export all backlinks from Ahrefs or Majestic for your highest-authority pages
• Export image URLs with their alt text from the crawl. Alt text is part of what makes an image rank and is commonly dropped by CMS media imports, so you need the before state to diff against

This baseline is what you measure recovery against. Without it, you cannot diagnose problems post-launch. The SEO Audit Guide covers how to run a complete audit before starting a migration.

Build the redirect map

A redirect map is a document recording a decision for every existing URL: its destination on the new site, a 410 for deliberate removal, or a considered 404. It is a critical migration deliverable.

Rules:

• Every URL that has ever ranked, earned links, or received meaningful traffic needs a redirect
• Redirect to the most semantically equivalent page, not the homepage by default
• If no equivalent page exists, redirect to the closest parent category
• Homepage is a last resort, not a default
• If a page with significant backlinks or rankings has no equivalent, treat it as a content planning problem first. Redirecting to a loosely related page is a fallback; recreating or migrating that content is usually the better answer. Before accepting the redirect, ask why the page is not coming across.
• Include pagination, filtered URLs with significant link equity, and RSS feeds
• Include image URLs. Image files earn direct links and image search traffic of their own, which Google names as the reason to move them.² Most of a page’s link profile points at the HTML page rather than the file, so the page-level redirect does the heavier lifting, but the image URLs still need mapping. Use the Image search type filter in GSC to identify which image URLs are driving clicks before migration.
• Include embedded and hosted assets beyond images: videos, PDFs and other downloads, JavaScript, and CSS. Google’s site move documentation names all of these as URLs that “need to be moved in the same way as all other content on your website”.² PDFs are commonly forgotten, because they rank and earn links independently of any page. JavaScript and CSS matter for a different reason: if render-critical assets are still served from the old domain when it is switched off, the new site renders unstyled to Googlebot.
• Use 301 redirects for all permanent moves

Test the redirect map against your crawl export before launch. Every URL in the crawl should have a decision, which is not the same as a destination: a 410 for content being deliberately retired, or a plain 404 for a URL that earned nothing and warrants no further handling, are both valid outcomes. What you are checking for is URLs nobody has considered, not URLs without a redirect.

Images during a migration

Images are the asset class most often half-migrated, because the pages move and the pictures do not. Image results are ranked in the context of the page that hosts them, so an image needs a live host page, a live file and the connection between the two; break any one and the result drops out. The three failure patterns, what is safe to change, the alt text and hardcoded references a redirect map never touches, and why image recovery lags page recovery are in Images During a Site Migration. For the redirect map, the rule is the same as for pages: one old image URL to one new one, in a single hop, with no batch fallback to a logo.

Pages being deliberately removed with no equivalent should return 410 (Gone), the accurate code for intentional removal. Do not expect it to deindex faster than a 404: Google’s documentation treats every 4xx except 429 the same way, and the HTTP status codes reference covers why. Do not redirect removed pages to the homepage.

Technical pre-checks

• Confirm the new site is blocked from crawling during development (noindex meta tags, password protection, or robots.txt disallow; never rely on robots.txt alone for staging)
• Verify the new site passes a technical SEO audit: no broken links, correct canonical tags, valid XML sitemap, HTTPS throughout
• Check Core Web Vitals on the new site before launch
• Confirm structured data is present and valid on key page types; CMS migrations often silently break JSON-LD blocks or change schema types, so compare against the pre-migration baseline
• Verify hreflang implementation if the site targets multiple languages or regions

Launch

The launch checklist

1. Remove crawl blocks (robots.txt disallow, noindex, password protection) on the new site

2. Implement all 301 redirects from old to new URLs
3. Update the XML sitemap to reflect new URLs and submit to Search Console
4. Update canonical tags to point to new URLs
5. Verify HTTPS is configured correctly (no mixed content, valid certificate, HSTS enabled)
6. Submit a change of address in Google Search Console (for domain migrations only)
7. Update hreflang tags if applicable
8. Notify key link partners of URL changes for high-equity backlinks
9. Check crawler access at the CDN, not only in robots.txt, and confirm the new domain’s settings match the old domain’s intent rather than inheriting a default nobody chose

On step 9, if the new domain is on Cloudflare. Two settings can be inherited without anyone choosing them. Since 15 September 2026, a newly onboarded domain that says it earns from ads is offered a preset with Training set to Disallow AI Training and Agent blocked on ad-displaying pages, with Search still allowed. And choosing Block on the Training category, if you do, also blocks Googlebot, Applebot and Bingbot, because they crawl for search and training at once and Block applies to them; Disallow AI Training is the setting that keeps them crawling for search.³⁴ The second is the one that can cost you the migration.

Timing

Launch on a Tuesday, Wednesday, or Thursday. Avoid Fridays: if something breaks, you want your full team available to respond. Avoid major holidays and peak trading periods.

Keep the old server live and serving redirects for a minimum of 12 months. Google’s site-move guidance is to “keep the redirects for as long as possible, generally at least 1 year”, because that is how long it takes to recrawl the old URLs and reassign the links other sites point at them.² Its change-of-address page sets a lower floor, “at least 180 days—longer if you still see any traffic to them from Google Search”, and recommends keeping the old domain registered for at least a year so nobody else can buy it.⁵ Where this guide says 24 months, that is this guide’s own extension for domains carrying a lot of accumulated links or citations, not a second Google rule. Decommissioning the old server early is a common cause of migration-related ranking loss.

Updating external profiles and directories

301 redirects handle inbound links from other websites, but they do not update the URL stored in your social profiles, directory listings, or Google Business Profile. Anyone clicking through from those sources will land on a redirect rather than a direct URL, and the profile itself continues to reference a domain you are moving away from. Update these as part of the launch process, not as an afterthought:

• Google Business Profile: update the website URL
• Social profiles (LinkedIn company page, X/Twitter, Facebook, Instagram, YouTube)
• Industry directories and trade association listings
• App Store and Google Play listings if applicable
• Email signatures and newsletter footers
• Any paid directory listings (Clutch, G2, Capterra, etc.)

Cross-reference the backlinks export you compiled during pre-migration to catch high-traffic referral sources that may not appear on this list.

If the migration also involves a brand rename, these same sources need the name updated too. Inconsistency across profiles creates ambiguity in Google’s entity model and can extend the recovery period. See the entity migrations section for more detail on managing name changes alongside domain moves.

Post-migration monitoring

Immediate (first 72 hours)

• Crawl the new site to confirm redirects are working
• Check Google Search Console for crawl errors, Page Indexing issues, and manual actions
• Use the URL Inspection tool to manually request indexing for your highest-priority pages: homepage, key category pages, top-traffic content. Do not request indexing for utility pages (contact forms, thank-you pages, login pages); those pages carry no ranking value and spending your request quota on them sends weak signals at the point when you most need strong ones.
• Monitor organic traffic in GA4 for unexpected drops
• Check Core Web Vitals in Search Console

First four weeks

• Monitor rankings daily for target keywords
• Watch Search Console for URL discovery rate on new URLs
• Check that Google is crawling new URLs, rather than only following redirects to old ones
• Verify old URLs are dropping from the index (gradual, not immediate)

Ongoing (four to twelve weeks)

Plan for four to twelve weeks to full recovery on a well-executed migration. Treat that as a planning range drawn from practice rather than a published figure: Google commits only to “a few weeks or more” for a medium-sized site to start showing new URLs instead of old ones, and longer for larger sites.² Rankings for individual pages may fluctuate significantly in the first two weeks before stabilising.

If traffic has not recovered to within 20% of baseline by week twelve, investigate:

• Incomplete redirect map (orphaned old URLs with no redirect)
• Crawl blocks on the new site (robots.txt, noindex)
• Canonical tags pointing to wrong URLs
• Significant content quality difference between old and new pages

Common mistakes

Redirecting everything to the homepage. Google’s site move guidance is specifically against redirecting many old URLs to “one irrelevant single URL destination, such as the home page”, which it warns may be treated as a soft 404.² A mass redirect there destroys page-level signals. The rule is the one given in the redirect map section above: the homepage is a last resort for an individual URL with no equivalent, never the default for a set of them.

Decommissioning the old server too early. Any link pointing to the old domain becomes a dead end. Keep redirects live for at least 12 months, ideally 24.

Launching without a baseline. Without pre-migration data, you cannot tell whether a traffic drop is migration-related or coincidental.

Combining multiple migration types at once. Changing domain, CMS, URL structure, and design simultaneously makes it impossible to diagnose what caused a problem. Separate migration types where possible.

Not monitoring immediately post-launch. Problems identified in the first 72 hours can be fixed before Google recrawls at scale. Problems identified at week four are far more damaging.

Redirect chains on large sites. On sites with hundreds of thousands of URLs, redirect chains burn crawl budget. Each additional hop delays Googlebot and dilutes equity. Audit for chain lengths above two hops across high-traffic URL patterns before launch.

Forgetting pagination, filters, and facets. These pages may carry link equity or ranking signals. Include them in the redirect map.

Domain migrations: change of address

For domain-to-domain migrations, submit a change of address in Google Search Console. It tells Google directly that your site has moved, prompting it to expedite recrawling of the new domain and to stop surfacing old domain URLs in search results. Without it, Google discovers the move through 301 redirects alone, which works but takes longer.

What it does not do. It does not transfer signals by itself. The 301 redirects do the work; the change of address tool is an additional signal that speeds up Google’s processing of them. Google scopes it to moves “from one domain or subdomain to another”, including a move from one domain to a path within another, and says not to use it for HTTP to HTTPS, for moving pages within the same site, or for www to non-www.⁵

Requirements:

• Verify ownership of both the old and new domains in Search Console before submitting
• Verify all variants of both the old and new domains in Search Console: www, non-www, HTTP, HTTPS, and any subdomains. Submit a separate Change of Address request for each variant of the old domain (e.g. en.example.com, www.example.com, example.com), even if those variants are not actively used
• Implement 301 redirects first; submitting before redirects are live will cause the tool to error
• The tool is in the old domain’s Search Console: Settings > Change of address
• Google shows the move notification in Search Console for 180 days, and you can cancel the request within that window⁵

After the window closes. The 180 days apply to the tool, not your redirects. Keep 301s live on the old domain for at least 12 months regardless. External links pointing to old URLs will continue to pass equity as long as the redirects are in place.

Change of address is not a substitute for redirects; it is an additional signal on top of them.

Entity migrations: brand renames

A brand rename adds a second layer of complexity on top of a standard domain migration. Search engines build associations around a brand name: Knowledge Graph entries, Wikipedia and Wikidata, Google Business Profile, Crunchbase, LinkedIn, press coverage, and the anchor text of backlinks. When the name changes, those signals reference an entity that no longer exists under that name.

The technical work (301 redirects, change of address) is necessary but not sufficient. Recovery also requires updating entity signals across external sources:

• Update Google Business Profile to the new brand name
• Update or create Wikipedia and Wikidata entries for the new entity
• Update Crunchbase, LinkedIn, and industry directories
• Issue a press release so new coverage uses the new name from the outset
• Reach out to high-equity link partners to request anchor text updates

Recovery timelines for entity migrations are typically longer than standard domain migrations. The name change creates ambiguity for search engines about whether the old and new entities are the same organisation, and resolving that takes time regardless of how clean the technical migration is.

What a migration does to AI search visibility

A migration moves your content out from under every URL an AI system has previously seen, and the tools for managing that are thinner than the ones Google gives you. There is no change of address request for ChatGPT, Perplexity or Claude. Each system re-discovers the new URLs on its own crawler’s schedule, and content already absorbed into a trained model still refers to the old domain until that model is retrained.

Three practical consequences:

• Redirects carry more weight than they used to. They are what turns a stale URL held by an AI system, or cited in an answer, into a live page for the user who clicks. This reinforces the existing advice to keep 301s live for at least 12 months, and is a reason to lean towards 24 on a domain that has accumulated citations.
• Confirm the AI crawlers can reach the new domain. Search-category crawlers (OAI-SearchBot, PerplexityBot) are what feed citations. If the new domain’s robots.txt or CDN configuration blocks them, citation visibility stops at the migration, and the site owner may never see a report telling them so. This is the check in step 9 of the launch checklist.
• Entity consistency is the part that transfers. The external signals listed above (Wikidata, Business Profile, directories, press coverage) are also what AI systems resolve a brand against. The entity work already required for a rename is doing double duty.

Expect AI citation recovery to lag organic recovery rather than track it. The redirect and entity work is the same work; only the timeline differs.

Footnotes

1. SEO Starter Guide — Google Search Central, “Things we believe you shouldn’t focus on” section. ↩

2. Move a site with URL changes — Google Search Central ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Your site, your rules: new AI traffic options for all customers — Cloudflare ↩

4. Have it both ways: stay discoverable in search while disallowing AI training — Cloudflare Blog, 15 September 2026 ↩

5. Change of Address tool — Search Console Help ↩ ↩² ↩³