Moving a website to a new host does not have to change its public URLs. If you keep the same domain and paths, the main job is to move the site safely, point DNS at the new server, and confirm that visitors and search crawlers can still reach it. A careful process reduces avoidable downtime, but no host migration can guarantee that search traffic will never fluctuate.
This checklist is for a small website moving between hosting providers while keeping its domain and URLs. If you are also changing the domain, URL structure, or content platform, treat that as a separate migration and plan redirects as well. For background on the relationship between hosting, uptime, speed, and HTTPS, see our guide to how web hosting affects SEO.
1. Inventory the site before changing anything
Write down what the current host runs and what the new host needs to provide:
- The site's files, database, runtime version, and required extensions.
- Scheduled jobs, uploads, forms, checkout, login, APIs, and other features that depend on the server.
- Environment variables, secrets, firewall rules, and integrations. Record where each value belongs, but do not put credentials in a shared checklist.
- The production hostnames, such as
example.comandwww.example.com, and the DNS records that serve them. - Any mail services that use your domain, including the provider responsible for sending and receiving messages.
Keep the move focused. Avoid changing the domain, redesigning the site, and switching hosting at the same time; separating changes makes faults easier to trace.
2. Make a recoverable backup
Back up the site's files and database before copying or changing the live site. Keep a copy somewhere separate from both hosting accounts, and make sure you can access the credentials and tools needed to restore it. A backup that has never been restored is not a tested recovery plan.
For WordPress, the official migration guide calls out backing up the WordPress directory and database before moving to another server. Include uploads, plugins, themes, configuration, and any host-specific files your installation depends on. If your site changes frequently, plan how to capture new content and orders made after the initial copy.
3. Prepare and test the new host
Copy the site and restore its database on the new host without sending public traffic there yet. Use a protected staging environment or another safe testing method. A temporary public hostname can be useful, but prevent it from being indexed and remove any temporary access restrictions before launch. Google's hosting-change guidance recommends testing the new infrastructure before changing DNS.
Check the parts of the site a visitor or administrator relies on: pages, images and downloads, forms, sign-in, checkout, scheduled jobs, and any important integrations. Confirm that the site's runtime and database settings match its requirements. For WordPress, verify the site address, database connection, and permalink behavior; do not make manual database replacements unless you understand what they change.
Set up HTTPS for every production hostname on the new host. If the provider manages certificates, confirm that issuance and renewal are enabled. If you manage certificates yourself, make sure the new setup can complete its domain-validation method; Let's Encrypt's challenge documentation describes the available approaches. Our WordPress HTTPS guide covers the WordPress-specific side of enabling HTTPS.
Before cutover, check the staging copy for accidental noindex directives or crawl blocks that should not be present on the live site. Keep staging protected; do not rely on a robots.txt rule to keep private data secure.
4. Preserve DNS and email settings
Export or record the current DNS zone before editing it. If you are moving only the website, change only the website-facing records your new host specifies. An A or AAAA record points a hostname to an IP address, while a CNAME points it to another hostname; check the new host's instructions rather than guessing at record values.
If you are changing DNS providers or nameservers, recreate the full zone before switching nameservers. Do not assume that a website migration also moves your email service. Preserve the existing MX records for mail delivery, along with email-related TXT or CNAME records used for SPF, DKIM, DMARC, domain verification, and other services. The exact records depend on your email provider. Our guide to SPF, DKIM, and DMARC for transactional email explains those email-authentication records.
DNS records are cached according to their time to live (TTL), so a change may not reach every resolver at once. If your DNS provider allows it, Google's hosting-change guide suggests lowering the website records' TTL well before the move; it gives a few hours as an example and recommends doing this at least a week ahead. Restore a suitable TTL after the migration is stable. Changing TTL does not make every cache update immediately, so keep the old host available during the transition.
5. Cut over with a rollback plan
Choose a lower-traffic time if that suits your audience, and decide in advance what would make you pause or roll back. For a site that accepts orders, publishes content, or stores user submissions, plan a short write freeze or a final data sync so that activity is not left behind on the old server.
When the new copy is ready:
- Take a final backup or sync any data that changed since the first copy.
- Remove temporary staging-only crawl blocks from the production copy.
- Update only the required website DNS records using the values supplied by the new host. Leave mail records and unrelated services alone.
- Check the site over HTTPS on both the root domain and any
wwwhostname you use. Confirm that each resolves to the intended setup. - Keep the old host running and avoid deleting files or databases while DNS caches may still direct visitors there.
If the new host serves errors or critical features fail, use your rollback plan: restore the previous website DNS values and investigate before trying again. DNS changes can take time to reach different resolvers, so switching records back does not guarantee that every visitor immediately returns to the old server.
6. Validate the live site and monitor it
Test the production URLs, not only the staging copy. Check a representative set of important pages, images, forms, downloads, sign-in or checkout flows, and any API or scheduled task that matters to your users. Look for server errors, missing assets, broken internal links, mixed-content warnings, incorrect canonical URLs, and unexpected redirects. Confirm that your sitemap is available and that the live site is not still blocked from indexing.
Check server logs on both hosts as traffic shifts. Compare error logs and normal site traffic, and use Search Console to monitor crawling and indexing. Google's guidance notes that crawl activity can fluctuate during a hosting change; investigate persistent errors or slow responses rather than treating every short-term change as proof of a failed move.
Do not cancel the old hosting account immediately after changing DNS. Google recommends monitoring both servers and shutting down the old infrastructure only when you are confident users and Googlebot are receiving the site correctly from the new host. This also gives you time to catch mail or other services that were overlooked.
If your URLs are changing too
A domain or path change is more than a hosting move. Create a mapping from each old URL to its most relevant new destination, use direct permanent server-side redirects such as 301 or 308 where possible, and update internal links, canonical URLs, and the sitemap. Do not redirect every old page to the home page.
Google's site-move guide for URL changes recommends keeping redirects for as long as possible, generally at least a year. Submit a Change of Address in Search Console when moving to a different domain or subdomain; it is not needed for a hosting change that keeps the same URLs. Search visibility can fluctuate temporarily while Google processes changed URLs, so monitor both properties and allow time for recrawling.
A short pre-launch checklist
- A separate backup exists, and the restore path is understood.
- The new copy passes staging checks for pages, media, forms, accounts, and other critical features.
- Production HTTPS is ready, and temporary staging protections are understood.
- The DNS zone is recorded; email and other non-website records will be preserved.
- The DNS cutover and rollback values are written down.
- Live URLs, logs, analytics, and Search Console will be checked after the switch.
- The old host will stay available until traffic and errors have been reviewed.