What should you check before pointing a domain at a new site?

What should you check before you point a domain at a new site?

Lower your DNS time to live a week early, confirm the new host has a working certificate, and find out whether you are sending HSTS. Those three in that order. The first buys you a fast retreat, and the third decides whether a retreat is even possible.

Cutovers rarely fail because someone typed the wrong record. They fail because the person switching had no way back, or because a security header they forgot about turned a small certificate delay into a site nobody could reach.

What follows is what I check before flipping a live domain. It is not exciting and it is the difference between a five-minute switch and an afternoon of apologising.

Why should you lower your DNS TTL before anything else?

Because TTL controls how long resolvers keep your old answer, so a high TTL on cutover day means you cannot undo a mistake quickly. Google's own guidance on moving a site without changing URLs says to consider lowering the TTL to a conservative low value, for example a few hours, at least a week in advance of the move.

The week matters as much as the value. Lowering TTL only takes effect once the old, longer TTL has expired everywhere, so doing it the night before achieves very little. You are waiting out the cache you already set, which is why this is the step that has to be planned rather than performed.

Think of it as buying an undo button. If the new host turns out to be misconfigured, a short TTL means you point the record back and most visitors recover within hours rather than days. Without it, you are committed to fixing forward under pressure.

What does HSTS do to a cutover that goes wrong?

It removes the escape hatch. According to MDN, the Strict-Transport-Security header informs browsers the host should only be accessed using HTTPS, and on future connections the browser will not allow the user to bypass secure connection errors, such as an invalid certificate.

Read that last clause again, because it is the whole risk. Normally a certificate problem shows a warning a visitor can click through. With HSTS in force there is no click-through. If your new host is serving an invalid or missing certificate, returning visitors get a hard wall, and you will hear about it from the loudest customer first.

MDN also explains the persistence. It says max-age is the time in seconds the browser should remember that a host is only to be accessed using HTTPS, and that every time the browser receives the header it updates the host's HSTS expiration time by adding max-age to the current time. So the instruction lives in your visitors' browsers, not on your server, and you cannot recall it by changing your configuration.

When should the new host's certificate be ready?

Before you touch the DNS record, without exception. Verify the new site serves valid HTTPS on its own hostname first, so that the only variable you change on cutover day is where the name points, and not whether HTTPS works at all.

The subdomain question catches people out. MDN notes that if the includeSubDomains directive is specified, the HSTS policy applies to all subdomains of the host's domain as well. So a policy set on your root domain can apply to a subdomain you had forgotten about, and that subdomain needs a valid certificate too, or it goes dark with no bypass.

If you have gone as far as preloading, treat it as a commitment rather than a setting. MDN states that when using preload, max-age must be at least 31536000, which is one year, and includeSubDomains must be present. It also notes that Google maintains an HSTS preload service and that while the service is hosted by Google, all browsers are using this preload list. Read that service's own guidance before you assume you can quickly undo it.

Should you keep the old server running?

Yes, and for longer than feels necessary. Google's guidance is to check the server logs on the old provider and, once traffic to the old provider reaches zero, then shut down the old hosting infrastructure. The trigger is the logs, not the calendar.

This is the step people skip to save a month of hosting cost, and it is the cheapest insurance in the whole exercise. While both are running, a bad cutover degrades into a slightly confusing period rather than an outage, because the visitors still hitting the old address are being served something.

It also protects you against the resolver you did not think about. Some caches are stubborn, some corporate networks are stranger still, and "traffic has reached zero" is the only honest evidence that everyone has moved. Until then, keep the lights on.

What should you watch in the hours after the switch?

Both sets of server logs, side by side. Google's guidance describes exactly the pattern to expect: as the DNS setting propagates and site traffic moves, you will notice a drop in traffic logged on the old servers and a corresponding increase on the new servers.

That shape is your confirmation that the switch is working, and its absence is your early warning. If old-server traffic is falling and new-server traffic is not rising to match, something is being lost in between, and you want to know that within the hour rather than from a report on Monday.

I also watch error responses on the new host specifically, because a fresh deployment can serve the wrong status code for pages that do not exist yet. Getting that right matters, and I have written about what a temporarily unavailable page should return, which is exactly the situation a half-finished cutover creates.

Why does Googlebot's crawl rate drop, and should you worry?

It usually does, and usually you should not. Google's guidance on this kind of move says it is normal to see a temporary drop in Googlebot's crawl rate immediately after the launch, followed by a steady increase over the next few days.

Knowing that in advance is worth a surprising amount, because the drop looks alarming in a dashboard and it is the moment people start changing things. Changing several things while a documented, expected dip is in progress is how a smooth migration turns into an unexplainable one.

So write the expectation down before you cut over, and tell whoever will be watching the graphs. Then set a date a few days out to check whether the steady increase actually arrived. If it did not, you have a real problem and a clean starting point for diagnosing it. Getting reporting in place first helps, which is why I set up Search Console on a new site before launch rather than after.

What breaks that has nothing to do with DNS?

Email, verification records and anything else living in the same zone. People replace a whole DNS zone to point a website and quietly delete the mail records. Then the website is perfect, and nobody can receive an invoice for a week.

Export the current zone before you change anything, and treat that export as the source of truth for what has to survive. Mail routing, domain verification strings for third-party services, and any subdomain pointing somewhere else entirely. Those are not website records and they are sitting in the same place you are about to edit.

The other non-DNS failure is URLs. Pointing a domain at a new site assumes the paths still match, and if the new build changed them you have a redirect project rather than a cutover. That is a different exercise, and it is worth having a redirect map ready before the migration rather than discovering the mismatch live.

What should you do next?

If you have a cutover coming, do the TTL change today and nothing else. It is the one step with a mandatory waiting period, so it is the one that determines your earliest safe date. Everything else on this list can be done the day before.

Then check your current response headers for Strict-Transport-Security and write down what they say. If HSTS is active, your certificate readiness moves from important to non-negotiable, and you should plan the cutover on the assumption that there is no warning screen anyone can click past.

Across 70+ projects for 25+ clients over 6+ years, the cutovers that went badly were never the complicated ones. They were the ones where somebody assumed a step could be skipped because the site was small. If you have a domain switch scheduled and have not exported the current zone yet, reach out and let's go through the checklist before the date.