Site migration checklist: move a site without losing SEO

The new host is faster, the new domain is shorter, the new theme finally looks like this decade. You flip the switch on a Friday. On Monday, Search Console shows a wall of 404s, and the page that brought in most of your visitors now lands on the homepage.

Nothing was wrong with the new site. The problem was the gap between the old one and the new one. A migration is a house move: the furniture usually arrives fine; what goes missing is the forwarding address.

The shift: three kinds of move, three levels of risk

Before the checklist, name the move you’re making. Google treats them differently in its own documentation:

• Same URLs, new hosting → lowest risk. Google has a separate guide for a site move without URL changes.
• New URLs on the same domain (new permalink structure, new platform, HTTP to HTTPS) → medium. Every changed URL needs a redirect.
• New domain → highest. Every URL changes, and Search Console’s Change of Address tool comes into play.

The core of all three is one flow:

Old URL → permanent (301) redirect → the matching new URL → Google recrawls → signals move to the new address.

Break any arrow and the page starts from scratch. Everything below is about keeping the arrows intact. Google is honest about the rest: its site-move guide says to expect temporary fluctuation in ranking during the move. A careful migration limits the damage. Nobody can promise zero.

The checklist

Before the move

1. Take a full website backup — files and database, stored somewhere other than the old host. WordPress’s own migration documentation starts the same way: back up the directory, images, plugins and the database before you touch anything.
2. List every old URL. Google suggests pulling them from your sitemaps, your most-visited pages, server logs and your CMS. Don’t trust one source; the pages that earn links are often the ones missing from the sitemap.
3. Build the URL map. A spreadsheet: old URL in one column, new URL in the next. One-to-one wherever a matching page exists. This is the single most valuable file in the whole project.
4. Decide what isn’t moving. Pages you’re dropping should return 404 or 410 on the new site, as Google’s guide recommends. Don’t redirect them all to the homepage; Google specifically says not to redirect many old URLs to one irrelevant destination.
5. Verify both sites in Search Console, and keep the old site’s verification working after the move.
6. If you’re only changing hosting, lower your DNS TTL to a conservative low value at least a week before, so the switch propagates quickly.
7. Prepare the new site: copy images and downloads, check robots.txt isn’t blocking everything (staging sites often are), and update canonical tags, hreflang and internal links to point to the new URLs — not to old ones that will redirect.

On move day

1. Switch on the redirects. Server-side, permanent (301), from each old URL straight to its new URL. No chains: A → B → C should be A → C.
2. Test them. Run your URL map through a redirect checker or a crawler: every old URL should answer 301 and land on a 200 page. Spot-check the top twenty by hand.
3. Check canonicals and robots meta tags on the live new site. A leftover noindex from staging is the classic migration disaster.
4. For WordPress, update the site address. Settings → General, both URLs with https:// and no trailing slash. If you search-and-replace the old domain in the database, use a tool that handles serialized data — WordPress warns that a naive replace can break data stored with the URL’s length. And per the same docs: never change the GUID column.
5. Re-save permalinks so rewrite rules are rebuilt on the new server.
6. For a domain change, submit Change of Address in Search Console for the old property. Requirements from Google’s help page: you must be an owner of both properties, using the same Google account, with a 301 from the old homepage to the new homepage. The tool works only on domain-level properties, and Google says not to use it for an HTTP to HTTPS change. Its effects last 180 days.
7. Submit the new sitemap in Search Console, then remove the old one.

After the move

1. Keep the redirects for a long time. Google says as long as possible, generally at least one year. In practice: keep them, and keep paying for the old domain. If the old domain lapses, the redirects die with it — and if that’s already happened, read domain name expired before anything else.
2. Update the links you control: social profiles, ads, email signatures, directory listings. Ask the sites that link to you most to update their links.
3. Watch the reports. Search Console’s Sitemaps and indexing reports, search queries, server logs and analytics. Google expects old-site traffic to fall while new-site traffic rises, and says a full move can take a few weeks or longer, longer for big sites.
4. For a hosting-only move, use the URL Inspection tool to confirm Googlebot can reach the new server, and keep the old server running until its traffic reaches zero. Google notes a temporary drop in crawl rate after the switch is normal.
5. Fix 404s from the logs for the first few weeks. Every one is a URL your map missed.

A worked example (hypothetical)

Say you’re moving a 200-page WordPress blog from old-example.com to new-example.com, and changing permalinks from /?p=123 to /post-name/ at the same time.

• You export URLs from the sitemap (180), add the top pages from analytics (12 not in the sitemap — old landing pages), and pull 404-prone ones from logs (8 PDFs). Total: 200 old URLs.
• Mapping: 185 go one-to-one; 10 thin tag pages go to 410; 5 old product pages go to the closest current category, not the homepage.
• Redirects are written once, old URL straight to final URL — not old domain → old new-style URL → new domain, which would be a chain.
• Move day: test all 200, find 3 landing on 404 because of a typo in the map. Fix them before lunch.
• Change of Address submitted, new sitemap in, old one removed. Old domain renewed for several years.

Two changes at once (domain and permalinks) double the mapping work but not the risk — if the map is right. I’d still split them into two moves if the calendar allows, so a problem has only one possible cause.

Common mistakes

• Redirecting everything to the homepage. Fast to set up, and exactly what Google’s guide warns against.
• 302s instead of 301s. Use permanent redirects for a permanent move.
• Launching with staging’s noindex or robots.txt block. Check the live site, not your memory of it.
• Letting the old domain expire a year later. All those redirects vanish in one billing failure.
• Forgetting images and PDFs. They have URLs too, and some of them earn links and search traffic of their own.
• Moving without a backup. Half-migrated with no way back is the worst place to stand.

When the old site is already gone

Sometimes the “migration” starts after the old host has already shut down, with no backup to move. Then the old URLs and content usually only survive in the Internet Archive’s Wayback Machine. A Wayback Press restore rebuilds the site from those captures with the original URL structure kept, so the redirect map above still has something to point to. If you want the result on WordPress rather than static HTML, see Wayback Machine to WordPress. You need to own the rights to the restored content, and a human reviews every restore before delivery.

Takeaway

Back up → map every URL → 301 one-to-one → test → tell Search Console → keep the redirects and the old domain for at least a year → watch the 404s. The new design is the fun part. The spreadsheet is the part that keeps the traffic.

Moving house is easy. Leaving a forwarding address is what the neighbours remember.