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 (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 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. 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 the most 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 URL cannot hold a position on its own: it needs a live host page, a live image file, and the connection between the two intact. Break any one of those and the result drops out.

Three failure patterns follow from that, in increasing order of damage:

• Images left on the old domain, referenced by pages on the new one. Referral traffic holds at first, because the page redirects work. But the old domain’s pages fall out of the index over the following months, the images lose the host page context they were ranking on, and there is no image-level redirect to consolidate anything onto the new URLs. The decay is slow enough that it is usually noticed long after the migration is signed off.
• Images referenced but never uploaded to the new site. Googlebot renders the new page, finds the image missing, and the image is dropped from results. This is the fastest and most complete loss of the three, and the easiest to catch with a pre-launch crawl.
• Images replaced with visually different versions at the same time as the move. Re-shot photography or a redesigned graphic is a new asset as far as Google is concerned, whatever the URL does. Treat a visual refresh as a separate change from the migration. Note what this does not mean: still redirect the old image URLs. Other sites’ embeds depend on them, and Google’s guidance to move image URLs carries no exception for changed content. What you drop is the expectation that a new photograph inherits the old one’s positions, not the redirect itself.

What is safe to change during the move. Converting formats (JPEG or PNG to WebP or AVIF) is fine and worth doing for the payload reduction. Renaming files to something descriptive is fine too, as long as each old URL has its own one-hop 301 to its specific replacement. What breaks it is the shortcuts: redirect chains, and batch-redirecting a set of missing images to a single fallback like a logo. Google’s site move guidance warns against redirecting many old URLs to “one irrelevant single URL destination”, which “might be treated as a soft 404 error”.¹ That instruction is written about pages rather than images, but the reasoning transfers: a redirect is a claim that this asset moved here, and a logo standing in for fifty missing photographs is not that.

A URL restructure on the same domain is still an image migration. Keeping the domain makes it easy to assume the images are unaffected, and they are not: the host pages have moved, and that is what image results depend on. One approach circulates for this case, keeping the old image URLs live so that a Google Images click lands on the old HTML page, which then redirects to the new one. It does work, and the user arrives in the right place, because the Visit click goes to the host page rather than the file. Treat it as a bridge rather than a fix. The old page is redirecting, so it leaves the index over the following months, and once it does the old image has no live host page and follows it out. If a particular image genuinely drives traffic, the durable version is to keep that image embedded on the new page.

Alt text and the references that point at images are separate assets from the files. If image results depend on host page context, then the alt attribute is part of what ranks, and it is routinely lost in a CMS migration when the media library is re-imported: the files arrive, the metadata does not. This is the one image failure that hits migrations where the domain never changes at all, so it survives a redirect-focused QA pass untouched. Export alt text alongside the image URLs when you baseline, and diff it after launch rather than spot-checking.

The same applies to every reference pointing at an image, which a page-level redirect map does not touch: <img> and srcset paths hardcoded in content bodies, Open Graph and Twitter Card image tags, the image property in JSON-LD blocks, and any image entries in the sitemap. These can all keep pointing at old URLs long after the pages themselves have moved, leaving working pages that reference a domain you are about to switch off. Crawl the new site for external image references before decommissioning anything.

Expect image recovery to lag page recovery. Google’s guidance for a site move overall is that a small to medium site takes a few weeks for most pages to move across, with larger sites taking longer.¹ Google publishes no image-specific timeline, and practitioners consistently report images taking longer than that to settle. Plan for it rather than treating a slow image recovery as evidence something is broken.

Two things help. Submitting the new sitemap aids discovery, and an image sitemap is worth having if you do not already run one; note that image sitemap entries attach <image:image> elements to a host page’s <url> entry rather than listing image URLs on their own, so there is no standalone list of image URLs to submit.² Second, reference each image by one consistent URL across the site. Google asks for this explicitly, so that it can cache and reuse an image rather than requesting it repeatedly, and notes that images referenced across many pages draw on the site’s overall crawl budget.³ A migration that scatters the same asset across several URL variants makes recrawling slower at exactly the point you need it fastest.

If images are served from a CDN or a media subdomain, that is explicitly supported, and it insulates image URLs from future CMS and template changes. Image sitemaps are the one sitemap type allowed to reference other domains for exactly this reason.² Two conditions are easy to miss. The host’s robots.txt must not disallow crawling of the images, and it is a different file from your main site’s. And Search Console coverage depends on your property type: a Domain property (sc-domain:) already covers every subdomain, so a media subdomain needs nothing extra, while a URL-prefix property does not, and a genuine third-party CDN domain is outside both. Google frames verifying the image host as encouraged rather than required, and the benefit is diagnostic: it is how you get told about crawl errors on those URLs.³

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
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. From 15 September 2026, newly onboarded domains have the Training and Agent AI crawler categories blocked by default on ad-displaying pages, with Search still allowed. And blocking the Training category, if you choose to, also blocks Googlebot, Applebot and Bingbot, because multi-purpose crawlers are judged on all their behaviours.⁴ 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.⁵ Where this guide says 24 months, that is a practitioner extension for domains carrying a lot of accumulated links or citations, not a second Google rule. 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, 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. 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
• 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
• 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.

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. Move a site with URL changes — Google Search Central ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Image sitemaps — Google Search Central ↩ ↩²

3. Google Images best practices — Google Search Central ↩ ↩²

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

5. Move a site with URL changes — Google Search Central ↩