The pages moved.
The rankings didn’t.
Pages redirect to a general destination, get consolidated, or lose the internal links that surfaced them.
SEO Migration
SEO Migration Services
SEO Migration Services
SEO Migration Services
Protect the traffic and AI visibility you’ve spent years building.
Protect the traffic and AI visibility you’ve spent years building.
Then improve on it, where the old architecture was holding it back.
Then improve on it, where the old architecture was holding it back.
A new platform, a new architecture or a new domain can make the site better. It can also lose years of search visibility if the move is handled as a rebuild rather than a migration. We work alongside your engineering team from the architecture decisions through launch and the weeks after.
What moves
A migration changes more than URLs.
The redirect map gets most of the attention. Traffic can disappear somewhere else entirely: content, templates, internal links, rendering, indexation, measurement. And the systems now answering questions about your business are part of that picture too, working from a cached index and references to your old URLs that do not clear the day your redirect goes live.
Hover or tap a layer →
Failure modes
Five clean launches that still lost traffic.
Five clean launches that still lost traffic.
Five clean launches that still lost traffic.
None of these involve a broken website. The launch went fine, the team celebrated, and the traffic went somewhere else.
The pages moved.
The catalogue moved.
The logic didn’t.
Products migrate. The variants, filters and category routes customers used to find them do not.
facetsPDP / PLP
The site works.
Search sees something else.
“Google renders JavaScript” is true right up until the category pages are the thing that does not render. The site passes every review, because every reviewer has a browser. You find out in a crawl, or you find out in the revenue.
renderingrobots
04
The right page exists. The wrong customer gets it.
Country versions all survive the move, but the signals between them consolidate onto one, so the wrong market sees the page, with the wrong currency, stock and shipping.
hreflangcanonicalslocalisation
05
Everything launched. Nobody can explain the drop.
Without a pre-launch baseline it’s impossible to tell whether it’s the migration, seasonality, an algorithm update, broken tracking, or all four at once.
measurementdiagnosis
Recognise one of these? Most of them cost more to diagnose than they would have cost to prevent.
Talk through your migration
Engagements
Where is your migration right now?
Where is your migration right now?
Where is your migration right now?
All three assume you already have a development team. We own the search layer, not the build.
EngagementBuild the migration plan
Migration Review
The decisions that cost the most get made before anyone writes a redirect. What the URL model looks like, what renders server side, what gets merged, and what quietly disappears. We review the proposed changes and write the search requirements as tickets your developers can estimate, while they are still cheap to change.
Duration2–4 weeks
RunsBefore the build
FeeFixed scope
- Crawl and commercial value baseline of the current site
- Review of the proposed architecture and URL model
- Keep / merge / redirect / retire decisions, reasoning recorded
- SEO requirements written as tickets your developers can estimate
EngagementReview our role
Migration Oversight
We review the new site as it is built. Templates, rendering, redirects and internal linking, in your staging environment, on your release schedule. Most of what goes wrong is visible weeks before launch to somebody who is looking for it.
DurationLaunch +30 days
RunsWith the build
FeeMonthly
- Template and rendering review as they are built
- Redirect map owned, versioned and QA’d against the baseline
- Staging crawl, indexability and sitemap validation
- Launch-day checks, same-day triage, 30 days monitored
EngagementGet a diagnosis
Migration Recovery
Something moved and nobody can say which thing. We separate the migration from seasonality and algorithm movement, diagnose it to a specific cause, and sequence the fixes by what they are worth. Sooner is materially better. Redirect logs, ranking history and crawl data all age, and some signals stop coming back once they have been gone long enough.
Duration2 weeks to diagnose
RunsStarts immediately
FeeFixed, then scoped
- Crawl of the new site against what the old one earned
- Migration effects separated from seasonality and updates
- Diagnosis to specific causes rather than symptoms
- Remediation sequenced by commercial impact
Already launched and traffic dropped, is it too late?
No, though diagnosis is harder without a pre-launch baseline. The first job is separating migration effects from seasonality and algorithm movement, then sequencing fixes by what they’re worth. Signals decay, so sooner is materially better.
How we look at it
A migration is not a checklist.
A migration is not a checklist.
A migration is not a checklist.
The redirects can be correct and the migration can still go wrong. So can the canonicals, the templates and the sitemap. Migrations cross systems, and somebody has to look at what happens between them. We do that inside your process: requirements into your backlog, QA in your staging environment, your release schedule. We own the search layer, not the build, and we are not here to slow you down.
01 / Beyond the URL
Look past the redirect map
- Templates, content and architecture, not only addresses
- How customers and crawlers reach important pages
- What gets merged, and what quietly disappears
- The pages that earn, not the pages that exist
02 / What search receives
Test what search sees, not what users see
- Rendering checked before launch, not after
- Initial HTML against the rendered page
- Staging rules and staging URLs confirmed gone
- Crawler access verified, including the AI crawlers
03 / Between systems
Check the systems together
- Redirects, canonicals and sitemaps read as one set
- Internal linking against the redirect map
- Template level checks, not page level
- Contradictions that each check passes individually
04 / Before and after
Know what changed
- What normal looked like, recorded before the move
- Migration effects separated from everything else
- Diagnosis to a cause, not to a symptom
- Fixes sequenced by what they are worth
Where we’ve worked
A hundred migrations tends to change what you look at first.
A hundred migrations tends to change what you look at first.
A hundred migrations tends to change what you look at first.
Fifteen years across enterprise, ecommerce and international sites, including AmLaw 100 and NYSE-listed clients. Most projects turn out to be two or three of the following at once, which is where the interactions get expensive.
The catalogue arrives. The logic that made it findable often does not. Variants, filters, faceted routes and category paths get regenerated, usually multiplying how many URLs exist and changing how products are discovered.
variantsfacetsPDP / PLPcrawl volume
New templates change headings, metadata, structured data and internal links across every page in one release, on sites large enough that nobody can check them by hand.
templatesmetadatastructured datainternal links
A host name change resets how authority is attributed. Merging several properties is harder still. The work is a per-URL judgement about what survives, what merges and what retires.
redirectsbacklinkscanonical signalsretention
A new front end changes what is in the initial HTML, what needs rendering to exist at all, and how pages link to one another. Often while the design looks unchanged.
renderingJavaScriptinformation architecturecontent parity
Country paths, canonicals and hreflang have to keep agreeing with each other through the move. Breaks here are slow to notice, because everything looks correct from a single market.
hreflangcountry URLscanonicalsmarket indexation
Measurement
You can’t know if a migration worked without a baseline.
You can’t know if a migration worked without a baseline.
You can’t know if a migration worked without a baseline.
Without a baseline, every conversation after launch is an argument. Traffic is down, and it could be the migration, the season, an algorithm update, or the tracking that broke in the same release. We record what good looked like before you move, so the question afterwards has an answer instead of four theories.
01
Before migration
Indexed URLs · key landing pages · rankings and visibility · organic traffic and conversions
02
Launch
Crawl and indexation · redirects and canonicals · rendering · tracking and events
03
After migration
Compare against baseline · separate migration effects from other factors · prioritise and resolve
Scope and cost
There is no standard migration scope.
There is no standard migration scope.
There is no standard migration scope.
A four hundred page CMS change and a two hundred thousand URL replatform are different projects, and the second one is not a bigger version of the first. The platform, the URL structure, the catalogue, the international setup and the amount of change all move the work. We tell you what we think needs doing, and which engagement fits, before you commit to anything.
Where the old architecture was the problem, we will say so. A migration is the one moment you get to fix things that are otherwise permanent.
Get it scoped
Complexity determines scope
number of URLs
·
platform and stack
·
how far the architecture moves
·
redirect complexity
·
catalogue and variants
·
markets and languages
·
domains consolidating
·
rendering approach
·
state of measurement
·
launch date
Common questions
A few things worth knowing before you brief anyone.
A few things worth knowing before you brief anyone.
A few things worth knowing before you brief anyone.
What is an SEO migration?
The work of preserving search visibility while a site changes its URLs, platform, domain, architecture or front end. Redirect mapping, indexation, internal linking, canonicalisation, rendering, structured data, and the measurement to confirm it worked.
When should SEO get involved?
While the architecture and URL model are still being decided. Arriving at launch limits the work to damage control, because the expensive decisions are already built.
Does a migration affect AI visibility?
Yes, and not on the same timetable as Google. Redirects restore retrieval quickly and memory slowly, so for a period some systems cite the new URL while others still cite the old one. Retiring redirects on the usual twelve month convention turns those remaining citations into dead links permanently.
Can a migration improve search performance?
It can, but rarely by accident. Most projects are scoped to avoid loss, so nobody is holding the ticket for improvement, and the architectural problems that are cheapest to fix during a move get carried across intact instead.
Do you replace our development team?
No. Requirements go into your backlog, QA happens in your staging environment, and we work to your release process. We own the search layer, not the build.
Next step
Moving the site? Let’s talk before you move it.
Moving the site? Let’s talk before you move it.
Moving the site? Let’s talk before you move it.
Tell us what is changing, where the project stands and what is worrying you most. We come back with the risks worth addressing and the engagement that fits. If there is nothing here worth paying for, we will say that too.
SEO Migration
SEO Migration Services
SEO Migration Services
SEO Migration Services
Protect the traffic and AI visibility you’ve spent years building.
Protect the traffic and AI visibility you’ve spent years building.
Then improve on it, where the old architecture was holding it back.
Then improve on it, where the old architecture was holding it back.
A new platform, a new architecture or a new domain can make the site better. It can also lose years of search visibility if the move is handled as a rebuild rather than a migration. We work alongside your engineering team from the architecture decisions through launch and the weeks after.
What moves
A migration changes more than URLs.
The redirect map gets most of the attention. Traffic can disappear somewhere else entirely: content, templates, internal links, rendering, indexation, measurement. And the systems now answering questions about your business are part of that picture too, working from a cached index and references to your old URLs that do not clear the day your redirect goes live.
Hover or tap a layer →
Failure modes
Five clean launches that still lost traffic.
Five clean launches that still lost traffic.
Five clean launches that still lost traffic.
None of these involve a broken website. The launch went fine, the team celebrated, and the traffic went somewhere else.
The pages moved.
The rankings didn’t.
Pages redirect to a general destination, get consolidated, or lose the internal links that surfaced them.
redirectscanonicals
The catalogue moved.
The logic didn’t.
Products migrate. The variants, filters and category routes customers used to find them do not.
facetsPDP / PLP
The site works.
Search sees something else.
“Google renders JavaScript” is true right up until the category pages are the thing that does not render. The site passes every review, because every reviewer has a browser. You find out in a crawl, or you find out in the revenue.
renderingrobots
04
The right page exists. The wrong customer gets it.
Country versions all survive the move, but the signals between them consolidate onto one, so the wrong market sees the page, with the wrong currency, stock and shipping.
hreflangcanonicalslocalisation
05
Everything launched. Nobody can explain the drop.
Without a pre-launch baseline it’s impossible to tell whether it’s the migration, seasonality, an algorithm update, broken tracking, or all four at once.
measurementdiagnosis
Recognise one of these? Most of them cost more to diagnose than they would have cost to prevent.
Talk through your migration
Engagements
Where is your migration right now?
Where is your migration right now?
Where is your migration right now?
All three assume you already have a development team. We own the search layer, not the build.
EngagementBuild the migration plan
Migration Review
The decisions that cost the most get made before anyone writes a redirect. What the URL model looks like, what renders server side, what gets merged, and what quietly disappears. We review the proposed changes and write the search requirements as tickets your developers can estimate, while they are still cheap to change.
Duration2–4 weeks
RunsBefore the build
FeeFixed scope
- Crawl and commercial value baseline of the current site
- Review of the proposed architecture and URL model
- Keep / merge / redirect / retire decisions, reasoning recorded
- SEO requirements written as tickets your developers can estimate
EngagementReview our role
Migration Oversight
We review the new site as it is built. Templates, rendering, redirects and internal linking, in your staging environment, on your release schedule. Most of what goes wrong is visible weeks before launch to somebody who is looking for it.
DurationLaunch +30 days
RunsWith the build
FeeMonthly
- Template and rendering review as they are built
- Redirect map owned, versioned and QA’d against the baseline
- Staging crawl, indexability and sitemap validation
- Launch-day checks, same-day triage, 30 days monitored
EngagementGet a diagnosis
Migration Recovery
Something moved and nobody can say which thing. We separate the migration from seasonality and algorithm movement, diagnose it to a specific cause, and sequence the fixes by what they are worth. Sooner is materially better. Redirect logs, ranking history and crawl data all age, and some signals stop coming back once they have been gone long enough.
Duration2 weeks to diagnose
RunsStarts immediately
FeeFixed, then scoped
- Crawl of the new site against what the old one earned
- Migration effects separated from seasonality and updates
- Diagnosis to specific causes rather than symptoms
- Remediation sequenced by commercial impact
Already launched and traffic dropped, is it too late?
No, though diagnosis is harder without a pre-launch baseline. The first job is separating migration effects from seasonality and algorithm movement, then sequencing fixes by what they’re worth. Signals decay, so sooner is materially better.
How we look at it
A migration is not a checklist.
A migration is not a checklist.
A migration is not a checklist.
The redirects can be correct and the migration can still go wrong. So can the canonicals, the templates and the sitemap. Migrations cross systems, and somebody has to look at what happens between them. We do that inside your process: requirements into your backlog, QA in your staging environment, your release schedule. We own the search layer, not the build, and we are not here to slow you down.
01 / Beyond the URL
Look past the redirect map
- Templates, content and architecture, not only addresses
- How customers and crawlers reach important pages
- What gets merged, and what quietly disappears
- The pages that earn, not the pages that exist
02 / What search receives
Test what search sees, not what users see
- Rendering checked before launch, not after
- Initial HTML against the rendered page
- Staging rules and staging URLs confirmed gone
- Crawler access verified, including the AI crawlers
03 / Between systems
Check the systems together
- Redirects, canonicals and sitemaps read as one set
- Internal linking against the redirect map
- Template level checks, not page level
- Contradictions that each check passes individually
04 / Before and after
Know what changed
- What normal looked like, recorded before the move
- Migration effects separated from everything else
- Diagnosis to a cause, not to a symptom
- Fixes sequenced by what they are worth
Where we’ve worked
A hundred migrations tends to change what you look at first.
A hundred migrations tends to change what you look at first.
A hundred migrations tends to change what you look at first.
Fifteen years across enterprise, ecommerce and international sites, including AmLaw 100 and NYSE-listed clients. Most projects turn out to be two or three of the following at once, which is where the interactions get expensive.
The catalogue arrives. The logic that made it findable often does not. Variants, filters, faceted routes and category paths get regenerated, usually multiplying how many URLs exist and changing how products are discovered.
variantsfacetsPDP / PLPcrawl volume
New templates change headings, metadata, structured data and internal links across every page in one release, on sites large enough that nobody can check them by hand.
templatesmetadatastructured datainternal links
A host name change resets how authority is attributed. Merging several properties is harder still. The work is a per-URL judgement about what survives, what merges and what retires.
redirectsbacklinkscanonical signalsretention
A new front end changes what is in the initial HTML, what needs rendering to exist at all, and how pages link to one another. Often while the design looks unchanged.
renderingJavaScriptinformation architecturecontent parity
Country paths, canonicals and hreflang have to keep agreeing with each other through the move. Breaks here are slow to notice, because everything looks correct from a single market.
hreflangcountry URLscanonicalsmarket indexation
Measurement
You can’t know if a migration worked without a baseline.
You can’t know if a migration worked without a baseline.
You can’t know if a migration worked without a baseline.
Without a baseline, every conversation after launch is an argument. Traffic is down, and it could be the migration, the season, an algorithm update, or the tracking that broke in the same release. We record what good looked like before you move, so the question afterwards has an answer instead of four theories.
01
Before migration
Indexed URLs · key landing pages · rankings and visibility · organic traffic and conversions
02
Launch
Crawl and indexation · redirects and canonicals · rendering · tracking and events
03
After migration
Compare against baseline · separate migration effects from other factors · prioritise and resolve
Scope and cost
There is no standard migration scope.
There is no standard migration scope.
There is no standard migration scope.
A four hundred page CMS change and a two hundred thousand URL replatform are different projects, and the second one is not a bigger version of the first. The platform, the URL structure, the catalogue, the international setup and the amount of change all move the work. We tell you what we think needs doing, and which engagement fits, before you commit to anything.
Where the old architecture was the problem, we will say so. A migration is the one moment you get to fix things that are otherwise permanent.
Get it scoped
Complexity determines scope
number of URLs
·
platform and stack
·
how far the architecture moves
·
redirect complexity
·
catalogue and variants
·
markets and languages
·
domains consolidating
·
rendering approach
·
state of measurement
·
launch date
Common questions
A few things worth knowing before you brief anyone.
A few things worth knowing before you brief anyone.
A few things worth knowing before you brief anyone.
What is an SEO migration?
The work of preserving search visibility while a site changes its URLs, platform, domain, architecture or front end. Redirect mapping, indexation, internal linking, canonicalisation, rendering, structured data, and the measurement to confirm it worked.
When should SEO get involved?
While the architecture and URL model are still being decided. Arriving at launch limits the work to damage control, because the expensive decisions are already built.
Does a migration affect AI visibility?
Yes, and not on the same timetable as Google. Redirects restore retrieval quickly and memory slowly, so for a period some systems cite the new URL while others still cite the old one. Retiring redirects on the usual twelve month convention turns those remaining citations into dead links permanently.
Can a migration improve search performance?
It can, but rarely by accident. Most projects are scoped to avoid loss, so nobody is holding the ticket for improvement, and the architectural problems that are cheapest to fix during a move get carried across intact instead.
Do you replace our development team?
No. Requirements go into your backlog, QA happens in your staging environment, and we work to your release process. We own the search layer, not the build.
Next step
Moving the site? Let’s talk before you move it.
Moving the site? Let’s talk before you move it.
Moving the site? Let’s talk before you move it.
Tell us what is changing, where the project stands and what is worrying you most. We come back with the risks worth addressing and the engagement that fits. If there is nothing here worth paying for, we will say that too.
SEO Migration
SEO Migration Services
SEO Migration Services
SEO Migration Services
Protect the traffic and AI visibility you’ve spent years building.
Protect the traffic and AI visibility you’ve spent years building.
Then improve on it, where the old architecture was holding it back.
Then improve on it, where the old architecture was holding it back.
A new platform, a new architecture or a new domain can make the site better. It can also lose years of search visibility if the move is handled as a rebuild rather than a migration. We work alongside your engineering team from the architecture decisions through launch and the weeks after.
What moves
A migration changes more than URLs.
The redirect map gets most of the attention. Traffic can disappear somewhere else entirely: content, templates, internal links, rendering, indexation, measurement. And the systems now answering questions about your business are part of that picture too, working from a cached index and references to your old URLs that do not clear the day your redirect goes live.
Hover or tap a layer →
Failure modes
Five clean launches that still lost traffic.
Five clean launches that still lost traffic.
Five clean launches that still lost traffic.
None of these involve a broken website. The launch went fine, the team celebrated, and the traffic went somewhere else.
The pages moved.
The rankings didn’t.
Pages redirect to a general destination, get consolidated, or lose the internal links that surfaced them.
redirectscanonicals
The catalogue moved.
The logic didn’t.
Products migrate. The variants, filters and category routes customers used to find them do not.
facetsPDP / PLP
The site works.
Search sees something else.
“Google renders JavaScript” is true right up until the category pages are the thing that does not render. The site passes every review, because every reviewer has a browser. You find out in a crawl, or you find out in the revenue.
renderingrobots
04
The right page exists. The wrong customer gets it.
Country versions all survive the move, but the signals between them consolidate onto one, so the wrong market sees the page, with the wrong currency, stock and shipping.
hreflangcanonicalslocalisation
05
Everything launched. Nobody can explain the drop.
Without a pre-launch baseline it’s impossible to tell whether it’s the migration, seasonality, an algorithm update, broken tracking, or all four at once.
measurementdiagnosis
Recognise one of these? Most of them cost more to diagnose than they would have cost to prevent.
Talk through your migration
Engagements
Where is your migration right now?
Where is your migration right now?
Where is your migration right now?
All three assume you already have a development team. We own the search layer, not the build.
EngagementBuild the migration plan
Migration Review
The decisions that cost the most get made before anyone writes a redirect. What the URL model looks like, what renders server side, what gets merged, and what quietly disappears. We review the proposed changes and write the search requirements as tickets your developers can estimate, while they are still cheap to change.
Duration2–4 weeks
RunsBefore the build
FeeFixed scope
- Crawl and commercial value baseline of the current site
- Review of the proposed architecture and URL model
- Keep / merge / redirect / retire decisions, reasoning recorded
- SEO requirements written as tickets your developers can estimate
EngagementReview our role
Migration Oversight
We review the new site as it is built. Templates, rendering, redirects and internal linking, in your staging environment, on your release schedule. Most of what goes wrong is visible weeks before launch to somebody who is looking for it.
DurationLaunch +30 days
RunsWith the build
FeeMonthly
- Template and rendering review as they are built
- Redirect map owned, versioned and QA’d against the baseline
- Staging crawl, indexability and sitemap validation
- Launch-day checks, same-day triage, 30 days monitored
EngagementGet a diagnosis
Migration Recovery
Something moved and nobody can say which thing. We separate the migration from seasonality and algorithm movement, diagnose it to a specific cause, and sequence the fixes by what they are worth. Sooner is materially better. Redirect logs, ranking history and crawl data all age, and some signals stop coming back once they have been gone long enough.
Duration2 weeks to diagnose
RunsStarts immediately
FeeFixed, then scoped
- Crawl of the new site against what the old one earned
- Migration effects separated from seasonality and updates
- Diagnosis to specific causes rather than symptoms
- Remediation sequenced by commercial impact
Already launched and traffic dropped, is it too late?
No, though diagnosis is harder without a pre-launch baseline. The first job is separating migration effects from seasonality and algorithm movement, then sequencing fixes by what they’re worth. Signals decay, so sooner is materially better.
How we look at it
A migration is not a checklist.
A migration is not a checklist.
A migration is not a checklist.
The redirects can be correct and the migration can still go wrong. So can the canonicals, the templates and the sitemap. Migrations cross systems, and somebody has to look at what happens between them. We do that inside your process: requirements into your backlog, QA in your staging environment, your release schedule. We own the search layer, not the build, and we are not here to slow you down.
01 / Beyond the URL
Look past the redirect map
- Templates, content and architecture, not only addresses
- How customers and crawlers reach important pages
- What gets merged, and what quietly disappears
- The pages that earn, not the pages that exist
02 / What search receives
Test what search sees, not what users see
- Rendering checked before launch, not after
- Initial HTML against the rendered page
- Staging rules and staging URLs confirmed gone
- Crawler access verified, including the AI crawlers
03 / Between systems
Check the systems together
- Redirects, canonicals and sitemaps read as one set
- Internal linking against the redirect map
- Template level checks, not page level
- Contradictions that each check passes individually
04 / Before and after
Know what changed
- What normal looked like, recorded before the move
- Migration effects separated from everything else
- Diagnosis to a cause, not to a symptom
- Fixes sequenced by what they are worth
Where we’ve worked
A hundred migrations tends to change what you look at first.
A hundred migrations tends to change what you look at first.
A hundred migrations tends to change what you look at first.
Fifteen years across enterprise, ecommerce and international sites, including AmLaw 100 and NYSE-listed clients. Most projects turn out to be two or three of the following at once, which is where the interactions get expensive.
The catalogue arrives. The logic that made it findable often does not. Variants, filters, faceted routes and category paths get regenerated, usually multiplying how many URLs exist and changing how products are discovered.
variantsfacetsPDP / PLPcrawl volume
New templates change headings, metadata, structured data and internal links across every page in one release, on sites large enough that nobody can check them by hand.
templatesmetadatastructured datainternal links
A host name change resets how authority is attributed. Merging several properties is harder still. The work is a per-URL judgement about what survives, what merges and what retires.
redirectsbacklinkscanonical signalsretention
A new front end changes what is in the initial HTML, what needs rendering to exist at all, and how pages link to one another. Often while the design looks unchanged.
renderingJavaScriptinformation architecturecontent parity
Country paths, canonicals and hreflang have to keep agreeing with each other through the move. Breaks here are slow to notice, because everything looks correct from a single market.
hreflangcountry URLscanonicalsmarket indexation
Measurement
You can’t know if a migration worked without a baseline.
You can’t know if a migration worked without a baseline.
You can’t know if a migration worked without a baseline.
Without a baseline, every conversation after launch is an argument. Traffic is down, and it could be the migration, the season, an algorithm update, or the tracking that broke in the same release. We record what good looked like before you move, so the question afterwards has an answer instead of four theories.
01
Before migration
Indexed URLs · key landing pages · rankings and visibility · organic traffic and conversions
02
Launch
Crawl and indexation · redirects and canonicals · rendering · tracking and events
03
After migration
Compare against baseline · separate migration effects from other factors · prioritise and resolve
Scope and cost
There is no standard migration scope.
There is no standard migration scope.
There is no standard migration scope.
A four hundred page CMS change and a two hundred thousand URL replatform are different projects, and the second one is not a bigger version of the first. The platform, the URL structure, the catalogue, the international setup and the amount of change all move the work. We tell you what we think needs doing, and which engagement fits, before you commit to anything.
Where the old architecture was the problem, we will say so. A migration is the one moment you get to fix things that are otherwise permanent.
Get it scoped
Complexity determines scope
number of URLs
·
platform and stack
·
how far the architecture moves
·
redirect complexity
·
catalogue and variants
·
markets and languages
·
domains consolidating
·
rendering approach
·
state of measurement
·
launch date
Common questions
A few things worth knowing before you brief anyone.
A few things worth knowing before you brief anyone.
A few things worth knowing before you brief anyone.
What is an SEO migration?
The work of preserving search visibility while a site changes its URLs, platform, domain, architecture or front end. Redirect mapping, indexation, internal linking, canonicalisation, rendering, structured data, and the measurement to confirm it worked.
When should SEO get involved?
While the architecture and URL model are still being decided. Arriving at launch limits the work to damage control, because the expensive decisions are already built.
Does a migration affect AI visibility?
Yes, and not on the same timetable as Google. Redirects restore retrieval quickly and memory slowly, so for a period some systems cite the new URL while others still cite the old one. Retiring redirects on the usual twelve month convention turns those remaining citations into dead links permanently.
Can a migration improve search performance?
It can, but rarely by accident. Most projects are scoped to avoid loss, so nobody is holding the ticket for improvement, and the architectural problems that are cheapest to fix during a move get carried across intact instead.
Do you replace our development team?
No. Requirements go into your backlog, QA happens in your staging environment, and we work to your release process. We own the search layer, not the build.
Next step
Moving the site? Let’s talk before you move it.
Moving the site? Let’s talk before you move it.
Moving the site? Let’s talk before you move it.
Tell us what is changing, where the project stands and what is worrying you most. We come back with the risks worth addressing and the engagement that fits. If there is nothing here worth paying for, we will say that too.