How to move your site without losing rankings, email and orders

You have decided to change your agency, your hosting or your design. Everyone tells you it is simple: copy the files, change the DNS, done. Two weeks after the move you notice that you no longer receive emails from customers, that traffic from Google has dropped and that the contact form sends to an address that no longer exists.

None of these problems shows up on the day of the move. They appear gradually, usually after the old server has been shut down and there is nowhere left to recover what is missing. A site is not just a folder of files. It is a domain, a DNS zone, mailboxes, certificates, API keys to the courier and the invoicing tool, scheduled tasks and Google accounts tied to an email address you may not even control.

Below you will find what usually gets lost and why, what to inventory beforehand, how the move itself goes and what to check afterwards, plus the three-stage list you can use no matter who does the move.

Four kinds of move, four kinds of risk

It is worth knowing which situation you are in, because the risks differ.

• Changing hosting (same site, different server). The risks are technical: missing files, DNS, email, cron jobs, certificate.
• Changing agency (usually the hosting too). Add the access problem: accounts in the agency’s name, licenses, integrations they set up.
• Redesigning (same domain, different site). The main risk is SEO: addresses changed without redirects, deleted pages.
• Moving to another domain. All of the above, plus the change of address in Search Console and a period in which Google relearns the site.

What usually gets lost and why

Redirects

After a redesign, the page /services/tax-consulting/ becomes /consulting/. The old address had been in Google for three years and brought in customers. Without a 301 redirect to the new one, Google sees a 404 and, after a few weeks, drops the page from the index. The ranking does not transfer on its own.

Email

The most painful loss, because you do not see it. When the DNS moves to another administrator, the MX, SPF, DKIM and DMARC records are missing from the new zone. Customer emails stop arriving, and yours land in spam. If on top of that the mailboxes lived on the same server as the site, they stay there, with all their history, and disappear when the server is shut down.

Integrations

The API keys for the courier, payments, invoicing or the newsletter live in the old configuration. Some do not make it through the copy, others are tied to the old server’s IP and refuse connections from the new one. The store works, but it no longer generates shipping labels or invoices.

Cron jobs

Stock synchronization, backups, reports, deleting abandoned carts: all of these run from scheduled tasks on the server, not from the site’s files. On the new server they do not exist until someone recreates them.

The SSL certificate

The certificate is tied to the server. If the DNS was moved before the new server had its own certificate, visitors get the security warning exactly in the first hours after the move.

Uploaded files

The folder with images and documents is the largest and the one most often copied incompletely: the transfer is interrupted or the archive exceeds a limit. The site looks fine on the homepage and has missing images on the products on page 40.

Orders placed during the move

For a store, hours can pass between copying the database and the moment the DNS points to the new server. Orders placed in that window go to the old server and do not exist on the new one. The customer has paid, you do not have the order.

Forms and Google accounts

The contact form sends to the address the agency configured, sometimes one on the old server. After the move, the messages go nowhere. And Analytics and Search Console, created from the agency’s account, stay with them along with the traffic history.

The inventory before the move

You cannot move what you do not know exists. For each item, write down where it is, who has access and whose name the account is in.

• The domain: which registrar it is with, in whose name, when it expires.
• The DNS: who manages the zone, and a complete export of the records, including MX, SPF, DKIM, DMARC, subdomains, ownership verifications.
• The hosting: provider, PHP and database versions, what else runs there.
• Email: where the mailboxes live, how many there are, whether they are on the same server as the site.
• The SSL certificate: issued by whom, automatic or paid, when it expires.
• Integrations: courier, payments, invoicing, SMS, newsletter, CRM, with the account and keys for each, and whether they are restricted by IP.
• Theme and plugin licenses: whose account they are on, whether they are transferable.
• Google accounts: Analytics, Search Console, Business Profile, Ads, Tag Manager. Who is the owner, who is only an editor.
• Scheduled tasks: what runs from cron and how often.

Then export the list of indexed addresses: the pages report from Search Console plus all the addresses in the sitemap. You will use it after the move to check that nothing was left on a 404.

Make a complete backup and verify it: extract it somewhere else, count the files in the uploads folder, compare the number of orders in the database with what you see in the admin area.

How the move itself goes

The copy on the new server, tested on a temporary address

The site is copied to the new server and started there, without touching the DNS. You test it on a temporary subdomain or by editing the hosts file on your computer, so that the real domain points to the new server only for you. This is where you check everything: pages, images, form, cart, login, speed.

The DNS TTL lowered a day before

The TTL tells internet providers how long to remember the site’s IP address. If it is 24 hours, some visitors keep landing on the old server for another day. A day before, lower the TTL to 300 seconds. At the move, the change propagates in minutes.

The migration window

Pick a low-traffic period, but check in Analytics: a store can have its peak exactly on Sunday evening. During that window nobody changes anything on the site.

Orders, for stores

You have two options. The first: you “freeze” the store for the duration of the move, with a clear message at checkout, take the final copy of the database and only then change the DNS. The second, when you cannot afford the pause: you take the copy, change the DNS, then compare the orders on the two servers and bring over by hand the ones that came in between. The first is safer.

The old server stays on

Keep it running for a few days, ideally a week. It is the only place you can recover a missing file, a stray order or a forgotten mailbox from.

What to check after the move

The move is not finished when the site loads, but when you have ticked off everything that follows.

1. Redirects: take the list you exported before and check that every address responds with 200 or with a 301 to an equivalent page. There are tools that do this for a whole list.
2. The sitemap: resubmit it in Search Console. The change of address in Search Console is used only when you move to another domain.
3. Email: send from every important mailbox to an external account and receive one back. If the message you sent does not land in spam, SPF, DKIM and DMARC are correct.
4. Forms: fill in every form and confirm that the message reaches the right address.
5. Checkout: place a test order with a real, low-value payment. Check that it appears in the admin area, that the invoice and the shipping label are generated, that the confirmation email arrives.
6. Cron jobs: confirm they exist on the new server and have run at least once.
7. The certificate: no warning in the browser, including on subdomains.
8. Speed: compare with what you had before. A new server is not automatically faster if the cache from the old one is missing.
9. 48 hours of monitoring: the server’s error logs and the 404 report in Search Console. The addresses that show up there are the ones missed in the redirects.

If the site stays on an upkeep and updates plan after the move, part of the checks above becomes part of the monthly routine and no longer depends on someone’s memory.

Redesign: where rankings are lost most often

A redesign is not a technical move, but it is the most common cause of lost traffic from Google. The reason is almost always the same: the page addresses change along with the design, and nobody sets up the redirects.

The second cause is deleting pages “because they were ugly”. An old article can be exactly the page that brings the most visits from search. Before the redesign, look in Analytics at the pages with traffic from Google over the last year. Those are kept, rewritten or redirected to a page on the same topic. They are not deleted.

The rule for addresses: keep them unchanged if you can. If you cannot, redirect one to one: the old service page to the new service page, the old article to the new article. Redirecting all old addresses to the homepage is treated by Google as a disguised 404.

Who owns what, and what to ask for when leaving an agency

The domain, the hosting, the DNS and the Google accounts must be in your company’s name. The agency gets access, not ownership. The difference seems formal until the day the relationship breaks down and the domain expires on their account.

When you leave an agency, ask in writing for:

• A complete export of the site: files, database, uploaded files, in an archive you can open.
• Administrator access (not editor) to the site, hosting, domain, DNS.
• Transfer of ownership for Analytics, Search Console, Business Profile, Tag Manager and Ads to an account belonging to the company.
• The list of services and subscriptions paid in their name: licenses, CDN, email, monitoring, with the expiry date of each.
• Documentation of the integrations and the scheduled tasks: what connects to what, with which account, where the keys are kept.

If the agency wrote custom code that connects the store to the courier or the invoicing tool, ask for the code and a description of it. Without them, at the move the connection to each external service will have to be rebuilt from scratch.

Checklist

• Before: complete inventory (domain, DNS, hosting, email, certificate, integrations, licenses, Google accounts, cron jobs), with the owner of each.
• Before: everything in the agency’s name is transferred to the company.
• Before: export of the indexed addresses from Search Console and from the sitemap.
• Before: complete backup, extracted and verified somewhere else.
• Before: DNS TTL lowered to 300 seconds a day in advance.
• During: the copy on the new server tested on a temporary address, including the form and the cart.
• During: certificate issued on the new server before the DNS change.
• During: store frozen, or a plan for syncing the orders that came in between the copy and the move.
• During: the email records (MX, SPF, DKIM, DMARC) copied identically into the new DNS.
• After: address list checked, sitemap resubmitted, email, forms and checkout tested with a real order.
• After: cron jobs recreated, speed compared, 48 hours of monitoring on the logs and the 404 report.
• After: old server shut down only after a week without problems.