Website Migration Checklist: Move Without Losing Rankings

Q: How long should I keep redirects?

Google says at least one year, and longer is better.

Q: Do I need the Change of Address tool?

Only for moving between domains or subdomains, not for HTTP to HTTPS, www toggles or path changes.

Q: Should I redesign and migrate at the same time?

Google advises changing one thing at a time, since combining changes makes problems harder to trace.

website migration checklist

Most traffic losses after a migration are not caused by Google. They come from a redirect that was never written, a noindex tag that was never removed, or a baseline that was never recorded. This checklist walks through the whole job in order: what to record before you touch anything, how to map URLs, which redirects to use, what to test on staging, what to do on launch day and what to watch for in the weeks after. It is built on Google’s own site-move documentation, and it covers each migration type separately because a hosting move and a domain change are very different jobs.

pre-launch, launch and post-launch lists
redirect rules from Google docs
five migration types compared
monitoring plan for 90 days

// note: This guide is built from Google Search Central documentation. I did not run a migration for this article and nobody can promise rankings will hold. Sources are linked throughout and listed at the end. If you want a person to run the move, see my website migration SEO service.

migration-phases.txtoverview

phase	when	main output
1 Audit	weeks before	URL inventory, baselines
2 Map	weeks before	old to new URL sheet
3 Stage	days before	tested copy, redirects ready
4 Launch	go-live day	cutover, sitemap, checks
5 Monitor	weeks after	indexing and traffic reviews

// phase order follows Google’s site-move documentation.

key takeaways

The Short Version Before the Detail

// 1

Redirects carry the move

Google says to use server-side permanent redirects (301 or 308) where you can, send each old URL to its matching new page, and keep them for at least a year.

// 2

Change one thing at a time

Google advises against combining a URL move with a CMS or layout change. Each extra change makes any traffic drop harder to explain.

// 3

Fluctuation is normal

Google says rankings and visibility can shift for weeks or longer while it recrawls. It also says every old and new URL must be visited at least once before the move counts as complete.

step zero

Which Kind of Migration Are You Doing?

The checklist changes with the move. Pick yours first, then follow the matching rows in the sections below.

Type	URLs change?	Redirects needed?	Biggest risk
Hosting or server move	No	No	DNS cutover errors, Googlebot blocked by a firewall
HTTP to HTTPS	Yes (protocol)	Yes, site-wide	Mixed content, missed Search Console property
Domain change or rebrand	Yes	Yes, one to one	Lost links, missing Change of Address request
CMS or platform change	Often	Often	URL patterns change silently, templates lose SEO fields
Redesign or restructure	Sometimes	Where paths change	Removed pages, rewritten content, lost internal links

Google publishes two separate guides: one for moving a site with URL changes and one for moving a site without URL changes. A hosting move falls under the second, which is far shorter. Everything else is the first.

PHASE 1

Audit and Baseline: Record Before You Touch

If you do not record how the site performs today, you cannot tell afterwards whether the migration helped, hurt or did nothing. Google’s documentation lists recording analytics baselines for both the old and new sites as part of preparation, and it also tells you to verify every variant of the site in Search Console: www, non-www, HTTP and HTTPS.

Capture these before any change:

Search Console performance: export clicks, impressions, position and top queries by page for at least the last 16 months, which is the most Search Console keeps.
Analytics: sessions, conversions and revenue by landing page.
Crawl: a full crawl of the live site with status codes, titles, descriptions, headings, canonicals, hreflang and internal links. A crawler such as those in my site audit tools comparison will do this.
Indexing: the Page indexing report counts, so you know how many URLs are indexed now.
Links: external links by target page, from Search Console’s Links report plus a backlink tool. See backlink checkers compared.
Speed: Core Web Vitals on your top templates, so the new build can be compared fairly.

baseline-export.txt

$ record before changing anything
[x] search console: 16 months by page + query
[x] analytics: landing pages, conversions
[x] full crawl: status, titles, canonicals
[x] indexed page count
[x] backlinks by target URL
[x] core web vitals by template
[!] save copies outside the old server

phase 1 continued

Build the Full URL Inventory

The inventory is the master list every other step depends on. A page missing from it will not get a redirect.

Google suggests collecting old URLs from several places because no single source is complete: your sitemaps, high-traffic pages in server logs or analytics, the Links report in Search Console, your CMS listings and recent server logs. It also says to include images, videos, JavaScript and CSS files, since these can receive traffic or links of their own.

Source	What it catches
XML sitemap	Pages you intended to be indexed
Crawler export	Everything reachable by links, including orphan-adjacent pages
Search Console performance	URLs that actually earn impressions and clicks
Analytics landing pages	URLs that bring visits from any source, including email and social
Backlink tool and Links report	URLs with external links, including old pages you forgot
Server logs	URLs Googlebot and users actually request, including images and files
CMS export	Published, draft and scheduled content

Merge these into one sheet, remove duplicates and add a column for traffic, a column for links and a column for the decision. Then sort by value. The top of that list is where a redirect error costs the most, so it is where you test hardest.

Decide what each page becomes

// keep

Same content, new URL

Map it one to one to its new address with a 301 or 308.

// merge

Several into one

Google says consolidating several old pages into one new page is fine. Redirect each old URL to that one page.

// remove

No longer needed

Google says removed or merged content should return a 404 or 410 on the new site. Do not redirect it to the homepage.

PHASE 2

URL Mapping: The Sheet That Decides Everything

A mapping sheet lists every old URL beside the exact new URL that replaces it. For a simple domain change where paths stay the same, Google says a wildcard redirect may be enough without a full list. For anything else, build the sheet.

Google’s guidance on mapping is specific:

Match like for like. Send each old URL to the closest equivalent page, not to a generic page.
Do not funnel everything to the homepage. Google says sending many unrelated URLs to one page can be treated as a soft 404.
Avoid chains. Point each old URL straight at its final destination. A chain of A to B to C wastes crawl effort and slows users.
Store the rules properly. Keep the mapping in a database or in rewrite rules, not in someone’s memory.

Also prepare the pieces that must change on the new site: a self-referencing canonical tag on every page, updated hreflang annotations if you use them, internal links pointing to new URLs, a new XML sitemap and a list of external sites that link to the old URLs.

url-map.csvexample

old url	action	new url
/services/seo/	301	/seo-services/
/blog/2019/tips/	301	/blog/seo-tips/
/tag/old-tag/	410	none
/about-us.html	301	/about/
/img/team.jpg	301	/media/team.webp

// illustrative rows, not from a real site.

redirects

Which Redirect to Use

The status code tells Google whether a move is final. Using the wrong one is one of the most common migration mistakes.

Method	Treated as	Google’s guidance
301 or 308	Permanent	The default for a move. Tells Google the new URL should be the canonical one.
302, 303, 307	Temporary	Leaves the original URL as the one shown in results. Using one for a permanent move may keep the old URL visible.
Meta refresh (0 seconds)	Permanent	Works when server-side is not possible. A delayed refresh counts as temporary.
JavaScript redirect	Depends on rendering	Last resort. Google sees it only after rendering, and if rendering fails it may never see it.

// source: Google Search Central, redirects and Google Search. Table is a paraphrase.

How long to keep redirects

Google says to keep redirects in place for at least one year so signals can transfer to the new URLs, and to consider keeping them longer because users who reach a page through a redirect see it load more slowly. In practice most sites leave redirects for as long as the old URLs still have links or traffic, which is often indefinitely.

Google also notes that after a move, old URLs may still appear in results for a while as alternate names. It says this is normal and tends to fade without action.

redirect-rules (nginx and apache)

# nginx: one old path to one new path
location = /services/seo/ {
return 301 https://example.com/seo-services/;
}
# apache .htaccess
Redirect 301 /about-us.html /about/

PHASE 3

Staging: Test Before Anyone Can See It

Build and test the new site on a staging address that search engines cannot index. Google’s hosting-move guide suggests a staging hostname, ideally restricted by IP, and a noindex on test pages so they do not get indexed. For a migration with URL changes it adds: install TLS certificates for HTTPS moves, import images and downloads such as PDFs, and set up the new robots.txt so it blocks only what you intend.

The central risk is the rule you add during development and forget to remove. Google lists leaving migration-only noindex tags or robots.txt blocks in place as a classic mistake. Write down, before launch, the exact moment each block will be lifted and who will do it.

Also confirm the server can cope. Google tells you to check the new infrastructure can handle heavier Googlebot traffic after the move, because crawling often rises once the redirects and sitemaps are live.

// staging gates

Do not launch until all are true

Staging is blocked from search (password, IP or noindex)
Every mapped redirect returns the intended status
Canonicals are self-referencing on the new URLs
Titles, descriptions, headings and schema carried over
Images, PDFs and downloads load
Forms, checkout and tracking fire correctly
TLS certificate is valid on every hostname
Server load tested for crawl spikes

what to carry over

On-Page Elements That Must Survive

A migration is the easiest moment to silently delete SEO work. Compare the new templates against your crawl export field by field.

// content

Text and headings

Keep the copy that earns rankings. Google tells you to change one thing at a time, so avoid rewriting pages during the same release unless you must.

// metadata

Titles and descriptions

Export them before and compare after. Many themes reset them to defaults when a CMS changes.

// signals

Canonicals and hreflang

Each page should point to itself as canonical. Hreflang annotations need updating to the new URLs on both sides of every pair.

// structure

Internal links

Update them to the final URLs so users and Googlebot do not pass through redirects. Google tells you to do this right away at launch.

// markup

Structured data

Re-test it. Schema often lives in a plugin or template that does not move with the content. See my technical SEO guide.

// media

Images and files

Image search can send real traffic. Keep file names and alt text, and redirect old image URLs if they change.

phase 4

Launch Day Checklist

Pick the quietest traffic period of your year. Google advises scheduling a move for your typically lowest-traffic time.

Freeze content. Stop publishing and editing on the old site so the new one does not miss late changes.
Activate redirects. Switch on the mapped 301 or 308 rules. For a hosting move there are no redirects: you update DNS to point at the new provider, having lowered the DNS TTL to a few hours about a week earlier.
Remove temporary blocks. Delete staging noindex tags and robots.txt disallow rules on the new site. Do this first-thing, then verify it.
Check Googlebot access. Run the URL Inspection tool on the new site. Make sure firewalls and DoS protection are not blocking Googlebot.
Submit the new sitemap. Google also suggests keeping the old sitemap submitted for monitoring purposes, even though another section says you can remove it.
Submit Change of Address if it applies. Google says to use it only for domain or subdomain changes, not for HTTP to HTTPS, www toggles or path changes. For a domain move, submit it for every verified variant of the old domain.
Update internal links. Point them to the new URLs immediately.
Contact linking sites. Ask the most valuable external sites, ranked by traffic, to update their links. Update social profiles, ad campaigns and email footers too.
Spot-check 50 URLs. Test the top pages by traffic and links, plus one URL from every template, with a status checker and URL Inspection.

PHASE 5

After Launch: What to Watch and When

Google is plain about what to expect: rankings and visibility may shift for weeks or longer while it recrawls and reindexes, new URLs gradually replace old ones in results, and Googlebot has to visit every old and new URL at least once before the move is complete. Small to medium sites may need a few weeks. Large sites take longer.

Google’s monitoring list is a good frame:

Sitemaps report: the new sitemap’s indexed count should rise while the old one falls. Redirect warnings on the old sitemap are expected.
Page indexing report: indexed pages drop on the old site and rise on the new one. Investigate surprise errors.
Performance report: new URLs should begin earning impressions and clicks.
Server logs: check Googlebot activity, error codes and normal user traffic.
Analytics: old-site traffic should decline as new-site traffic grows.

For a hosting move, Google adds that a short drop in Googlebot’s crawl rate right after launch is normal and typically recovers within a few days. Keep the old server running until its logs show zero traffic, and only then shut it down.

monitoring-schedule.txtsuggested

when	check
Day 0 to 1	Status codes, robots.txt, noindex, sitemap fetch
Day 2 to 7	Crawl errors, indexing report, server logs
Week 2 to 4	Indexed counts, top landing pages, conversions
Month 2 to 3	Traffic against baseline, lost links, redirect chains
Month 12	Review before removing any old redirect

// the schedule is my suggestion; Google gives no fixed timetable.

by migration type

Extra Steps for Each Kind of Move

// hosting or server move

No URL changes

Copy the site and test on a staging hostname
Lower DNS TTL about a week ahead
Confirm Googlebot is not blocked by firewalls
Keep verification files and tags on the new copy
Keep the old server until logs show no traffic

Host choice affects speed, so see my LiteSpeed hosting and VPS hosting comparisons.

// http to https

Protocol change

Install and test the certificate first
Redirect every HTTP URL to its HTTPS equivalent
Verify the HTTPS property in Search Console
Update canonicals, sitemaps and internal links
Fix mixed content
No Change of Address request needed

// domain change

New domain

Verify old and new domains, all variants
Redirect one to one, not to the homepage
Submit Change of Address for every old variant
Carry over the disavow file if you had one
Check a used domain for old manual actions
Update Business Profile and directory listings

// cms or platform change

New system

Compare the new URL pattern to the old before building
Rebuild redirects from the inventory, not from defaults
Check titles, descriptions and schema fields carried over
Review pagination, filters and parameters
Do not redesign in the same release

Choosing a platform? Read website builders compared for SEO.

common mistakes

Where Migrations Usually Go Wrong

// mistake 1

noindex left on

The staging rule goes live. Pages drop out of the index.

Check the live HTML and robots.txt within minutes of launch.

// mistake 2

Redirect to homepage

Hundreds of old URLs all point at one page. Google may treat them as soft 404s.

Map like for like, or return 404/410 for removed content.

// mistake 3

Redirect chains

Old to temporary to final. Each hop slows crawling and users.

Point each old URL directly at the final destination.

// mistake 4

Temporary redirects

A 302 is used for a permanent move, so old URLs stay in results.

Use 301 or 308 for final moves.

// mistake 5

No baseline

Traffic drops and nobody can say by how much or where.

Export Search Console, analytics and a crawl first.

// mistake 6

Too many changes

URLs, design, copy and CMS all change together.

Move first, redesign later, as Google advises.

WORDPRESS

Migrating a WordPress Site: Practical Notes

WordPress adds a few specific traps on top of the general list.

Search engine visibility setting. The “discourage search engines” checkbox under Settings, Reading adds noindex. It is often ticked on staging and carried to production.
Hard-coded URLs. Old domain names live inside post content, widgets and page-builder data. Use a search-and-replace tool that handles serialized data safely.
Permalinks. If the structure changes, old URLs need redirects. Save permalinks again after moving to refresh rewrite rules.
Plugins that store SEO fields. Titles and descriptions in an SEO plugin must move with the database. See WordPress SEO plugins compared.
Caching and CDN. Purge caches after launch, otherwise visitors and crawlers may see old versions.

If you want this handled for you, my WordPress SEO services include migration planning.

wordpress-launch-checks.txt

$ run on launch day
[ ] settings > reading: search visibility OFF
[ ] robots.txt allows crawling
[ ] permalinks re-saved
[ ] no old domain left in content
[ ] seo plugin titles carried over
[ ] sitemap submitted
[ ] cache purged (plugin + cdn)

if traffic drops

When Rankings Fall After a Move

A dip is expected, but a sustained fall needs a diagnosis, not a panic.

Symptom	Likely cause	First check
Pages missing from Google	noindex or robots block still live	URL Inspection on a lost page
Old URLs stay in results	Temporary redirects, or not yet recrawled	Status code of the old URL
One section drops	Unmapped or wrongly mapped URLs	Crawl the old URL list against redirects
Whole site drops	Blocked crawling, server errors, canonical mistakes	Server logs and the Page indexing report
Slow recovery	Content, structure or speed changed in the same release	Compare the new crawl to the baseline
Crawled but not indexed	Thin or duplicate templates	See my crawled, currently not indexed guide

If the drop lines up with a Google update rather than your launch date, read core update recovery before changing anything else.

// how this guide was made

What I Checked and What I Didn’t

I read Google Search Central’s documentation on moving a site with URL changes, moving a site without URL changes and redirects. Timing figures such as “at least a year” and “a few weeks” are Google’s. The monitoring schedule and the WordPress notes are my own suggestions from standard practice, not Google statements. I did not run a migration for this page, and there are no affiliate links here.

faq

Website Migration Checklist FAQ

What is a website migration?

A website migration is any major change that can affect how search engines find your pages: a new domain, a new hosting provider, a switch to HTTPS, a new CMS or a redesign that changes URLs or structure.

Will I lose rankings when I migrate?

Not necessarily. Google says rankings and visibility may fluctuate for weeks or longer as it recrawls, and that this is normal. Careful redirects and testing reduce the risk, but no one can guarantee the outcome.

How long does a migration take to settle?

Google says Googlebot must visit every old and new URL at least once. Small to medium sites may need a few weeks, and large sites longer.

Should I use 301 or 302 redirects?

Use 301 or 308 for permanent moves. Google says a temporary redirect leaves the original URL shown in results, so it is wrong for a final move.

How long should I keep redirects?

Google says at least one year, and longer is better because users experience redirects as slower than direct links.

Do I need the Change of Address tool?

Only for moving between domains or subdomains. Google says not to use it for HTTP to HTTPS, www and non-www switches, or path changes.

Can I redirect everything to the homepage?

No. Google warns that sending many unrelated URLs to one page can be treated as a soft 404. Redirect each URL to its closest equivalent.

Should I redesign and migrate at the same time?

Google advises changing one thing at a time. Combining a URL move with a CMS or layout change makes problems harder to trace.

When is the best time to migrate?

Google suggests your typically lowest-traffic period. Avoid peak sales seasons and campaign launches.

Do I need to move my disavow file?

Google lists re-uploading any disavow file to the new property as part of preparation for a move. See my Penguin update guide for when disavowing matters.

Can I do a migration myself?

A small site with no URL changes, such as a host move, is realistic to do yourself. A domain change or CMS switch on a site with real traffic is where a second pair of eyes pays off. See my migration service if you want help.

sources

Sources Used on This Page

// keep reading

More on Technical Moves

Read the technical SEO guide, compare site audit tools, and see the website migration SEO service.