How to Move a Website Without Losing Traffic

A website migration is the only maintenance task that can destroy months of SEO work in an afternoon if done wrong. The three causes of traffic loss are the same every time: DNS cut over before propagation is ready, missing 301 redirects, and nobody watching what happens after the switch. This guide walks through each phase with the specific steps that prevent those failures.

Pre-migration checklist

Before you touch a single file, document the current state. Without a baseline you cannot tell whether the migration succeeded or caused damage. Record all of the following at least 48 hours before cutover.

• Current Search Console performance data for the last 30 days
• Current traffic figures from analytics
• Page speed scores (Core Web Vitals lab data)
• A full sitemap of every indexed URL from Search Console
• Email configuration, MX records and any active mailboxes
• Database credentials and current database size
• All active plugins, extensions and third-party integrations
• SSL certificate expiry date and provider
• DNS zone file export from the current registrar
• Server-side caching configuration and any CDN settings

If you are migrating a site built by someone else, also verify that you have cPanel or equivalent access, SFTP credentials and the database password. A surprising number of migrations stall because the client only has FTP access and no way to export the database.

Backup process

A complete backup includes three things: the file system, the database, and the email data if hosted on the same server. Store them in three separate places — a local download, a cloud storage bucket, and a different server. A backup that sits on the server you are about to decommission is not a backup.

In cPanel, use the Backup tool to generate a full home directory backup and a separate database export. Download both. If your site uses WordPress, also run a plugin-based backup as a second method — the database export from cPanel combined with a WordPress export file covers you if the database format is incompatible with the new server.

Verify the backup files are not corrupt by opening them on a different machine. This takes two minutes and catches a surprising number of failed backups before they matter.

Setting up on the new host

Get the new hosting environment running with your live site files before you change a single DNS record. This is called the staging or pre-staging phase, and it is the step that most DIY migrators skip.

Upload your files to the new server, import the database, and configure the environment to match the old server's PHP version, MySQL settings and PHP.ini values as closely as possible. Inconsistencies between environments cause the most common post-migration bugs: pages that load on the old server but white-screen on the new one because of PHP version differences.

Set up the SSL certificate on the new server before cutover. Many hosts provide auto-SSL through cPanel's AutoSSL feature, but verify it works before cutover because an invalid certificate on the new server will cause browser warnings that kill traffic instantly.

DNS cutover (TTL lowering)

DNS TTL (time to live) controls how long internet providers cache your server address. The default TTL is often 14,400 seconds (four hours) or 86,400 seconds (24 hours). If you change DNS with a high TTL, some visitors will hit the old server for up to 24 hours while others hit the new one — and if those visitors are search engine crawlers recrawling your site for indexing, you risk inconsistent page versions being cached.

Lower the TTL 72 hours before cutover. Change the TTL on your A, CNAME and MX records to 300 seconds (five minutes). This tells caching resolvers to check for updates every five minutes instead of every few hours. The 72-hour window ensures the low TTL propagates to most resolvers before you make the actual change.

At cutover time, point the A record to the new server IP address. The DNS change itself propagates within minutes because of the lowered TTL, though some older resolvers may still cache for longer. Wait at least 60 minutes for the change to stabilise before decommissioning the old server.

301 redirects

If your URL structure stays the same — same domain, same paths — a simple server-level redirect at the new host handles everything. Most migrations, however, involve some URL changes: a new CMS, a different permalink structure, or a site rebuild.

Build a complete redirect map spreadsheet with three columns: old URL, new URL, and redirect type. Every old URL must map to something — never 404. If a page genuinely no longer exists, map it to the nearest relevant category or the homepage, but use homepage redirects sparingly because they weaken the topical signal for the referring page.

Use 301 (permanent) redirects, never 302 (temporary). Search engines treat 301s as a permanent signal that the new URL replaces the old one, passing most of the link equity. A 302 says the move is temporary, and the old URL retains ranking authority. If your migration is permanent, the 301 is the only correct choice.

Implement the redirects in your .htaccess file (Apache) or the server config (Nginx). Test every row of your redirect map before launch using a browser with cleared cache. A redirect that works in theory often breaks in practice because of a trailing slash mismatch or a query string parameter you forgot.

Testing

Before changing DNS, test the new site as though you were a visitor. Work through this checklist on the new server only.

Run these tests on the new server while it is still behind a staging URL or hosts file override. Once you confirm everything works, you are ready for the DNS change.

Post-migration monitoring

The 48 hours after cutover are the most critical period. Watch these three data sources daily.

Search Console. Check for a sudden coverage drop in the Index report. If indexed URL counts plummet, search engine crawlers found errors on the new server. The most common post-migration issues in Search Console are server errors (5xx), soft 404s (pages returning a 200 but showing no content), and redirect errors. Address these within 24 hours or rankings will drop.

Analytics. Compare traffic day over day against the pre-migration baseline. A dip of 30 to 50 percent in the first 48 hours is normal while DNS propagates and crawlers adjust. If traffic has not recovered to 90 percent of baseline by day five, investigate. The likely cause is either a redirect issue or a page speed regression on the new server.

Server logs. Check for 404 errors in the server access logs or through a monitoring tool. Each 404 is a redirect you missed. Build a 404 report and add the missing redirects within hours of spotting them. The longer a 404 stays live, the less link equity survives.

If you host your site with us, we handle the full migration — backup, file transfer, database import, redirect setup, DNS coordination and 48-hour monitoring — at no charge. It is the most common way we win clients from other hosts, because a botched migration is expensive and we remove that risk completely.