Get a quick orientation before deeper domain work
Review DNS, registry, hosting, availability, and safety modules together so you can see which public signals need attention before opening a focused diagnostic tool.
Domain Report
Free, no signup. One bounded check for the public signals around a domain: DNS, registry data, hosting, reachability, and safety. Every section keeps its evidence and its focused-tool handoff.
Sample report
Illustrative example — fixed module states using the real roll-up formula
Domain report needs follow-up · 64/100
- DNS: Pass
- Whois / RDAP: Needs attention
- Hosting: Not evaluated
- Availability: Pass
- Safety: Needs attention
Two warnings · one not evaluated. The missing hosting check contributes zero and remains visible; it is not treated as a pass.
How to use it
- Enter a root domain.
- Run the report, then read every module state before the overall score.
- Expand evidence and open the focused handoff for any warning, error, or not-evaluated module.
- Download a summary card or print only after reviewing the point-in-time caveat.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
This report combines bounded public checks at one point in time. A passing section is not proof that a service is healthy, secure, authoritative, or free of hidden configuration problems.
Rate this tool
What the results mean
- Pass means that bounded module observed no implemented error.
- Needs attention means the evidence contains a warning.
- Errors means a defined adverse condition was observed.
- Not evaluated means the service or request did not supply usable evidence.
The average uses pass 100, warning 60, errors 0, and not evaluated 0. It is an orientation score, not a domain-health standard.
How it works
One request runs five bounded modules: public DNS, registry RDAP, hosting evidence, one-location availability, and public website-safety signals. Each module returns its own state, summary, and evidence so partial failures remain isolated. The browser calculates the transparent roll-up and links every module to its focused tool.
Features
- Five public-signal checks in one request.
- Partial-result handling with explicit not-evaluated states.
- Evidence drawers and prefilled focused-tool handoffs.
- Downloadable result card and print/PDF layout.
Limitations
This is not authoritative DNS, registrar account access, origin discovery, continuous uptime monitoring, a penetration test, or full safety assessment. A CDN can hide the origin; registry data can be redacted; external services can be unavailable; and every result is a point-in-time public view.
Frequently asked questions
Does this reveal my origin server?
No. A CDN or reverse proxyA CDN (content delivery network) is a geographically distributed network of edge servers that caches and serves your content from a location close to each visitor and crawler. It isn't a ranking factor itself, but it affects things Google and Bing do use — page speed and Core Web Vitals, crawl efficiency, uptime, and HTTPS delivery — and, if misconfigured, can block crawlers or muddle canonicalization. can deliberately hide an origin. The hosting section reports only public DNS, network, and response-header evidence.
Why is a section marked not evaluated?
Each section relies on a different public service or bounded web request. If one cannot complete, the report keeps that section visible as not evaluated instead of implying a pass or leaving a blank result.
Is this an uptime monitor or security scan?
No. Availability is a point-in-time check from one Cloudflare location, and safety is a public-signal snapshot. Neither replaces monitoring, a penetration test, or incident response.
How is the overall domain score calculated?
Each of five modules contributes 100 for pass, 60 for warning, and 0 for errors or not evaluated, then the values are averaged. Because unavailable evidence scores zero, always read module states instead of using the score alone.
Can I use this report as proof of domain health?
No. It is an orientation report built from bounded public checks at one point in time. Open the focused tools and your provider accounts for authoritative diagnosis.
Feature requests for Domain Report
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Preflight a domain for a launch or migration
Check whether the domain resolves, has usable registry evidence, returns a website response, and exposes obvious public safety findings before a launch checklist is signed off.
Triage partial and conflicting evidence honestly
Read every module state separately and keep unavailable evidence marked not evaluated instead of treating a missing check as a pass.
Investigate ownership and infrastructure clues
Use public RDAP, DNS, network, and response evidence to guide follow-up while remembering that redaction, CDNs, and reverse proxies can hide authoritative account or origin details.
Create a point-in-time handoff
Download a result card or print the reviewed report so teammates can see the score, module states, evidence, and focused-tool next steps without mistaking it for continuous monitoring.
Watch the full workflow
Domain Report walkthrough
Read the transcript
Domain Report
This beginner walkthrough explains what Domain Report checks, when it helps, how to run one complete fictional report, how to read the score and all five modules, what not evaluated means, how to inspect evidence and continue into focused tools, and which important domain questions remain outside this snapshot.
Step 1
Domain Report is an orientation tool for one root domain. One request gathers five bounded public-signal modules: domain name records, public registration data, hosting evidence, one-location availability, and website-safety signals. Each module keeps its own state and evidence, so the report helps you decide where to investigate next without pretending to certify the whole domain.
Step 2
Use it for a quick orientation before deeper domain work, a launch or migration preflight, honest triage when evidence is partial, public ownership and infrastructure clues, or a point-in-time handoff. The common thread is prioritization: the report tells you which focused check or account to open next, not whether the domain is universally healthy.
Step 3
Enter a root domain such as example dot com and choose Run domain report. The server makes bounded public domain-record, registry, and website requests. Results may be cached briefly, but the report is not stored as a user profile or monitoring subscription. A live result can change whenever public data, the website, or a dependency changes.
Step 4
The sample shows the same sixty-four-point mix used in this walkthrough: domain records and availability pass, registration and safety need attention, and hosting is not evaluated. The missing hosting check contributes zero and remains visible. That is deliberate: unavailable evidence must lower confidence, never quietly become a pass.
Step 5
The workflow is simple. Enter the root domain. Run the report and read every module state before the overall score. Expand evidence and use the focused handoff for any warning, error, or not-evaluated section. Only then download a summary card or print the report, keeping its point-in-time limitation attached.
Step 6
For the complete walkthrough, enter audit-demo dot example. Dot-example names are reserved for documentation, so this is not a customer or public site. The capture fulfills the Domain Report endpoint locally with fixed evidence and blocks every external response. That makes the walkthrough private, realistic, and identical across retakes.
Step 7
Choose Run domain report. The button names the five-check request, then the result appears with its score, summary, and actions. A live run can take longer because the modules rely on different public systems. Partial failure does not erase the completed sections; each module settles independently and remains visible.
Step 8
The fictional result is sixty-four out of one hundred and needs attention. The summary says two warnings and one not evaluated. Treat that score as a compact index of this run, not a domain-health standard. Its job is to orient you; the module states explain why the number exists and what deserves follow-up.
Step 9
The Domain Name System is the set of public records that connects a domain name to services. This module passes because three public address answers appear across a three-resolver comparison. The evidence preserves resolver coverage, a documentation-only address, and nameservers. A pass does not prove authoritative account control or that every resolver everywhere has converged.
Step 10
Whois and the Registration Data Access Protocol provide public registration context. This fixture warns that the registration expires in twenty-four days and lists the public registrar, expiry, and nameserver count. Confirm any action in the registrar account: public registry fields can be redacted, incomplete, delayed, or different from the authoritative account record.
Step 11
Hosting is not evaluated because this run did not return usable public hosting evidence. That is not a failure and definitely not a pass. Availability passes separately because the site responded successfully over a secure connection after one redirect. A content delivery network can hide an origin, and one successful response is not continuous uptime.
Step 12
Safety needs attention at seventy-two out of one hundred because the observed response lacks Content Security Policy. The evidence also says security dot text is valid, no mixed-content finding was observed, and Web Risk is not configured. Not configured is unavailable advisory evidence, not a clean verdict. This module is not a penetration test or vulnerability scan.
Step 13
Open Evidence under the module you are investigating. The registration drawer reveals the exact public registrar and expiry used by the warning. The safety drawer reveals the header grade, security dot text state, mixed-content count, Web Risk availability, and missing policy. Preserve these observations with the domain and check time, then use the focused-tool link for deeper diagnosis.
Step 14
Download result card creates a compact image of the score and leading module states. The printable report preserves the fuller result. These are handoff formats, not proof of health. Review the evidence and point-in-time caveat first, then include the provider-account, monitoring, or focused-tool evidence that can confirm the real condition.
Step 15
Every module uses one of four states. Pass means no implemented error was observed. Needs attention means a warning is present. Errors means a defined adverse condition was observed. Not evaluated means usable evidence was unavailable. Pass scores one hundred, warning sixty, error zero, and not evaluated zero; the five values are averaged transparently.
Step 16
One server request runs the five modules, while each module keeps its own state, summary, and evidence so partial failures stay isolated. The browser calculates the roll-up. Useful features include explicit not-evaluated states, evidence drawers, prefilled focused-tool handoffs, a downloadable result card, and a print-friendly report.
Step 17
This report is not authoritative domain-record evidence, registrar account access, origin discovery, continuous uptime monitoring, a penetration test, or a full safety assessment. A content delivery network can hide the origin, registry data can be redacted, and public dependencies can be unavailable. Use the score to choose the next check, validate findings with the responsible owner, and rerun after the underlying condition changes.
Use the report to choose the next check
Save the exact domain, check time, module states, and evidence with the handoff. Confirm registration in the registrar account, domain records with authoritative providers, hosting with the infrastructure owner, availability with monitoring, and safety with authorized security review. Then rerun the focused check after the underlying issue changes.
Common issues & how to fix them
- Error DNS section failed Fix: Repair the domain’s delegation or authoritative DNS response, then rerun the report after propagation.
- Error Registration status needs attention Fix: Review the flagged RDAP status with the registrar and renew, unlock, or correct registration data as appropriate.
- Warning Origin host is not identified Fix: Confirm the origin using your DNS/CDN configuration or hosting account because public signals do not identify it reliably.
- Error Availability section failed Fix: Restore a reachable HTTPS response at the checked host and resolve any DNS, TLS, timeout, or origin error.
- Error Safety section failed Fix: Investigate the named safety signal, remove compromised or deceptive content, and request review from the relevant provider.