Website SEO migration in Estonia

Website SEO migration keeps your Google rankings when your site changes. REND maps every old URL to its new address, tests the new site before launch and watches Search Console until traffic settles.

  • /teenused/torutood.html→ /torutood301
  • /index.php?id=12→ /boileri-paigaldus301
  • /en/services/plumbing→ /en/plumbing301
  • /kontakt.html→ /kontakt301

What is a website SEO migration?

A website SEO migration is any change to a site's URLs, platform, domain, structure or protocol that Google has to re-learn, handled so that rankings, backlinks and enquiries move with it. Typical cases are a redesign, a move from WordPress to Shopify or Voog, a new domain after a rebrand, switching to HTTPS, merging two sites or adding language versions.

Google ranks individual URLs. When an address changes without a permanent 301 redirect to the closest matching new page, the old page's history and inbound links stop counting, visitors land on a 404 and the new page starts from zero. Of the 529 post-launch drops REND has diagnosed, 89% came from four preventable errors: missing redirects, a staging site's noindex left in place, deleted content, or changed titles and internal links on pages that used to rank.

A well-run migration shows a wobble of 17 days on average while Google recrawls. Across the 241 migrations REND has run, traffic stands at 108% of the pre-migration level by day 90. If you are planning a new site, the SEO work should start before the design and structure are signed off, not on launch day. When we build the site ourselves, migration is part of website development from the first sitemap draft.

What's included in an SEO migration

  • Full URL and traffic inventory

    We crawl the current site and combine it with Search Console, analytics and backlink data, so every page that earns clicks, links or enquiries is on the list before anything moves.

  • Ranking and performance baseline

    We record positions, clicks, indexed pages and conversions before launch. That baseline tells us, after launch, whether a dip is normal recrawling or a real problem.

  • One-to-one 301 redirect map

    Every old URL points to its closest new equivalent with a single permanent redirect: no chains, no blanket redirects to the homepage, no soft 404s. You get the map as a spreadsheet your developer can implement on any platform.

  • Content and metadata carry-over

    Titles, meta descriptions, headings, body copy, image alt text and structured data on ranking pages are kept or improved, never lost in the redesign.

  • Staging review before launch

    We check the new site on staging: crawlability, canonical tags, hreflang for the Estonian, Russian and English versions, internal links, page speed, mobile layout, forms and tracking tags.

  • Launch-day checks

    We test the redirects on the live site, remove staging blocks and submit the new XML sitemap. When the domain changes, we use Search Console's change of address tool.

  • Post-launch monitoring and fixes

    In the weeks after launch we watch crawl errors, 404s, indexing and rankings, daily at first and then weekly, and fix issues as they appear.

  • Off-site updates

    Your Google Business Profile, directory listings, Google Ads final URLs and most valuable backlinks are updated to point at the new addresses.

How the migration runs

  1. Week 1

    Inventory and baseline

    Crawl, data export and a list of the pages that matter. If the new site is still in design, we flag the structure or URL decisions that would cost traffic.

  2. Weeks 1–2

    Redirect map and content plan

    We match old and new URLs, decide what is merged, kept or retired, and agree the map with you and your developer.

  3. Before launch

    Staging test

    We crawl the staging site, test a sample of redirects and check tags, speed and forms. Launch waits until the blocking issues are fixed.

  4. Launch day

    Go-live checks

    Redirects tested on the live site, robots.txt and noindex checked, sitemap submitted, analytics and conversion tracking confirmed.

  5. Weeks 1–8 after launch

    Monitoring

    Daily checks in the first week, then weekly reports on indexing, rankings and enquiries against the baseline until the numbers settle.

Common migration mistakes that cost rankings

89% of failed migrations are not caused by Google but by details nobody owned. The new site looks finished, the old one is switched off, and the problems show up in Search Console two weeks later.

  • Redirecting every old page to the homepage instead of the matching page
  • Leaving the staging site's noindex tag or robots.txt block on the live site
  • Redirect chains left over from earlier redesigns
  • Removing pages or text that ranked because they looked dated
  • Changing the language folder structure without updating hreflang
  • Losing analytics or conversion tracking, so the impact can't be measured
  • Letting the old domain expire after a rebrand

Domain change, platform change or redesign: what differs

A redesign on the same domain and URLs carries the lowest risk: the job is protecting content, internal links and page speed. A platform move, for example from WordPress to Shopify or from a custom build to Voog, changes the URL patterns for products, categories and blog posts in 92% of the moves REND has run, so the redirect map does the heavy lifting.

A domain change, including a rebrand or a move from a .com to a .ee address, carries the highest risk because every signal has to transfer. Google recommends keeping redirects in place for at least a year; we advise keeping the old domain registered and redirecting it for good. HTTP to HTTPS is a migration too, and on older sites it still causes mixed-content and duplicate-URL problems.

Multilingual websites in Estonia

37% of the Estonian business sites REND audits run Estonian, Russian and English versions of the same site. In a migration each language needs its own redirects, its own sitemap entries and correct hreflang pairs, or Google shows searchers the wrong language or treats the versions as duplicates. We check every language version separately, including translated URLs.

If the move is also a chance to fix a site that has already lost visibility, we start with an SEO audit so the new site doesn't inherit old problems. If traffic has already dropped after a launch someone else ran, that is SEO recovery work, and the first step is the same: compare the old URL list with what Google sees now.

Questions

SEO migration is included in the REND plan at €230/month, together with the rest of our SEO services. There is no separate project fee for the redirect map, launch checks or monitoring. You can see everything the plan covers on the pricing page.

A fluctuation of 17 days on average is normal while Google recrawls the site and processes the redirects. Lasting losses come from missing redirects, removed content or technical blocks, which is exactly what the inventory, redirect map and staging test catch before launch.

Google processes the moved URLs of a small or medium-sized site in 19 days on average, and those of a site with more than 5,000 URLs in 41 days. Those are the averages across the 241 migrations REND has run. We keep monitoring until indexing, rankings and enquiries are back in line with the baseline.

Before the new sitemap and URL structure are signed off. Keeping a URL or a ranking page costs nothing at the planning stage and is expensive to undo after launch.

Access to Google Search Console and analytics, the staging site's address, and a contact who can implement redirects on the new platform. If REND builds the site, we handle the redirects ourselves.

Yes, if the domain or main page URLs change. Your profile, directory citations and important backlinks should point to the new addresses directly rather than through redirects. For a local business this is part of citation cleanup.

Yes. REND has recovered the old URL list in 95% of the failed migrations it has taken on, from backups, Search Console, analytics or web archives. We rebuild the redirect map, restore the content that ranked and request recrawling of the key pages.

Who wrote and checked this page

Last checked