Article · Site migrations

Website redesign or migration: an SEO checklist for a small business client

A new design, host or domain can change the addresses and files Google has already crawled. Before launch, launch day and the first weeks, with a redirect map to copy and a client message that sticks to what Google says.

Google documentation checked on 29 October 2026.

The short answer: first find out what is changing: the URLs, the host, the domain, or only the design. List every old URL, map each one to its closest new page, and launch with server-side permanent redirects (301 or 308). On launch day, remove the staging blocks and submit the new sitemap. Then watch Sitemaps, Page indexing and Performance in Search Console every week. Google says rankings may fluctuate during a move and settle over time. It gives no date for that, so neither should you.

First, name the change

Clients say "redesign" for very different jobs. Ask the developer in writing: will any page address change, will the host or CDN change, and will the domain change? The answers decide which Google guide applies.

What changes	Google guide	Change of Address tool?
Design only; every URL and the host stay	No move guide; the launch checks below still apply	No
Host or CDN, same URLs	Site moves without URL changes	No
Paths on the same domain	Site moves with URL changes	No: add redirects, update the sitemaps
HTTP to HTTPS	Site moves with URL changes	No: Google says it will figure out the change
www to non-www, or back	Site moves with URL changes	No: use redirects or canonical tags
New domain or subdomain	Site moves with URL changes	Yes, from the old property, once redirects are live

If the project changes the domain and also rewrites the content and URL structure, show the client Google's warning first: the Change of Address help page says that combination will probably cause some traffic loss. Google's move guide says to change one thing at a time, for example the domain first and the layout afterward. Where the budget allows, plan two launches.

Before launch

1. Build the URL inventory

List every old URL a visitor, a link or Googlebot might still request. Google's move guide points to:

The current sitemaps, where the most important URLs have likely been submitted.
Server logs and analytics: the URLs with the most traffic, and any URL requested at least once recently.
Search Console's links data (the guide calls it Links to your site), for pages with internal and external links.
The CMS page list.
Embedded files: images, videos, JavaScript and CSS.

Also export the Pages view of the Performance report, so you know which URLs bring search clicks, and save it with the dated baseline as your "before" picture. For organic landing pages in GA4, see step 3 of the GA4 organic search report.

2. Fill in the redirect map

One row per old URL, in a spreadsheet the developer and the client can both open. Fill in the last column during testing.

Old URL	New URL	Response	Why	Checked
/services.php?id=3	/services/water-heaters/	301	Same service, new address	[date, one hop]
/about-us.html	/about/	301	Same page, new address	[date, one hop]
/blog/winter-pipes.html	/blog/frozen-pipes/	301	Two posts merged into one	[date, one hop]
/blog/frozen-pipe-tips.html	/blog/frozen-pipes/	301	Two posts merged into one	[date, one hop]
/files/price-list.pdf	/pricing/	301	PDF replaced by a page	[date, one hop]
/images/team.jpg	/assets/team.jpg	301	Embedded image moved	[date, one hop]
/spring-special-2023/	None	404 or 410	Expired offer, no equivalent	[date, code]
http://old-name.example/ (any path)	https://www.new-name.example/ (same path)	301	Domain change, one pattern rule	[date, sample paths]

Example only: a hypothetical plumbing business with made-up URLs and domains. Replace every row with your own client's URLs.

Rules for each row, from Google's move and redirect guides:

Closest equivalent, not the home page. Sending many old URLs to one irrelevant page, such as the new home page, can confuse users and might be treated as a soft 404. Old pages merged into one new page can all point to it.
No equivalent: 404 or 410. Google handles both the same way: indexed URLs are dropped and crawled less often over time.
Permanent and server-side. 301 or 308; Google treats a 308 as equivalent to a 301. Temporary redirects (302, 303, 307) show the old URL in results, and Google does not treat them as a sign that the target should be canonical. Client-side redirects are a last resort.
One hop. Redirect to the final URL directly. If a chain cannot be avoided, Google says ideally no more than 3 hops and fewer than 5.

Google says 301 and other permanent redirects don't cause a loss in PageRank. That is not a promise that rankings stay put. For a simple domain change, Google says a wildcard server-side redirect may do instead of a list; keep the inventory anyway, because you test against it.

3. Keep staging out of Google, and plan how the blocks come off

Password protection. Google says private content should be password protected so only authorized users can reach it. Staging qualifies.
noindex, as a robots meta tag or an X-Robots-Tag header, drops a page from results once Google sees it. Google's hosting-move guide suggests it for a temporary test hostname. Google only sees it if robots.txt does not block the page.
robots.txt manages crawling. Google says it is not a way to keep a page out of Google: a blocked URL might still be indexed if it is linked from elsewhere. Each file covers only its own protocol, host and port.

The launch-day risk: a disallow-all robots.txt or a noindex template carried from staging onto the live site. Google's move guide says to prepare the launch-ready robots.txt and the list of URLs whose noindex rules come off, in advance. Write both down now, with a named owner.

4. Prepare the new site

Canonicals: each new URL has a self-referencing rel="canonical" tag.
Internal links point to the new URLs, not to old URLs that redirect. Update hreflang if the site has language versions.
New sitemap: only the URLs you want in search results, as full absolute URLs. Google uses <lastmod> only if it is consistently and verifiably accurate.
Search Console: verify all variants of both the old and new sites, plus any temporary test hostname. Tokens may differ when the URL changes, so check that verification survives the rebuild.
Capacity: Google says it will temporarily crawl the new site more heavily than usual.
Host or CDN moves: lower the DNS TTL to a few hours at least a week ahead, check that firewall or denial-of-service protection does not block Googlebot, and confirm access with URL Inspection.

Launch-day checklist

Google's move guide sets the order: redirects on, canonicals and robots meta rules checked, redirects tested, Change of Address if the domain changes, new sitemap submitted. Copy this into the launch ticket.

Launch day: [client site], [date]

Redirects from the map are live, server-side, as 301 or 308. [Developer]
Staging blocks are off: launch robots.txt in place, noindex removed from every URL on the list, no password on the live site. [Developer]
robots.txt loads at the root of the live host in a private window, with no Disallow: / you did not intend. Check the robots.txt report in Search Console. [Consultant]
Canonical tags point to the new URLs. [Consultant]
Redirect test: URL Inspection for single URLs, a command-line tool or script for the whole map. Each old URL: permanent code, one hop, mapped destination. [Consultant]
Money pages in URL Inspection, Test live URL: Crawl allowed? and Indexing allowed? say Yes, and the page fetch worked. If robots.txt blocks crawling, Indexing allowed? still shows Yes, because Google cannot see the noindex. Read both lines. [Consultant]
Request indexing for a few key pages only: there is a daily limit and no guarantee, and for many URLs Google points to the sitemap. [Consultant]
Submit the new sitemap in the Sitemaps report: owner per its help page, owner or full user per the permissions table. Otherwise list it in robots.txt. [Consultant or client]
Domain or subdomain moves only: Change of Address from the old property, for every variant of the old domain, even unused ones. The submitter must own both properties; full and restricted users can only view it. [Client]
Annotation on the Performance chart, such as "Relaunch: redirects live" (up to 120 characters; owners and full users). [Consultant]
Analytics records visits on the new site. Google suggests Google Analytics real-time reporting early in a move. [Consultant]
Links the client controls point to new URLs: Google names profile links and ad campaigns; add email signatures and listings. [Client]
The old setup stays: the old domain registered and redirecting, or the old host running until its logs show traffic, Googlebot included, has reached zero. [Client]

Design only, same URLs and host: skip items 1, 5, 9, 12 and 13. Host or CDN move, same URLs: skip 1, 5, 9 and 12, and switch DNS once the temporary blocks are off.

The first weeks: what to watch

Google's move guide says a small to medium-sized site can take a few weeks for most pages to move, and larger sites take longer. For a move to count as complete, Googlebot has to visit every URL on the old and new site at least once.

Where	What Google says to expect	Look closer when
Sitemaps report	A status for each sitemap. Warnings on the old-URL sitemap about redirecting URLs are normal.	Has errors or Couldn't fetch on the new sitemap
Page indexing, filtered by sitemap	The new-URL sitemap starts at zero indexed and rises; the old-URL sitemap drops toward zero. Old URLs appear under Page with redirect: a non-canonical URL that redirects.	Not found (404) for mapped URLs, Redirect error, Soft 404, URL marked 'noindex' or URL blocked by robots.txt on pages meant to rank
Performance	New URLs start getting impressions and clicks as they are indexed and ranked. The newest data can be preliminary.	A money page's new URL gets no impressions after its old URL fades
URL Inspection	For an old URL, the result describes that URL's own index entry, not the redirect target.	Google-selected and declared canonicals differ on a money page
Server logs, analytics	Traffic shifts from old URLs to new. After a host move, a temporary drop in crawl rate, then a steady increase over the next few days.	Error codes you did not plan for

Google says you can remove the old sitemap once the new one is in, but also to submit both to watch the counts. Removing one only takes it off the report, so keep the old-URL sitemap listed until its indexed count reaches zero.

A suggested watch schedule (not a Google requirement)

Launch day and the day after: redirect test results, robots.txt, money pages in URL Inspection.
Twice in week one: Sitemaps status and the error reasons in Page indexing.
Weekly until the counts settle: Page indexing for each sitemap, and Performance against the weeks before launch, filtered by page (URLs containing) for old and new paths. Google suggests weekly or monthly granularity for date comparisons; one comparison runs at a time, and annotations do not show in comparison mode.
After a fix: click Validate fix once; validation typically takes up to about two weeks, sometimes much longer.
Then: back to the monthly cycle, with the move noted in the monthly report email.

What to tell the client about temporary fluctuations

Send this before launch, not after the first dip. The "What Google says" part only paraphrases Google's site move guide, which calls the fluctuation normal and says rankings will "settle down over time". Add nothing Google does not say.

Subject: What to expect in Google after the new site launches

Hi [first name],

The new site goes live on [date]. Here is what changes, what Google says happens next, and what we will do.

What changes: [the addresses of [number] pages / the domain, to [new domain] / only the design; every page keeps its address].

What Google says: Google's guide to site moves says rankings can fluctuate while Google recrawls and reindexes a site after a significant change, that this is normal, and that rankings settle over time. [For a small to medium-sized site like yours,] Google says most pages can take a few weeks to move. Google gives no date for traffic, so we will not give one either.

What we have done: every old page address sends visitors and Google to its closest new page with a permanent redirect[, and pages with no replacement return a "not found" code].

What we will watch: Google Search Console every week until the indexing counts settle, then in the monthly report. If something needs fixing, you will hear from us that week.

What we need from you: [keep the old domain registered and its redirects in place / tell us before anyone changes page addresses or the redirect setup / update the website link on [profiles]].

[Your name]

What not to say

A recovery date. Google's few weeks are about pages moving, not traffic.
"Rankings will come back." Google says they settle, not where.
"Redirects keep your rankings." Google's claim is narrower: no PageRank loss.
"It's a Google update." Not before you have checked the launch list.

If the numbers do not settle

Google's move guide names these common mistakes:

Leftover noindex or robots.txt blocks. Remove them and test with URL Inspection. No robots.txt at all is fine, if the missing file returns a 404.
Incorrect redirects, such as old URLs pointing to new URLs that do not exist. Look for an unusually high number of Not found errors, or crawl the site.
Other crawl errors: spikes in errors for the new site.
Server capacity for the heavier crawling after a migration.
Sitemaps not updated with the new URLs.

For each status, see Page indexing statuses explained. If the client asks about a drop, use how to explain a ranking drop.

How long to keep redirects and the old domain

Redirects: Google's move guide says as long as possible, generally at least 1 year. The Change of Address page says at least 180 days, longer if they still get Google Search traffic.
Old domain: Google recommends paying for it for at least a year, so no one can use it for malicious purposes.
180 days: Change of Address effects last that long, and a move can be cancelled within it. After that, Google no longer recognizes a relationship between the sites, and treats a still-crawlable old site as unrelated.

Write it into the hand-off: where the redirects live (server configuration, CMS setting or plugin), who owns them, and the earliest date anyone may review them.

Sources

checked on 29 October 2026

Inventory, mapping, one change at a time, launch order, chains, PageRank, monitoring, timing, fluctuation, mistakes, 1 year: Site moves with URL changes
Test hostname, DNS TTL, Googlebot access, blocks off before DNS, crawl rate, old host shutdown: Site moves without URL changes
Permanent and temporary redirect codes, canonical signals, server-side first: Redirects and Google Search
308 equals 301, 404 and 410 handling: HTTP status codes and network errors
When to use it, ownership, redesign warning, 180 days, old domain for a year: Change of Address tool
Password protection: Control what you share with Google
noindex forms, not blocked by robots.txt: Block indexing with noindex
robots.txt does not keep pages out of Google: Introduction to robots.txt
robots.txt scope, testing, robots.txt report: Create a robots.txt file
URLs you want in results, absolute URLs, lastmod: Build and submit a sitemap
Statuses, owner permission, robots.txt alternative, filter by sitemap, removing a sitemap: Sitemaps report
Indexing reasons, Validate fix timing: Page indexing report
Redirected URLs, live test, Request indexing limits: URL Inspection tool
Sitemap and Change of Address permissions: Users and permissions
Pages view, preliminary data: Performance report
Page filters, one comparison at a time, granularity: Advanced filtering and comparison
Annotation length, who can add them, comparison mode: Search Console annotations