Moving a business website to a new platform, host, or domain can solve real problems. It can also create new ones if important URLs disappear, internal links break, or search engines find conflicting versions of the site. The solution is not to avoid change. It is to plan the move around the content and paths customers already use.
A site migration might mean changing the hosting provider without changing URLs, redesigning a WordPress site on the same domain, changing the URL structure, or moving to a completely different domain. Each situation has different risks. The more URLs and systems you change, the more carefully you should test.
Identify exactly what is changing
Write down whether the domain, host, CMS, theme, page structure, permalink format, content, or design will change. A hosting-only move generally has different search implications than a full domain and URL migration. Avoid bundling unrelated changes together when they can be staged separately.
- Hosting move: preserve existing public URLs where possible.
- Redesign: compare layouts and content before deciding whether URLs should change.
- CMS change: map WordPress or other platform content to the destination system.
- Domain move: prepare site-wide redirects, search verification, and communication updates.
- URL cleanup: replace old paths with logical new paths and document every mapping.
Define success before starting: core pages remain accessible, important content is preserved, inquiry routes work, and technical signals point to the intended new pages.
Build a reliable inventory of existing URLs
Export the current XML sitemap and crawl important internal links. Also review analytics, search data, and any known landing pages that may not appear in a menu.
A sitemap alone may omit older pages, redirects, documents, and URLs that still receive visits or links. Include those where they matter.
For each old URL, note its page title, status, current destination, intended new destination, and whether a redirect will be needed. Preserve pages that answer different customer needs. Avoid redirecting every old service page to the home page simply because the old content was removed.
Check content types beyond pages: blog posts, media downloads, product pages, category archives, and custom post types may all have discoverable addresses.
Choose redirect destinations by intent
When a URL changes permanently, a server-side 301 redirect is usually appropriate. Send each old page to the most closely related replacement page. If the content has moved to a new path, the redirect should preserve the visitor’s ability to find that content.
A missing page with no relevant replacement should not automatically redirect to an unrelated location. Review whether it should remain a genuine 404 or 410 response instead. Avoid redirect chains and loops by sending old addresses directly to final destinations.
- Old service page → matching new service page.
- Old blog article → the same migrated article at its new URL.
- Renamed downloadable guide → its replacement resource when equivalent.
- Old campaign page → a relevant active page only if it truly satisfies the same need.
- Deleted content without a replacement → a legitimate not-found or gone response.
Prepare content and technical signals together
Before launch, compare headings, titles, meta descriptions, canonical URLs, structured data, and internal links. Preserve important content unless there is a deliberate editorial reason to change it. A new design should not quietly remove sections that help visitors choose a service.
Check the new templates at desktop and mobile widths. Pay special attention to menus, forms, image sizing, and heading structure.
Keep draft or staging copies out of public search results while allowing the final production site to be crawlable after launch.
Make sure internal links point to the final destination URLs, not old addresses that rely on redirects. Update navigation, footer links, buttons, image links, and relevant references in blog content.
Use only one intended canonical tag on each page. Verify that no staging-domain canonicals or accidental noindex settings remain when the new site becomes public. Review schema output rather than blindly copying markup that may no longer match the page.
Back up and test before switching traffic
Create a complete backup of the original site, and ideally verify restoration in an isolated environment. Record the existing DNS configuration, particularly settings that support email. A host migration can go wrong if website-related DNS changes unintentionally remove records used by other services.
Test important URLs on the destination before the public switch. Use a staging domain or supported preview method, and protect it from indexing and unintended transactions. Confirm contact forms, payments, downloads, and logins without generating real customer activity.
Use a launch-day checklist
- Confirm the source backup is available and tested as far as practical.
- Deploy the approved site and verify SSL and HTTPS connections.
- Check a sample of old URLs for correct final redirects.
- Verify the home page, major service pages, contact form, and mobile menu.
- Check robots directives and canonical tags on the public destination.
- Generate or verify the updated sitemap and submit it in the appropriate search tools.
- Watch for server errors and missing assets after the switch.
Do not assume a successful home-page load proves the migration worked. Test a sample of important deep links and older URLs. Separate hosting problems, redirect mapping errors, and content regressions in your notes so each can be fixed correctly.
Monitor the site after launch
A migration is not finished when the DNS change is made. Monitor index coverage, crawl errors, top landing pages, and real inquiries over the following weeks. Changes in search performance can take time to settle, and not every fluctuation indicates a permanent problem.
Keep old redirects in place for as long as they are useful and necessary. Update important external profiles and business listings with the new addresses. Retain the original URL mapping document as an ongoing reference.
If the site has many pages, prioritize review using traffic, business value, and inbound links. Fix broken customer journeys first, then less-visited archives or supporting content. Continue checking that new pages use the correct final URLs.
Get help with the parts that are easy to miss
A business migration benefits from coordination between content, design, hosting, and SEO. For a platform or layout change, website redesign planning can help define the new structure. For changes affecting local service visibility, review local SEO considerations before removing important location or service content.
The practical rule is to make every important old address accountable: keep it, map it to a relevant new address, or document why it is being retired. Customers should still find what they came for, and the technical signals should clearly identify the version you want search engines to use.