Site Migration Without Losing Rankings

First decide what kind of migration you are doing

“Website migration” can mean several different projects. The right controls depend on what is changing.

Change	What moves	Main search risk
Hosting or CDN	Infrastructure, but public URLs stay the same	Downtime, blocked access, slow responses or missing files
CMS or framework	How pages are built and rendered	Missing content, links, metadata, status codes or tracking
URL structure	Paths change on the same domain	Old URLs lose a relevant destination or signals conflict
Domain or subdomain	The public address changes	Search engines must process old-to-new relationships
Redesign	Templates, navigation and content presentation change	Important pages lose content, prominence, links or usable actions
Consolidation	Several pages or sites become fewer owners	Unclear page decisions and irrelevant bulk redirects

Google publishes separate guidance for moves with URL changes and hosting changes that keep the same public URLs. That distinction should be made before anyone writes a redirect file.

A hosting move with unchanged URLs does not need a new destination for every page. A domain or path change does. A framework change may keep every URL and still remove content from the rendered page.

Write down the exact changes. If the project combines a new domain, new CMS, new design, new copy and new URL structure, decide whether any part can move separately. Fewer simultaneous variables make a later problem easier to diagnose.

Record the site before anyone replaces it

The old site is the evidence. Once it is replaced, memory is not an adequate baseline.

Save a crawl and a page-level record while the current site is live. Include:

every known HTML page, image and downloadable file that receives links or search visits;
HTTP status, index rule and declared canonical;
title, main heading and useful page content;
navigation, breadcrumbs and contextual internal links;
structured data and international annotations where they apply;
Search Console clicks, impressions, queries and page groups;
analytics events and the business record tied to the page;
forms, phone links, booking tools, demos, carts and other critical actions.

Do not reduce the baseline to a list of ranking positions. Google’s traffic-drop guide recommends looking for patterns across pages, queries, countries, devices and search appearances. A longer comparison window can also reveal seasonality that would otherwise be blamed on the migration.

Search and business records answer different questions. Search Console can show that impressions or clicks changed. Your own systems show whether qualified calls, appointment requests, prospective-client enquiries, demos, trials or valid orders changed. Keep those records separate.

Give every old URL one destination decision

Every known old URL needs one decision:

Keep it: the URL and useful page remain.
Move it: the page has a relevant new URL.
Merge it: several old pages have one genuinely equivalent consolidated owner.
Retire it: there is no useful replacement, so the old URL returns an honest 404 or 410 response.

A redirect is not the decision. It implements the decision.

For a permanent move, Google recommends a permanent server-side redirect where possible. 301 and 308 are permanent. 302 and 307 are temporary and communicate a different intention. The Google redirect guide explains the distinction.

Do not send unrelated old pages to the homepage. Google says this can confuse users and may be treated as a soft 404. Do not preserve a page merely because it exists either. A removed page without a relevant replacement can return a real error response.

Use this migration decision record before launch:

Record field	Decision to make
Old URL	What public destination exists now?
Business role	Which buyer question or action does the page support?
Evidence at risk	Does it earn search clicks, links, visits or qualified actions?
Disposition	Keep, move, merge or retire?
New URL or status	Where should the old request resolve?
Content and link parity	Which useful facts, sections and relationships must remain?
Signal check	Do redirect, canonical, sitemap and internal links agree?
Critical-path test	Can the buyer complete the intended action?
Owner and severity	Who fixes a failure, and does it block launch?
Live result	What did the production test and post-launch crawl show?

Include old images and PDFs when they receive search visits or links. Google’s site-move guidance specifically calls out hosted images and downloads because they can have their own discovery and link history.

Make four signals agree on the new URL

The new destination should receive one consistent message.

Signal	Correct state after a URL move
Redirect	Old URL resolves to the final relevant destination
Canonical	New page identifies the intended new canonical URL
Sitemap	Lists the absolute new canonical URL
Internal links	Point directly to the new URL, not through the old one

These signals do different jobs, but they should not nominate competing URLs. A redirect to /new-service/, a canonical back to /old-service/ and a sitemap entry for a third version create an avoidable conflict.

Google recommends self-referencing canonicals on new URLs and internal links that point to the canonical destination. Its canonical documentation also warns against naming different canonicals through different methods.

The new XML sitemap should list fully qualified URLs that you want considered for Search. A sitemap helps discovery. It does not guarantee crawling, indexing or rankings.

Use Search Console’s Change of Address tool only for a qualifying domain or subdomain move, after the site has moved and redirects are active. Do not use it for ordinary path changes, an HTTP-to-HTTPS move or a hosting change with the same public URLs.

Google’s current site-move guide says to keep redirects as long as possible, generally at least one year. Users may still follow old links after search engines have processed the move, so many redirects remain useful beyond that period.

Test what the live server and rendered page actually return

A staging screenshot cannot prove the production site is ready.

Test the real response after the release is available at its final URL. Check:

status code and final redirect destination;
redirect loops and chains;
canonical and robots directives in HTML and response headers;
robots.txt access;
sitemap URLs and responses;
visible and rendered main content;
crawlable navigation and internal links;
structured data that still matches the visible page;
images, PDFs and other important resources;
forms, phone links, booking, intake, demos, cart and checkout;
analytics and conversion events.

This matters on JavaScript-heavy builds. Google can render JavaScript, but its JavaScript guidance recommends inspecting loaded resources, console errors and the rendered DOM. Links should be real anchor elements with href destinations. Canonicals and error states should remain clear after scripts run.

Staging controls also need a deliberate exit. If a test environment uses access control or noindex, record what must change before launch. Then inspect production. Google notes that crawlers must be allowed to access a page before they can read its robots meta or X-Robots-Tag rules.

For a hosting or CDN move, keep the old infrastructure available until traffic and crawler requests are reaching the new infrastructure correctly. Test the new host before changing DNS and watch availability after the cutover.

Use a go, hold or investigate launch gate

A checklist records activity. A launch gate records the decision.

Ruling	Conditions
Go	Critical URLs have approved outcomes, final responses work, signals agree, buyer actions pass and rollback is available.
Hold	A valuable URL has no destination, production is blocked or noindexed, rendered content is missing, tracking is absent or a critical action fails.
Investigate	The release works technically, but a dated search or business movement needs segmentation before anyone assigns cause.

Name the person who can stop the launch. Name the person who can reverse it. Define the rollback trigger before the release, when the decision is still calm.

A rollback should respond to a material technical or buyer-path failure—not one normal ranking change. Reversing a domain move or URL migration creates another change for users and search systems to process. Use the evidence and severity record.

Protect the buyer path in all five industries

The technical controls remain similar. The page relationships and critical actions change.

Industry	Pages and relationships to preserve	Critical action to test
Home Services	Service, market and location relationships; public profile and campaign landing links	Qualified call, estimate request and booking path
Healthcare	Service, provider and location facts; medically governed information and access routes	Appropriate appointment request without exposing protected information in analytics
Legal	Practice-area, attorney and jurisdiction relationships; approved public claims	Confidential prospective-client enquiry and consultation path
B2B SaaS	Product, use case, integration, comparison, pricing and documentation relationships	Demo, trial, signup and qualified pipeline event
eCommerce	Category, product, variant, inventory, policy and merchant-feed relationships	Product selection, cart, checkout and valid order record

Healthcare migrations require clinical, privacy and operations review for the actual content and measurement setup. Legal migrations require a qualified reviewer for the relevant jurisdiction, advertising rules and intake confidentiality. A technical migration checklist cannot grant either approval.

For B2B SaaS and eCommerce, compare the rendered page—not only source metadata. A framework or platform change can preserve a URL while changing which product facts, links or catalog relationships are visible after scripts run.

Measure crawl, index, visibility and business outcomes separately

Post-launch monitoring needs a sequence of questions:

Layer	Question	Useful evidence
Availability	Can users and crawlers reach the final URL?	Status checks, uptime and server logs
Crawl	Has Googlebot requested the old and new URLs?	Server logs and Crawl Stats
Index	Which URL does Search Console report?	URL Inspection and Page indexing
Visibility	Did impressions, queries, pages or average position change?	Search Console Performance report
Visits	Did organic landing-page sessions change?	Privacy-governed analytics
Qualified action	Did the right buyer complete the next step?	Call, appointment, intake, demo, trial or order records
Commercial result	Did the business accept and fulfil the work?	CRM, practice, pipeline or commerce records

Do not merge these into one “SEO score.” A page can be crawlable but not indexed. An indexed page can lose clicks because demand changed. Visits can remain stable while tracking breaks. A form submission is not automatically a qualified client or sale.

If you already monitor AI-assisted answers, keep the same defined question set and record each observation with its date, platform and conditions. Treat that as a separate visibility observation. It does not replace crawl, index, search or commercial records, and no migration can guarantee an AI citation or recommendation.

Diagnose the pattern before changing the site again

Start with the shape of the problem.

Pattern	First checks
Whole site disappears or falls sharply	Availability, robots rules, noindex, canonicals, DNS, Page indexing and tracking
One template falls	Rendered content, template canonicals, internal links, structured data and critical action
Old URLs remain while new URLs lag	Redirects, destination relevance, canonicals, sitemap and internal-link updates
Impressions hold but clicks fall	Queries, titles, snippets, search appearance and result competition
Search visits hold but leads/orders fall	Form, phone, booking, demo, cart, checkout and attribution changes
Search and business records move seasonally	Compare page/query groups and a longer historical window

Google says ranking fluctuations can occur while it recrawls and reindexes moved URLs. It does not publish one recovery deadline for every site. Recrawl requests and sitemaps can help discovery, but they do not force instant crawling or inclusion.

Fix a confirmed defect. Do not launch another broad redesign because one aggregate chart moved.

Bring the migration record to the review

If the project is planned or already in staging, gather the current domain, proposed destination, launch window, URL decision record and the person responsible for implementation.

Mindflow can review the evidence, identify the checks that should block launch and connect the migration to the broader Organic SEO service. Development and specialist implementation may be handled by your team or other specialists. Mindflow sets the evidence priorities and checks whether the recommendation still matches the result.

For broader diagnosis, use Does my site need technical SEO?. If the concern is page speed, start with Core Web Vitals in plain English. For create, merge and retire decisions outside the migration event, review planned pages versus publishing volume.

Request your Free Visibility Check or contact Mindflow with the migration record. Rankings, recovery timing, leads and revenue cannot be guaranteed.

Protect what already works before you move your website.