A Checklist Beyond Redirects (2026)
Website Migration SEO: How to Move a Site Without Losing Ranking
Most rebrands end up moving a website. Most website moves are planned in a spreadsheet: the old URL in column A, the new URL in column B, and a 301 redirect between them. That spreadsheet is necessary. It is also the smallest part of the job.
Google’s site-move guidance asks for considerably more:
- a prepared and tested replacement site;
- old URLs mapped to their genuine new equivalents;
- server-side permanent redirects;
- verified canonical annotations;
- a new sitemap;
- redirects retained for at least a year, while Google recrawls the old URLs, transfers signals and reassesses the links pointing at the former site.
A year. Not the fortnight after launch when the project budget closes.
The gap between those two versions of the job is where rankings go.
Picture your employment law page. Google knows it answers questions about settlement agreements, that it is the canonical version, that it loads in under three seconds, and that the Law Society’s find-a-solicitor listing points at it. That knowledge is the asset.
The URL is just where it is filed. Move the URL without the rest, and the redirect tests green while the enquiries from that page stop.
If your firm is rebranding ahead of a growth push, a merger or a sale, that risk arrives at the worst moment: when the market is looking hardest at you.
Whether the rebuild is handled by an in-house team or a web design agency, this is the technical foundation to hold them to.
Summary (TL;DR)
- Map each old URL to a genuinely equivalent new page with server-side 301/308 redirects; avoid page-to-section or multi-hop redirects.
- Ensure canonical tags, XML sitemap and internal links all point to final URLs and carry structured data and organisation markup.
- Verify server HTML rendering, avoid thin client-only content, and pass Core Web Vitals on staging for every core template before launch.
- Record a pre-launch baseline, keep analytics and Search Console verified, and measure recovery by page groups, query clusters and conversions.
- List and verify every hostname variant, submit Change of Address for domain moves, and retain redirects at least one year.
How a Website Migration Keeps Its Search Equity
A website migration keeps its search equity when every signal Google attaches to the old URLs is moved deliberately:
- relevance, through relevant redirect mapping;
- meaning, through canonicals and sitemaps;
- content, through verified rendering;
- trust, through domain-level notices.
Measurement must survive, too, or nobody can prove the rest did.
Three supporting points:
- Google treats 301 and 308 responses as permanent moves, but a redirect only transfers signals when the destination genuinely replaces the original page.
- Google recommends keeping redirects in place for at least a year so it can recrawl old URLs and reassess external links.
- Google publishes no universal recovery period after a migration, so recovery has to be measured by page group, query cluster and conversions.
Website migration SEO is the transfer of a site’s search signals and tracking to new URLs through mapped 301 redirects, correct canonicals and verified rendering.
Why Migrations Lose Rankings When Every Redirect Works
Start with the case for the redirect spreadsheet, because it is a good one.
A missing redirect is the one migration failure that is guaranteed, immediate and visible: a high-value URL returns a 404, and its rankings go with it.
Redirects are also testable. Crawl the old URL list, confirm that each row redirects to a live page with a 301 response, and tick the box. Practitioners focus there because it is where the most obvious damage happens.
The trouble is what a redirect actually communicates. It tells Google where a page went. It says nothing about whether the new page deserves what the old one earned.
Google has to work that out from everything else: does the destination cover the same subject, does its canonical tag agree with the redirect, can Googlebot render its content, and is it linked from the rest of the site?
Google’s own guidance says as much. It treats 301 and 308 as permanent moves, then adds relevant mapping, correct canonicals, updated sitemaps and ongoing monitoring as separate requirements. The redirect is necessary. It is not proof.
“A redirect is an instruction, and an instruction carries no evidence. It tells Google where a page went; it cannot tell Google that the new page deserves what the old one earned. That judgement is made from content, canonicals, internal links, rendering and speed. Migrate the instruction without the evidence, and the rankings follow the evidence, which stayed behind.”
In professional services, the evidence usually goes missing during the design phase, well before anyone touches the redirect map:
- Content is cut. A redesign trims a 1,200-word employment law page to 300 words “because nobody reads that much”. The page that answered specific questions about settlement agreements now answers none of them.
- Profiles are gutted. A partner profile that lists sectors, cases and publications becomes a headshot and two lines.
- Services are merged. Three specific services collapse into one generic hub page.
Every one of those old URLs can still redirect perfectly. The destination simply no longer matches what the old URL ranked for.
The objection an MD will raise at this point is fair: “Our agency has redirects in the scope. Isn’t that the migration?” Ask them what else is in scope.
The table below is the complete list of items to be moved. Any row without a named owner and a named verification method is a row nobody is checking.
SignalWhat carries itHow a migration breaks itProof it survivedRelevanceRedirect to a genuine equivalent pageMapping to hubs, homepage or loosely related pagesPage-to-page map, reviewed against the queries each old URL ranked forCanonical meaningCanonical tags, sitemap, internal linksStaging canonicals shipped live; sitemap lists old URLs; nav links route through redirectsCrawl showing every indexable page self-canonicalises to its production URLRendered contentServer HTML and JavaScript outputContent only exists after client-side rendering; removed URLs return 200Raw server HTML contains the primary content, title and linksPerformanceTemplates, media, fonts, third-party scriptsHero video, font weights and consent banners added in the redesignAll three Core Web Vitals are passing on each key template before launchDomain identitySearch Console properties, Change of AddressUnverified hostname variants; old subdomains forgottenChange of Address submitted for every subdomain and www/non-www variantCrawl permissionrobots.txt, meta robots, X-Robots-TagStaging noindex or Disallow carried to productionLive response headers checked on launch dayMeasurementGA4 property, key events, Search ConsoleTag missing on new templates; enquiry events not rebuiltKey events firing on staging; pre-launch baseline exported
The Technical Controls, Signal by Signal
Relevance: Mapping Redirects to Genuine Equivalents
Does a 301 redirect preserve a page’s rankings? Only when it points to a page that answers the same query.
Google treats 301 and 308 responses as permanent moves and recommends server-side redirects wherever feasible, but its site-move guidance pairs that with relevant URL mapping.
Four rules follow:
- Map page to page, not page to section. The old “Commercial Property Disputes” URL goes to the new commercial property disputes page, not to a generic “Disputes” hub.
- Return a 410 for content that is genuinely gone. Don’t redirect it to something loosely related to keep the spreadsheet tidy.
- Redirect in a single hop. An old URL that passes through the http version, then the www version, then the new domain makes Googlebot fetch three times for one answer.
- Leave the redirects alone. Google recommends keeping them for at least a year.
The judgement call sits in consolidation. A rebrand is often when a firm finally merges its thin service pages into fewer, stronger ones, and that can be the right commercial decision. It is only safe for search when each merged page genuinely covers what the absorbed pages ranked for.
Consolidation without that content audit converts ranking pages into redirects pointing at pages that answer something else.
Canonical Meaning: Canonicals, Sitemaps and Internal Links Must Agree
Canonical tags, XML sitemaps and internal links are how a site tells Google which URL is the real one. After a migration, all three must name the same final URL. Google’s migration guidance asks site owners to verify canonical annotations and submit a new sitemap for exactly that reason.
The failure is a contradiction:
- The redirect says the page moved to the new domain;
- A canonical tag inherited from a staging template says the real version lives on the staging server;
- The sitemap still lists old URLs;
- The main navigation links to URLs that themselves redirect.
Each signal is small. Together, they tell Google the site does not know its own structure.
The controls are mechanical, which is good news, because mechanical checks can be delegated and verified:
- Crawl the staging site and confirm every indexable page self-canonicalises to its final production URL.
- Confirm that the new sitemap lists only final URLs that return a 200 status.
- Update internal links to point straight at final URLs rather than relying on redirects.
- Carry structured data across with updated names and URLs: Organisation markup, Person markup on partner profiles, and office location markup.
Rendered Content: What Googlebot Sees on a JavaScript Rebuild
Google’s JavaScript SEO documentation states that Googlebot queues pages that return a 200 HTTP status code for rendering, unless a robots meta tag or an HTTP header tells it not to index them. That sentence matters more on a replatform than anywhere else.
A move from a traditional WordPress build to a headless site on React, Next.js, Vue or Angular changes where your content lives.
It is either in the HTML the server sends, or in JavaScript that runs afterwards. If the words that ranked only appear after rendering, indexing depends on rendering going right.
Two failures recur:
- The thin shell. The server sends an almost empty page, and the content arrives later.
- The app that returns 200 for everything. A JavaScript router that shows a friendly “page not found” message with a 200 status gives Googlebot a page to queue for rendering instead of an error to act on.
The check takes minutes. View the raw server response for your ten most valuable pages, not the rendered page in a browser, and confirm the primary content, title, canonical tag and internal links are present.
A migration that preserves every URL and moves the content behind JavaScript has preserved the addresses and made the pages harder to read.
Performance: Core Web Vitals as a Launch Criterion
HTTP Archive, the open project that tracks how the web is built, found in its 2025 analysis that 56% of pages passed all three Core Web Vitals:
MetricPages passing (HTTP Archive, 2025)Largest Contentful Paint (LCP)74%Cumulative Layout Shift (CLS)72%Interaction to Next Paint (INP)97%All three together56%
Passing one metric is common. Passing the full set is only slightly better than a coin toss.
Visual redesigns are where that set gets broken. The rebrand brings an autoplaying hero film, four weights of a new brand typeface, a cookie consent banner that pushes the layout down, and a scrolling carousel of client logos. Each is a reasonable design request, and each costs LCP or CLS.
Make Core Web Vitals a launch criterion, measured on staging, for each core template: homepage, service page, partner profile and insight article.
Performance is a property of templates rather than individual pages, which is why it belongs on the same release gate as web accessibility compliance. Fixing either after launch means fixing it on every page built from the template.
Domain Identity: Change of Address for Every Variant
In June 2026, Google updated its site-move guidance.
Domain migrations should now submit Change of Address requests for all subdomains and for both www and non-www variants of the old domain, including variants that are not actively used.
Google states that domain migrations work best when all variants are migrated properly.
For a firm that has been online for fifteen years, “every variant” is rarely short. Alongside www and non-www, there is often:
- A careers subdomain from a recruitment drive;
- An insights subdomain from an old blog platform;
- A campaign microsite someone set up in 2019.
List every hostname the old domain has ever served. Verify each as a Google Search Console property and submit the change for each. This applies to domain moves only. A same-domain restructure uses redirects without the Change of Address tool.
Staging Leakage: The Noindex That Ships
The most expensive line of code in a migration is usually one word long: noindex.
Staging sites should be blocked from search engines, with password protection plus a noindex directive. The failure is that the block travels with the build.
A robots.txt Disallow copied from staging stops Google from crawling the entire new site. A noindex set in an X-Robots-Tag HTTP header is worse, because it never appears in the page source, so a visual check of the site misses it completely.
On launch day, check the live robots.txt, the meta robots tag and the response headers of every core template. It takes ten minutes. Skipping it can cost weeks of indexing.
What Changes When the Migration Is Also a Rebrand
Most migration guides assume the brand stays put. For a professional services firm, the migration usually exists because the brand did not.
A name change creates a problem no redirect map solves: clients, referrers and journalists keep typing the old firm name, and Google needs a reason to connect that query to the new domain. Give it one on the page:
- Put “formerly [Old Name]” on the About page and in the footer.
- Add the old name to the Organisation structured data using the schema.org alternateName property.
- Where the story matters, publish a proper announcement page explaining the change.
These signals turn the old-name query from an orphan into a route to the new site.
The off-site record needs the same attention:
- Legal directory profiles, professional body listings and trade association member pages all point to the old domain, and they are often among the few authoritative links a professional services firm holds.
- Regulated firms have specific obligations. An SRA-regulated practice must display the SRA digital badge on its website, so the badge must be reinstalled and made to work on the new domain.
- FCA-authorised firms should update the website listed on the Financial Services Register.
Neither regulatory step is an SEO task. Both belong on the migration plan.
Partner profiles deserve their own line. They are the pages prospects search by name before a first meeting, so a rebrand that thins them out loses rankings and weakens the pitch at the same time.
Measuring Recovery Without a Promised Date
Some ranking volatility after a URL migration is normal while Google recrawls and reindexes the site.
Google does not specify a universal settling period. Any plan that promises “traffic back in six weeks” has invented the number.
A credible plan measures recovery on three levels:
- Page groups. Practice or service pages, partner profiles, insight articles, and office location pages.
- Query clusters. Old firm name, new firm name, and service-plus-location queries such as “employment solicitor Manchester”.
- Conversions. Enquiry form submissions and tracked calls.
That requires a baseline captured before launch, long enough to include your normal seasonality. It also requires a measurement that survives the move:
- Keep the same GA4 property.
- Confirm the enquiry key events fire on the staging templates.
- Verify the new domain in Google Search Console before the switch.
- Annotate the launch date.
There is now a fourth layer.
Google introduced Generative AI performance reports in Search Console in 2026. They show how often URLs appear in AI Overviews and AI Mode, broken down by page, country, device and date, and Google says they were rolled out worldwide by 31/08/2026.
Export the report before launch. If your practice-area pages were cited in AI Overviews under the old URLs, you want to know whether the new URLs retain that visibility. Otherwise, a loss you cannot see goes unrecorded.
The second objection a sceptical MD raises: “If a dip is normal anyway, why pay for all this?” Because in week three, normal volatility and a broken migration produce the same headline number. Only page-group data tells you which one you have. Only one of them fixes itself.
“A migration without a pre-launch baseline cannot fail, because nothing it does can be measured. That is its appeal to everyone except the person paying for it. Record page-group traffic, query clusters, enquiries and AI Overview appearances before launch, and the migration becomes accountable. Skip it, and every outcome, good or bad, becomes an anecdote.”
Build the Signal Inventory Before the Design Brief
The order is where most migrations go wrong. The redirect map gets built at the end, when the new site already exists, so it can only record decisions the design has already made.
By then, the thin partner profiles, the merged service pages and the JavaScript-rendered content are fixed. The spreadsheet just documents the damage.
Reverse it. Before the design brief is signed, build the inventory:
- every indexable URL;
- the queries each one ranks for;
- the links pointing at it;
- the enquiries it produces;
- whether it appears in AI Overviews.
That inventory tells the designers which pages the new site must keep, and at what depth. It turns the migration from a redirect project into what it actually is: a controlled transfer of everything your site has earned.
Today, export twelve months of Google Search Console performance data by page, sort by clicks, and hand the top fifty URLs to whoever is building your new site with one question: what happens to each of these?
If you want that question answered before the rebrand commits you, request a free Brand Equity Audit™. It is a structured diagnostic of where your brand is losing commercial ground, including the search equity a rebuild puts at risk, and what to do about it.
Frequently Asked Questions
How long does SEO take to recover after a website migration?
Google does not publish a universal recovery period for website migrations. Some ranking volatility is normal while Google recrawls and reindexes the new URLs. Recovery should be judged by page group, query cluster and enquiry volume against a pre-launch baseline, not by a promised date.
How long should 301 redirects stay in place after a migration?
Google recommends keeping redirects in place for at least a year after a site move. That window lets Google recrawl the old URLs, transfer their signals and reassess external links. Redirects for URLs that still receive traffic or backlinks are worth keeping well beyond that minimum.
Do I need Google’s Change of Address tool for a website migration?
Yes, for a domain move. Since June 2026, Google’s guidance has required Change of Address requests covering every subdomain and both the www and non-www variants of the old domain, including unused ones. Migrations that stay on the same domain rely on redirects and do not use the tool.
Is a 308 redirect the same as a 301 redirect for SEO?
Yes. Google treats both 301 and 308 responses as permanent moves. The choice between them is a technical one about how browsers handle the request method. Either works, provided the redirect is server-side and points at a genuinely equivalent page.
Will changing our firm’s name hurt our search rankings?
A firm name change puts branded search at risk because clients and referrers continue to search for the old name. Mentioning the former name on the new site, listing it as an alternateName in the Organisation schema, and updating directory and regulator listings gives Google a clear route from the old name to the new domain.
Should removed pages be redirected or return a 410?
Removed pages with no genuine equivalent should return a 410 status. A 301 belongs only where a new page answers the same query as the old one. Redirecting deleted pages to loosely related pages or the homepage keeps the redirect map tidy but gives Google a mismatch rather than a replacement.
Can a website redesign hurt SEO without changing any URLs?
Yes. A redesign that keeps every URL can still cut the content that ranked, move it behind JavaScript rendering, introduce Core Web Vitals failures or break analytics tracking. Search signals attach to what a URL serves, not just its address, so a same-URL redesign needs the same checks as a migration.
When should SEO be involved in a website rebuild?
SEO should be involved before the design brief is signed. The inventory of ranking pages, their queries, links and conversions determines which content the new design must keep. Brought in at launch, SEO can only map redirects around decisions that have already removed the pages’ ranking value.