Moving a website can affect your search rankings, organic traffic and customer experience. A website migration might involve changing your domain name, switching hosting providers, moving to WordPress or restructuring your URLs. Each change comes with its own technical requirements.
The biggest risks usually appear when a migration goes live without proper preparation. Important pages disappear, old URLs stop working, redirects point to the wrong destinations or search engines struggle to access the new website.
A well-planned website migration helps you avoid these problems. You can preserve the parts of your website that already perform well while making the technical changes your business needs.
This guide explains how to plan a migration, protect your existing SEO work and check that everything works after launch.
Website migration is the process of moving a website from one setup to another. The changes might involve its domain name, hosting environment, content management system (CMS), URL structure or underlying technology.
For example, a business might move from an older website builder to WordPress because it needs more control over its content. Another business might change its domain name after a rebrand.
Website migration can involve several types of changes.
Migration type | What changes | Example |
Domain migration | The website’s domain name | Moving from oldbrand.com to newbrand.com |
Hosting migration | The server or hosting provider | Moving from one hosting company to another |
CMS migration | The platform used to manage content | Moving from Wix to WordPress |
URL migration | Page addresses or URL patterns | Changing /services.php to /services/ |
HTTP to HTTPS migration | The website’s security protocol | Moving from HTTP to HTTPS |
Website structure migration | Navigation, folders or page hierarchy | Moving blog posts into new categories |
Full website migration | Several parts of the website change | Moving to a new domain and CMS with redesigned pages |
The type of migration determines how much preparation you need. A hosting change that keeps every public URL the same has different requirements from a domain migration that changes hundreds of page addresses.
A migration usually happens because the existing setup no longer meets the business’s needs.
You might need one when:
Before deciding to migrate, identify the problem you’re trying to solve. If the issue is slow loading speed, changing hosting providers might be enough. If your current platform cannot support important business functions, a CMS migration might make more sense.
A clear reason for the move helps you choose the right approach and avoid unnecessary changes.
Search engines use page URLs, content, internal links and other signals to understand your website. A migration can change several of these signals at once.
For example, if a page ranks well for a service keyword and its URL changes, Google needs to discover the new address and process the relationship between the old and new pages. Redirects and consistent page content help search engines understand that relationship.
Temporary ranking fluctuations can occur during a migration. Google explains that processing moved URLs can take several weeks or longer depending on the website’s size and other technical factors. There is no fixed recovery timeline for every site.
Missing redirects: Visitors and search engines reach broken pages when old URLs no longer work.
Lost content: Important paragraphs, headings, metadata or images disappear from the new website.
Incorrect canonical tags: Canonical tags point search engines toward the wrong version of a page.
Blocked crawling: A development setting, robots.txt rule or noindex tag prevents search engines from accessing the new website.
Broken internal links: Navigation menus, blog links and buttons still point to old URLs.
Unchanged XML sitemap: The sitemap continues listing URLs that have moved or no longer exist.
Tracking problems: Analytics settings are missing or configured incorrectly, making it difficult to compare performance before and after launch.
These issues can affect different pages in different ways. That’s why a page-level audit is more useful than checking only the homepage.

Preparation should begin before your developer moves any files or changes DNS settings. Your existing website provides the baseline you’ll use to check whether the migration has worked.
Start by collecting a complete list of your current URLs. A website crawler can identify pages, status codes, title tags, meta descriptions, headings, canonical tags and internal links.
Export the URLs from your XML sitemap as well. Compare that list with your crawl so you can spot pages that might be missing from one source.
Pay special attention to:
Save the results in a spreadsheet. You’ll use this information to plan redirects and compare the old website with the new one.
Use Google Search Console and your analytics platform to record the website’s performance before migration.
Capture organic clicks, impressions, search queries, landing pages and conversion data where available. Record your important keyword rankings separately if you track them using an SEO tool.
Review a period that accounts for normal changes in traffic, such as seasonal demand or a recent marketing campaign.
Without a baseline, it’s difficult to tell whether a traffic drop came from the migration or from an existing trend.
Create a complete backup before making major changes. Depending on your setup, this might include website files, databases, uploaded media, configuration files and email-related settings.
Store a copy somewhere separate from the website’s current hosting account. Confirm that the backup can be restored before relying on it.
Ask your hosting provider or developer about the recovery process if you don’t manage backups yourself.
A staging website lets your team test the new setup before visitors use it.
Check that important pages are present and that forms, navigation, images, downloads and other functions work properly. Review mobile layouts and page loading performance.
Also check the technical settings that control indexing. Development sites are sometimes protected with passwords or noindex directives. Those settings must be reviewed before launch so they don’t accidentally remain on the public website.
If your URLs will change, map every important old URL to its intended destination.
Old URL | New URL | Action |
example.com/web-design-old/ | example.com/website-design/ | 301 redirect |
example.com/blog/old-guide/ | example.com/blog/updated-guide/ | 301 redirect |
example.com/old-service/ | No relevant replacement | Review for 404 or 410 |
Use the closest equivalent destination for each moved page. A retired service page shouldn’t automatically redirect to the homepage if the homepage doesn’t answer the visitor’s original question.
This mapping becomes the working document for your developer and SEO team.
Once preparation is complete, follow a controlled launch process. The exact technical steps depend on whether you’re changing hosting, domains, platforms or URLs.
Review the content on the old and new versions of each important page.
Check the page title, main heading, body copy, structured data where applicable, internal links, image alt text and canonical tag. If a page ranks for a specific search query, make sure its replacement still answers the same question.
You can improve weak content during migration, but avoid rewriting every page without a clear reason. Changing the domain, URLs, templates and content all at once makes it harder to identify the cause of a ranking change.
When a page moves permanently to a new URL, configure a server-side 301 redirect from the old address to the closest relevant replacement.
For example:
https://example.com/old-services/
redirects to:
https://example.com/services/
Test the redirect after implementation. It should take users directly to the correct destination without unnecessary redirect chains or loops.
Avoid redirecting every old URL to the homepage. A redirect should preserve the original page’s purpose as closely as possible.
If a page has genuinely been removed and has no suitable replacement, it may be appropriate to return a 404 or 410 status instead.
Internal links on the new website should point directly to the new URLs.
Review navigation menus, footer links, breadcrumbs, blog posts, related-content sections and calls to action. Updating these links reduces unnecessary redirects and helps visitors move through the new site.
For example, if your web design service page changes its URL, update every blog post that links to the old address.
You should also review links between related services. A migration article might link to your website design services, website redesign services or SEO services when the context is relevant.
Each indexable page should generally have a canonical tag pointing to its preferred URL. During migration, check that canonical tags don’t still reference the old domain or point to unrelated pages.
Review the robots.txt file and any page-level noindex directives. Confirm that Google can crawl the pages you want indexed.
If you use hreflang annotations for language or regional versions, update them to reference the correct new URLs.
Your XML sitemap should list the canonical URLs you want search engines to discover.
Remove old URLs that have permanently moved and include the correct new URLs. Check that the listed pages return successful HTTP responses and aren’t blocked from indexing.
Submit the updated sitemap in Google Search Console after launch.
Make sure your analytics platform still records visits and conversions after the migration.
Test contact forms, phone-number clicks, quote requests, checkout steps and other important actions. A website might look fine while its conversion tracking has quietly stopped working.
If your domain changes, review any settings that depend on the domain or cross-domain tracking.
Use a launch checklist so the team can confirm that the important parts of the website work.
Check | What success looks like |
Homepage and key pages | Load correctly without server errors |
Redirects | Old URLs reach their intended destinations |
Forms and calls to action | Submit and record correctly |
Mobile usability | Navigation and page layouts work on smaller screens |
Robots.txt | Allows crawling of intended public pages |
Noindex directives | Temporary development restrictions are removed |
Canonical tags | Point to the preferred new URLs |
XML sitemap | Contains the correct new URLs |
Analytics | Records visits and conversions |
SSL certificate | HTTPS works without security warnings |
Images and files | Load from their intended locations |
Run a fresh crawl of the new website and compare it with your original crawl. Fix broken internal links, unexpected redirects, missing metadata and important pages that return errors.
If you’re changing hosting, confirm that DNS records point to the correct environment and that the new server can handle normal traffic.
Even a well-planned migration can run into problems. These mistakes deserve particular attention.
If you don’t know which pages existed before migration, you can miss URLs that still receive traffic or backlinks. Use crawler exports, sitemaps, analytics data and Search Console to build a fuller inventory.
Old blog posts and service pages may attract search traffic even when they look outdated. Review their performance and purpose before removing them.
If a page needs updating, preserve its useful information and give it a relevant replacement where necessary.
A migration that includes a new domain, a new CMS, a new design and a complete content rewrite introduces several sources of risk.
Where practical, separate major changes into stages. This makes testing and troubleshooting easier.
Check payment gateways, CRM systems, booking tools, email forms, chat widgets and tracking scripts. Some integrations rely on approved domains or specific URLs and may need reconfiguration.
Keep the old hosting available until you’ve confirmed that the new website is working correctly and the migration has been checked. The appropriate handover period depends on your setup and the services involved.
The work continues after launch. Monitor the website closely so you can catch technical problems before they affect more pages.
Check Google Search Console for indexing problems and unexpected crawl errors. Test your most important redirects and review server logs if they’re available.
Crawl the new website again. Look for 404 errors, redirect chains, broken links, missing canonical tags and pages that are accidentally blocked.
Compare analytics data with your pre-migration baseline, allowing for normal reporting delays.
Review organic clicks and impressions by landing page and search query. Look for pages that have lost traffic unexpectedly.
If a key page drops, inspect its new URL, redirect, content, canonical tag and indexing status. Compare its old and new versions before changing anything else.
Also check whether important pages are being indexed at their new URLs.
Continue tracking organic traffic, conversions, keyword visibility and indexing. Some migrations take longer to settle, particularly when many URLs or a large site structure have changed.
Use the results to fix remaining issues and improve pages that need attention. Keep the redirect map and migration records available for future audits.
Google’s official guidance on site moves and URL changes and hosting changes provides further technical instructions.
The timeline depends on the size of the website, the platform you’re using and the number of changes involved.
Migration stage | Typical planning estimate |
Small website with limited URL changes | A few days to 2 weeks |
Medium website with content and platform changes | 2 to 6 weeks |
Large website or complex ecommerce migration | Several weeks to several months |
These are broad project-planning estimates, not guaranteed delivery times. A website with thousands of URLs, custom integrations or multiple languages will need more preparation than a small brochure website.
Also, completing the technical migration and seeing search performance settle are two different milestones. Google needs time to crawl and process the new URLs.
Professional help is useful when the migration affects important search traffic or involves complex technical changes.
Consider bringing in an experienced developer and SEO specialist if you’re changing domains, moving a large website, migrating an ecommerce store or restructuring hundreds of URLs.
A specialist can audit the current site, prepare the redirect map, test the staging environment, check indexing settings and monitor performance after launch. This work helps reduce avoidable mistakes.
If you’re planning a redesign at the same time, review your existing website redesign services before deciding how to manage both projects. For a broader rebuild, your website design and development team can help assess the technical work involved.
A successful website migration starts with a clear plan. Document your existing URLs and SEO performance, test the new website before launch, map redirects carefully and verify that search engines can access the new pages.
After launch, keep checking redirects, indexing, traffic and conversions. Fix problems at the page level and give search engines time to process the changes.
If your business is planning a website migration or a major rebuild, Clear Solutions Technology can help you assess the work involved and plan the website changes around your SEO needs. Visit Clear Solutions Technology to discuss your project.
It can. Google may need time to recrawl and process changed URLs, and technical mistakes can cause ranking losses. Proper redirects, consistent content, working internal links and careful monitoring help reduce the risk.
Yes. A hosting migration can keep the public URLs unchanged. You’ll still need to test the new server, SSL certificate, DNS settings, website functionality and analytics configuration.
You need a relevant permanent redirect when a page has moved to a new URL and an appropriate replacement exists. Pages that have been intentionally removed without a suitable replacement may return a 404 or 410 status.
You can, but combining a redesign with a domain or platform migration increases the number of changes you need to test. Keep the content and URL structure stable where practical, then document any planned changes carefully.
Check whether important pages load correctly, redirects work, search engines can crawl the new website and analytics records visits and conversions. Monitor organic clicks, impressions and rankings over time rather than judging success from a single day’s results.
Submit the updated XML sitemap in Google Search Console after the new website is live and the sitemap contains the correct canonical URLs. Continue checking indexing reports for unexpected errors.