A model deciding whether to cite a page is, among other things, deciding whether the page is what it claims to be. That is not a question about reputation. It is a question about whether the site offers anything a program could check. Check D2 asks for two such things: a way to reach the organisation, and a piece of structured data that points at something outside the site which corroborates it. Four points, Low effort. The second half is where sites go wrong in an interesting way, not by leaving sameAs out but by filling it with a URL nobody ever created.
What D2 measures
D2 is "Verifiable identity", worth 4 of the 25 points in pillar D. The rubric's definition is "A contact page or discoverable contact details, plus Organization schema with sameAs links to at least one social or registry profile." The engine splits that into two halves of two points each.
| Part | Points | What earns it |
|---|---|---|
| Contact discoverable | 2 | A link to a contact, about, impressum or legal path, or any mailto: link, on any fetched page |
| Identity corroborated | 2 | An Organization type in the JSON-LD, and a sameAs with at least one URL |
The evidence block records contactDiscoverable, hasOrganizationSchema and sameAsCount. When the second half fails, the fix text tells you which of its two conditions was missing.
Contact discoverable
The engine joins the raw HTML of every fetched page that returned 200 with a body and runs two tests over it. The first looks for an href whose path contains /contact, /about, /impressum or /legal. The second looks for any href beginning with mailto:. Either one earns the two points.
Three things follow from that. It is a link test, not a page test: the scanner is looking for the route to be reachable from the pages it crawled, not verifying that a contact page exists at the other end. It runs over raw HTML, so a contact link that only appears after JavaScript runs is not seen, which is the same constraint that governs most of the rubric. And mailto: is enough on its own, which is why a footer with an email address passes even on a site with no contact page at all.
Organization schema with sameAs
For each fetched page, the engine parses every <script type="application/ld+json"> block, walks any @graph and every nested object, and collects the @type values it finds. If any of them is Organization, the first condition holds. A block that does not parse as JSON is skipped, so a syntax error in your JSON-LD costs you here as well as under B1.
Then the parsed blocks are stringified and searched for a "sameAs" property. If it is an array, the number of http:// or https:// strings inside it is the count. If it is a single string beginning with a URL, the count is one. The highest count across all pages is kept, and the check wants at least one.
Both conditions have to hold together. An Organization with no sameAs earns nothing for this half, and the report says "Organization schema has no sameAs links" rather than "no Organization schema", so the two failures are distinguishable.
What the engine does not do is fetch the URL. It counts a claim; it does not test it. That is a limit of a pure scoring function that takes a snapshot in and returns a result, and it is also the reason the next section exists.
Why a sameAs that does not resolve is worse than none
The sameAs property, documented on the Organization type page among others, is a URL of a reference page that unambiguously indicates the item's identity. Its entire purpose is to be followed. A scanner that only counts will award the points either way, but anything that actually wants to corroborate you does what the property invites and requests the URL.
Leaving sameAs out is a gap. A model looking for corroboration finds nothing and has to decide without it. Pointing sameAs at a profile that returns a 404 is a different thing: it is a false statement in the one place on the site you chose to make a verifiable one, and it is trivially checkable. A site that says "here is where you can confirm who we are" and is wrong about it has told a program something about its reliability that an absent field never would.
The same applies, less starkly, to a sameAs that resolves to the wrong thing: a profile belonging to a different entity with a similar name, a page that has been reassigned, or the site's own homepage, which corroborates nothing because it is the thing being checked. One link to a profile you control and keep current is worth more than five you have stopped maintaining.
We hold ourselves to this. Our sameAs points at a single LinkedIn company page, and our own build notes treat that page's existence as a blocker for the schema going live, on precisely the grounds above: a claim that does not resolve is not a claim we are prepared to publish.
How we build ours
Our Organization node is produced by one function, organisationSchema(), and emitted inside the @graph on every page. Trimmed to the fields that matter for D2, it looks like this:
{
"@type": "Organization",
"@id": "https://agentfriendlyrank.com/#organization",
"name": "AgentFriendlyRank",
"legalName": "Socio360",
"url": "https://agentfriendlyrank.com",
"email": "hello@agentfriendlyrank.com",
"sameAs": ["https://www.linkedin.com/company/socio360"],
"address": { "@type": "PostalAddress", "addressRegion": "Karnataka", "addressCountry": "IN" },
"contactPoint": { "@type": "ContactPoint", "contactType": "customer support" }
}
The email, the sameAs array and the postal address are read from one site configuration object. The footer reads the same object, so the address printed at the bottom of every page and the address in the schema cannot drift apart, and adding a second profile to sameAs is a one-line change that reaches every template at once. Structured data across templates is the general argument for building it that way.
The contact half is covered twice over. Every page carries a mailto: link in the footer, alongside the legal name, the physical address and a link to /contact, which is a server-rendered form that posts to the same handler as our audit request. The /about page is linked from the same footer. Either route satisfies the test on its own; having both means the check does not depend on which six pages the crawl happened to pick.
The fixes
If contactDiscoverable is false, add a /contact link or a mailto: to the footer, in the server-rendered HTML. That is the whole fix and it takes minutes.
If hasOrganizationSchema is false, add an Organization node to the JSON-LD on every page, with name, url and sameAs. If it is true and sameAsCount is zero, add the array. Choose profiles you control: a company page on a professional network, a registry entry, a verified developer or app-store listing. Before you publish, open each URL in a private browser window and confirm it shows your organisation. Then keep the list short enough that you will notice when one of them stops resolving.
Check your own site
The free scan reports the three D2 fields with the evidence behind each, and you can compare the sameAs it counted against what those URLs actually return. The definition sits with the rest of the trust pillar on the methodology page.