What does a website migration SEO checklist cover that a launch checklist doesn't?
A launch checklist asks whether the new site works. A website migration checklist asks whether Google can still find everything the old site earned. The search side of a move is the handover from every old address to its new one, and most launch checklists skip it because nothing looks broken on the day.
I'll be clear about the border. I don't build or design the new site, and this checklist doesn't cover hosting setup, theme work or copying the database. That's your developer's job. What I own is the search side: the URL inventory, the redirect map, the checks on the day and the weeks of Search Console reading after. Here's the whole thing on one screen, to copy into your own project notes.
| Phase | The checks | When it runs |
|---|---|---|
| Before launch | Baseline export, full crawl, hidden URLs added, a one to one redirect map, templates checked, robots.txt and sitemap written, the map tested on staging | As soon as staging exists, well before the switch |
| Launch day | Robots.txt, noindex, canonicals, the sitemap, one-hop redirects, Search Console verification, analytics tags, Change of Address for a new domain | In the first hour after the new URLs go live |
| After launch | Page indexing and clicks by page, old URL against new URL | Day 7, day 14 and day 28, against the same stretch before |
Which kind of migration is this?
The type decides how much of the checklist applies. A hosting switch with identical URLs needs very few items, and Google says a short drop in crawl rate right after that kind of launch is normal. A domain change needs every item, plus the Change of Address tool.
| Migration | What changes | What it needs most |
|---|---|---|
| New domain | Every URL's host | The full map, Change of Address, a new Search Console property |
| New platform or CMS | Usually every URL pattern | A pattern by pattern map and template checks |
| HTTP to HTTPS | The protocol only | One-hop 301s and no mixed content; Google says not to use Change of Address |
| New URL structure | Slugs or folders on the same domain | The map and internal links updated to the new URLs |
| New host | The server, not the URLs | Robots.txt, noindex and Search Console checks, with no map |
Each has its own walkthrough: changing a WordPress site's domain, moving WordPress to a new host, and the Wix to WordPress walkthrough for a platform move. On WordPress the list doubles as a WordPress migration checklist with two additions: the permalink setting, checked before any redirect's written, and the Discourage search engines box under Settings, Reading, which is often left ticked on staging. If the site already has faults, I record them first, so old problems don't get blamed on the move.
How I run the pre-launch checks, in order
Each step needs what the step before it produced.
- Step 01
Save the baseline
I export the Search Console Performance report by page for the last three months and keep the file. Exports are truncated to 1,000 rows, so on a bigger site I split them by date range or folder, or use the API.
- Step 02
Crawl the old site
A full crawl gives every internally linked URL with its status code, title, meta description, canonical and H1. Once the new site replaces the old one, it's the only record of the old titles.
- Step 03
Add the URLs a crawl can't see
Old XML sitemaps, pages Search Console shows with impressions that nothing links to any more, and URLs from a backlink export.
- Step 04
Give every old URL one destination
Its direct replacement, or the closest page answering the same query. A page with nothing close returns a 404 or a 410, and nothing goes to the homepage by default. Google recommends server-side permanent redirects, a 301 or a 308.
- Step 05
Check what the new templates carry
Titles, descriptions, headings, structured data and internal links on staging. Google's guidance is a self-referencing canonical on each new URL, and internal links that point at new URLs rather than lean on the redirects.
- Step 06
Write the live robots.txt and sitemap
Both get written before launch. Staging's robots.txt often blocks everything, and it's the file most likely to travel to the live server by accident.
- Step 07
Test the whole map on staging
I run the full old URL list against staging and flag anything that isn't a single hop to a page returning 200: chains, loops, 404s and redirects to the homepage.
Don't import content first and settle the URLs later. Once pages exist with their own slugs, the map has to chase whatever got generated. I agree the URL pattern with your developer before any import runs.
Rather have me do this? One person, whole job.
Book a call on UpworkWhich checks do I run over HTTP on launch day?
On launch day I don't trust dashboards. A settings screen shows what the CMS thinks it's sending, and a request to the live URL shows what Googlebot actually gets. Every check below reads the real response in the first hour after the switch.
- i.
Robots.txt allows crawling
A leftover
Disallow: /from staging blocks the lot, and Google's documentation adds a twist: if a page is blocked, the crawler never sees its noindex, so the URL can stay in results with nothing behind it. - ii.
No noindex in the head or the headers
A noindex can arrive as a meta tag or as an X-Robots-Tag response header, and Google says they have the same effect. A header set at server level won't show up in the page source.
- iii.
Canonicals name the live URL
Each new page's canonical points at itself on the live domain. Not at staging, and not at the old address it's replacing.
- iv.
The sitemap lists pages that answer 200
I sample its URLs and confirm each one returns 200 with no redirect. Only then does it go into Search Console.
- v.
Old URLs redirect in one hop
The top old URLs by clicks from the baseline, plus a sample from every URL pattern, each returning a single 301 or 308 to its mapped page. Any that 404, chain or fall back to the homepage get fixed before I close the day.
- vi.
Analytics and tags carry over
The GA4 or Tag Manager snippet is in the live page source, a test visit shows in the GA4 Realtime report, and the conversion events still fire on the new form and checkout URLs. Without this, nobody can see what the move did to enquiries.
- vii.
Search Console still verifies
Google says removing a verification file or tag loses verification. A Domain property verified through DNS covers every subdomain, so I set one up if the site hasn't got one.
- viii.
Change of Address, only for a new domain
For a move to a new domain or subdomain I submit it for the old site. For http to https, a www switch or path changes on the same domain, Google says not to use it.
Keep the old domain registered and its server answering. A redirect only works while something's there to send it, so letting the old domain lapse cuts every redirect at once.
What do I compare in Search Console after 7, 14 and 28 days?
Google says a small to medium site can take a few weeks for most pages to move, and that visibility can fluctuate while it does. So the three checkpoints aren't deadlines. They're the points where I compare like with like, the same number of days before and after launch, page by page.
| Checkpoint | What I compare | What would worry me |
|---|---|---|
| Day 7 | Page indexing status for the old URLs, and clicks by page against the 7 days before launch | Old URLs showing Not found (404), which means a gap in the map, or new URLs excluded by a noindex |
| Day 14 | Clicks and impressions for each old URL against its new URL, pair by pair | An old URL losing clicks while its new URL gains none |
| Day 28 | The full 28 days against the 28 before launch, by page and by query | A whole template or folder down, which points at a template fault rather than one redirect |
In the Page indexing report, old URLs moving into Page with redirect is what I want to see. Google's description is plain: a URL that redirects won't be indexed, and that's the point. Old URLs showing Not found (404) are missing redirects, and each one goes into the map the day it appears.
Google also notes that the sitemap of new URLs starts with zero pages indexed while the old one shows many. That's expected in week one. It's the direction over the following weeks that tells me whether the move is taking.
Does a redesign on the same domain need the same checks?
Yes, for every URL, title or internal link it changes, and my website redesign SEO checklist covers the content risks a redesign adds. It skips the domain work, like Change of Address. The GK Jewelers redesign is the case I point people to: a redirect map built before the redesign shipped, rather than after, would have meant no crash to recover from.
What gets missed most often on a website migration SEO checklist?
None of these are exotic. They're missed because nobody's looking on launch day, and each shows up later as a slow leak rather than a crash.
- i.
Pages nothing links to
They don't appear in a crawl, but Search Console shows them earning impressions. A map built from a crawl alone leaves them to 404.
- ii.
Images and PDFs
Media URLs often change with a new upload path, and any image search traffic or PDF backlinks go with them unless they're mapped too.
- iii.
Paginated and parameter URLs
Page two of a category, or a filtered URL with its own impressions, needs a rule or a deliberate decision to let it go.
- iv.
Chains from older moves
A site that's moved before already has redirects. I point those straight at the new destinations instead of stacking another hop.
- v.
Titles that fell back to defaults
Rebuilt templates often use the page name as the title. I compare the old crawl's titles with the new ones before launch, not after clicks dip.
If you want the baseline, the map, launch day and the 28 days after handled by one person who answers for all four, that's the migration work I do, fully remote. The build stays with your developer.
Book a call on Upwork
