Check D3 does not read your privacy policy. It looks for the link. That distinction decides most of the scores we see on it: the policy exists, a lawyer signed it off, it lives at a sensible URL, and it scores zero because none of the pages the crawler visited link to it. D3 is four points, rated Low effort, and which pages it wants depends on what kind of site you run. This post covers how the scanner decides both, what each policy tells a program, and the footer pattern we use to make the check trivial on every page.
What D3 measures
D3 is "Policies discoverable", worth 4 of the 25 points in pillar D. The rubric's definition is "A linked privacy policy, plus shipping and returns pages for commerce sites or a terms page otherwise." The engine scores it as two halves.
| Site type | Two points for | Two more points for |
|---|---|---|
| E-commerce | A linked privacy policy | A linked shipping page and a linked returns page |
| Everything else | A linked privacy policy | A linked terms page |
The evidence block records hasPrivacy, hasTerms, hasShipping, hasReturns and siteType, all five regardless of which pair was scored, so you can see what the crawl found and which rule it applied.
Discoverable means linked
The engine joins the raw HTML of every fetched page that returned 200 with a body, then runs a substring test over the href attributes it finds. Privacy is an href containing privacy. Shipping is one containing shipping or delivery. Returns is one containing return or refund, singular or plural. Terms is one containing terms, tos or conditions. The match is on the link target, so /privacy, /legal/privacy-policy and /en/privacy-notice all count, and so does an absolute URL to a policy hosted elsewhere.
What the engine does not do is fetch /privacy to see if it exists, guess likely URLs, or read the page it finds. A policy nobody links to is invisible to it, and for practical purposes invisible to any agent that arrives the same way, by following links from a page it was given. Three consequences follow.
The test runs over raw HTML. A footer assembled on the client after hydration is not seen. That is the same constraint as the rest of the rubric, and the reason our own footer is a server component.
The test runs over the pages the crawl reached, which is six at most. A link that appears only on a checkout page or inside an account area does not count. The one place that is guaranteed to be on every page is the footer, which is why the footer is where the check is won.
The test is per policy. For a shop, hasShipping true and hasReturns false earns nothing for the second half, and the fix text says "shipping and returns pages not both linked" so that the missing one is not mistaken for a general failure.
Site type decides the second pair
Which rule applies comes from the siteType the crawler assigned when it fetched the homepage. It is classed as e-commerce if the homepage JSON-LD contains a Product, Offer or OnlineStore type, or if the homepage HTML contains a /cart path, the words "add to cart" or "add to bag", or the strings "shopify" or "woocommerce". Otherwise the homepage is tested for the signals of a software or content site, and anything left is "other". For D3, every non-commerce type is treated the same way: it wants a terms page.
This is worth knowing because the classification can surprise you, and the evidence shows it. A shop whose homepage is a landing page with no product schema and no cart link can be typed "other" and asked for terms rather than shipping and returns. A software company whose homepage mentions its Shopify integration can be typed e-commerce and asked for shipping. Both are visible in the siteType field, and both are fixed the same way: link all four policies, and the classification stops mattering.
What each policy tells a machine
None of this is legal advice, and the engine is not checking whether a policy is adequate. What a privacy notice or a set of terms must contain varies by jurisdiction; a business selling into Singapore and the United States, as we do, is looking at guidance from the PDPC and the FTC respectively, and at whatever applies where it is incorporated. The check is about presence and reachability. But presence matters because each page answers a question a program acting for a person has to ask.
Privacy policy. What is collected, on what basis, and what happens to it. An agent submitting a contact form, an email address or a payment detail on someone's behalf is handing over that person's data, and the policy is the only document that says where it goes. A site with a consent banner and no linked policy is asking the visitor to agree to something it has not stated, which is why cookie walls and D3 tend to fail together: the wall is an interstitial under A6, and the missing link is a gap under D3.
Terms. Who the contract is with, under which law, and what is actually being provided. The legal entity named in the terms is also the thing the Organization schema claims to be, so terms and verifiable identity corroborate each other: a legalName in the JSON-LD that matches the party named in the terms is two independent statements agreeing.
Shipping. Whether the shop delivers to the buyer's country, in how long, and at what cost. For an agent asked to buy something, this is the first question, and it has to be answered before anything is added to a basket. A shop that only reveals shipping options at checkout has hidden the answer behind the very steps the agent is trying to decide whether to take.
Returns. The second question. A purchase an agent cannot undo is a purchase it should be reluctant to make, and the returns page is where the conditions live.
Terms, shipping and returns are all, in the end, the same kind of signal as a sameAs link: a machine-checkable statement about who is behind the site and what it commits to. Their absence does not prove anything bad. Their presence, linked from every page, removes a reason to prefer a competitor that has them.
Our footer as the pattern
Every page on this site ends with the same server-rendered footer. Its legal column links /privacy, /terms and /dpa, and its company column links /contact. The links come from one navigation object in the site configuration, so a new page gets them without anyone remembering to add them. Reduced to its structure, the relevant part is:
<footer>
<nav aria-label="Legal">
<ul>
<li><a href="/privacy">Privacy</a></li>
<li><a href="/terms">Terms</a></li>
<li><a href="/dpa">Data processing</a></li>
</ul>
</nav>
<address>
AgentFriendlyRank is a service of Socio360 …
<a href="mailto:…">…</a>
</address>
</footer>
The /dpa link is not scored by D3. It is there because customers processing personal data through us ask for it, and because a policy that a prospect would otherwise have to email us for is, by the rubric's own logic, not discoverable. The address element and the mailto: are for D2, and sit in the same block because the two checks are asking neighbouring questions.
We are not a shop, so the crawler types us as something other than e-commerce and looks for terms. If we ever sold a physical product, the same footer would gain shipping and returns links and nothing else would change.
The fix
If hasPrivacy is false, link the policy from the footer, in the server-rendered HTML, with privacy somewhere in the URL. If the second half is false, do the same for terms, or for shipping and returns, depending on the siteType the evidence shows. If you have all four pages, link all four; the classification then has nothing to get wrong. Where a policy does not yet exist, writing it is a matter for whoever advises you on the jurisdictions you sell into, and no scanner can tell you what it should say.
Check your own site
The free scan reports the five D3 fields and the site type it assigned, so a surprising classification is visible rather than silent. The definition sits with the rest of the trust pillar on the methodology page.