A website migration SEO checklist has three phases: before launch, list every URL, save a baseline and map each old URL to its closest new page with a 301. On launch day, switch the redirects on, remove staging blocks and submit the new sitemap. Then watch indexing, 404s and redirect chains against your baseline for the next few weeks, because Google says some ranking movement is normal for a few weeks or more.
You’ve signed off on a new website. Maybe it’s a redesign, a move off WordPress, a new domain after a rebrand, or a long-overdue switch to HTTPS. The developers have a launch date. And somewhere in the back of your mind is the story you’ve heard from another business owner: the new site went live on a Friday, and by the next month the phone had stopped ringing.
That does happen, and it’s almost always preventable. Rankings vanish when old addresses stop working, pages lose what made them rank, or Google is shut out of the new site by mistake. This checklist is the order we work in, phase by phase.
What counts as a website migration?
Google splits site moves into two kinds, and the work is very different for each.
- Moves without URL changes. You switch hosting providers or put the site behind a CDN, and every address stays exactly the same. Google’s advice is mostly about testing the new setup, lowering your DNS TTL ahead of time and watching server logs while traffic shifts (Google Search Central).
- Moves with URL changes. HTTP to HTTPS, a new domain, a new URL structure, or a new platform that writes URLs its own way. Each changed URL needs a redirect, and Google has to crawl both the old and the new address before it swaps them in results (Google Search Central).
A redesign or a platform change can fall into either group. If the new site keeps every address, you’re in the first, easier group. If even one section changes its URLs, that section is a move with URL changes. Google also suggests changing one thing at a time, for example the domain first and the design later.
Before launch: the website migration SEO checklist
Most migration problems we’re called in to fix were decided in this phase.
1. Crawl and list every URL you have
You can’t redirect a page you don’t know exists. Build one list from several places: a crawl of the live site, your XML sitemaps, your CMS, Search Console’s Performance and Links reports, and your analytics. Google also suggests server logs and reminds you to include images, videos, PDFs and other files, which are easy to forget. Old campaign landing pages often appear only in analytics.
2. Save a baseline before anything changes
Export at least three months of Search Console data (clicks, impressions and position by page and by query) and the matching numbers from analytics, including leads or sales from organic search. After launch, this is what you compare against. Without it, nobody can say whether a dip is normal settling or a real problem.
3. Keep URLs the same wherever you can
The safest redirect is the one you never need. If the new platform lets you keep the current addresses, keep them. Every changed URL adds a redirect to maintain and a page Google has to process again.
This is the approach we took when we moved our own site off WordPress. Every page, post and image kept its exact address, and each of the 148 pages was compared with its old WordPress version before launch: 145 matched, and 3 were changed on purpose. You can read the details in our own migration case study. We’re publishing the Search Console comparison at 90 days, in January 2027, rather than claiming a result early.
4. Build a one-to-one 301 redirect map
For every URL that does change, write down where it goes. One row per old URL, one destination per row, and the destination is the closest matching page on the new site. Google recommends server-side permanent redirects (301 or 308) and says permanent redirects don’t cause a loss in PageRank (Google Search Central).
Two rules make or break the map:
- Don’t send everything to the homepage. Google warns against redirecting many old URLs to one unrelated page such as the new homepage, because it confuses users and may be treated as a soft 404. If a page has no replacement, let it return 404 or 410.
- Redirect in one hop. Googlebot can follow up to 10 redirects in a row, but Google advises redirecting to the final destination directly and keeping any chain short: ideally no more than 3 hops, and fewer than 5.
Chains build up by accident: an HTTPS rule, a www rule and a page rule each add a hop. If your site runs on Apache, paste your .htaccess into our free analyzer: it explains each rule and its redirect tester follows any address through your redirects one step at a time, so you can see chains and loops before Google does.
5. Carry over what made each page rank
A redirect passes signals to a page. It can’t make up for what the new page is missing. Check that every important page keeps its title, meta description, main content, headings and structured data. Rebuild internal links so they point straight at the new URLs, not through redirects, and keep each page’s place in the menu and site structure.
This is the quiet failure. When a luxury resort came to us after close to a year of slipping traffic, the redirects existed. But pages that used to anchor the site sat deeper in the hierarchy, templates had dropped content that supported relevance, and internal links were thinner. The full story is in our luxury resort migration recovery case study. Structured data is easy to lose in a template rebuild too, and our guide to schema for AI visibility covers what it does for you.
6. Keep the staging site out of Google
The new site needs a place to be tested, and that copy must not be indexed. A password on the whole staging site is the safest option. A noindex tag works too, but it’s exactly the setting that later gets copied to the live site by mistake, often along with a robots.txt that blocks everything. Google advises writing the live site’s robots.txt in advance, so it blocks only what you mean to block, and removing any noindex or robots.txt blocks that were only there for the migration.
Launch day: what to switch on and check
Google suggests moving during a low-traffic period. Have your developer and whoever owns the SEO side available, then work through this list in order:
- Turn on the redirects and test them right away: a sample of old URLs from every section and template, each landing on the right page with one 301. Search Console’s URL Inspection tool works for single URLs, and a crawler run against your old URL list catches the rest.
- Remove the staging blocks. Check robots.txt on the live domain, and check page source for a noindex tag on a few templates. Our free robots.txt validator fetches your file, explains each line and tells you whether your sitemap pages are blocked.
- Check canonical tags. Each new page should point to its own new URL, not to the old domain or the staging address.
- Submit the new XML sitemap in Search Console, listing only the new, live URLs that return a 200 status.
- Verify every version of the site in Search Console. Google says to verify old and new sites, including www, non-www, HTTP and HTTPS variants, and to keep your verification file or tag on the new site.
- For a new domain, use the Change of Address tool. Run it from the old domain’s property after the redirects are live. You need to be an owner of both properties, and Google now asks you to cover every variant of the old domain, such as www and non-www (Search Console Help). You don’t need it for HTTP to HTTPS, a www change on the same domain, or path changes.
The most expensive launch-day mistake we see is the staging block going live: a robots.txt "Disallow: /" or a sitewide noindex copied from the test site. It can take your pages out of Google within days. Check both within the first hour, on the live domain.
After launch: what to watch in the following weeks
Some movement is normal. Google says that for medium-sized sites it can take a few weeks or more before the new URLs replace the old ones in results, and that Googlebot has to visit every old and new URL at least once (Google Search Central). Your job is to tell normal settling from a real problem. Check these at least weekly:
- Page indexing. In Search Console’s Page indexing report, old URLs should move into “Page with redirect” and new URLs should become indexed. Watch the “Not found (404)” and “Redirect error” counts. A redirect error can mean a chain that’s too long, a loop or a bad URL in the chain (Search Console Help).
- 404s and redirect chains. Crawl the old URL list again a week after launch. Fix any 404 that had traffic or links, and flatten any chain to a single hop.
- Rankings, clicks and leads against the baseline. Compare page by page. A steady site total can hide one section that lost half its traffic.
- Crawling. Google crawls the new site harder after a move. Crawl stats in Search Console settings show server errors and response times. Our guide to crawl budget explains what to look for.
Also update the links you control: your Google Business Profile, social profiles, directory listings and ad campaigns.
Keep your redirects for as long as possible, generally at least a year, Google says. A Change of Address notice runs for 180 days, and Google recommends keeping the old domain for at least a year (Google Search Central, Search Console Help).
If traffic is still falling after a month with no sign of settling, treat it as a problem to diagnose. Our guide on how to read a technical SEO audit report helps you sort what matters from the noise.
Your migration checklist for this week
FAQs
Will I lose rankings when I migrate my website?
Some movement is normal while Google crawls the old and new URLs, and Google says it can take a few weeks or more for a medium-sized site. Lasting losses usually come from missing or wrong redirects, content or internal links lost in the rebuild, or a staging block left on the live site. A full URL inventory, a one-to-one redirect map and a baseline to compare against prevent most of them.
How long should I keep 301 redirects after a site migration?
Google recommends keeping them as long as possible, generally at least a year. For a domain change, keep the old domain registered and redirecting for at least a year as well. Many sites keep them indefinitely for old links and bookmarks.
Do I need the Change of Address tool when moving to HTTPS?
No. Google detects HTTP to HTTPS moves on its own, so you only need redirects, updated internal links and canonicals, and a new sitemap. The Change of Address tool is for moving to a new domain or subdomain, and you run it from the old domain’s Search Console property.
Can I redirect old pages to my homepage?
Not as a general rule. Google says redirecting many old URLs to one unrelated page, such as the homepage, confuses visitors and may be treated as a soft 404. Send each old URL to its closest matching page, and let pages with no replacement return 404 or 410.
Is changing web hosting a site migration for SEO?
It’s a move, but an easier one if every URL stays the same. Test the new setup first, lower your DNS TTL about a week ahead, remove any test-site blocks and watch your server logs as traffic shifts. Google says a short dip in crawl rate after the switch is normal.
Sources
- How to move a site with URL changes, Google Search Central
- Changing your hosting (site moves without URL changes), Google Search Central
- Change of Address tool, Search Console Help
- Page indexing report, Search Console Help
