A WordPress NXDOMAIN error should be investigated at the domain-resolution layer before changing WordPress files or settings. Record the exact hostname and resolver result, compare authoritative and cached answers, and identify the owner of any discrepancy. Recheck the same names after an authorised correction so the evidence shows what changed and what remains unresolved.
Start by copying the address that failed, including its subdomain. The homepage hostname, a www address and an administrator’s remembered domain can be different test subjects. Keep the browser message, time and network context with the record. This helps the person investigating distinguish a repeatable domain problem from a report about another address.
The diagnostic worksheet below uses fictional hostnames and proposes read-only observations. Its primary references are Cloudflare DNS and Google Public DNS documentation, retrieved on 24 October 2026. For the application context, see WordPress; domain ownership and configuration questions belong with domains.
What does the error tell you to check first?
Cloudflare describes NXDOMAIN as a DNS lookup result that the domain does not exist. Its NXDOMAIN guide discusses the error in the context of domains activated on Cloudflare. Treat the actual DNS response as the starting evidence, then establish which DNS service is authoritative for the affected domain.
Cloudflare recommends checking the apex domain and active subdomains. Write each expected name as a separate row of the worksheet. A successful lookup for the apex does not answer whether the www or other requested hostname has the intended record. Keep the returned status and record type alongside the full name.
Cloudflare also recommends checking that records point to the intended origin address. Ask the authorised domain owner to confirm the intended destination before proposing a correction. A remembered server address or an unrelated working domain is not a reliable substitute for the current configuration record.
The WordPress site can be inspected once the hostname resolves appropriately. Keeping those stages separate makes the investigation more precise. It also avoids changing application settings in response to an observation that has not yet reached the application at all.
How can a second resolver help the investigation?
Google provides a DNS lookup form at dns.google. The Google Public DNS troubleshooting guide describes using it to inspect a domain. Record the exact query and result rather than simply noting that the web tool opened successfully.
Google’s lookup form accepts a specified resource-record type. Select the type relevant to the question and retain it with the name. A record-type distinction is useful when a domain serves several purposes: the evidence needed for website addressing is different from the evidence for another service using the same domain.
Google’s detailed DNS results can include a Comment field with diagnostics. Preserve that text with the response so the person investigating can follow the relevant guidance. The diagnostic wording can help route the issue towards delegation, name-server or DNSSEC checks instead of treating every resolution failure as the same problem.
Compare the browser’s network context with the independent result. If the answers differ, record both and identify which resolver the affected device is using. The aim is to narrow the discrepancy, not to declare whichever response looks familiar to be correct.
| Worksheet row | Observation to retain | Question it helps answer |
|---|---|---|
| Exact failed hostname | Full name and browser message | Are all reviewers testing the same address? |
| Expected apex | Resolver, type, status and answer | Does the main domain resolve as intended? |
| Expected subdomain | Same details for that specific name | Is the requested name configured? |
| Independent resolver | Identical query through another route | Is the discrepancy resolver-specific? |
| Authoritative comparison | Name server and relevant zone evidence | Are the published answers consistent? |
| Post-correction check | Same query and recorded time | Did the intended observation change? |
This is an original diagnostic sheet. Keep the observed values blank until the queries have actually been made.
What can explain differing answers?
Google notes that recent name-server changes can leave unexpired cached answers. Record when a configuration change occurred and which result is being examined. A cached answer can remain relevant evidence without describing the currently intended authoritative configuration.
Google recommends checking the SOA serial when stale answers persist after a cache flush. Google says differing SOA serials can indicate stale data on authoritative name servers. These are useful diagnostic examples when the domain owner is comparing published zone versions. Keep the queried name server and serial together so the comparison is repeatable.
Google says ping and traceroute do not measure DNS resolution speed. Those tools can help with reachability questions, but their results should be labelled according to what was measured. Use the DNS query evidence for a resolution question and avoid describing a successful ping as proof that the domain’s requested record is correct.
Google recommends including diagnostic outputs when reporting a persistent problem. Assemble the exact hostname, query type, resolver, response and relevant configuration history into one concise report. This gives the responsible DNS operator evidence they can assess without asking each colleague to reconstruct the failed attempt from memory.
Original hostname-to-authority recovery worksheet
For a hypothetical site, list the apex and www hostname as separate expected addresses. Add another row for the exact name reported by the user, even if it appears to be a typing error. Ask the domain owner to confirm which names are intended to serve the website and which DNS service currently owns their records.
Begin with read-only queries from the affected context and the independent lookup form. Record the answers exactly, including status and record type. If the results differ, inspect the resolver context and authoritative publication with the responsible administrator. Keep each observation tied to its source rather than combining them into a single unsupported diagnosis.
Write the proposed correction only after the discrepancy is identified. The change record should name the affected record, intended value and authorised owner. Preserve the existing relevant configuration before a later approved edit. This gives the team a clear before-and-after reference and helps prevent an unrelated service record from being changed during website troubleshooting.
After the correction, repeat the original queries and compare their results. Then inspect the website response at the intended hostname and identify any remaining application-level issue separately. A restored DNS answer and a working WordPress page are useful but distinct observations, and the worksheet should show both where relevant.
Finish with the evidence needed by the next owner: names tested, configuration decision, observations and unresolved questions. For hosting-side investigation, see hosting. To discuss the specific domain and its evidence, get started with the diagnostic sheet rather than an assumed application fix.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.