WordPress DNS Errors: Check the Hostname, Nameservers and Records

If the browser says it cannot find your site, begin with the address it tried to open. The root domain, www version and any other subdomain can have different DNS records, so one may work while another fails.

This problem happens before WordPress loads. Changing a theme or clearing a page cache will not create a missing DNS record; the useful first step is to confirm the exact hostname and which DNS provider is authoritative for it.

Next confirm which provider currently answers for the domain. A correct-looking record in an old DNS dashboard will not help visitors if the nameservers now point elsewhere.

Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.

Confirm which hostname fails before changing DNS

Clue	First check	Next action
Root works, www fails	www record at active DNS provider	Check that hostname’s destination
Failure follows nameserver move	Registrar delegation and active zone	Compare nameservers and migration requirements
Only one network fails	Source answer versus cached resolver answer	Keep the correct source stable while checking caches
Domain resolves to old site	A/AAAA/CNAME destination	Compare with current host instructions
Cloudflare page now returns an origin error	Exact origin error	Move to that error guide; DNS lookup has progressed

Begin with the exact address that fails

Copy the hostname from the browser error.
Compare the root domain, www and any required subdomain separately.
Write down the full error and the network where it occurs.
Test from a second available network to learn whether the failure is local or shared.

Compare the hostname in the address bar with the one configured for the site. The root domain and www are separate names, and another subdomain needs its own appropriate configuration. A working root domain does not automatically mean that www will resolve.

For example, if example.com opens but www.example.com produces a DNS error, look at the record for www before changing the entire domain. A browser cannot follow the site’s normal redirect until it can reach the hostname used in the first request.

Note the full error message as well. NXDOMAIN generally indicates that the queried name does not exist in the DNS answer. Other DNS failures can involve resolution or validation problems, so they should not all be treated as a missing A record.

Make sure you are editing the active DNS provider

Open the domain registrar’s nameserver settings.
Compare them with the intended DNS provider’s assigned nameservers.
Open that provider’s zone and find the exact failing hostname.
Before editing, save the current record type, value, proxy state and TTL.

For a DNSSEC-enabled move, follow the registrar and new provider’s migration procedure. A record can exist while validation still fails.

The registrar’s nameserver setting identifies the service responsible for the domain’s authoritative DNS. Records visible in an old provider’s dashboard may no longer be the records that visitors use.

This matters after a move to a new host or DNS service. If you change a record in the previous provider while the domain delegates to the new one, the public answer will remain unchanged. Compare the registrar’s nameservers with the values supplied by the intended DNS provider.

A recent nameserver move also makes DNSSEC configuration relevant. A mismatch can prevent validation even when records appear to exist. The registrar and DNS provider’s migration instructions are the appropriate reference for that configuration.

Compare the record with the intended destination

Illustrative comparison: example.com points to the new host, but www.example.com still targets a retired host. Check the www record, including any CNAME chain, rather than replacing the root record that already works.

For the hostname used by your site, inspect its A, AAAA or CNAME configuration as appropriate. The destination should agree with the current host’s instructions. An address copied from an old server can lead visitors somewhere else even though the DNS query succeeds.

If both IPv4 and IPv6 records are present, both deserve attention. An obsolete IPv6 destination can affect visitors using that path while others appear to have no problem. Similarly, a CNAME depends on its target remaining valid.

Before editing, save the existing value and record the time of the change. That leaves you a clear way to compare results and undo an incorrect correction.

Why two networks can give different results

Recursive resolvers cache DNS answers. They can also retain a negative answer from a time when a name was missing. As a result, one network may still fail while another has already received the corrected record.

A comparison between the authoritative answer and a public resolver helps explain that difference. If the source answer is still wrong, more waiting will not repair the zone. If the source answer is correct and one resolver still returns an older result, repeated record changes are unlikely to help.

There is no single waiting period that fits every change. Record TTLs, negative caching and delegation changes can affect how long different resolvers retain information. Keeping a correct configuration stable is more useful than changing it repeatedly during that interval.

Cloudflare’s proxy setting is a separate decision

When Cloudflare hosts the DNS zone, supported web records may be proxied or DNS-only. That choice changes the route taken by web traffic, but it does not create a missing hostname. A valid DNS record is still required.

A hostname that resolves but returns a Cloudflare origin error has moved beyond a simple DNS-name lookup failure. Investigate the reported error and connection to the host rather than continuing to modify unrelated WordPress settings.

What a successful correction looks like

Test the root domain and the subdomains your site actually uses. Compare another network when the original failure was limited to one location. Then open the HTTPS address and make sure it reaches the correct site, rather than a parking page or an old installation.

If DNS now works but a certificate warning or redirect loop appears, that is the next issue to investigate. Resolving the domain is necessary, but it does not by itself repair the web server, certificate or WordPress configuration behind it.

Authoritative DNS references and related guides

After the name resolves

Open the intended HTTPS hostname and confirm it serves the correct installation. Then check certificate coverage and redirects separately. DNS success is one checkpoint, not proof of a fully working website. Cloudflare’s DNS_PROBE_POSSIBLE guidance explains checking zone settings for that browser error.