Specialist SEO
SEO Migration Services That Move Your Rankings With the Site
A relaunch is the quickest way to lose organic traffic it took years to build. Planned properly, it is also the cheapest moment to fix problems the old site has carried for just as long.
- years in SEO
- 6+
- site migrations handled
- 50+
- person doing the work
- 1
What goes wrong when a relaunch has no SEO migration plan
SEO migration work is the URL planning, redirect mapping, staging review, launch checks and monitoring that keep a redesigned, replatformed or rebranded site's rankings in place. When a business calls me after a redesign has gone badly, the new site usually looks better than the old one. The design is rarely the problem. The damage comes from things nobody on the build team was asked to own: URLs that changed with no redirect, redirects pointing at the homepage instead of the matching page, copy that got shortened in the rewrite, and a staging site that went live with its noindex tag or robots.txt block still in place.
Each of those on its own can be recovered. Together, and discovered a month late, they can take a long time to undo, because Google has already recrawled the new site, dropped the old URLs and started reassessing pages that lost their content and internal links at the same moment.
The fix is not a better checklist on launch day. It is treating search as a requirement from the start of the project, alongside design and functionality, so that the URL plan, templates and content decisions are made with the rankings in mind rather than patched afterwards.
Key takeaways
- Traffic losses after a relaunch rarely come from the new design. They come from missing redirects, dropped content, changed templates and staging settings that shipped to production.
- The redirect map starts from a full inventory of every URL that earns traffic, links or enquiries - not from the new sitemap.
- SEO has to be in the project from the first sprint. Bolting redirects on in launch week is how chains, gaps and blanket homepage redirects happen.
- The first days after launch decide most of the outcome, so I monitor daily and agree a rollback trigger before go-live.
- A migration is the one time you can restructure a site without a long internal debate. Use it to merge thin pages and fix old architecture, deliberately.
What's included in my SEO migration services
Each part is a deliverable your developers and project manager can see and check. How much of it a move needs depends on its type, set out in the table below.
Pre-migration benchmark and a full inventory of the URLs worth keeping
Before anything changes I record rankings for core queries, organic landing page traffic, backlinks and enquiries per page. The inventory comes from a full crawl plus Search Console, analytics, backlink data and your XML sitemaps - not from the new sitemap, which misses old URLs with links but no menu entry.
- Baseline of rankings, landing pages and enquiries
- Every old URL that earns traffic, links or leads
- The evidence for keeping, merging or retiring each page
A page-by-page content and metadata plan for the new site
We agree which pages carry over, merge, retire or are new. Each surviving page keeps its main copy, title, headings and internal links unless there is a written reason to change them. This is also where thin pages that split one topic get merged on purpose, with their ranking queries in view.
- Carry, merge, retire or new - decided per URL
- Titles, headings and copy compared with the old pages
- Internal link plan for the new templates
A one-to-one redirect map, tested against staging before launch
Every old URL with traffic, links or enquiries gets a destination chosen by a person, with patterns used only where pages genuinely match. The rules below are agreed with your developers before the map is written, and the full map is tested on staging so broken targets and chains are found while they cost nothing.
- Like for like: the closest equivalent page, never a blanket homepage redirect
- One hop: redirects from earlier rebuilds updated to the final URL
- Server-side permanent redirects, not JavaScript or meta refresh
- The long tail: PDFs, linked images, old campaign and parameter URLs
- Kept live indefinitely, with old domains left registered
Staging review written up as tickets your developers can pick up
Templates, rendered HTML, canonicals, structured data, internal links, mobile layout and page speed are all checked on staging. Staging stays blocked from search engines, and removing that block on launch day has a named owner. Findings arrive as developer tickets rather than a report someone has to interpret.
- Template and rendered output checks
- Canonical and structured data review
- A named owner for lifting the staging block
Go-live checks against production within hours of launch
On launch day I run the checks in the go-live table further down against the live site, not staging, and record the results. Anything that fails is fixed or rolled back before the site is left to settle. The rollback trigger is agreed in advance, so nobody has to debate it under pressure.
- Indexing controls and a redirect sample
- Canonicals, sitemaps and tracking on the new templates
- A rollback trigger agreed before go-live
Daily post-launch monitoring until rankings and enquiries settle
For the first weeks I watch crawl activity, indexing, rankings and enquiries per landing page every day, then weekly until the numbers stop moving. The project closes with a settled-state review that compares the new site with the benchmark and lists anything still to recover.
- Daily checks through the first weeks
- Weekly checks until the numbers settle
- Settled-state review against the baseline
Recovery work when a migration has already gone wrong
If the call comes after launch, the process runs backwards: I rebuild the old URL list from Search Console, backlink data, archived copies and old analytics, compare it with the live site, and fix the gaps in order of what they were worth. Recovery is faster the sooner it starts, so I ask for access on the first call.
- Old URL list rebuilt from several sources
- Gaps ranked by the value they lost
- Missing redirects, lost copy and staging settings fixed first
Experience
SEO Migration from someone who has done it many times
You work with me from the first call to the last report. No account managers, no hand-offs to a junior team.
Book a free call- years in SEO
- 6+
- client websites worked on
- 60+
- site migrations handled
- 50+
- documented case studies
- 35
Migration types and the risk each one carries
Not every move is equally dangerous. The type of change decides where most of the planning effort goes.
| Type of move | What changes | Where rankings are most at risk | Extra work it needs |
|---|---|---|---|
| Redesign, same URLs | Templates, navigation, copy | Lost body copy, weaker internal linking, heading and title changes | Template and content comparison against the old pages |
| Redesign with a new URL structure | Templates plus paths | Every changed URL that is not redirected to its true equivalent | Full URL inventory and one-to-one redirect map |
| Replatform (for example WordPress to Shopify) | CMS, URL patterns, rendering | Platform-forced URL formats, faceted URLs, lost schema, JavaScript rendering | Platform constraint review and rendered output checks |
| Domain change or rebrand | Every URL on the site | Signals moving across domains; brand searches during the transition | Change of Address in Search Console, backlink outreach for top links |
| Merging several sites into one | Domains, content, structure | Overlapping pages competing, content that has no home on the new site | Content consolidation plan before mapping |
| Moving markets or languages | Country folders, domains, hreflang | Broken hreflang and canonical logic across every market at once | Structure decision made with international SEO |
Small housekeeping moves, such as switching to HTTPS or tidying a handful of URLs, still need redirects and monitoring, but rarely the full process below.
The five phases of a migration I run
The timeline follows your build, not the other way round. I join as early as possible - ideally while the sitemap and wireframes are still being argued about.
- 1
Benchmark the old site
Starts the week I get access, ideally while the sitemap and wireframes are still open. Nothing else gets planned until there is a baseline to judge the new site against.
- 2
Plan URLs and content
Runs alongside the wireframes and content drafts, in one shared sheet that designers, writers and developers all work from, so every change to a page is visible.
- 3
Build and test the redirect map
Starts once the new URL structure is stable enough to map to, and finishes only when the complete map passes a test on staging.
- 4
Review staging
Happens as templates are built, not in launch week, so fixes land in the normal sprint cycle rather than as emergency patches.
- 5
Launch and monitor
Go-live checks within hours, daily monitoring for the first weeks, weekly after that, and a settled-state review once the numbers stop moving.
Free review
Get a free SEO Migration review
Send me your site. Before the call I look at your rankings and pages, then tell you what I would fix first and what it is likely worth.
Launch-week redirects versus a planned migration
Both approaches produce a list of redirects. Only one produces a site that keeps its traffic.
Redirects bolted on before go-live
- Built from the new sitemap, so old URLs with links but no menu entry get missed
- Pattern-based rules that send hundreds of pages to one category or the homepage
- Content cut during the redesign without anyone checking what it ranked for
- No baseline, so nobody can say afterwards what was lost or why
- Problems noticed when enquiries fall, weeks after launch
Migration planned from the first sprint
- Map built from a complete inventory of old URLs that earn traffic, links or leads
- Page-level destinations checked by a person, with patterns used only where pages really match
- Content decisions recorded per page, with ranking queries in view
- Benchmarks for rankings, traffic and enquiries taken before anything changes
- Daily monitoring and an agreed rollback trigger from the moment the site goes live
Go-live checks I run on the live site
These run on launch day against production, not staging. Anything that fails gets fixed or rolled back before the site is left to settle.
| Check | What I look for | If it fails |
|---|---|---|
| Indexing controls | No leftover noindex tags, robots.txt blocks or password protection from staging | Fix immediately - this is the most common launch-day disaster |
| Redirect sample | Old top pages return a single permanent redirect to the right destination | Correct the rule, re-test the full map |
| Canonicals and hostnames | Canonicals point at the live domain, not staging, and at the preferred version of each URL | Template fix, then recheck key page types |
| XML sitemaps | Only live, indexable new URLs listed; submitted in Search Console | Regenerate and resubmit |
| Tracking | Analytics, key events and enquiry tracking firing on the new templates | Restore before the baseline comparison becomes meaningless |
| Internal links | Navigation and body links point at new URLs directly, not through redirects | Update templates and in-content links |
Enquiries, not just rankings
A redesign changes how people convert, not just how pages rank
New templates move the phone number, shorten the form, rewrite the headline and drop the reviews block that used to sit by the button. Any of those can cut enquiries while rankings hold steady, and if tracking broke in the same release, nobody notices. I compare enquiries per landing page before and after launch, not just traffic, and flag conversion paths the new design removed.
Timescales, your team and what sits outside this work
A straightforward redesign needs me for a few weeks either side of launch. A replatform, domain move or site merger usually runs alongside the whole build, with most of the effort in the inventory and mapping phases and in the first weeks after go-live. I need access to Search Console, analytics and the staging environment, and a developer contact who can answer questions about how redirects and templates are deployed.
This is project work tied to one launch. It is not ongoing crawl, render and indexing work, which belongs to technical SEO, and it is not a full review of content and authority. If you want that picture before deciding what the new site should be, an SEO audit is the right first step, and its findings feed straight into the migration plan.
Making the new site better, not just safe
Keeping rankings is the minimum. A migration is also the moment to merge pages that split one topic across three URLs, retire content that no longer earns its place, and fix the structure the old site outgrew. Those decisions go better with keyword research behind them and a content strategy for what the new site should cover.
Online stores carry extra risk in category and faceted URLs; e-commerce SEO covers that in depth. And because redesigns so often break measurement, analytics should be tested on staging, not discovered missing after launch; a GA4 audit covers it when a quick check is not enough. The SEO services overview shows how the rest fits together.
Growth from real projects
Learn more about SEO Migration
Often needed alongside this
SEO Migration Services FAQs
When should SEO migration planning start in a website redesign?
As early as possible, ideally before the sitemap and wireframes are signed off. URL structure, page templates and content decisions all affect rankings, and changing them late is expensive. Joining in the last fortnight before launch still helps, but it limits the work to damage control rather than planning.
Will we lose traffic after a website migration?
Some short-term movement is normal while Google recrawls and reprocesses the site, especially after a domain change. A well-planned migration keeps that dip small and brief. I cannot promise no fluctuation, and anyone who does is guessing, but large, lasting losses almost always trace back to avoidable mistakes.
How long should redirects stay in place?
At least a year, and I recommend keeping them indefinitely. Old links on other sites, bookmarks and email signatures keep sending people to the old URLs for years. Removing redirects to tidy a server config throws that value away for no real benefit.
Can you help if our site has already launched and traffic dropped?
Yes. I rebuild the list of old URLs from Search Console, backlink tools, analytics and archived copies of the site, compare it with what is live now, and fix the gaps in order of value. The sooner this starts after launch, the more of the lost ground comes back quickly.
Do you work with our developers or agency, or replace them?
I work alongside them. Your developers or build agency own the site; I provide the URL plan, redirect map, staging review and launch checks, and write findings as tickets they can pick up. I do not need to touch your code or hosting to do this well.
Is a platform change riskier than a redesign?
Usually, yes. A new platform often forces new URL formats, handles categories and filters differently, and can render content with JavaScript in ways the old site did not. Each of those needs checking on staging before launch, on top of the normal redirect and content work.
Planning a relaunch? Get SEO migration advice before the URLs are set
Share your launch date, platform and what is changing. In a free 30-minute call we will go through where your organic traffic comes from today, which parts of the move carry the most risk, and what needs planning before the build goes much further.