Moving Your Domain to WordPress: DNS, HTTPS and a Controlled Cutover

A website migration can look finished while its domain is still pointing at the wrong infrastructure. The new WordPress pages are ready, the editor works, and the design is recognisable, yet visitors continue reaching the previous deployment. Domain changes are not difficult because DNS is mysterious. They are difficult because several independent systems share the same hostname: the registrar, authoritative nameservers, hosting, certificates, email and sometimes a proxy. Treating those systems as one switch is how an otherwise straightforward launch becomes an unnecessary incident.

This guide deals with that boundary between a converted website and its public address. It assumes the presentation layer has already moved from an AI builder to WordPress. It does not assume that your database, payment logic or user accounts have moved with it. Those are separate migrations. The objective here is narrower: put the right site behind the right hostname, keep email working, and retain a practical way to reverse the change if the new hosting becomes unavailable.

Start with the authoritative source, not the registrar screen

The company where you bought a domain is not necessarily the company serving its DNS. The nameserver records determine where authoritative answers come from. A registrar might display an attractive DNS editor whose records have no effect because the domain delegates to another provider. Before changing anything, identify the active nameservers and export the records from that provider. Record the existing A, AAAA, CNAME, MX and TXT values, including verification records that look unrelated to the website. They may support email, analytics ownership or an integration someone configured long ago.

Keep the export somewhere accessible outside the hosting account. A screenshot is better than nothing, but a structured record list is easier to compare and restore. Also record whether a proxy is enabled for each hostname. A proxied record can return the proxy's address instead of the origin's address, which makes a superficial DNS comparison misleading. This inventory takes little time and prevents the most expensive category of mistake: changing the wrong control panel, then trying to repair the consequences in several other places.

Change the website records without moving everything else

For a routine migration, changing the records used by the website is usually less risky than changing the entire nameserver delegation. Your WordPress host may ask for an A record, a CNAME or a provider-specific alias at the apex. Follow its current instructions rather than copying an example from another host. Preserve mail-related records unless email is explicitly part of the project. A website hosting change does not require a mailbox migration, and combining the two creates an unnecessary dependency during launch.

Inspect both IPv4 and IPv6. Updating an A record while leaving an old AAAA record can send IPv6-capable visitors to the previous site. The result appears random because some networks prefer IPv6 and others do not. Likewise, configure both the apex domain and the www hostname. Choose one preferred public address, but make sure the other resolves and redirects to it. The redirect belongs in the web server or proxy configuration; DNS alone cannot issue an HTTP redirect or preserve a requested path.

Lower TTL early, but do not promise instant propagation

The time-to-live value tells recursive resolvers how long an answer may be cached. If the existing record has a long TTL, lowering it immediately before launch does not invalidate answers already cached under the old value. Lower it in advance and allow the previous TTL to expire. The exact lead time follows the records you actually have, not a universal migration rule. Avoid describing propagation as a global event with one finish time. Different resolvers, browsers and applications retain answers differently, and some caches do not behave ideally.

During the overlap, both old and new infrastructure should remain usable where possible. For a mostly static brochure site, this is easy. For a shop or membership service, writes complicate the picture: visitors reaching two systems can create divergent orders or profile changes. Use a deliberate write freeze, a shared service or a coordinated data handover for that case. A lower TTL reduces the overlap but does not eliminate the need to decide which system owns incoming data.

Provision HTTPS before visitors arrive

A certificate must cover the hostnames visitors actually use. A working certificate for www does not automatically cover the apex, and the reverse is also true. Many managed hosts can provision certificates through DNS validation before traffic moves. Others need the hostname to point at their service first. Understand that dependency before scheduling the launch. If a proxy terminates HTTPS, confirm that the connection between proxy and origin also uses a valid certificate and an appropriate verification mode. Encryption without origin verification is not the same as a properly authenticated connection.

Be cautious with HSTS while configuration is still changing. An existing HSTS policy can force browsers to use HTTPS even when a newly configured origin is not ready. Policies covering subdomains deserve particular attention. Do not enable a broad or preloaded policy simply because a checklist recommends it. First make HTTPS reliable across the intended hostname scope, then adopt a policy that your team can sustain. Certificate renewal must also have an owner; a successful initial issuance is not a permanent solution.

Prepare WordPress for its final address

WordPress stores its site and home addresses, and content or plugin settings may contain absolute URLs from staging. Update these through supported tools. A blind database text replacement can corrupt PHP-serialized values because their recorded string lengths no longer match. A serialization-aware search-and-replace tool, including the relevant WP-CLI command, is the safer approach. Take a database backup first and use a dry run to understand the scope. Do not replace every occurrence of the old domain without considering links that are intentionally external.

After updating the addresses, refresh rewrite rules if the host or permalink configuration requires it, and clear caches that can retain staging redirects or asset paths. Remove staging-only indexing restrictions from production while keeping staging itself private or excluded. Look at the initial response of a representative page for the final canonical address. A migrated page can render beautifully while still declaring the staging domain as its preferred URL. Our related redirect and SEO migration guide explains the content-side mapping separately.

Protect email and account recovery

Mail failures often accompany a website migration because someone replaces a DNS zone with the host's default template. Preserve MX records and the TXT records supporting SPF, DKIM and DMARC. If WordPress will send notifications through a new provider, add its authentication records carefully. A domain should not have multiple competing SPF policies. Consolidate authorised senders into a valid policy and consider lookup limits rather than appending arbitrary includes. Website notifications and ordinary employee mail may use different providers, but their domain authentication still needs a coherent configuration.

Administrative recovery also matters. Verify that the person performing the change can access the registrar, DNS provider and hosting independently. Do not rely on a single account whose recovery email is hosted on the system being changed. Use multi-factor authentication and securely retain recovery methods. This is not elaborate enterprise ceremony; it is a sensible precaution for a small business where one inaccessible inbox can turn a reversible record change into a prolonged support request.

Run a small, explicit cutover

Write the exact changes in order: update the required website records, confirm resolution from an authoritative source and a separate resolver, request the apex and www addresses over HTTPS, and confirm the intended redirect destination. Follow with a representative public page and one important business workflow using safe test data. There is no need to pretend every decorative interaction has been audited. Concentrate on the infrastructure assumptions that affect every visitor. Record the time of the change and leave the old hosting available through the planned overlap.

Rollback means restoring more than an IP address when the new site has accepted writes. Define how new submissions or orders will be retained before reversing traffic. For a read-only launch, restoring the previous records is generally simpler, although cached DNS answers still create an overlap. Convert2WP.net can be considered for the visual conversion stage; domain management remains the responsibility of the hosting and DNS team. Small visual differences can usually be polished later, often through a plugin or theme adjustment. DNS, certificates and ownership deserve a clear decision before launch.