WordPress DNS Errors: Diagnose NXDOMAIN, DNS_PROBE and Missing Records

WordPress cannot load until the domain name resolves to the correct destination. Browser messages such as DNS_PROBE_FINISHED_NXDOMAIN and DNS_PROBE_POSSIBLE therefore need to be diagnosed at the DNS layer before you change WordPress plugins, themes, or PHP settings.

Quick diagnosis

DNS_PROBE_FINISHED_NXDOMAIN: the resolver concluded that the requested hostname does not exist or has no usable DNS record.
DNS_PROBE_POSSIBLE: the resolver could not find the expected DNS records for the hostname.
Only one device is affected: check local DNS cache, network, VPN, security software, and resolver settings before changing authoritative DNS.

Check the hostname before changing DNS

Confirm that the domain or subdomain is spelled correctly. Test the exact hostname visitors use, including the apex domain and any active subdomain such as www.

If the apex domain resolves but www does not, the fix may simply be a missing www A or CNAME record. If neither resolves, check the authoritative DNS configuration.

Verify the required DNS records exist

Cloudflare’s DNS troubleshooting guidance recommends checking the expected apex and subdomain records first. Make sure the record exists and points to the correct origin IP address or intended CNAME target.

Check:

the apex A, AAAA, or CNAME setup,
the www record if the site uses it,
any subdomain used for the WordPress installation,
the origin IP address after a hosting migration,
and whether a stale or incorrect CNAME target is still configured.

Check authoritative nameservers

If DNS records look correct in one dashboard but public resolvers do not return them, confirm that the domain’s registrar points to the nameservers that actually host those records. Editing records at an old DNS provider has no effect after nameservers move elsewhere.

After a nameserver change, verify that the domain is using the assigned authoritative nameservers and that DNSSEC settings are compatible with the new provider.

Separate authoritative DNS from local resolver problems

A site can resolve correctly from one network and fail from another because recursive resolvers cache negative responses. Query the authoritative nameserver directly when you need to prove that a record exists at the source.

If the authoritative server returns the correct record but a public resolver does not, the issue may be cache propagation rather than a missing record. Avoid repeatedly changing the DNS record while caches are still updating.

Cloudflare proxy status is a separate setting

When Cloudflare hosts the DNS zone, A, AAAA, and CNAME records can be proxied or DNS-only. The proxy choice affects how web traffic is handled, but the hostname still needs a valid DNS record first. A missing record cannot be fixed by changing WordPress settings.

Safe troubleshooting order

Verify the exact hostname and spelling.
Check whether the apex and required subdomains have DNS records.
Confirm the record points to the correct origin or CNAME target.
Verify the registrar uses the intended authoritative nameservers.
Check DNSSEC after provider or nameserver changes.
Query the authoritative nameserver directly if public resolvers disagree.
Wait for caches to update before making additional DNS changes.

Official references

Bottom line: browser DNS errors occur before WordPress can run. Confirm the hostname, authoritative nameservers, and required records first. Change WordPress only after DNS reliably points visitors to the correct server.