How to move a business website without breaking its search visibility.

A website migration is not simply moving text and pictures. The old site has accumulated URLs, links, search history, forms, customer bookmarks, and connections to other systems. A clean design can still fail if those working parts disappear at launch.

The goal is continuity: customers should reach the right information, important actions should work, and search engines should understand where each useful page moved. This checklist explains how to get there.

1. Define what kind of move you are making.

Changing hosting while keeping the same domain and URLs is different from changing the domain, platform, or page structure. A hosting move focuses on server readiness, DNS, certificates, and making sure the same pages remain available. A move with URL changes also needs page-by-page mapping and permanent redirects.

Write down what will change: domain, HTTPS, hosting, content system, design, URLs, forms, commerce, analytics, and integrations. The more that changes at once, the harder it becomes to isolate a problem.

2. Inventory the old site before building the new one.

Begin with more than the visible menu. Collect URLs from the current sitemap, analytics landing-page reports, Search Console, internal links, backlinks, and a crawl of the site. Include PDFs, campaign pages, old blog posts, downloadable files, image URLs that other sites use, and pages that are not linked from navigation.

Add the business functions attached to those pages: forms, email recipients, booking, checkout, tracking events, CRM handoffs, and logins. A page can look correct while quietly sending every inquiry into the void. Our guide to measuring local website leads explains which actions deserve verification.

3. Decide what happens to every useful old URL.

Give each old URL one decision: keep it, improve it, merge it into a closely related page, or retire it. If a page moves, map it to the most relevant new destination. If several weak pages are genuinely combined into one stronger page, they can share that consolidated destination.

Do not send every missing URL to the homepage. Google’s site-move guidance warns against redirecting many old URLs to one irrelevant page because it confuses visitors and may be treated as a soft 404. If no useful replacement exists, a proper 404 or 410 response is more honest than a misleading redirect.

The mapping sheet should include the old URL, new URL, action, redirect status, and test result. It becomes the launch checklist and the record of why a page changed.

4. Prepare the new site for continuity.

Each new page should have a useful title, description, main heading, self-referencing canonical URL, working internal links, and the correct structured data where appropriate. Update links so they point directly to new URLs instead of relying on redirects. Include only canonical new URLs in the new sitemap.

Move analytics and conversion tracking deliberately. Test form recipients, downloads, booking, payments, and CRM or ERP connections. If staging uses noindex or blocked robots rules, remove that protection from the public site at launch. This tiny checkbox has ruined larger afternoons than it deserves.

Keep a backup of the old site, its database, and the final mapping. A controlled repository and repeatable deployment process make rollback safer than editing the live site by hand.

5. Use permanent server-side redirects for moved pages.

For a permanent move, Google recommends server-side 301 or 308 redirects when possible. Point each old URL directly to its final new location rather than creating chains such as old page to temporary page to new page. Redirect chains add delay and more places to fail.

Google states that permanent redirects do not cause a loss of PageRank, but the replacement still must be relevant and accessible. Keep redirects for at least a year; for customer bookmarks and durable links, keeping them indefinitely is often sensible.

If the domain changes, verify the necessary Search Console properties and use Google’s current site-move process. If only hosting changes and URLs remain identical, follow the simpler hosting-move workflow instead. Our website migration and redirect service separates these cases before the launch plan is written.

6. Test the public site, not only the preview.

After launch, test representative URLs on the actual domain. Check each old URL's status and final destination. Verify HTTPS, canonicals, robots rules, sitemap access, forms, analytics, and structured data. Test on a phone and desktop, and complete the primary customer action.

A redirect can return 301 and still be wrong. A form can show a success message and never send the email. Our quality-assurance process combines automated checks with human testing because both kinds of failure matter.

• Sample every redirect type: homepage, service, article, file, campaign page, and retired content.
• Complete every critical action: inquiry, booking, purchase, login, download, call, and text.
• Read the public metadata: canonical, robots directives, titles, and structured data.
• Check monitoring: analytics events, Search Console, uptime, and server errors.

7. Expect a transition and monitor it.

Google notes that rankings can fluctuate while a moved site is recrawled and reindexed. For a medium-sized site, new URLs may take weeks or longer to replace old ones. Submit the new sitemap, watch indexing and crawl reports, and compare important landing pages, leads, and server errors before and after launch.

Look for 404 spikes, redirect loops, unexpected noindex rules, broken forms, and old URLs that still receive visits. Fix the cause rather than repeatedly requesting indexing. A website health check can reveal public failures, but it does not replace real customer and search data.

8. Ask a migration provider questions that reveal the plan.

• How will you discover old URLs? The answer should include more than the current sitemap.
• Who decides what gets kept, merged, or retired? Technical convenience should not make the content strategy.
• How will redirects be tested? Ask for the map, status checks, final destinations, and known exceptions.
• How will forms and integrations be verified? A visual comparison is not enough.
• What happens after launch? Monitoring, rollback, ownership, and a defined support period should be clear.

9. Know when migration is not the right first project.

Do not migrate because a new platform is fashionable. If the current site is secure, maintainable, and supports the business, a focused repair may cost less and introduce less risk. Do not begin until you control the domain, hosting, content, credentials, and critical third-party accounts.

Migration becomes worthwhile when the platform blocks necessary work, creates recurring risk, or costs more to preserve than to replace. A strong proposal should explain both the benefit of moving and the cost of staying.

The final test is simple: customers should find the right page, complete the same or better action, and never need to understand that a migration happened. The project may be complicated behind the curtain. The public experience should not be.