Website Migration Guide

Website Migration: The Complete Guide to Moving a Website Without Losing What You've Built

A website migration is not just moving files from one server to another. Done well, it preserves the work a business has already invested in—its pages, content, URLs, search visibility, images, brand, analytics, and customer pathways—while changing the technology underneath.

By Randa Vandenack Schilling · Founder of PeachSites and creator of Panderr · September 7, 2026

Businesses migrate websites for all kinds of reasons. A hosting relationship changes. A platform becomes too expensive or restrictive. An agency changes technology. A site becomes difficult to maintain. A company wants a redesign but does not want to throw away years of useful content.

The common misconception is that moving a website means starting over. It does not have to.

What is a website migration?

A website migration is a significant change to the environment, structure, URLs, platform, domain, design, or delivery of an existing website. Some migrations change only the hosting infrastructure. Others move a site to a different platform or provider. Some change the domain or URL structure. Others combine migration with a redesign.

The important distinction is that the website is more than the software currently hosting it. It includes the content people read, the URLs search engines know, the images customers recognize, the navigation people use, the metadata search engines interpret, and the links and history accumulated over time.

What needs to survive a migration?

A good migration begins with an inventory. Before changing anything, identify what the current website contains and what should be preserved.

• Pages and copy: service pages, articles, contact information, policies, landing pages, FAQs, and other useful content.
• URLs: the addresses already indexed by search engines, linked from other sites, bookmarked by customers, and used in marketing.
• Images and files: logos, photography, PDFs, downloads, video, icons, CSS, JavaScript, and other assets.
• Navigation and relationships: menus, internal links, parent/child page relationships, and calls to action.
• SEO metadata: page titles, meta descriptions, canonical URLs, structured data, robots directives, and social metadata.
• Measurement: analytics, conversion tracking, Search Console verification, advertising pixels, and other measurement tools.
• Functional pieces: forms, booking links, ecommerce, logins, integrations, downloads, and third-party services.

Start with a URL map

One of the most important migration documents is also one of the simplest: a list of old URLs and their intended destinations.

If a URL can remain the same, keeping it can reduce unnecessary change. If it must change, map the old address directly to the most relevant new address. Google recommends preparing an old-to-new URL mapping and using server-side permanent redirects for changed URLs. It also recommends avoiding large numbers of irrelevant redirects to the homepage.

Redirects are only one part of SEO migration

A 301 or 308 redirect tells browsers and search engines that a resource has permanently moved. But redirects alone do not make a migration complete.

The new pages should also use their new URLs consistently in internal links, canonicals, structured data, navigation, and the sitemap. Google specifically recommends that each new URL have a self-referencing canonical and that internal links be updated to point directly to the new URLs.

Canonicals: the invisible detail that can cause visible problems

A canonical tag tells search engines which URL you prefer as the representative version when duplicate or very similar URLs exist. During migration, stale canonicals can quietly point back to an old address—or to an incorrect generated address—even when the page itself looks perfect in a browser.

That is why visual QA is not enough. Inspect the actual HTML. Confirm that each indexable page's canonical matches its intended public URL, and make sure your sitemap, redirects, and internal links reinforce the same choice.

Update the sitemap and robots rules

The post-migration sitemap should contain the canonical URLs you actually want indexed. Old, redirected, duplicate, preview, administrative, or accidental URLs should not be treated as primary sitemap entries.

Also inspect robots.txt and page-level robots directives. Development sites are often blocked from crawling or temporarily marked noindex. Those protections are useful before launch and disastrous if accidentally carried into production.

Preserve your content—and its context

Copying text is not the same as preserving a page. Headings, supporting images, internal links, calls to action, related pages, metadata, and the page's role within the broader site all contribute to what that page does.

This is one reason migration can become labor-intensive when approached as a page-by-page copy-and-paste project. A migration system should understand the site as a connected structure, not a folder of unrelated documents.

Move the assets, not just the HTML

A migrated page can technically render while still depending on images, fonts, scripts, or files hosted by the old provider. Audit asset URLs and decide which resources need to be transferred, replaced, or intentionally kept external.

Pay special attention to logos, hero imagery, downloadable documents, background images, web fonts, icons, CSS resources, and files that receive direct search or referral traffic.

Test forms and integrations separately

Forms deserve their own migration checklist. A contact form can look completely normal and still fail to deliver a message. Test submissions from desktop and mobile, verify the destination inbox, and confirm success/error states.

Do the same for booking systems, payment links, ecommerce, customer portals, analytics events, embedded maps, chat tools, CRM integrations, and any workflow that depends on a third party.

Preserve analytics and Search Console visibility

Before launch, document the measurement tools on the existing site. After launch, confirm that analytics are firing on the new pages and that Search Console verification still works.

For URL-changing migrations, monitor old and new URLs as search engines recrawl them. Google notes that ranking fluctuations can occur during significant moves while its systems process the changes. A submitted sitemap can help discovery, but migration processing still happens URL by URL.

DNS and launch: change the infrastructure carefully

The final switch may involve DNS records, nameservers, SSL/TLS certificates, hosting configuration, or a domain change. Prepare those changes before launch and keep the old environment available long enough to verify the transition when possible.

If URLs change, keep permanent redirects in place for the long term. Google's current guidance recommends keeping redirects for at least a year, and from a user-experience perspective it can make sense to keep useful redirects indefinitely.

Preserve, improve, or redesign?

Migration and redesign are different decisions. At Panderr, we think about migration in three paths:

1. Preserve: keep the existing website as faithful as possible and change primarily the environment underneath it.
2. Improve: retain the site's identity and useful content while fixing weaknesses in layout, usability, responsiveness, structure, or presentation.
3. Redesign: use the existing website's content, brand, and business information as source material for a larger visual and structural change.

Separating these decisions matters. A business should not be forced into a redesign simply because it needs to leave a provider, and it should not have to abandon valuable content simply because it wants a new design.

A practical website migration checklist

1. Crawl or inventory the existing site.
2. Record important URLs, metadata, assets, forms, integrations, analytics, and Search Console configuration.
3. Decide whether each page will be preserved, improved, redesigned, consolidated, or removed.
4. Create an old-to-new URL map.
5. Build and test the new site before cutover.
6. Transfer required images, files, scripts, and other assets.
7. Update internal links to the final URLs.
8. Set correct self-referencing canonical URLs.
9. Implement direct permanent redirects where URLs change.
10. Generate a sitemap containing the intended canonical URLs.
11. Check robots.txt and remove accidental production noindex directives.
12. Test forms, navigation, mobile layouts, downloads, and integrations.
13. Verify analytics and Search Console.
14. Complete the DNS/domain cutover and verify HTTPS.
15. Crawl the live site again and monitor indexing, errors, traffic, and conversions.

What a successful migration actually looks like

A successful migration is not merely a site that loads at a new host. It is a site where customers can still find what they need, search engines receive consistent signals, important links still work, forms still reach the business, analytics still measure activity, and the company's accumulated digital work has not been unnecessarily discarded.

That is the larger idea behind Panderr: your website should be portable. Changing technology should create options, not force you to erase what you have already built.

Technical reference: This guide follows current Google Search Central guidance for site moves and canonicalization, including URL mapping, permanent redirects, self-referencing canonicals, updated internal links, sitemaps, Search Console monitoring, and long-lived redirects.