When you change web hosts and your URLs stay the same, the move plan decides the SEO risk, not the addresses themselves. Google's documentation on changing your web hosting gives the order: prepare and test the new infrastructure, lower the DNS TTL at least a week before the move, make sure Search Console verification works on the new copy, remove any temporary blocks, update the DNS records, and keep the old host running until its traffic reaches zero.
This guide is for site owners, developers and agency staff. It starts with the weeks before the move, then covers how to check the copy before it goes live, what to do on cutover day, what to watch for three days afterward and how to decide when the old server can go.
Before the Move: TTL, Timing and the Old Host
The calm week before cutover is where most of the risk is removed. Treat it as its own project phase, with an owner and a date.
What "no URL changes" means
The Google guide to changing your web hosting (Opens in a new tab) covers moves where user-visible URLs do not change, for example switching hosting providers or moving to a CDN. Because addresses stay the same, there is no old-to-new address mapping to build. The job is to make sure crawlers and visitors reach the same content after DNS points elsewhere. If the domain, protocol or path structure changes too, you are in a different kind of move; for that case read our piece on preserving backlink value during a site migration.
Why TTL comes first
TTL (time to live) tells DNS caches how long they may keep a record. Google's guide says DNS settings are usually cached by internet service providers according to the TTL you specify. If the TTL is long and you change the record on cutover day, some visitors and crawlers keep reaching the old server for a while. A lower TTL lets the new record spread faster. The guide recommends lowering the TTL to a conservative low value, "for example, a few hours", and doing it at least a week in advance of the move. The reasoning is simple: the old, higher TTL must expire in caches before the lower value takes effect, so lowering it on the day of the move defeats the purpose.
Write down the old value
Record the current TTL before changing it. That number is the upper bound on how long old caches can hold the old record. If it was a day, do not assume the new low value applies everywhere until at least that much time has passed. Raising the TTL again after the move is part of the plan too, because permanently low values mean more DNS lookups.
Keep the old host alive
The guide says that once traffic to the old provider reaches zero, you can shut down the old hosting infrastructure. So tie the old contract's end date to your move calendar. If the contract expires soon, ask for an extension or a short add-on period before you start. Otherwise visitors still served from DNS caches will land on an address that no longer answers.
Inventory what must move
Files and the database are the obvious part. Also list rewrite rules, redirects, custom error pages, scheduled jobs, server-level headers, email settings and third-party callbacks. These items often arrive on the new host with default values and quietly behave differently. Lay the old and new configuration files side by side and compare them line by line.
| Preparation item | Why it matters | When |
|---|---|---|
| Lower TTL to a conservative value | New record spreads quickly at cutover | At least a week before |
| Record the previous TTL | Sets the wait and the rollback math | Before lowering |
| Extend the old hosting contract | Keeps the old host up until traffic is zero | During planning |
| Compare server configuration | Finds rewrite, header and redirect differences | During testing |
| Confirm Search Console verification method | Keeps access to reports after the move | Before cutover |
Example scenario: a publisher moving a blog to a managed WordPress host
Example scenario: a small publisher is moving its blog from a general hosting plan to a managed WordPress provider that also offers a CDN. The editor lowers the TTL a week and a day before the date, notes the old value, and extends the old plan by a month. The new host is tested through a local hosts-file override, so neither readers nor crawlers see it yet. The editor also lists every subdomain: the newsletter sign-up page lives elsewhere and must not change. This sequence shows that preparation is a separate piece of work from cutover.
Speed is often the reason for moving, but a faster host is an expectation to be measured, not assumed. For response time and caching, see our TTFB, caching and CDN guide.
Verifying the Copy Before Anyone Sees It
With the site running on the new host, three areas need checking before it goes public: indexing directives, crawler access and the secure connection. Google's guide opens this stage with "create a testing environment".
A restricted test environment
The guide suggests a testing environment on the new infrastructure with access restricted by IP address. If you need public testing, use a temporary hostname and, per the guide, add the noindex robots rule to the HTML or the HTTP headers of your pages. If a test copy does leak into search, our article on diagnosing pages not indexed by Google helps you read the situation from the other side.
Removing temporary blocks at the right time
The same guide reminds you to remove such blocks, meaning robots.txt disallow rules and noindex tags, from the new copy when you are ready to start the move. A block left in place on cutover day makes the live site disappear from search. Put this step at the top of your cutover checklist and make the removal part of an environment setting, not a manual edit.
Can Googlebot reach the new host?
The guide asks for two checks. First, use the URL Inspection tool to confirm that Googlebot can access the new infrastructure. Second, make sure your firewall and DoS protection settings do not block Googlebot's ability to reach the DNS or the hosting provider's servers. New providers often ship aggressive default protection, which can block crawlers by accident. Compare the rule list on both hosts.
Certificate and canonical hostnames
Install the certificate before cutover so visitors never see a security warning, and confirm it covers every hostname variant. Re-test the redirect chain between www, non-www, http and https, plus trailing-slash behavior. Our guide on www, non-www, HTTPS and trailing slash standardization explains the rules to compare.
Keep Search Console access intact
If you verified with an HTML file, the guide says to include your current verification file in the new copy. If you verified through a meta tag or Google Analytics, make sure the new CMS copy includes them. Losing verification during the move leaves you blind exactly when reports matter most.
Parity checklist
- Do the home page, one category, one article and one product page return the same content and headings on both hosts?
- Do status codes match (200, 301, 404)? See the HTTP status codes guide for what each means.
- Do robots.txt and the sitemap point to the live hostname?
- Are temporary noindex and disallow rules marked for removal on cutover day?
- Does the certificate cover every hostname variant?
- Do the firewall and DoS settings leave Googlebot alone?
- Does the Search Console verification method work on the new copy?
- Were email, forms and checkout tested on the new host?
Spotting quiet differences
The same code can behave differently on two servers. Server software version, runtime version, file permissions and character encoding can all differ, so pages look identical while headers do not. A short script that requests the same URL list from both hosts and compares status codes and headers is more reliable than clicking around. Include at least your most visited and most linked pages in the list.
Cutover Day, Step by Step
On cutover day you should not be making new decisions. Everything was settled in the earlier phases, and this phase executes it.
Choosing the window
Schedule the switch for a low-traffic period when the team can monitor. Google's guide does not recommend a particular day or hour, so use your own traffic data to find your quiet window. Avoid changing anything else that day: no redesign, no plugin updates, no campaign launch. When many things change at once, a problem cannot be traced to its cause.
The sequence
- Confirm the lowered TTL has been in effect for longer than a week.
- Remove temporary noindex tags and robots.txt disallow rules from the new copy.
- Run a final data sync for anything written to the old host since testing: orders, forms, comments.
- Update the DNS records to point to the new hosting provider, which is the step the guide names.
- Check propagation from several locations with public DNS tools.
- Open the home page, a category, an article and a product page on the live hostname and check status codes and headers.
- Run the live URL test in the URL Inspection tool.
- Start watching the access logs on both hosts.
DNS records beyond the web address
Changing where the website points should not touch email, but some DNS dashboards rebuild a zone wholesale, and MX, SPF or DKIM records can disappear. Export the full zone before the change and compare afterward. List every subdomain (blog, shop, support, API) and note whether each runs on the same server or on a separate service. If you are also moving DNS hosting, you are changing two layers; change one at a time so a failure points to a single cause.
When a CDN or security layer joins the move
Google's guide includes moving to a CDN within its scope. If you add one, purge its cache after the switch so stale content is not served, and retest its bot rules after every rule change. The guide's concern about Googlebot reaching DNS and servers applies equally to every extra layer in front of the site.
Handling data written during propagation
Because DNS propagation is not instant, both servers can receive traffic for a while. On sites with orders, sign-ups or forms, data can split across two databases. Decide in advance whether you will use a short maintenance window, make the old host read-only, or point both at one database. Google's guide gives no advice here because write patterns depend on the site. Write the chosen approach down.
A rollback rule
If the live hostname errors in the first hours after the DNS change, switching the record back to the old host is safer than debugging in place, because the old host is still running. The rollback is fast only thanks to the lowered TTL, which is the second benefit of preparing it early. If the problem is small and quick to fix, fix it on the new host; if many core pages return 5xx, roll back.
| Situation | Decision | Reason |
|---|---|---|
| Home and core pages return 200 | Keep monitoring | Expected state |
| A few secondary pages return 404 | Fix in place | Limited impact, easy fix |
| Many pages return 5xx | Point DNS back to the old host | Google's crawlers slow down on server errors |
| Every response carries noindex or disallow | Remove the block at once | A temporary block reached live |
The First 72 Hours: Errors, Crawling and Speed
The first days show whether the plan worked. The aim is not to chase numbers but to catch inconsistencies early.
Traffic shifting from old to new
Google's guide says to expect a drop in traffic logged on the old servers and a corresponding increase in traffic on the new servers. Watch both logs together. If old-host traffic falls while new-host traffic rises, propagation is on track. If old-host traffic stays high far longer than expected, caches may still point at the old address, or the lowered TTL was never applied.
Reading server errors the way Google does
Google's page on how HTTP status codes affect its crawlers says 5xx and 429 server errors prompt Google's crawlers to temporarily slow down. For a 500 it decreases the crawl rate for the site, and the decrease is proportionate to the number of individual URLs affected. Once the server returns 2xx again, Google gradually increases the crawl rate. It treats 429 as a signal that the server is overloaded. All of this is why the new host must be sized for the burst of crawling that follows a move. The full text is in Google's HTTP status codes and crawlers documentation (Opens in a new tab).
Persistent errors and index loss
The same page says already indexed URLs that keep returning server errors are preserved in the index at first but eventually dropped, and that for 502 and 503 the indexing pipeline removes URLs that persistently return a server error. It does not say how long "persistently" is. Do not leave a server error to see if it clears; find the cause. As for DNS and network errors, that page only links to a separate document, so do not draw conclusions about them from it.
Crawl rate and Search Console
The hosting guide says a temporary drop in Googlebot's crawl rate right after launch is normal, followed by a steady increase over the next few days, possibly above pre-move levels. Watch the crawl stats and index coverage in Search Console. Do not treat a short dip as an emergency, but a dip that continues while error counts rise deserves an investigation.
Response time
If the new host answers more slowly than the old one, crawling and visitors can both suffer. In the first days, measure response times for the home page and the core templates, and confirm the cache layer works. If you recorded baseline values before the move, comparison is easy; measure before and after with the same tool and conditions.
| Window | Where to look | Normal | Warning sign |
|---|---|---|---|
| First hours | Access logs on both hosts | Old traffic falling, new rising | No traffic on the new host |
| First day | Live status codes | 200 and expected 301 | Unexpected 5xx or 404 |
| First 48 hours | Crawl stats | Temporary dip, then a rise | Dip continues, errors rising |
| First 72 hours | Index coverage, response time | Stable page counts | Sudden growth of excluded pages |
Who owns what when a problem appears
Name an owner for each type of problem before cutover: the hosting provider for server issues, the developer for content and configuration, the SEO lead for search visibility findings. If everyone intervenes at once, nobody knows which change fixed what. Log every intervention with a timestamp, try reversible changes (a DNS record, a config setting) before irreversible ones (database edits), and prefer fixing a template's server setting over a full DNS rollback when the issue is confined to one part of the site.
A short daily routine
For three days, run the same small list: no noindex in the live home page source, robots.txt does not block the whole site, server error rate looks normal, response time is acceptable, and the traffic split between hosts matches expectations. Record results in a table. A short, consistent routine catches problems faster than random checking.
When to Shut the Old Host Down
Shutting down the old host is the last step that is hard to undo, so base it on evidence, not on a date.
Google's criterion
The guide says that once traffic to the old provider reaches zero, you can shut down the old hosting infrastructure. It gives no fixed retention period; the decision hangs on what you observe in the old provider's logs. If you still see a few requests, find out who sends them: crawlers, monitoring tools, an email system or a payment callback that still uses the old address.
Checks before switching it off
- Has human traffic to the old host dropped to zero, and do you know who sends the remaining requests?
- Do email, payment callbacks, APIs and scheduled jobs all connect to the new host?
- Do you hold a verified full backup of the old files and database?
- Are the old host's certificates and redirect rules covered on the new host?
- Has the TTL been raised back to a normal value?
- Have old subdomains and extra domains been moved?
A decision rule
Turn off the old host when three conditions hold together: its access logs show no traffic, or only known automated requests; the new host has run without problems through at least one full monitoring cycle that you define, such as a week; and the backup is verified. Google's guide names no such week, so treat it as your own safety margin. If one condition is missing, wait. A few extra days of hosting cost less than a mistaken shutdown.
Aftercare
After shutdown, restore the normal TTL, delete temporary test records, and put backups and monitoring on the new host. For several weeks, check index coverage and crawl stats weekly. Do not delete the old backup immediately: keeping it for a short period as an archive gives you a way to recover a forgotten file, mailbox or custom configuration. Note where it is, who can access it and when it will be removed, and make sure any personal data in it follows your retention policy. Google's recommendations and interface names can change, so check the current pages before you act.
The whole plan on one page
| Phase | Main work | Exit condition |
|---|---|---|
| Preparation | Lower TTL, build the new host | TTL low for over a week, test environment ready |
| Verification | Noindex, robots, SSL, Googlebot access | Parity checklist complete |
| Cutover | Remove blocks, update DNS | Live hostname returns 200 from the new host |
| Monitoring | Logs, error codes, crawling | No errors, crawling recovered |
| Shutdown | Decommission the old host | Old traffic zero, backup verified |
Frequently Asked Questions
When should I lower the TTL before changing hosts?
Google's hosting guide recommends lowering the TTL to a conservative low value, for example a few hours, at least a week before the move. DNS settings are usually cached according to the TTL you set, so a change made on cutover day would not take effect until older caches expire.
Will changing hosts hurt my rankings?
Google's documentation does not promise any ranking outcome or describe the effect with a number. It says a temporary drop in Googlebot's crawl rate right after the move is normal, followed by a steady increase. The goal of a planned move is to avoid downtime and accidental blocks.
When can I shut down the old server?
According to Google's guide, once traffic to the old provider reaches zero. The guide gives no fixed number of days. Before shutting down, inspect any remaining requests, verify your backup and confirm that email, payments and scheduled jobs use the new host.
What should I do if Googlebot's crawl rate drops after the move?
Google's guide says a temporary drop right after launch is normal and a steady increase follows over the next few days. If the drop continues or server errors rise, check for 5xx and 429 responses, firewall rules that block crawlers, and whether the new server can handle the load.
How do I protect the test copy on the new host?
Google's guide suggests a test environment restricted by IP address. If you use a public temporary hostname, add a noindex rule to the HTML or headers. When the move starts, remember to remove noindex tags and robots.txt disallow rules from the new copy.
Do I need redirects when only the host changes?
Google's hosting guide covers moves where URLs do not change, so there is no old-to-new address mapping in its steps; the key step is pointing DNS records at the new provider. If the domain, protocol or path structure also changes, you need a separate migration plan.
Related guides: Website Redesign SEO Checklist: Protect Rankings When You Relaunch, WordPress Tag and Archive Pages: Noindex or Index?, Staging Site Indexed by Google: How to Fix and Prevent It.
Conclusion
A host move with unchanged URLs is manageable when done in order. Following Google's guide, lower the TTL to a conservative value at least a week ahead, verify the copy in an access-restricted environment, check Googlebot can reach the new infrastructure with the URL Inspection tool, remove temporary noindex and disallow rules as the move starts, then update the DNS records. After cutover, watch both hosts' logs, server error codes and crawl stats; a temporary dip in crawl rate is described as normal. Shut the old host down when its traffic reaches zero, not on a calendar date. None of this guarantees a particular ranking outcome; the goal is a move that is invisible to crawlers and visitors.
If you plan to strengthen your link profile after the move, you can look at the backlink packages at Akua Adforce; scope and terms are listed on the product page.
Post a comment
Please log in to leave a comment. Login