Will we lose rankings when we migrate?

Some short-term movement is normal even when everything is done correctly — Google has to recrawl and reassign signals across the new URLs, and that takes weeks. What is not normal is a permanent loss. That comes from redirects that were never written, canonicals left pointing at the old site, or content dropped in the rebuild, and all three are preventable before launch rather than fixable after.

Can you work with our existing development team?

Yes, and it is often the cheapest arrangement. We can produce the URL map and the redirect rules for your team to implement, review their implementation against the crawl, or do the work in your repository ourselves. What we would push back on is a migration where the SEO plan and the engineering happen in separate conversations, because that is exactly where the redirect map goes missing.

What if we already launched and traffic dropped?

That is recoverable and worth acting on quickly, because the longer the old URLs return 404 the more of the link equity pointing at them decays. We reconstruct the old URL inventory, find what 404s or lands wrongly, rebuild the missing redirects and restore content that was cut. Recovery is usually weeks to a few months depending on how much was lost and how long it has been broken.

Does this cover a domain change or just a redesign?

Both, plus platform changes and URL restructures — the mechanics are the same and the risk profile only differs in degree. A domain change is the highest-risk version because every single URL changes at once, so it gets the most careful staging validation and the closest launch-day watch.

How much does it cost?

Sized from our EUR 35-55/hour band against the scope, with a written estimate and a clear range before anything starts. The main drivers are how many indexed URLs you have and how many languages, not how large the visual redesign is — a 200-page single-language site is a much smaller project than a 200-page site in five languages.

Website Migration SEO

Most traffic lost in a migration was never lost to Google's judgement — it went to a redirect that was never written, a canonical pointing at a dead URL, or a staging site that got indexed. We plan the migration, build the redirect map as code, validate it before launch and watch the recovery afterwards.

Last updated: August 14, 2026

Start your project Get a free estimate

What actually costs you the traffic

Migrations rarely fail for subtle reasons. They fail for a short list of concrete, preventable ones — and every item on that list is caught by a checklist plus someone who can read the codebase.

Redirects that were never mapped: old URLs return 404 and every link and ranking pointing at them dies with them
Chained or looping redirects, where old → interim → new bleeds authority at each hop
Canonicals left pointing at the old domain, telling Google the new site is the copy
The staging site indexed because a robots rule shipped to production inverted, or never shipped at all
Content quietly dropped in the rebuild — the paragraphs that were actually ranking, cut as clutter
The sitemap and internal links still describing the old structure weeks after launch

How we run a migration

The work splits cleanly into before, during and after, and most of the value is in the first part. A migration that is planned properly is mostly uneventful; one that is planned on launch day is a recovery project.

Baseline first: current rankings, top landing pages, crawl inventory and traffic captured before anything moves, so 'did we lose something' is answerable with data
URL map built from the crawl, not from memory — every indexed URL gets a destination or an explicit decision to drop it
Redirects implemented as code in your repo, reviewable in a pull request and diffable, not typed into a plugin UI
Staging validation: crawl the new site, verify every mapped redirect resolves in one hop, check canonicals, hreflang and robots before launch
Launch-day watch and a post-launch recovery window, comparing against the baseline rather than against a feeling

International migrations are the hard case

If the site serves more than one language, a migration multiplies every risk: each locale needs its own redirect map, hreflang has to keep reciprocating across the new URLs, and per-locale canonicals must move together or Google will treat the translations as duplicates of the English page. This is the failure we see most often and the one that takes longest to recover from.

A redirect map per locale, including translated slugs that do not share the English URL shape
Hreflang rebuilt against the new URLs and verified reciprocal in both directions before launch
Per-locale canonicals moved in step, so no language ends up pointing at another language's page
Locale-aware internal links updated, so each language cluster keeps supporting itself
Sitemaps regenerated per locale rather than one English sitemap with translated URLs bolted on

Already migrated and lost traffic?

That is a normal reason to call us, and it is diagnosable. The pattern of the loss usually names the cause: an across-the-board drop points at redirects or robots, a drop confined to one language points at hreflang or canonicals, and a drop on a handful of pages points at content that went missing in the rebuild.

Reconstruct the old URL inventory from the index, archives and any logs still available
Find what returns 404 or lands on the wrong page, and rebuild the missing part of the redirect map
Check whether the loss is uniform, per-locale or per-page — each points somewhere different
Restore content that was cut in the rebuild but was doing the ranking
Resubmit and monitor the recovery, with a realistic timeline rather than a promise

How we work and what it costs

Priced from our EUR 35-55/hour band with a written estimate first. A migration is bounded work with a definable end, which makes it easier to scope than an ongoing programme — the size is driven by how many URLs you have and how many languages, not by how big the redesign looks.

Written estimate first, with the range and the assumptions stated
We work in your repository and your deployment process — the redirects ship the way the rest of your code ships
Comfortable in Next.js, React and server-rendered stacks, where routing and canonical logic actually live
Full CET overlap from Tirana, with engineers who work in English and Italian
Honest about timing: recovery after a botched migration is usually weeks to a few months, and nobody can promise a date

FAQ

Frequently Asked Questions

Will we lose rankings when we migrate?
Some short-term movement is normal even when everything is done correctly — Google has to recrawl and reassign signals across the new URLs, and that takes weeks. What is not normal is a permanent loss. That comes from redirects that were never written, canonicals left pointing at the old site, or content dropped in the rebuild, and all three are preventable before launch rather than fixable after.
Can you work with our existing development team?
Yes, and it is often the cheapest arrangement. We can produce the URL map and the redirect rules for your team to implement, review their implementation against the crawl, or do the work in your repository ourselves. What we would push back on is a migration where the SEO plan and the engineering happen in separate conversations, because that is exactly where the redirect map goes missing.
What if we already launched and traffic dropped?
That is recoverable and worth acting on quickly, because the longer the old URLs return 404 the more of the link equity pointing at them decays. We reconstruct the old URL inventory, find what 404s or lands wrongly, rebuild the missing redirects and restore content that was cut. Recovery is usually weeks to a few months depending on how much was lost and how long it has been broken.
Does this cover a domain change or just a redesign?
Both, plus platform changes and URL restructures — the mechanics are the same and the risk profile only differs in degree. A domain change is the highest-risk version because every single URL changes at once, so it gets the most careful staging validation and the closest launch-day watch.
How much does it cost?
Sized from our EUR 35-55/hour band against the scope, with a written estimate and a clear range before anything starts. The main drivers are how many indexed URLs you have and how many languages, not how large the visual redesign is — a 200-page single-language site is a much smaller project than a 200-page site in five languages.