Configuring your domain for a new build without losing rankings is mostly about continuity: keep the same domain and the same URLs, and the search engines see no disruption to manage. The mechanics are to deploy and fully test the new site on a staging URL first, then update DNS to point the domain at the new host, using a low TTL set in advance so the cutover is fast and uniform. Keep the old host live during propagation and make sure HTTPS is in place, now effectively universal: the 2024 Web Almanac reports the overwhelming majority of pages are served over HTTPS, so a missing or misconfigured certificate at cutover stands out as a problem. WPBuildAI handles the domain cutover and the redirect map so the switch is invisible to Google.
Cover the variants, not just the domain you use: Google’s June 2026 site move guidance asks for Change of Address requests across all subdomains and both the www and non-www forms of the old domain, even the ones you thought were dormant.
Why a host move is SEO-safe
The reassuring fact underneath all of this is that search engines key on URLs and content, not on which server answers the request. When you move your domain to a new host but keep the URLs identical, Google sees the same pages at the same addresses; there is nothing for it to re-evaluate or re-index, because from its perspective nothing changed except an IP address it does not care about. Ahrefs found in its search traffic study that a small set of pages carries most traffic, and as long as those URLs keep resolving to the same content, their rankings hold through the host change. This continuity principle matches Google’s site move guidance, where preserving URLs is exactly what makes a move clean. So a pure host move, same domain, same URLs, is among the lowest-risk changes you can make to a site’s infrastructure, provided the cutover itself is handled cleanly.
What DNS actually does here
It helps to understand what you are changing, because it demystifies the risk. Your domain name points, via DNS records, at the server that hosts your site. Moving to a new host means updating those DNS records (typically the A record or a CNAME) to point at the new server instead of the old one. The domain itself does not change, your registrar, your domain name, your email records can all stay as they are; you are only redirecting where the domain resolves. This is why a host move does not touch SEO: the public identity of the site, the domain and its URLs, is unchanged, and only the underlying pointer moves. Knowing that you are editing a pointer, not the site, frames the whole task: the work is making that pointer flip cleanly and quickly, which is what TTL and the staging test are for.
The cutover, step by step
A clean cutover follows a specific order:
- Lower the DNS TTL to a few minutes, a day or more before the switch, so the change will propagate fast.
- Deploy and fully test the new site on a staging URL, including HTTPS, confirming everything works before any traffic hits it.
- Point DNS at the new host by updating the records.
- Keep the old host live until propagation completes, so any visitor still resolving to the old server gets a working site, not a gap.
Done in this order, there is no window where visitors hit a broken or missing site. This is the domain half of keeping your domain and email when moving off WordPress, and it overlaps with the host-move mechanics in moving an AI-built site to Vercel or Railway.
Why TTL matters
TTL, time to live, is the single most useful lever for a clean cutover, and it is worth understanding. TTL is how long DNS resolvers around the world cache your records before checking again. If your TTL is, say, 24 hours, then after you change the record some resolvers will keep using the old value for up to a day, so the switch propagates slowly and unevenly, with some visitors hitting the old host and some the new for an extended window. If you lower the TTL to a few minutes a day or two before the switch (so the low value itself has time to propagate first), then when you flip the record, resolvers pick up the change within minutes, making the cutover fast and uniform. This is why lowering TTL in advance is step one: it shrinks the propagation window from hours or days to minutes, which is the difference between a tense, drawn-out switch and a clean flip. After the cutover settles, you can raise the TTL again.
A worked example: a clean cutover
Picture moving a site to a new host. Two days before, you lower the domain’s DNS TTL from 24 hours to 5 minutes, and let that low value propagate. You deploy the new site to the new host and test it thoroughly on a temporary URL, confirming pages render, HTTPS works, and the redirect map (for any changed URLs) resolves. On cutover day, you update the DNS A record to the new host. Because the TTL is 5 minutes, within minutes resolvers worldwide point at the new host, and visitors land on the new site. You keep the old host running for a day just in case any straggler resolver is slow, so no one hits a gap. Once traffic has fully moved and the site is confirmed healthy, you raise the TTL back. From Google’s perspective, the same URLs kept serving the same content throughout, so rankings never wavered. The whole move was a few minutes of real cutover, planned around the TTL.
HTTPS and the certificate
One detail that trips up otherwise-clean cutovers is the HTTPS certificate, so handle it as part of the move. Nearly all sites are served over HTTPS, and the 2024 Web Almanac reflects how universal that has become, which means a site that suddenly serves a missing, expired, or mismatched certificate at cutover looks broken and untrusted to visitors and crawlers. So before pointing the domain, ensure the new host has a valid certificate for your domain in place and tested, many hosts provision one automatically, but confirm it covers the exact domain and any subdomains you use. The goal is that the moment the domain resolves to the new host, HTTPS works seamlessly, with no certificate warning. This is part of the staging test: load the new site over HTTPS on its temporary URL and confirm the certificate is valid, so the cutover does not introduce a security warning that undoes the seamlessness you planned for.
If URLs change too
The domain configuration keeps the site reachable at the same domain; it does not handle URLs that change in the rebuild, which is a separate job. If the new build changes any URLs, even though the domain is the same, each changed URL needs a 301 to its new address, per Google’s redirects guidance, as set up in 301 redirects for a move. Keep the two concerns distinct: the domain cutover (DNS) makes the site resolve to the new host, and the redirect map (301s) preserves the rankings of any URL that moved. A pure host move with identical URLs needs only the first; a rebuild that also restructures URLs needs both. The two together are the full move in converting to an AI website. Keeping them separate in your mind prevents the common confusion of thinking a clean DNS cutover alone protects rankings when URLs also changed.
Common mistakes in a domain cutover
The recurring errors all create the downtime or breakage that a host move otherwise avoids. Pointing the domain before deploying and testing the new host means visitors hit an unready or broken site. Not lowering the TTL in advance stretches the propagation window so the switch drags and is uneven. Tearing down the old host immediately, before propagation completes, leaves slow-resolving visitors with a gap. Forgetting the HTTPS certificate serves a security warning the moment the domain flips. And assuming a clean DNS cutover protects rankings even when URLs changed skips the redirect map. Each is avoided by the planned sequence: lower TTL first, deploy and test on staging including HTTPS, then flip DNS while keeping the old host live, and 301 any changed URLs separately, which turns the cutover into a seamless, zero-downtime, rankings-safe switch.
Key points to remember
Point your domain to a new build without losing rankings by keeping the same domain and URLs, so search engines see continuity and have nothing to re-evaluate, you are only changing where DNS points, not the site’s public identity. Lower the DNS TTL to a few minutes a day before the switch for a fast, uniform cutover, deploy and fully test the new site on staging including a valid HTTPS certificate, then flip DNS and keep the old host live until propagation completes so no visitor hits a gap. A pure host move with identical URLs carries essentially no SEO risk; if any URLs change in the rebuild, 301 each separately. WPBuildAI handles the domain cutover and the redirect map together, so the switch is invisible to Google; send your site URL for a fixed quote.
Not affiliated with Google, WordPress, or Lovable.