A website migration checklist turns a move into a set of checks people can own. You may be changing the host, the website platform, the domain or the page addresses. Each choice affects what you need to test.
This guide covers the move itself: what to save, where old links should go and what must work at launch. Plan the content and design first, then use this checklist to move the agreed site.
The short answer
- Decide whether the host, platform, page paths or domain will change.
- Keep useful URLs, map moved pages to a relevant destination and test the final response.
- Preserve mail records, account access and verification while checking the live move.
How this guide was made
This checklist draws on Google site move guidance and Cloudflare mail record documentation. The URL map and release record are fictional planning examples. No migration or mail delivery test was performed, and unchanged search traffic is not guaranteed.
Sources checked .
Define exactly what is moving
Write a short scope statement. For example: We are changing the website host and keeping the domain and page addresses. That is a different job from moving to a new domain with a new set of pages.
Avoid changing every part at once when you can. Smaller changes are easier to check and easier to explain if something fails. Name the person who will decide whether the launch is ready.
Set a launch window when the right people are available. Keep contact details for the website provider, domain owner and email provider. Do not plan the switch for a time when no one can respond to a blocked form or missing page.
| Move type | Main change | Extra focus |
|---|---|---|
| Host only | Hosting and possibly DNS | Same URLs, verification, traffic at both hosts |
| New platform, stable URLs | Code and editing system | Content, forms and responses |
| New page paths | Part of affected URLs | Individual redirect map |
| New domain | Host name in public addresses | Domain access, redirects and search settings |
Keep the same URLs
A host only move changes where files are served. A platform move may also keep the same public URLs. Check that each full old address still opens the correct content.
Source for this section: [3] Google guidance on moving hosts with unchanged URLs
Change page paths
If /quote becomes /contact, map that move explicitly. A new design alone is not a reason to discard a useful address.
Source for this section: [1] Google guidance on site moves with changed URLs
Change the domain
A new domain changes every full address even if paths stay the same. Include ownership access, preferred URLs and old domain redirects in the scope.
Source for this section: [1] Google guidance on site moves with changed URLs
Save an inventory and recovery plan
List your important pages, images, files and forms. Include pages linked from email messages or ads, not just the main menu. Record any tools that measure visits or pass inquiries to another system.
Save protected backups or exports before the move. Confirm what they include and how they can be restored. Customer information needs careful handling and should not be copied into a public planning sheet.
Agree on a rollback plan. Rollback means returning to the previous working setup. Name who can do it and which failures would trigger it. Also plan how to protect any new inquiries or data collected during the launch.
- Save the page and file inventory, including links used in ads and emails.
- Preserve search ownership verification files or tags.
- Confirm domain, hosting, mail and search account access.
- Save current DNS records and name the person permitted to edit them.
- Record how to protect new enquiries if the site must be restored.
Source for this section: [3] Google guidance on moving hosts with unchanged URLs
Map each old page to its next home
Keep useful URLs where possible. Map each changed page to its closest relevant replacement. Sending unrelated old pages to the homepage does not preserve their purpose.
HTTP 301 and 308 are permanent redirect options. Ask the technical owner to check the response, the direct destination and the final working page. Avoid loops and chains through retired paths.
The paths below are fictional examples. A removed page with no useful replacement should return a genuine 404 or 410 response rather than pretend to be a working homepage.
| Old path | Decision | Expected response | Final check |
|---|---|---|---|
| /services | Keep /services | 200 | Current service content |
| /quote | Move to /contact | 301 or 308, then 200 | Contact page and working enquiry |
| /event2018 | Remove, no replacement | 404 or 410 | Clear missing or removed page response |
Sources for this section: [1] Google guidance on site moves with changed URLs; [4] Google guidance on permanent redirects; [5] Google guidance on crawling and missing page errors
Check the new site before the switch
Use a private preview or staging area to review the new pages. Check the content against your inventory. Read the main service pages, open downloads and test the menu on a phone.
Have the technical owner check canonical URLs. These identify the preferred address of a page. They should point to the intended public site, not to a temporary preview address.
Check links, redirects and the sitemap, which lists pages for search engines. Plan the change from private preview rules to public indexing rules. A setting that keeps a test site out of search can block the live site if it is left in place.
Source for this section: [1] Google guidance on site moves with changed URLs
Protect email and contact paths
A website DNS change can break email if records are removed or replaced by mistake. Keep the exact records supplied by your mail provider. Do not copy mail values from a generic website example. Confirm email still sends and arrives after the switch.
Test forms using labeled test details. Confirm the page result and actual delivery. Check the form that a paid advert or old email links to as well as the one in the main menu.
Treat a broken contact path as a launch blocker. Other blockers can include a missing key service page, an incorrect canonical address or a public site that still blocks indexing. Decide these rules before the launch window.
Source for this section: [2] Cloudflare guide to domain email records
Check the live site after launch
Open the public domain and test the most important old links. Confirm the final destination and content, not just whether something loads. Ask the technical owner to check the actual response codes for redirects and removed pages.
Submit the current sitemap through the search tools you use. A submitted sitemap is a discovery step. It does not prove that every page has been indexed or that rankings will stay the same.
Google notes that ranking changes can happen during a move. Its guidance says to keep redirects for as long as possible, generally at least one year. Add their care to the site owner's task list rather than deleting them after launch day.
Source for this section: [1] Google guidance on site moves with changed URLs
Keep a launch record and follow up
Use one row for each check with an owner, result and evidence. Mark unchecked work as Pending. Save the old and new address map beside the launch record so future editors understand the choices.
Watch important pages, search reports and incoming inquiries after the switch. Investigate a missing page or failed task directly. Do not assume that all changes in traffic have the same cause.
A move is complete when the agreed pages and business tasks work and someone owns the follow up. Keep the plan available. It will make the next website change much easier to handle.
| Old URL or path | Expected result | Actual final URL | Owner and evidence |
|---|---|---|---|
| /services | 200, retained content | Pending | Builder, test record pending |
| /quote | Permanent redirect to /contact | Pending | Builder, response check pending |
| /event2018 | 404 or 410 | Pending | Builder, response check pending |
Decide when the old host can close
For a hosting move, check logs and traffic at both hosts. Keep the old service available until the switch is confirmed and traffic no longer depends on it. A fixed number of hours does not prove every visitor has moved.
Record retirement approval separately from launch approval. If redirects depend on the old system, arrange continued hosting before cancelling it.
Source for this section: [3] Google guidance on moving hosts with unchanged URLs
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview