Website Migration SEO: A Checklist for Tech Companies Changing Platforms or Domains

Website migration SEO means moving a site to a new platform or domain while keeping the search value the old pages earned. You do it with a URL map, 301 redirects and a check of old against new.

Migrations fail in boring ways.

A redirect file with 40 rows when the old site had 900 URLs. A staging robots.txt that shipped with the launch. A case study link that says “not found” the first time a prospect clicks it. Each one is visible in advance, which is the annoying part, and each one gets missed because the new site works perfectly well for the people building it.

The cause is usually the framing. We treat a migration as a design project when it’s closer to moving offices, where the furniture matters less than the labels on the boxes. Skip the labels and somebody spends a month opening every box.

What Website Migration SEO Covers

Website migration SEO is the planning, redirecting and monitoring that protects a site’s search visibility while it changes platform, domain, URL structure or hosting. Google calls these site moves. The goal is simple: every address that earned traffic keeps answering, and Google learns the new locations quickly.

Not every move carries the same risk. Far from it. Google’s guide to site moves with URL changes lists the cases: a switch from HTTP to HTTPS, a new domain name, merging domains, and changes to the URL paths. A hosting or CDN change that leaves the URLs alone gets its own, shorter guide.

What Changes, and What It Puts at Risk

Read the table top to bottom and the pattern is plain. The more URLs that change, the more mapping you owe. A domain change sits at the bottom of that table for a reason, because it touches every address on the site and every Search Console setting Google keeps for each variant of it. Plan accordingly.

Step 1: Decide What Is Actually Changing

Write it down in one sentence. “We’re moving from our old CMS to a new one, and the URLs stay the same.” Or, “We’re changing domains.” Two different projects. Different risks, too.

Google’s advice on this is blunt. It says to change only one thing at a time, and gives the example of a company that wants a new domain, a new CMS and a new layout. Do them one after the other, it says, starting with the domain.

Its Search Console help page for the Change of Address tool repeats the point. If you combine a site move with a redesign of the content and URL structure, you will probably see some traffic loss, because Google may need to relearn and reassess the individual pages.

That’s a hard sell inside a company. The rebrand, the new platform and the new domain all feel like one launch, and the launch date has probably been announced to the board. Split them anyway. If traffic drops, you want to know which change did it. More moving parts, more places for the cause to hide.

Step 2: Build the URL Map First

Before the new site exists, list every old URL that matters and decide where each one goes. Google’s guide suggests where to look: your sitemaps, your server logs and analytics for the busiest pages, the Links report in Search Console for pages with links pointing in, and your CMS’s own page list.

Include files. Images, PDFs, videos, scripts and stylesheets all have URLs, and Google says those need to be moved the same way as pages. A datasheet that earns links from a partner’s site is easy to forget, and it’s exactly the kind of URL that quietly returns an error.

• One row per old URL, one destination per row.
• Send each page to its closest equivalent, not to the home page. Google warns that redirecting many old URLs to one irrelevant destination can confuse users and may be treated as a soft 404.
• Merged pages can point to the page that absorbed them.
• Retired content with no equivalent should return a 404 or 410 on the new site.

Add a column for the owner, a column for priority and a column for “tested.” Dull? Very. It’s also the best protection you have.

Step 3: Prepare the New Site and Test It Hidden

Build the new site somewhere search engines can’t index it. Google suggests a testing environment with restricted access, or a temporary hostname with a noindex rule, so the test copy doesn’t get indexed by accident. It also says to check that a firewall or DoS protection isn’t blocking Googlebot.

Then run through the page-level signals, because one template change touches every page that uses it, and a missing canonical or a stray noindex in a shared header can spread across the whole site before anyone opens a single page to look.

• Each new URL carries a self-referencing rel=”canonical” link.
• If the site has multilingual or multinational pages, the hreflang annotations point at the new URLs.
• Internal links use the new URLs, so visitors never pass through a redirect inside your own site.
• The new robots.txt matches what you want crawled. Sites often block everything during development, so prepare the launch version in advance, plus a list of pages where noindex has to come off.
• Both the old and new sites are verified in Search Console, in every variant (www, non-www, HTTP and HTTPS).

One more for modern stacks. Google’s JavaScript SEO basics explain that Googlebot first checks robots.txt, and if a URL is disallowed it skips the request and doesn’t render it. So a client-side app that hides its content behind a blocked script path can look empty. Open the test site’s key pages with the URL Inspection tool and see what Google sees.

Step 4: Launch Day, in Order

Redirects first. No exceptions. Google recommends server-side permanent redirects, and its redirect documentation lists 301 and 308 as the permanent kind. Temporary redirects such as 302 tell Google to keep showing the source page, which is the opposite of what a migration wants.

Watch the chains. Googlebot follows up to 10 hops, Google says, but it advises pointing straight at the final destination, and keeping any chain to no more than three, fewer than five at the outside. Every hop adds latency for a real person too.

1. Turn on the redirects from your URL map.
2. Confirm the canonical tags and robots rules on the new site use the new URLs, and remove any noindex you added for testing.
3. Test the redirects with a crawler or script, then spot-check the top pages by hand.
4. For a domain or subdomain move, submit a Change of Address in Search Console for every verified variant of the old site, even variants you don’t use.
5. Submit the new sitemap, with the new URLs only.

Skip the Change of Address item if only the platform changed. Google says the Change of Address tool isn’t for HTTP to HTTPS moves, www to non-www switches or path changes on the same domain.

Step 5: The First 90 Days

Plan on a wobble. It’s normal. Google says visibility may fluctuate temporarily during a move, and that a small to medium site can take a few weeks for the bulk of its pages to move, with larger sites taking longer. It doesn’t promise a date, so nobody else can.

That’s Google’s own guidance, and it’s the item that gets dropped first when a redirect file starts to feel messy. Don’t. Keep it. The year exists so Google can transfer signals and reassign links on other sites that still point at your old URLs, and from a visitor’s side, an old bookmark or an email from 2023 keeps working long after your team has forgotten the redirect was there.

Then do the cleanup that makes the redirects unnecessary for your own traffic.

• Update internal links to the final URLs.
• Ask the sites that link to you often to update their links.
• Fix your profile links, directory listings and ad campaigns.
• Compare the old and new sitemaps in Search Console. Indexed pages should drift from one to the other, and the Index Coverage report should show it.

Check weekly for the first month, then monthly. Not because Google needs hand-holding. Because a 404 that appears on week three is much cheaper to fix than the one you find in a quarterly report.

Where Tech Company Sites Get Caught

Software and IT companies tend to carry more than a marketing site. Ask these before launch, and expect at least one to turn up something.

• Does the docs or help center live on a subdomain that the new platform doesn’t cover?
• Which app login and signup URLs sit in emails, product tooltips and old PDFs?
• Where do gated datasheets and whitepapers live, and who links to them?
• Are the integration and partner pages mapped one to one? Those are the ones partners link to.
• The status page and API reference, because an engineer bookmarked both.
• Old campaign landing pages that still receive paid or email traffic.

One theme runs through the list. A disconnected site doesn’t compound. It resets. If you’re weighing the whole project, our post on what a redesign costs a tech company covers the budget side, and the website maintenance checklist is what keeps the new site healthy afterward.

Simple. Not easy. If you want a second set of eyes on the URL map before launch, book a growth strategy call.