How to transfer a website to a new host without losing pages or SEO

Transferring a website to a new host is not just a DNS change. A safe move preserves the pages people visit, the assets those pages need, the metadata search engines read, and the services that sit around the site.

The most reliable order is simple: inventory the current site, create a portable copy, test the new destination, reconnect external services, and only then move traffic. That gives you a reviewable handoff and a clear rollback point.

The short website transfer checklist

1. Record the current URLs, redirects, forms, analytics, and important integrations.
2. Export the published website into files you can inspect and keep.
3. Test the copy on a preview URL before changing DNS.
4. Configure the new host, domain, redirects, forms, and analytics.
5. Compare important pages on desktop and mobile.
6. Change traffic only after the new destination passes review.
7. Keep the old host available until the move is proven.

This sequence separates a content transfer from a live cutover. If a page or integration needs work, you find out before visitors do.

What to inventory before moving a website

Start with the public site, not just the builder project or hosting login. Make a list of:

• every indexed or campaign URL;
• page titles, descriptions, canonical URLs, and social images;
• images, fonts, downloads, video, and embedded content;
• forms, bookings, payments, newsletters, analytics, chat, and consent tools;
• redirects, 404 behavior, sitemap, and robots rules;
• the domain owner, hosting owner, and person approving the handoff; and
• the date of the last approved version.

Search Console and analytics are useful here because a page that is absent from the main navigation may still be valuable. Record high-value URLs before deciding what can be removed.

Create a portable copy before the handoff

If the site lives in a visual builder, export the published version into portable static files before you change the host. A static copy gives you something concrete to review, archive, deploy, or give to the next operator.

ToStatic verifies that you are authorized to work with a source site, then turns the public site into static output that can be previewed and downloaded. That makes the export useful as a migration package or a dated recovery point. It does not replace a review of forms, commerce, memberships, or other services that run outside the page.

For a large site, start with the homepage, one representative content page, a lead-capture page, and the highest-value search pages. Expand the scope after those pages pass review.

Test the new host before changing DNS

Use a preview URL or temporary destination to compare the old and new versions. Check the following in order.

Pages and links

• important pages load at the intended paths;
• navigation, footer links, downloads, and internal links work;
• images, fonts, video, and embeds load correctly;
• mobile layouts and menus behave as expected; and
• missing pages return the intended 404 or redirect.

SEO signals

• titles and descriptions match the page intent;
• canonical URLs use the final domain;
• the sitemap contains the intended canonical pages;
• robots behavior is intentional; and
• old paths redirect to the right new paths.

Do not treat a page that looks correct in a screenshot as a finished migration. A screenshot cannot prove that links, metadata, redirects, or forms work.

External services

Static files can preserve the page and its embed code, but they do not automatically recreate a third-party service. Submit a test form, check analytics, verify cookie consent, test booking or payment paths, and confirm any script that depends on the old domain.

If one of these is not ready, keep the current host live and document the remaining work.

Choose the right handoff package

A useful handoff contains more than a ZIP file. Give the next owner:

• the reviewed static export and export date;
• the URL inventory and redirect list;
• the dependency list for forms, analytics, embeds, and other external tools;
• the target host and domain steps;
• known limitations or pages that still need manual work; and
• the person responsible for approving the final cutover.

This is especially important when a client, agency, or contractor is taking ownership. The goal is not merely to move files; it is to make the next person confident about what they received and what they still need to configure.

Cut over traffic with a rollback plan

When the preview is approved, prepare the new host and change DNS or the relevant domain setting. Keep the old site available during propagation and monitor the highest-value pages first.

After the change, check:

• the homepage and top landing pages;
• forms, bookings, payments, and analytics;
• redirects and 404s;
• sitemap and robots URLs; and
• Search Console coverage and traffic trends.

Keep the original site until the new destination has stayed healthy through the agreed review window. If a critical page or service fails, the rollback should be a documented decision—not a hurried search for an old login.

Common website transfer mistakes

Moving the domain before reviewing the copy

This turns a content issue into an outage risk. Test the destination first.

Forgetting low-visibility URLs

Campaign pages, old landing pages, and client-specific paths may still receive traffic. Use analytics and Search Console before pruning them.

Confusing export with a complete platform migration

Exported HTML can preserve the public presentation, but dynamic services need separate testing or replacement.

Treating ownership as an afterthought

Record who owns the domain, export, hosting account, analytics property, and connected services. A handoff is incomplete if the next owner cannot access the pieces needed to operate the site.

FAQ

Can I transfer a website without rebuilding it?

Often, yes. Exporting the published site into portable static files can avoid rebuilding the public layout. Forms, embeds, analytics, and other external services still need review.

Is moving a website to HTML the same as moving hosts?

No. Exporting to HTML creates the portable files. Moving hosts adds destination setup, domain configuration, redirects, testing, and the final traffic change.

How long should I keep the old host?

Keep it until the new destination passes the page, SEO, integration, and mobile checks and the agreed monitoring window has ended.

What is the safest first step?

Create a URL and dependency inventory, then capture the last approved public version before changing the source or domain.

Final takeaway

Treat a website transfer as a controlled handoff. Preserve the URLs people already use, export a copy you can inspect, test the services around the pages, and change traffic only after approval. A portable static export gives you a practical recovery point while you move hosting with less risk.

For the builder-specific path, read the Framer migration checklist. For a broader backup workflow, see how to keep a portable website copy.

If you are ready to create a portable copy of a site you own, start with ToStatic and review the result before moving the domain.