METHODOLOGY
How a reading is taken
Everything this site claims about a domain should be checkable by the person it describes. This page states what is measured, exactly what goes on the wire, what the scan cannot establish, and how long anything is kept.
What each family measures
- Site securityCollected, deliberately ungraded
Public DNS records and what the server volunteers in its own handshake and its own redirect. Every observation is reported as evidence with a provisional label - ok, warn, risk, or indeterminate. There is no failing verdict in this family and none can exist: no threshold has been measured against real domains, so the block carries a score weight of zero and reaches the scorer not at all.
- Agent readinessGraded, 30 checks
Five weighted categories. A pass earns full weight, a warn earns half, and a category that could not be measured leaves the denominator entirely rather than counting against the store. Grades follow fixed thresholds, so the same report always produces the same letter.
- Skill and MCP supply chainNot measured
Nothing in the engine implements this family. It has no module, no check and no finding, so a scan returns no grade for it and the dial reads as a slate dash rather than a low score.
The graded family, by category
- Discovery6
- Crawl access10
- Product schema7
- Merchant data4
- Content quality3
What a scan sends
We read public DNS and public responses. Nothing is probed - no port range is swept, no path is guessed, no payload is sent, and no attempt is made to authenticate as anyone.
That sentence needs its qualifier, so here it is. The DNS half sends the domain nothing whatsoever: it asks resolvers questions about the domain. The rest does connect - to ports 443 and 80, the two a browser connects to - and reads what the server offers unprompted. Speaking to a service a host publishes is not the same act as discovering what a host runs, and the whole list is below rather than summarised.
- To public DNS resolvers, about the domain
TXT lookups for SPF, DMARC, MTA-STS and TLS-RPT, a CAA lookup, and one TXT lookup per common DKIM selector. These ask a resolver a question about the domain. The domain receives nothing and learns nothing.
- To a third-party DoH resolver
One HTTPS request for the DNSKEY record, to establish whether the zone is signed. It goes to a public recursive resolver we do not control, never to the scanned domain.
- To the domain, port 443
Two TLS handshakes - the apex and its www form. Each reads the certificate the server itself presents, then closes. No application data is ever written to those sockets.
- To the domain, port 80
One GET of the site root, to see whether plain HTTP redirects to HTTPS. The root only, and the redirect is not followed.
- To the domain, for agent readiness
The homepage; robots.txt, llms.txt, llms-full.txt, agents.md and the UCP manifest; the sitemap one level deep; up to 5 product pages and up to 3 policy pages found from it. All ordinary GETs of published URLs, identified as SextantBot, 3 of them repeated to time the homepage.
- For security headers and cookies
Nothing at all. Both are read from responses the scan had already received for the reasons above.
Passive only, and why that is a line
Every scan reads what a public response or a public DNS record already returns. No path guessing, no port scanning, no injection payloads, no authentication attempts - against any domain, including ones that have asked for a scan.
This is not a preference that could be traded for better coverage. Actively probing a system you do not own is the thing computer-misuse law is about, and consent to be scanned is not something a form on our site can establish on behalf of whoever actually operates the domain. Reading what a server publishes to everyone needs no permission; anything past that needs permission we are not in a position to have. So the engine is built so the interesting-but-active checks are not available to be switched on in a hurry.
A report is evidence of what could be seen from outside at one moment. It is never certification, and nothing here asserts that a site is secure or compliant.
What a scan cannot establish
Each of these is a place where not finding something could be mistaken for the thing not being there. The engine refuses that step, and so does this page.
A missing DKIM key does not mean the domain does not sign.
Selectors are not discoverable: a signing domain can use any name it likes. The scan probes a list of common ones, so a miss is what that list did not find, and the finding is worded that way rather than as an absence.
An announced MTA-STS policy is not proof of a served policy.
The announcement lives in DNS; the policy itself is a file on a host. Fetching it would mean making a request to the domain, which this block does not do, so the announcement is reported as an announcement and nothing is claimed about the file behind it.
TLS 1.0 and 1.1 support cannot be established at all.
The runtime this scanner uses is built against a TLS library that will not offer those versions, so a probe for them cannot distinguish a server that refuses from a client that never asked. Rather than report a refusal we did not observe, the probe is off and the result is indeterminate.
Site security is not graded, and no grade should be inferred from its findings.
No threshold has been measured across real domains, so there is no defensible line between a pass and a fail. The block carries a score weight of zero as data, not as a comment, and a test asserts the scorer cannot consume it even if handed it directly.
A store that renders only in the browser scores badly, and that is the finding.
No JavaScript is executed. An agent arriving without a browser sees what this scan sees, so a catalogue that exists only after hydration is genuinely invisible to it.
A reading describes one moment, from outside, of what was published.
Nothing behind a login is visible, no session is established, and no part of the scan sees more than a member of the public could. A later change can invalidate any finding without notice.
What is kept, and for how long
These windows are rendered from the constants the retention sweep actually runs on - the same source the privacy policy uses - so this page cannot promise a window the job does not enforce.
- A free scan90 days
Then it is anonymised: scores, grades and check results are kept, and everything naming the store or quoting its pages is removed. The URL is cleared, so after this the record cannot be matched to a domain at all.
- A scan behind an embedded badge30 days
A badge that has been loaded within this window keeps its scan out of anonymisation. A badge is the only signal available that an embed is still live, so recency of use is what holds the reading open - and only genuine, non-refused loads count.
- An enquiry sent through the site12 months
Then the person is removed and the fact of the enquiry is kept.
- A report emailed on request90 days
The subscribing address is cleared on the same clock as the scan it belongs to.
A profile page is a permanent route over impermanent data. When a domain's scans age out, the page stops showing a reading and becomes an offer to take a new one. It does not mean the domain failed anything, and nothing about the page extends the retention window that emptied it.
Check it
Every family page states the same limits in its own terms, and the directory shows only what this policy allows to be public.