HomeServicesWebsite Migration SEO

SEO

Website Migration SEO

A migration is the one SEO job where you can lose in a day what took years to earn. Most of the damage is not mysterious: addresses that changed without a redirect, a noindex tag copied across from staging, content that only appears after JavaScript runs. We plan those out before launch, and we will not promise you a move with no dip at all.

Start a project See what we build

What is included

A full inventory of live URLs drawn from a crawl, Search Console and analytics
A redirect map from every old URL to its closest new equivalent, with the reasoning for each exception
A crawl of the staging site, including a check of what a non-rendering crawler receives
A written list of staging settings to switch off at launch: noindex, robots rules, access control and canonical targets
Analytics and conversion tracking tested on staging and again on the live site

Talk through what you need

On this page

What is an SEO migration, and why does it put traffic at risk?
What actually breaks in a website migration?
Which kind of website migration are you planning, and how risky is it?
Why does the redirect map decide most migration outcomes?
What does a safe website migration look like, in order?
What should be checked before a migration goes live?
What should be checked straight after launch, and in the weeks that follow?
Can any agency promise a migration with no traffic loss?
When should you not migrate, or change less?
Who should run the migration: an agency, a freelancer or your own developer?
How do you judge a website migration agency?
What decides what a website migration costs?
What is our record on migrations, and who does the work?

What is an SEO migration, and why does it put traffic at risk?

An SEO migration is a change to a website's URLs, platform, domain, structure or templates, planned so that search engines can find the new version of every page that mattered. It puts traffic at risk because search engines know your site by its addresses, and a migration changes the addresses. Anything not carried across properly can fall out of the results.

Not every redesign is a migration. A new look on the same platform, with the same URLs and the same copy, is a low-risk change. The risk rises with each thing you alter at once: the platform, the URL structure, the domain, the page templates, the copy, the navigation. Each is a separate way for a page to drop out of the index, and when several change together, working out which one caused a fall becomes guesswork.

What you are protecting is specific. It is the pages that bring in enquiries, the links other sites have pointed at them over the years, and the history a search engine holds about each address. We treat that as a narrow part of the wider search work, with a plain brief: leave the new site as findable as the old one on the pages that earn money, and be honest about the parts where that is hard.

A migration is also the best moment to fix what was already wrong, such as thin duplicate pages, redirect chains and old URL patterns. That only helps if the fixing is planned. Fixing everything in the same release is how a migration becomes impossible to diagnose.

The point
A migration is also the best moment to fix what was already wrong, such as thin duplicate pages, redirect chains and old URL patterns.

What actually breaks in a website migration?

Nine things break most often: URLs changed without a redirect, redirects sent to the wrong place, canonical tags naming old or staging addresses, noindex rules copied from staging, content drawn only by JavaScript, stale internal links, broken analytics, content cut without a record, and structured data or sitemaps describing the old site.

URLs that change with no redirect. The old address now returns a 404. Every link, bookmark and search result pointing at it lands on an error page, and the history search engines held for it goes nowhere. This is the most common cause of lasting loss and the most avoidable.
Redirects that exist but go to the wrong place. Sending hundreds of old product or article URLs to the homepage, or to one category, is treated by search engines much as if the pages had gone; Google describes this pattern as likely to be handled as a soft 404. Redirect chains, where A goes to B goes to C, slow crawling and are often left over from earlier moves.
Canonical tags pointing at the wrong address. A canonical that still names the old domain, the staging domain or a URL that no longer exists tells search engines to prefer a page that is not there. It is a template-level setting, so one mistake affects every page built from that template.
A noindex or robots.txt block carried over from staging. Staging sites are kept out of search with noindex tags or robots rules. If either is copied to the live site, the new pages ask not to be indexed from day one. It looks perfect in a browser, which is why it survives, and it is the first thing a technical audit looks for.
Content that only exists after JavaScript runs. A new front end can serve an almost empty page and draw the content in the browser. Google often copes, with a delay; many other crawlers do not. Check what the response contains, not what the screen shows.
Internal links still pointing at old URLs. Menus, breadcrumbs, in-content links and sitemaps that name the old addresses push every click through a redirect and tell crawlers the old structure is current. They should point directly at the final URL.
Analytics that stop recording. A tag container not carried across, events renamed, or a form rebuilt without its conversion event leaves a gap in the data exactly when you need to compare before and after. Without it, nobody can say whether traffic fell or only the measurement did.
Content cut, merged or rewritten without a record. A cleaner design often means shorter pages. The page that ranked for a particular question can lose the section that answered it, and the ranking goes with it. Titles, headings and copy are part of what is being migrated, not only the addresses.
Structured data, hreflang and sitemaps that describe the old site. Markup that no longer matches the page, hreflang pointing at addresses that now redirect, and an XML sitemap listing the old structure all send mixed signals. Sites serving several countries carry the most risk here.

Which kind of website migration are you planning, and how risky is it?

Risk follows how much changes at once. A redesign that keeps every URL sits at the low end; a new domain, a new platform and a new URL structure together sit at the high end. The table sorts the common cases by what changes, what usually goes wrong and what the plan must include. Count how many rows your project combines.

Type of move	What changes	Main risk	What the plan must include
Redesign, same platform, same URLs	Look, layout, templates and probably copy. The addresses stay as they are.	Titles, headings and copy are cut or rewritten, and rankings move because the pages changed rather than the URLs.	A record of what each key page says and ranks for now, and a decision on every cut before it is made.
Replatform, URLs mostly unchanged	The CMS or commerce engine underneath. Platforms generate URLs differently by default.	Small differences in trailing slashes, capitalisation, parameters and folder names, each of which is an unmapped page. Moves to or from WordPress are a common case; see WordPress development.	A comparison of how the two platforms form URLs, and a redirect for every difference found.
Replatform with a new URL structure	The platform and the address of nearly every page.	The largest number of redirects, and the highest chance of chains, orphaned pages and mismatched internal links. Stores are the heavy end; see e-commerce replatforming.	A full map with merge and retire decisions, internal links rewritten to final URLs, and monitoring against a baseline.
Domain change or rebrand	The domain itself, often with the brand name and copy.	Everything the old domain earned has to be passed across, and links from other sites still point at the old domain.	Page-for-page server-level redirects, Search Console's change of address step, updated canonicals, sitemaps and profiles, and the old domain kept registered and redirecting.
HTTP to HTTPS, or www to non-www	The protocol or host name. The paths stay put.	Pages reachable on several versions, with canonicals and sitemaps naming the wrong one.	One version chosen, every other version redirecting to it in a single step, and every internal reference updated.
Merging sites, or moving a subdomain into a folder	Content from several properties brought into one.	Overlapping pages compete or get dropped, and redirects span different platforms.	A merge decision for each overlapping page, redirects from every source and one consistent canonical plan.
New country or language versions	The addresses, and the relationships between versions.	hreflang that is not reciprocal or points at redirected URLs, so the wrong version is served.	A consistent hreflang set across all versions, covered in more depth under international SEO.

Why does the redirect map decide most migration outcomes?

Because the redirect map is the only thing connecting what search engines already know to what you are about to launch. Each old URL that earned traffic, links or rankings needs a permanent, server-side redirect, in one step, to its closest equivalent on the new site. Where the map is complete and accurate, the signals those pages built up can follow them. Where a row is missing, they cannot.

Building it is slow, unglamorous work. The URL list comes from three places rather than one: a crawl of the live site, Search Console and analytics, because each sees pages the others miss, such as old campaign landing pages, parameter versions and PDFs. Every URL is then given a destination, and the map records why. Some pages merge. Some have no equivalent and are retired deliberately, with a redirect to a relevant parent or a proper 410, and that choice is made on purpose.

Two shortcuts do most of the harm. One is a pattern rule that sends every old product or article to the homepage, which looks complete in a spreadsheet and teaches search engines nothing. The other is “we will sort the 404s out after launch”, which leaves pages broken at the moment they are being re-crawled most closely. Redirects belong at server level, tested on staging against the whole list, and live from the first minute.

A developer can write the rules. Deciding what each of two thousand old URLs should become is a search decision, and it is the one that gets rushed when a launch date is fixed. Treat the redirects as permanent: they stay for as long as the old addresses have links or visitors.

The point
Deciding what each of two thousand old URLs should become is a search decision, and it is the one that gets rushed when a launch date is fixed.

What does a safe website migration look like, in order?

Eight steps, in this order: record the baseline, inventory every URL, decide what each page becomes, build the redirect map, build and test on private staging, run the pre-launch checks, launch with the map live, and monitor against the baseline. Skipping the first three is what makes the last five frantic.

Record the baseline. Before anything changes: what ranks and for which queries, which pages earn links, which produce enquiries, how the site performs on Core Web Vitals and what Search Console shows as indexed. This is the only way to tell afterwards whether something fell or merely feels lower. A proper SEO audit of the old site produces most of it.
Inventory every URL. A crawl of the live site, then Search Console and analytics added in, so pages the crawler cannot reach are included. Mark which earn traffic, which carry links, which are duplicates and which can go.
Decide what each page becomes. Keep, merge, rewrite or retire. Decisions made now cost minutes; made after launch they cost rankings. Content that ranks is kept unless there is a reason to change it, and the reason is written down.
Build the redirect map and the new structure together. Old to new, one row per URL, with the reason. Internal links, menus, breadcrumbs, canonical targets and the XML sitemap are specified against final URLs, not against the redirects.
Build and test on private staging. Staging is protected with access control, not only a noindex tag, and crawled as if it were live, including a check of what a crawler that does not run JavaScript receives from each template. When we build the site, this is part of the website build itself.
Run the pre-launch checks. The redirect map against the full URL list, canonicals, noindex and robots rules, titles and headings, structured data and analytics events. The table in the next section lists them.
Launch with the redirects live from the first minute. The old and new sites are never both answering, a rollback is available, and the staging-only settings are switched off in a written order rather than from memory.
Monitor against the baseline. Crawl errors, indexation, redirects, rankings and enquiries compared with what was recorded before. Expect movement. The question is whether it is the movement of re-crawling or the sign of something broken, and the redirects stay in place either way.

What should be checked before a migration goes live?

Check nine things on staging: the redirect map against the full URL list, indexing rules, canonical tags, what a non-rendering crawler receives, titles and key copy, internal links, structured data and sitemaps, analytics, and speed. Each is cheap to fix on staging and costly after launch. A longer working version is in the migration checklist article.

Check	What you are looking for	Why it matters
Redirect map against the full URL list	Every old URL returns one permanent redirect to a page that loads normally on the new site. No chains, loops or 404s.	Redirects are how earned signals move. A missing row is a lost page.
Noindex, robots.txt and access control	Staging blocks are present on staging and absent from the live build. The live robots.txt allows crawling of what should be crawled.	A copied noindex asks search engines to drop the whole new site.
Canonical tags	Each page's canonical names its own final live URL: not staging, not the old domain, not a redirect.	Wrong canonicals point authority at addresses that do not exist.
What a non-rendering crawler receives	Title, meta description, one h1, body copy, internal links and structured data are present in the raw HTML of every template.	Content drawn only by JavaScript can be indexed late, partly or not at all, and many crawlers never see it.
Titles, headings and key copy	The pages that ranked still carry the wording that matched the queries, unless a change was agreed.	Quiet copy changes are an ordinary cause of ranking movement that has nothing to do with URLs.
Internal links and navigation	Menus, breadcrumbs and in-content links point at final URLs with no hop through a redirect.	Stale links keep the old structure alive and add a step to every click.
Structured data, sitemaps and hreflang	Markup validates and matches the visible page. The XML sitemap lists only final, indexable URLs. hreflang is reciprocal.	Each is a signal, and a wrong one contradicts the rest.
Analytics and conversion tracking	Page views and every conversion event (forms, calls, emails, WhatsApp clicks) record correctly on staging and on a test of the live site.	Without them you cannot compare before and after.
Speed and mobile behaviour	Core Web Vitals on real mobile conditions are no worse than the old site on the pages that earn traffic.	A slower site gives back what the redesign was meant to gain.

What should be checked straight after launch, and in the weeks that follow?

Straight after launch, test the redirects on the live domain, confirm the site is indexable, submit the new sitemap and check analytics is recording. In the weeks that follow, watch Search Console for crawl errors and indexation, compare traffic and enquiries with the baseline, and fix 404s as they surface.

Redirects on the live domain. Test the whole map against the live site, not a sample. Live servers sometimes behave differently from staging, particularly where a host or CDN rewrites rules.
Indexability. Confirm the live pages carry no noindex, the live robots.txt is the intended one and canonicals name live URLs. Spot-check key pages with the URL Inspection tool in Google Search Console.
The sitemap. The XML sitemap lists final URLs only and is submitted in Search Console, so crawlers have a clean list of the new structure to work from.
Analytics and conversions. A test enquiry through every form and a call to the tracked number, confirmed in GA4, before the first real one is missed.
Crawl errors and indexation in Search Console. New 404s, redirect errors, soft 404s and pages discovered but not indexed. Triage by whether the URL earned traffic or links before the move.
Traffic and enquiries against the baseline. Expect old URLs to lose traffic as new ones gain it. The comparison that matters is the combined picture, page group by page group, and the enquiries, not one day's graph.
Server logs, where they exist. Log analysis shows how search engines are crawling the new site and whether they are still spending time on old addresses.
Links from other sites. Look for linked addresses the map missed, add the redirects, and ask the most valuable linking sites to update. Later updates and plugin changes can reintroduce faults, so keep a monitoring routine going, whether in your own team or through a website care plan.

Can any agency promise a migration with no traffic loss?

No. Anyone who promises zero traffic loss is promising something they do not control. Search engines decide when to re-crawl, re-evaluate and re-rank the new pages, and that process involves some temporary movement even on a well-run move. Google's own guidance on site moves tells you to expect it.

What a supplier can control is the list of things that cause permanent loss: unmapped URLs, wrong redirects, blocked or mis-canonicalised pages, unreadable content and lost tracking. We commit to the work on that list, to testing it before launch and to watching it afterwards. We cannot commit to a number, and we will not put one in a proposal. Most of those causes are the technical checks that decide whether a move recovers.

There is a difference between a dip and a loss. A dip is the new site being re-crawled and re-ranked, and it settles. A loss is a page that cannot be found, or a ranking the new version no longer deserves because its content got worse. The first is expected. The second is diagnosable, which is why a baseline recorded before launch is worth more than any promise made after it.

Be wary of any supplier who offers a before-and-after traffic graph as proof. One site's graph says nothing about yours, because the sector, the URLs and the changes made all differ. We will not quote one either.

The point
Be wary of any supplier who offers a before-and-after traffic graph as proof.

When should you not migrate, or change less?

When the current site earns enquiries from search and the reason for the move is cosmetic. Changing the platform, the URLs and the copy together for a fresher look is the combination that most often costs traffic. If the old site works, keep its URLs and fix what is actually broken first.

Phasing helps. Move the platform first and hold the URLs and copy still, then change the structure later, once the new platform is stable. That takes longer and can mean a second round of redirects, but when something moves you know what moved it. Whether it is worth doing depends on how much of your enquiry volume rides on search; if hardly any does, a single move is reasonable.

Sometimes the right answer is no migration at all. A slow site can often be repaired in place, and whether the platform is really the constraint is the question explored in WordPress or a custom build. Be suspicious of any supplier who recommends a rebuild without checking.

Timing matters too. The busiest trading weeks, or a launch date driven by a deadline unrelated to readiness, are poor times to move. A launch that slips is annoying; a broken one in the middle of peak season is expensive.

The point
The busiest trading weeks, or a launch date driven by a deadline unrelated to readiness, are poor times to move.

Who should run the migration: an agency, a freelancer or your own developer?

Use your own developer when the URLs are not changing and the site is small. Use a specialist when the URLs, platform or domain change on a site that earns enquiries from search. The deciding factor is who owns the redirect map and the testing, not who writes the code. The table compares the three.

Option	Suits	Watch for
Your own developer, or the agency building the site	A small site where the URLs stay the same, or a build supplier who has a clear migration brief and has done this before. We would sooner tell you that than sell you a project you do not need.	Migration is rarely in a build quote. Ask in writing who produces the URL map, who tests staging and who watches Search Console after launch. If the answer is nobody, the work is unowned.
A freelance SEO consultant	A site of modest size where one person can own the inventory, the map and the checks, and your developers will implement them.	One person is a single point of failure on launch day, and may be unable to change the site themselves. The wider trade-off is set out in freelancer, agency or in-house.
An SEO migration agency	Larger or more complex moves, such as a new platform, a new domain, thousands of URLs, a store or several countries, where search and development have to work to one plan.	Check that the people who plan the migration are the people who test it, and that the agency will work alongside your build supplier if it is not building the site.

How do you judge a website migration agency?

Ask who writes the URL map, whether staging is tested before launch, what is recorded as a baseline, how the agency tells a dip from a loss, and what you keep afterwards. Good answers are specific. A supplier who cannot describe launch day in order has not planned it. These seven questions work on us too.

Who produces the URL map, and from which sources? A good answer names a crawl, Search Console and analytics, and says every row has a reason. “We will set up redirects” is not an answer.
Will you test the staging site before it goes live, and with what? A good answer includes a crawl of staging, a check of the unrendered HTML and a written list of settings to switch off at launch.
What will you record before the move, and where do I see it? A good answer covers rankings and indexed pages by section, pages with links and enquiries, stored in accounts you can open yourself.
What will you refuse to do? A good answer has examples: launching without a tested redirect map, promising a traffic figure, or changing platform, URLs and copy in one release when it can be avoided.
What happens on launch day itself? A good answer describes the sequence, who decides to roll back and who is checking what in the first hours. Vagueness here is the warning sign.
How will you tell a normal dip from a real problem? A good answer names the measures, the comparison with the baseline and what would trigger a fix.
What do I keep afterwards? A good answer is the map, the crawl data and the launch notes, all in your accounts. You also deal with the people doing the work rather than an account manager passing messages along.

What decides what a website migration costs?

Cost is decided by the number of URLs to map, how much of the structure changes, how complex the platform is, whether a domain or country changes, and who builds the new site. We do not publish prices and we scope after looking at the site. A migration done alongside our own build is planned inside that build.

How many URLs there are. A forty-page brochure site and a store with a very large catalogue need the same method and very different amounts of mapping and checking. Stores repeat their problems at template level, which is the territory of e-commerce SEO.
How much of the structure changes. The same URLs on a new platform produce a small map of differences. A new structure produces a map of everything.
How complex the platform is. A standard CMS behaving in known ways is quicker to assess than a bespoke application or a headless build, and moving store data brings its own reconciliation work. Retailers weighing this up will find the wider picture on the e-commerce and retail sector page.
Whether a domain, a language or a country changes. Domain moves add Search Console steps and updates to canonicals, sitemaps and profiles. Several countries add hreflang across every version.
Who builds the new site. If we build it, the migration plan sits inside the build. If another supplier does, our work is the specification and the testing of their staging site.
How much checking you need afterwards. Larger sites with more at stake need more watching than a small one that kept its URLs.

What is our record on migrations, and who does the work?

We plan and test migrations as part of technical SEO and website development, with the search work and the build handled by one small team. Our delivery record to date is international rather than UK-based, and we will not pretend otherwise: we are building a UK client base now. We are not going to cite migration results on this page, because we would rather you could check the method than take a number on trust.

What we can point to is evidence of how we check things. In September 2026 we audited our own website and found that all 47 URLs in our sitemap returned identical HTML to a crawler that does not run JavaScript. We fixed it. That is not a migration result, but it is why a check of the unrendered HTML sits on the pre-launch list. You can see the sites we have built and judge them directly.

If you want to talk through a specific move, such as the platform, the domain and a rough count of URLs, send us the details. We will say whether it needs a specialist or whether your own developer can handle it. Prabhu Solutions is registered at 14 Chester Rise, Oldbury, B68 0SS, West Midlands, and the work runs remotely by default.

The point
If you want to talk through a specific move, such as the platform, the domain and a rough count of URLs, send us the details.

Capabilities

What Website Migration SEO covers

Not a menu to pick from. Most projects use some of this and ignore the rest, and the scope conversation is mostly about working out which half you actually need.

URL inventory and redirect map

Every live URL listed from a crawl, Search Console and analytics, then mapped one by one to its closest equivalent on the new site, so no page that earns traffic or links is left to a 404.

Indexation and canonical planning

Which pages should be indexed, which should be merged, and which canonical, noindex and robots rules the new site needs on day one, written down before the build is finished.

Rendering and template checks

A check of what a crawler that does not run JavaScript receives from each new template, so content, titles and structured data are in the HTML response rather than drawn afterwards.

Internal linking and navigation

Menus, breadcrumbs and in-content links carried across and pointed at final URLs rather than at redirects, so the new structure supports the pages that matter.

Analytics and Search Console continuity

GA4 events, conversions and Search Console properties checked before launch, so before and after can be compared without a gap in the data.

Staging control

Staging kept private and out of search with proper access control, plus a written list of every staging setting that has to change at launch.

Domain, subdomain and protocol moves

Domain changes with Search Console's change of address step where it applies, www and HTTPS resolution, and consistent hreflang where a site serves several countries.

Launch and post-launch monitoring

Redirects, indexation, crawl errors and enquiry tracking watched in the weeks after launch against the baseline, with a rollback available if the launch itself goes wrong.

The case for it

Why this is worth doing properly

A baseline before anything moves

We record what ranks, what earns links and what produces enquiries before the change. After launch, “it feels lower” becomes a comparison against numbers rather than an argument.

Redirects decided page by page

The map is built by looking at each URL, not by a rule that sends everything to the homepage. Pages with no equivalent are retired on purpose rather than lost by accident.

The people who plan it also test it

Search and development sit in one team, so a rendering fault or a leftover noindex is a ticket in a shared backlog. Where another supplier builds the site, we write the requirements and test their staging site before launch.

An honest account of the risk

We tell you which parts of your move carry the most risk, and that some temporary movement is normal. We do not put a traffic promise in a proposal, because nobody controls how a search engine re-crawls a new site.

You keep the reasoning

The redirect map, the crawl data and the launch notes are handed over as documents, so whoever maintains the site next inherits the decisions as well as the result.

What arrives

What you are handed, and who this suits

Deliverables

A baseline record of rankings, indexation, links and enquiries taken before the move
A URL inventory with a decision against every row
A redirect map from old to new, with reasons
A staging test report covering redirects, indexation rules, canonicals, rendering, structured data and tracking
A launch-day runbook: the order of changes, the settings to switch off and the rollback route
Tested analytics and conversion tracking on the new site
A post-launch monitoring report compared with the baseline
Handover notes so the next developer inherits the reasoning

Everything on that list is yours on final payment, in your own company's accounts — the handover is written into the contract, not offered as a favour at the end.

Usually a fit for

Businesses about to redesign a site that already brings in enquiries from search
Companies replatforming, for example from one CMS or e-commerce platform to another
Brands changing domain after a rename, merger or rebrand
Stores with large catalogues where the URL structure changes at template level
Sites that were migrated before and never recovered the traffic they had
Teams whose designer or developer is building the new site and who want an independent check before launch

Built with

Google Search Console
Google Analytics 4
301 redirect mapping
Robots.txt and XML sitemaps
Canonical tags
hreflang
Server-side rendering
Schema.org structured data
Core Web Vitals
Log file analysis

Chosen per project, not per fashion. If your team already runs something else and can maintain it, that usually wins.

Ask what this would involve for you

How we work

Four gates, and you sign off at each one

Every stage ends with something you can read and approve — inventory and baseline, map and plan, staging and pre-launch, launch and watch. Nothing moves to the next stage until you say so.

Inventory and baseline

Map and plan

Staging and pre-launch

Launch and watch

A crawl of the live site, joined to Search Console and analytics so pages a crawler cannot reach are included. We record what ranks, what earns links, what is indexed and which pages produce enquiries.

Every URL is given a destination: keep, merge, rewrite or retire. The redirect map, internal link targets, canonical rules and sitemap are specified against final URLs, with the reason for each decision written down.

The new site is crawled on private staging and tested for redirects, indexation rules, canonicals, rendering, titles, structured data and tracking. Faults are fixed on staging, where they are cheap.

Launch with the redirects live from the first minute, staging-only settings switched off in a written order and a rollback available. Then monitoring against the baseline, fixing what surfaces and keeping the redirects in place.

01
Inventory and baseline
A crawl of the live site, joined to Search Console and analytics so pages a crawler cannot reach are included. We record what ranks, what earns links, what is indexed and which pages produce enquiries.
02
Map and plan
Every URL is given a destination: keep, merge, rewrite or retire. The redirect map, internal link targets, canonical rules and sitemap are specified against final URLs, with the reason for each decision written down.
03
Staging and pre-launch
The new site is crawled on private staging and tested for redirects, indexation rules, canonicals, rendering, titles, structured data and tracking. Faults are fixed on staging, where they are cheap.
04
Launch and watch
Launch with the redirects live from the first minute, staging-only settings switched off in a written order and a rollback available. Then monitoring against the baseline, fixing what surfaces and keeping the redirects in place.

Explore Related Services

Frequently Asked Questions

What does an SEO migration agency actually do?

It plans the parts of a site change that search engines care about: which old URLs map to which new ones, what is indexable, what the new templates actually serve to a crawler, and whether tracking survives. It then tests those on staging before launch and monitors the result afterwards against a baseline recorded in advance.

Can anyone promise a migration with no traffic loss?

No. Search engines decide when to re-crawl and re-rank a new site, and temporary movement is normal even on a well-run move. What a supplier controls is the list of causes of permanent loss: unmapped URLs, wrong redirects, blocked pages and lost tracking. Be wary of anyone who puts a traffic figure in a proposal.

How do I choose a website migration agency?

Ask who produces the URL map and from which sources, whether the staging site is tested before launch, what is recorded as a baseline, and how they will tell a normal dip from a real fault. Good answers are specific. A supplier who cannot describe launch day in order has not planned it.

Do I need an SEO migration plan before a redesign?

If the new design keeps every URL and most of the copy, a short plan is enough. If the platform, the URL structure or the domain changes, you need a written plan with a redirect map and pre-launch tests. The more that changes at once, the harder it is to work out what caused a drop.

Will changing my domain name hurt my rankings?

It can, because everything the old domain earned has to be passed to the new one. Page-for-page 301 redirects at server level, updated canonicals and sitemaps, and Search Console's change of address step reduce the risk. They do not remove it, and links from other sites still point at the old domain for some time.

How long should 301 redirects stay in place?

Treat them as permanent. Keep each one for as long as the old address has links pointing at it or visitors arriving on it, which for most sites is a long time. Removing redirects to tidy the server is a common way to turn a recovered migration back into a broken one.

Is moving to HTTPS or dropping www a migration too?

Yes, a small one. The paths stay the same but the address of every page changes, so each old version must redirect to the chosen one in a single step, and canonicals, sitemaps and internal links must name it. It is the lowest-risk kind of move, and still one where leftovers cause duplicates.

What should a website migration plan include?

A baseline of current performance, a URL inventory with a decision per row, the redirect map, rules for indexing and canonicals, a staging test plan, a launch-day sequence with a rollback route, a list of staging settings to switch off, and a post-launch monitoring routine. Anything less leaves a gap someone discovers after launch.

Do you handle e-commerce store migrations?

Yes, as part of our e-commerce development work and with the same method: every product, category and page mapped before anything moves, data reconciled against the source, and monitoring afterwards. Stores are the heavy end of the work because catalogues repeat problems at template level. Store replatforming is scoped on catalogue size and data quality.

What does an SEO migration cost?

It depends on how many URLs need mapping, how much of the structure changes, how complex the platform is, whether a domain or country changes, and who builds the new site. We do not publish prices and we scope it after looking at the site. A migration done alongside our own build is planned inside that build.

Last reviewed: 8 October 2026 · Prabhu Solutions, 14 Chester Rise, Oldbury B68 0SS

Let's Build Something That Matters.

Tell us what you're trying to achieve and we'll help you find the right solution.

Start a Conversation