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/. Generally positive for SEO as it consolidates authority to one domain.

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 (Coverage 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

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 matching every existing URL to its destination on the new site. It is the single most important 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. Images accumulate link equity and image search traffic. Use the Image search type filter in GSC to identify which image URLs are driving clicks before migration.
• 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 destination.

Pages being deliberately removed with no equivalent should return 410 (Gone) rather than 404. A 410 signals to Googlebot that the removal is intentional, which speeds up de-indexation. 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

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 needs time to recrawl and transfer signals. Decommissioning the old server early is one of the most common causes 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, coverage 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)

Full recovery typically takes four to twelve weeks for a well-executed migration. 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. A mass redirect to the homepage destroys all page-level signals and looks like a spam signal to Google. Always redirect to the equivalent page.

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. It also does not apply to subdomain migrations (moving blog.example.com to example.com/blog/) or URL restructures on the same domain - only domain-to-domain moves.

Requirements:

• Verify ownership of both the old and new domains in Search Console before submitting
• 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
• It remains active for approximately 180 days, after which it expires automatically

After the window closes. The 180-day expiry applies 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.