How to Move a Website Without Losing SEO Rankings

You move a website without losing SEO rankings by keeping the same URLs, serving the same content, and making the cutover atomic. The search engines do not care which host you use, they care that the response to a given URL does not change in a way that looks like a 404, a redirect to a different page, or a sudden slowdown. The practical work is a checklist of DNS, HTTP, and server configuration steps, and you can do all of it from a terminal.

Why the move website without losing seo checklist starts with DNS

Your domain name is the only stable identifier the search engines have. If you change the IP address that the domain resolves to, you are not changing the URL, so the ranking signals stay attached to that domain. The risk is that a DNS change propagates slowly, and during that window some visitors and crawlers hit the old server while others hit the new one. That split is fine as long as both servers serve identical content for identical URLs. The moment one server returns a different page, a 404, or a redirect, you create a consistency problem that can look like a site change to a crawler.

Before you touch DNS, make sure the new server is fully configured and tested. Point a test hostname at the new IP, for example staging.yourdomain.com, and run a full crawl against it. Check that every URL returns the same status code and the same canonical tag as the old server. You can do this with a simple loop in bash that compares the HTTP status and the Location header for a list of URLs. Save that list from your old server logs or from a crawl tool, then run this:

while read url; do
  old_code=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  new_code=$(curl -s -o /dev/null -w "%{http_code}" --resolve yourdomain.com:443:NEW_IP "$url")
  echo "$url old=$old_code new=$new_code"
done < urls.txt

Look for any line where the two codes differ. A common mistake is that the new server redirects http to https while the old one did not, or vice versa. That is a change in the redirect chain, and it can cause a temporary loss of the accumulated link equity. You want the new server to reproduce the exact same redirect behavior, including the same target URL and the same redirect status code, either 301 or 302.

Set the HTTP headers that tell crawlers nothing changed

The most important header is Canonical, which you should already have on every page. If you do not have it, add it now, before the move. The canonical tag tells the search engine which URL is the authoritative version, and if it points to the same URL on the new server, you are telling the crawler that the page identity is unchanged. You also need to check the Server header, because some hosting stacks add a version string that can change, but that is harmless. What matters is the Content-Type header, the Content-Length, and the Last-Modified date. If you copy files with rsync and preserve timestamps, the Last-Modified header will match, which helps with conditional requests and reduces the chance of a re-crawl.

You should also verify that the new server sends the same Cache-Control headers for static assets. If the old server cached images and CSS for a week and the new one sends no cache headers, the first crawl after the move will be slower, and a slow crawl can reduce the crawl rate. Set the same cache policy on the new server before you switch DNS. A typical nginx snippet for static files looks like this:

location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg)$ {
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
}

Do not forget the X-Robots-Tag header. If you have any page that should not be indexed, the new server must send the same noindex directive. A missing noindex on a staging page that accidentally goes live can cause the search engine to index a duplicate, and that is a ranking loss you will have to fix later.

Switch DNS with a low TTL and keep the old server running

Before the move, lower the TTL on your DNS records to something like 300 seconds. That is not a magic number, it is just a value that gives you a short propagation window. Do this at least 24 hours before the cutover, so the old TTL has expired everywhere. Then, when you are ready, change the A record and the AAAA record to point to the new IP. Do not delete the old server. Keep it running for at least a week, because some crawlers and some users will still hit the old IP from cached DNS. If the old server is gone, those requests get a connection refused, which is worse than a slow response.

You can also set up a redirect on the old server that sends all traffic to the new IP, but only if the old server is on a different IP. If you are moving to a new host, the old server can issue a 301 to the same URL on the new IP. That is a temporary measure, and you should remove it after a week. The goal is to avoid any period where a crawler sees a connection error or a timeout.

Verify the move with server logs and a crawl

After the DNS change, watch the access logs on the new server. You want to see requests from the search engine crawlers, and you want to see the same URL patterns that the old server received. If you see a spike in 404s, you have a broken link or a missing rewrite rule. The most common cause is that the new server does not have the same .htaccess or nginx rewrite rules that the old server had. Copy those rules exactly, including any that handle trailing slashes, query strings, or case sensitivity.

Run a final crawl from a machine outside your network, using a tool that follows redirects and reports status codes. Compare the list of URLs from the old crawl to the new crawl. The set of URLs should be identical, and the status codes should match. If you have a page that used to return 200 and now returns 301, you have a problem. If you have a page that used to return 301 to /new-path and now returns 301 to /old-path, you have a problem. Fix those before you consider the move complete.

What to do next

After the DNS has propagated and you have verified the logs for a few days, you can shut down the old server. But before you do, export your old server logs and keep them for reference. You will need them if you ever want to compare crawl patterns or investigate a sudden drop in rankings. Also, update your sitemap and resubmit it in the search console, but do not change the URLs in the sitemap, they should be the same as before. The move is done when the new server has served traffic for a full week without a single 404 that the old server would not have returned. That is the only metric that matters.