SEO Website Migration Checklist: Planning to Day 30

A safe website migration comes down to three jobs: map every old URL to its closest new URL, keep the new site out of Google until launch day, and leave 301 redirects in place for at least a year afterwards. This checklist puts those jobs in order across four phases, from planning to the first 30 days.

It follows Google's guidance on site moves with URL changes and adds the practical steps that guide leaves to you. Each list is plain text, so paste it into your project tool and tick as you go.

Work out what kind of move this is

Most of the checklist applies to every move. Change of Address in Search Console only applies to some of them.

If only the hosting is changing and every URL stays the same, follow Google's shorter guide to moving a site with no URL changes. If you are also changing the design, work through the website redesign checklist alongside this one and split the two if you can. Google's advice is to change only one thing at a time, which also makes problems far easier to trace.

As a rough plan for a site with a few hundred pages, allow 2 to 4 weeks for planning and mapping, 2 to 3 weeks for staging and testing, then a launch day followed by 30 days of monitoring. Book someone's time for that last month as well. Google says most pages on a small to medium site move across in a few weeks, and larger sites take longer.

Phase 1: Planning

Agree who owns what

Baseline and access

• ☐ Write down the move type from the table above and the one person who owns the migration.

• ☐ Export top pages and queries from Search Console as far back as the data goes.

• ☐ Export top landing pages and conversions from analytics for the same period.

• ☐ Record current rankings for the terms that bring in paying customers.

• ☐ Crawl the old site with a tool such as Screaming Frog or Sitebulb and save titles, status codes, canonicals and indexability.

• ☐ Pick a launch window in a seasonal or weekday dip in traffic.

• ☐ Verify every variant of the old and new sites in Search Console: www, non-www, HTTP and HTTPS.

• ☐ Confirm one Google account owns both properties, because Change of Address needs that.

• ☐ Re-upload any disavow file to the new property.

• ☐ If the new domain was bought recently, check Search Console for manual actions and leftover URL removals.

Build the redirect map

• ☐ Combine URLs from the crawl, XML sitemaps, server logs, analytics, the Search Console links report and a CMS export into one list.

• ☐ Include images, PDFs, videos, CSS and JavaScript files that are moving.

• ☐ Give every old URL one row in a spreadsheet with its new URL and status code.

• ☐ Map every page with traffic, links or conversions to its closest equivalent, one to one.

• ☐ Redirect merged pages to the new combined page.

• ☐ Mark content that is not moving as 404 or 410. Google can treat bulk redirects to the homepage as soft 404s.

• ☐ Update redirects left over from past migrations so each old URL goes straight to its final URL. Googlebot follows up to 10 hops, but Google says to keep chains under 5 and ideally no more than 3.

• ☐ Decide how trailing slashes, uppercase letters and query strings behave.

Here is what the map looks like for a fictional agency site:

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Start your free trial

Phase 2: Staging

Keep it out of search

• ☐ Put staging behind a password or IP allowlist. This stops people as well as crawlers.

• ☐ If staging must be public, add noindex to every page with a meta robots tag or an X-Robots-Tag header.

• ☐ Never pair noindex with a robots.txt Disallow. A page blocked by robots.txt never has its noindex read, and blocked URLs can still be indexed if something links to them.

• ☐ List every place noindex or staging protection is set, so launch day does not rely on memory.

Get the new site right

• ☐ Give every indexable page a self-referencing canonical tag with the full absolute URL.

• ☐ Update hreflang annotations to the new URLs if the site has language versions.

• ☐ Change internal links to the new URLs, so the site does not rely on its own redirects.

• ☐ Keep titles, H1s and body copy on mapped pages close to the old site unless you are deliberately rewriting them.

• ☐ Carry over structured data and check it still validates.

• ☐ Move images and downloads such as PDFs and confirm they resolve.

• ☐ Prepare the launch robots.txt now, blocking only what you intend. If you are not using one, the URL should return a real 404.

• ☐ Build an XML sitemap of new canonical URLs only, using absolute URLs and splitting at 50,000 URLs or 50MB.

• ☐ Save a second sitemap of the old URLs to use for monitoring after launch.

• ☐ Check removed URLs and the 404 page return a real 404 status and not a 200.

• ☐ Search the code and database for the staging hostname and fix anything hardcoded.

Test the redirects before they go live

• ☐ Load the map in a pre-production environment or test the rules against a sample.

• ☐ Run every old URL through your crawler in list mode. Each should land on its mapped URL with a 200 in one hop.

• ☐ Confirm the codes are 301 or 308. Google treats 302, 303 and 307 as temporary, so the old URL tends to stay in results.

• ☐ Test each variant: HTTP, HTTPS, www, non-www, trailing slash and uppercase.

• ☐ Confirm campaign parameters survive the redirect.

• ☐ Check the new server can cope. Google warns that crawling gets heavier after a move.

• ☐ Complete a full website QA pass on forms, payments and key journeys.

If several people are testing staging, QualityHive's website review tool lets them click the broken element and type what is wrong, so each issue lands on one Kanban board with a screenshot and not in an email thread.

Phase 3: Launch day

Launch early in the week and make sure whoever built the redirects is around for the rest of the day. If hosting is moving too, lower your DNS TTL to a few hours at least a week ahead. On WordPress, the WordPress launch checklist covers the platform-specific steps.

• ☐ Back up the old site, database and server config.

• ☐ Re-crawl the old site and add any URLs created since mapping.

• ☐ Deploy the new site.

• ☐ Remove the staging password and every noindex on your list.

• ☐ Swap in the launch robots.txt and check it loads at /robots.txt on each host, because rules apply per host and protocol.

• ☐ Turn on the redirects.

• ☐ View source on one page of each template and check the canonical and meta robots tags.

• ☐ Re-run the full old URL list through the crawler.

• ☐ Spot-check key old URLs with Search Console's URL Inspection tool.

• ☐ Domain or subdomain moves only: submit Change of Address from the old site's property, once for each variant. It needs a 301 from the old homepage to the new one.

• ☐ Submit the new XML sitemap in Search Console, plus the old URL sitemap for tracking.

• ☐ Check analytics is recording and conversions are firing.

• ☐ Update ad landing pages, social profiles, email signatures and anything else holding the old URLs.

• ☐ Run a smoke test on the homepage, forms, search and checkout.

Phase 4: The first 30 days

Days 1 to 3

• ☐ Crawl the new site for broken links, stray noindex tags and canonicals pointing at old or staging URLs.

• ☐ Check server logs for Googlebot activity and unexpected errors on both the old and new sites.

• ☐ Add redirects for any old URLs showing as 404s in the logs.

Week 1

• ☐ Check the Page indexing report on the new property every day.

• ☐ Check the Sitemaps report. New URLs should climb from zero as old URLs fall, and redirect warnings on the old sitemap are expected.

Weeks 2 to 4

• ☐ Compare clicks and impressions for your top pages with the baseline.

• ☐ Ask the sites sending you the most links to update the URL.

• ☐ Fix any soft 404s or redirect errors that appear in Search Console.

• ☐ Remove the old URL sitemap once you have what you need. Google says it can go as soon as the new sitemap is in, so the old one is only there for tracking.

After day 30

• ☐ Keep redirects live for at least a year, ideally indefinitely. Change of Address runs for 180 days, after which Google treats the two sites as unrelated, so the redirects still matter.

• ☐ Keep the old domain registered and renewing, because the redirects stop working if it lapses.

• ☐ Leave old URLs crawlable. Googlebot cannot follow a redirect on a URL it is not allowed to fetch.

When it goes wrong

The Removals tool only hides a URL for about six months, so keep the password or add noindex as well. Some ranking movement during a move is normal, and Google says permanent redirects do not cause a loss in PageRank, so give it a few weeks before changing anything that is working.

Revolutionise your QA processes

Start free trial

FAQ

How long should redirects stay in place after a migration?

Google says to keep them for as long as possible, and generally for at least a year. Keep them longer if the old URLs still get traffic or links, because real visitors use old bookmarks too.

Should I block a staging site with robots.txt?

No. robots.txt controls crawling and is not a way of keeping pages out of Google. Password protect staging, or use noindex without a robots.txt block so crawlers can read it.

Do I need Change of Address for a move to HTTPS?

No. Google says the tool is for moves between domains or subdomains. HTTP to HTTPS, www to non-www and path changes on the same domain rely on redirects and updated sitemaps.

Do 301 redirects lose PageRank?

Google says 301 and other permanent redirects do not cause a loss in PageRank. Rankings can still fluctuate during the move while Google recrawls every old and new URL.

How long does a site migration take to settle?

Google says most pages on a small to medium site move across in a few weeks, and larger sites take longer. Speed depends on the number of URLs and how quickly your server responds.