Skip to content
BOOSTD

Website Migration SEO

SEO website migration service for domain, platform and URL changes

Our SEO website migration service plans your move to a new domain, platform or URL structure, with every redirect mapped and a written way back.

No cost to ask. A person replies within one working day.Or get an instant free SEO auditSee pricingBook a free callCall 647-896-7674

Organic visits

Example

Drop starts the day the new site went live. 212 old URLs have no redirect.

Example chart with invented numbers. It shows how a drop is traced to a cause.

Managed SEODone by our specialist team on top of the platform, with a monthly meeting and a price agreed with you.

See Managed SEO

What counts as a migration

More projects are site migrations than people think

A migration is any change to the web addresses Google already knows, or to what they show. That includes a new domain, a new platform, a subdomain moving to a subfolder, restructured navigation, two sites merged into one, one split into two, or a template system that renames every page.

It matters because rankings belong to URLs. Links and search history build up against one address. Change the address without telling Google, and you are asking it to start again.

The steps and the common mistakes are well known. Almost all of the risk sits in decisions made before launch.

Before anything moves

Building a full list of your URLs

A redirect map is only as good as the URL list behind it, and one crawl of the live site never finds them all.

  • A full crawl of the current site, including pages with no links to them that still get visits
  • Every XML sitemap, including old ones nobody has updated in years
  • Server logs, which show every URL Google requests, including ones you forgot about
  • Search Console pages by clicks and impressions, exported before anything changes
  • Analytics landing pages by visits and revenue, so your most valuable pages stand out in the map
  • External links grouped by the page they point to, so no valuable link gets redirected carelessly
  • Files and other non-page URLs: images, PDFs, product feeds, RSS, downloads and API endpoints the site calls
  • URLs with parameters or page numbers, and any filtered pages you chose to let Google index
  • Existing redirects, so new rules point straight to the final page and don’t stack on old ones
  • robots.txt, canonical tags, hreflang and structured data as they stand today
  • Internal links, because they need updating to the new URLs and shouldn’t be left to redirect

Where things go wrong

Each stage can only work with what the stage before it passed on

A migration narrows as it goes. A URL missing from the list can never be mapped. A mapping choice can’t be revisited once the old site is gone.

A website migration, stage by stage.
  1. 1URL list — Every URL the site has ever served, gathered from crawls, sitemaps, server logs, Search Console and analytics.
  2. 2Redirect map — Each old URL sent to one new page, chosen page by page. No bulk rule pointing everything at the home page.Anything missing from the list can’t be mapped
  3. 3Test-site rollout — We crawl the new build the way Google would, checking the index block, canonicals, rendering and one-step redirects.Faults found too late to fix before launch
  4. 4Launch day — The launch plan: go live, remove the block, submit sitemaps, register the change of address and check a sample of redirects by hand.Steps nobody was named to do
  5. 5First 72 hours — Error codes, redirect chains added by caching or server rules, crawl volume, indexing and the pages that bring in revenue.The window when fixes are still cheap

Timeline

The website migration plan, counted back from launch day

  1. Six weeks out: benchmark

    We record what normal looks like: rankings and traffic by page type, URL and search topic, plus crawl stats, indexing and conversion rate by landing page. Without it, every debate after launch is guesswork.

    You get: A dated benchmark to compare against later

  2. Four weeks out: map

    We match every old URL to one new page. Where there is no match, we choose carefully: the closest page, the parent category, or a 410 "gone" response. Sending everything to the home page is not a mapping decision.

    You get: A one-to-one redirect map, with the top pages checked line by line

  3. Two weeks out: check the test site

    We crawl the test build the way Google would, checking it is blocked from Google, canonicals point to the live URLs, pages render on the server and redirects work in one step.

    You get: A test-site report with faults assigned to developers

  4. Launch day: follow the plan

    A written launch plan with a named owner for each step. Go live, remove the block, check robots.txt and submit new sitemaps. Register the change of address if the domain is moving, and test a sample of redirects by hand.

    You get: A completed plan with times and initials against each step

  5. First 72 hours: watch the key signals

    Server errors, redirect chains added by caching or server rules, crawl volume, indexing of new URLs and the pages that bring in the most business. Fixes are still cheap here.

    You get: A daily problem report for three days

  6. Weeks two to twelve: judge the result

    We compare against the benchmark, and not against last year. We separate URLs that are recovering from URLs Google never picked up. The rollback option stays open for as long as the agreed window allows.

    You get: A keep-or-roll-back recommendation with the evidence behind it

The first month

How to tell a normal dip from a problem

Both look like a drop on a graph. You can usually tell them apart within days if you know what to check.

How normal settling after a migration differs from a failed migration
DimensionNormal settlingSomething is wrong
Shape of the dropA dip that levels off and starts to climb within a few weeksA drop that keeps going, or a cliff on launch day that doesn’t move
Which pagesSpread across all page types, roughly in proportion to the siteFocused on one section, one page type, or the pages with the most links
IndexingNew URLs being found and indexed steadilyNew URLs not indexed, or old URLs still indexed next to them
Response codesClean one-step redirects from old URLsChains, loops, soft 404s or unexpected 302s
Impressions and clicksImpressions holding while clicks lag a littleImpressions falling fast, which means Google has stopped showing the pages
What to doNothing drastic. Keep watching and avoid changing anything elseFind the cause within days, fix the specific fault and check the rollback window before it closes

Common mistakes

What goes wrong in a migration, most common first

Every moved page was redirected to the home page.
It is quick and clears the error report, but it throws away what each page was relevant for. A redirect tells Google this address is now that address. Pointing 400 product pages at the home page tells it nothing useful.
The redirects chain together.
New rules stack on rules from past migrations, so an old URL passes through three or four hops. Each hop can fail, and Google may give up. We flatten every chain to a single step.
The test site got indexed.
A test site left open to Google, or a launch that keeps the test-site block on, are the same mistake at opposite ends. One check prevents both.
Content and URLs changed at the same time.
When URLs and content change together, nobody can tell which caused a rise or fall. If the timeline allows, move the URLs first and change the content later.
Nobody kept the old site.
You can only roll back while the old build still works and the DNS change can be undone. Deciding on day nine to go back, then finding the old site was switched off on day two, is painful.

Questions

Questions to ask before you move your site

How long does traffic take to settle after a migration?

It depends on the size of the site and how much changed. A small site with clean one-to-one redirects often looks normal within a few weeks. A large catalogue with new URLs can take much longer, because Google has to crawl and assess everything again.

Nobody can know the number in advance. At each check-in, we tell you whether the pattern looks like normal settling or a fault.

The developers are handling redirects. What is left to do?

Deciding which old page goes to which new one. That is a content and search decision. Setting up the redirects is the last and easiest step.

The usual failures are bulk rules that send whole sections to the home page, chains of old and new rules, and images, PDFs and feeds nobody put on the list.

We are keeping our URLs. Do we still need this?

Yes, but less of it. If templates, internal links, headings or page content change a lot, the pages are different even at the same address. A benchmark lets you tell what caused any change.

You can usually skip the redirect map and the change of address step. The benchmark, the test-site checks and the first week of monitoring are still worth doing.

What does a rollback plan mean?

It is a written answer to three questions. What evidence would make us go back? Who decides? How long does the old site stay ready to switch back on?

It is rarely used, but it turns launch into a decision you can undo, which keeps everyone calmer in the first week.

Can you join a project that launches in two weeks?

Often, yes, with a smaller scope. With two weeks we focus on the URL list, the redirect map and the benchmark. Those are the things you can’t rebuild after launch.

If the date looks too risky, we will name the parts we would push back and explain why.

Bring us in before your launch date

Tell us what is moving and when. We will tell you what has to happen before launch, what can wait until after, and whether we would change the date.

References

Sources for SEO website migration service

The official documents and research this page is based on. Platform rules change, so check the source before you act on a detail.

  1. Google Search Central: site moves with URL changes
  2. Google Search Central: redirects and Google Search
  3. Google Search Central: debugging drops in Google Search traffic

Last updated · Published by Zubair Afzal, responsible editor