Website Migration SEO

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

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

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

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

Priced from our EUR 35-55/hour band with a free 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.

• Free 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