The fourth pillar of the rubric asks one question, in exactly these words: should an agent, or the model behind it, trust and cite this site? It is the pillar people most expect to be soft, because "trust" sounds like reputation, and reputation is not something a crawler can measure. The premise of the pillar is that this is the wrong reading. The question an agent faces when it decides whether to cite a page is a question about provenance, and provenance is checkable. Each of the seven D checks is a file, a header or a field that either exists or does not.
This post sets out that logic and walks through the seven checks as a set. The individual posts, linked below, cover each in depth; this one is about why they belong together.
Provenance, not reputation
When a model has fetched a page and is deciding whether to lean on it, the questions that can be answered from the page itself are narrow. Was it served securely? Is there a named organisation behind it, and does that organisation exist anywhere else? Does it say what it does with your data? Has it been touched recently? Does it call itself the same thing everywhere? Is there a way to report a problem? Does the rest of the site behave like this page?
None of those is a question about whether the site is good, well known or widely linked. They are questions about whether the page is what it claims to be, and about whether the claim is corroborated by something other than the page. That is what provenance means, and it is why the pillar can be scored without judgement: every answer is a fact captured during the crawl and recorded in the evidence block.
It follows that the pillar is deliberately blind to some things. It does not count backlinks, read review scores, look up domain age, or weigh brand. A site with no reputation at all can score 25, and a household name can score poorly, because the pillar measures whether the site has published the signals, not whether the world has noticed it.
The seven checks as a set
Together the checks are worth 25 points. This is what each one proves, in the sense of what a passing result allows an agent to conclude.
| Check | Points | Effort | What a pass establishes |
|---|---|---|---|
| D1 Transport security | 4 | Low | The page arrived intact and over a channel that could not be quietly downgraded |
| D2 Verifiable identity | 4 | Low | There is a way to reach the operator, and the organisation exists on at least one other site |
| D3 Policies discoverable | 4 | Low | The site states its terms, and for commerce, how it ships and takes things back |
| D4 Freshness signals | 4 | Medium | Someone is still maintaining it, and the pages say when they changed |
| D5 Identity consistency | 3 | Low | The site calls itself one thing, and its icon and preview image resolve |
| D6 security.txt | 2 | Low | There is a named channel for reporting a problem, and it has not lapsed |
| D7 Multi-page stability | 4 | Medium | The rest of the site behaves like the page the agent is reading |
The order matters less than the shape. D1 is about the channel. D2, D3, D5 and D6 are about the organisation: who they are, what they promise, whether they say the same thing twice, and how to reach them when something is wrong. D4 and D7 are about time and consistency, which are the two properties a single fetch cannot establish on its own.
HSTS in one header covers D1. Verifiable identity covers D2. Which policies an agent looks for covers D3. Freshness signals covers D4. Identity consistency covers D5. security.txt in ten minutes covers D6, and Multi-page stability covers D7.
Where the points sit
Five of the seven checks carry a Low effort rating, and between them they are worth 17 of the pillar's 25 points. The remaining eight points, D4 and D7, are rated Medium, and both are Medium for the same reason: they cannot be fixed on a single page. Freshness needs a sitemap with honest lastmod values and a fifth of its URLs touched in the last 90 days, and stability needs every crawled page to be built from the same template and to answer within four seconds.
This makes the trust pillar the cheapest of the four to move. A header, a policy link, a sameAs array, a text file and a consistent site name are each an afternoon's work, and none of them requires an engineer to touch the rendering pipeline. Where the discovery pillar can hinge on a CDN default and the actionability pillar on architecture, most of D is configuration and content.
It is also, for the same reason, the pillar most often left half-done. The checks are small, none is a launch blocker, and each is the sort of thing that gets a ticket and never a sprint.
Why a fact and not a judgement
We could have scored trust the way a reviewer would, reading the about page and deciding whether the company seems real. We did not, for the reason set out in why we publish the rubric: a score nobody can reproduce is an opinion. Every D check can be re-run by anyone with curl and the methodology page, and every result carries the evidence it was based on. If we say a site has no Organization schema with a sameAs, the report shows the count we found. If we say the security.txt has expired, the report shows the date we parsed.
This is also why the pillar makes no claim about what any particular model does with these signals. The rubric's bet is that provenance is what a model can reasonably weigh when deciding what to cite, and that a site which has published all seven signals has given it every reason it can be given. Whether a given product weights HSTS above lastmod is not something the rubric knows or pretends to.
What the pillar cannot tell you
Two limits are worth being clear about.
The first is that a signal can be present and wrong. A sameAs can point at the right kind of profile that belongs to someone else. A privacy policy can be linked and say nothing. A lastmod can be regenerated on every build regardless of whether the page changed. The free scan checks that the signal exists and is well formed; it does not read the policy or follow the profile. That is what the paid audit is for, where a person reads the templates rather than inferring them.
The second is that a signal that is present today may be gone tomorrow. Most trust signals decay silently: a header dropped by a proxy change, an Expires date that passes, a sitemap that stops being regenerated. Nothing in a browser reveals any of these. The pillar can only report what it saw on the day, which is the argument for scanning more than once.
Check your own site
Run the free scan and read the seven D blocks together. Each records the specific file, header or field it looked for and what it found, so the fix for a low score is usually visible in the evidence. The full pillar definition is on the methodology page.