A zero-downtime launch: DNS, SSL and the go-live checklist
An IT consultant's go-live runbook for switching an AI-built site to WordPress without downtime, covering DNS, SSL and redirects.
Convert2WP – convert your AI website to WordPressClick here
Launch day should be boring
I have done many launches, and the best ones were the ones nobody noticed. Visitors kept browsing, email kept arriving and search traffic did not dip. That does not happen by luck. It happens because the work is done in the days before, and launch day is just executing a checklist.
This guide is the runbook I use when moving a site from an AI builder to WordPress on a new host.
Seventy-two hours before
I lower the TTL of the relevant DNS records, usually the A record and the www CNAME, to five minutes. TTL tells resolvers how long they may cache a record. Lowering it in advance means that when I switch, the change spreads within minutes instead of hours.
At the same time I freeze content on the old site, or agree with editors that any changes are also made on the new site. Nothing is worse than losing a week of edits because they were made on the platform you are leaving.
Preparing SSL in advance
A new host can only issue a free certificate automatically once the domain points to it, which can mean a few minutes of certificate warnings. To avoid that, I either use DNS-based validation to issue the certificate before the switch, or temporarily upload a certificate. Some hosts handle this with a preview domain.
I also make sure both the root domain and www are covered, and decide which one is canonical. One redirects permanently to the other, always.
Testing the new site under the real domain
Before switching DNS, I test the new server using a hosts file entry on my own machine, so my browser sees the new site under the real domain. I click through key pages, test forms, check the sitemap and look at the raw HTML for canonical and hreflang tags.
This is also the moment to confirm redirects from old URLs. AI builders often use different URL patterns than WordPress. Every old URL with traffic or backlinks needs a 301 redirect to its new equivalent, and unknown paths should land on a sensible page instead of an error.
The switch itself
With everything prepared, the switch is a few minutes of work. I update the DNS records, keep the old site running for at least a week, and watch the server logs on the new host. Within minutes the first visitors arrive on the new server.
I do not touch MX records unless email is moving too. Accidentally changing mail records is one of the most common causes of launch-day panic.
The first hour after go-live
I check the homepage and key templates from different networks, including mobile data, to make sure resolvers pick up the new records. I verify certificates, redirects and the sitemap, and submit the sitemap in Search Console and Bing Webmaster Tools.
Monitoring tools that ping the site every minute and alert on errors are switched on before the launch, not after. If something fails, I want to know before a customer tells me.
The first weeks
Over the following weeks I watch crawl errors, indexing reports and traffic per page. A small dip in rankings after a migration is common and usually recovers. A large drop on specific pages points to a missing redirect or a changed canonical, which I fix immediately.
Once things are stable, the TTL goes back up to a normal value such as one hour, and the old platform can be cancelled.
Accepting small imperfections
Even with careful preparation, a few small issues show up after launch: an image that did not convert perfectly, a spacing difference on one template. That is normal. The converter handles the design and pages, not the old backend, and minor glitches are easy to fix afterwards, often with a plugin.
What matters is that the site stays reachable, secure and findable throughout the switch. With this runbook, that is the realistic outcome.