Domains and DNS when moving an AI website to WordPress
An IT consultant explains how to handle domains, DNS records, email and certificates safely when moving an AI-built site to WordPress.
Convert2WP – convert your AI website to WordPressClick here
The part of the migration nobody sees
Clients usually focus on how the new WordPress site looks. In my experience the riskiest moment of a migration is not the design at all, but the few minutes in which the domain starts pointing to a new server. If DNS is handled carelessly, a site can be unreachable for hours, email can stop arriving, and search engines can briefly see errors on every URL.
None of that is necessary. With a bit of preparation the DNS switch becomes the most boring step of the project, which is exactly what it should be.
Know where your domain really lives
Many AI builders let you connect a custom domain through a wizard. Months later, nobody remembers where the domain was registered, who manages the DNS zone, or which records were added. The first thing I do is find the registrar, the DNS provider and the login details, and I export a full copy of the current DNS zone.
That export is my safety net. If anything goes wrong, I can restore the previous records in minutes. I also check the expiry date of the domain; I have seen more than one site go offline because a domain quietly expired during a busy period.
Do not break email
The DNS zone often contains more than the website. MX records route email, and TXT records hold SPF, DKIM and DMARC settings that protect against spoofing. When people switch name servers to their new host without copying these records, email stops working. Clients notice that much faster than any SEO problem.
I copy every non-website record to the new zone before changing anything, and I send a test email in both directions after the switch.
Lower the TTL in advance
The time-to-live of a DNS record tells resolvers how long they may cache it. If the TTL is a full day, some visitors may keep reaching the old platform for a day after the switch. A day or two before launch I lower the TTL of the relevant records to a few minutes. After launch, once everything is stable, I raise it again.
This small step turns a slow, unpredictable switch into one that completes for most visitors within minutes.
Choose one canonical host
Decide whether the site lives on the domain with or without www, and make the other variant redirect permanently to it. Both variants must resolve in DNS; a missing record for the bare domain is a surprisingly common reason for lost traffic. In WordPress the site address setting should match the chosen variant exactly, and Search Console should be verified for that variant.
Mixing the two versions confuses search engines and splits signals. Consistency here is cheap and very valuable.
Certificates and HTTPS
Most hosts issue free certificates automatically, but only after the domain points to them. I plan for a short window in which the certificate is being issued, and I check that both variants of the domain serve HTTPS without warnings. Afterwards I search the database for old http links and update them, so browsers do not report mixed content.
Small issues like a single image loading over http are normal right after launch and quick to fix.
Launch day checklist
On launch day I switch the records, test the homepage and a sample of deep URLs, check the redirects from the old addresses, confirm the certificate, send test emails and submit the sitemap in Search Console. I keep the old platform running for a few days in case a rollback is needed, then cancel it once traffic and email are confirmed.
Handled this way, the domain move is calm and predictable. The visitors never notice, and that is the best compliment a migration can receive.