Anyone Can Claim It: hasCredential vs Third-Party Verification, the Dividing Line for AI Trust

One-line conclusion: schema.org's hasCredential can turn "we are certified" into machine-parseable structured data, but anyone can write any certification into their own JSON-LD, so "self-declared" is only a claim. What actually turns a claim into a fact is a third-party verification page that lives on the issuer's domain, requires no login, can be checked in real time, and reflects revocation. This article shows you how to close that gap.

Run a small experiment first. Open the source of any website and find the <script type="application/ld+json"> block. Every word in it was placed there by that site's own owner, including "this company is certified by so-and-so" and "winner of such-and-such award." No technical mechanism checks whether any of it is true before you hit save. That is the core problem this article addresses: when the cost of self-assertion approaches zero, what do AI and search engines use to decide whom to trust?

1. The one-line answer: the gap between claim and fact is whether it can be re-checked

The difference is not what you wrote, but whether someone else can check it. Self-declared schema is a lone assertion: the source and the claimant are the same party. A third-party verifiable endorsement is cross-evidence: an issuer (another verifiable entity), on its own domain, using a page anyone can open, vouches for your identity and qualification. To any system doing cross-verification, those are two entirely different classes of signal.

This principle is not an AI-era invention. Google's quality-rating framework has consistently held that authority and trustworthiness come from "what others say about you" — off-site, independent reputation — not from what you declare on your own page^[3]. Google's Search Liaison has even said plainly that adding an author byline by itself will not help you rank better^[4]. AI answer engines face the same problem when picking which sources to cite: the web is full of pages that call themselves authoritative, so what an engine needs is a re-checkable chain of evidence, not a louder self-introduction.

2. What hasCredential is: turning "we are certified" into one machine-readable line

hasCredential is a property schema.org defines on Person and Organization, whose value is an EducationalOccupationalCredential. It can describe the certification name, its category, and most critically recognizedBy — who recognizes or issued the credential^[1][2].

A minimal usable example looks like this:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company Ltd.",
  "url": "https://example.com",
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "name": "Verified Partner Certification",
    "credentialCategory": "certification",
    "recognizedBy": {
      "@type": "Organization",
      "name": "Issuer Organization Name",
      "url": "https://issuer.example"
    }
  }
}

Its value is disambiguation and parseability: a sentence buried deep in an "About us" page saying "this company is certified" leaves the machine to guess; a structured hasCredential lets the machine read out directly "who holds what certification, issued by whom." This is the correct syntax for wiring a certification fact into the knowledge graph.

3. The uncomfortable truth: self-declared schema takes five minutes to forge

That JSON-LD above can be copy-pasted by anyone who swaps the name, and in five minutes they "hold" any certification. No signature, no check, no gatekeeper. This is not a flaw in schema.org — it was only ever a description syntax, not a verification mechanism. The flaw is in treating "written down" as "proven."

The implication is direct: if self-declared schema alone could establish trust, that trust would have inflated to worthlessness long ago. In practice, any system that does cross-verification — whether Google's rating mechanism or an AI engine picking citation sources — must discount information that "only the claimant says." You can fill your entire JSON-LD with awards, certifications, and memberships, but when those claims have no matching evidence anywhere else on the web — the issuer has no such page, the names do not match, the institution itself is a phantom — they are just noise.

Self-declared schema: "We hold certification X." — source = the claimant, cost = five minutes, credibility = discounted.

Third-party verifiable endorsement: "The issuer has a page on its own domain stating: we reviewed this company, the certificate is currently valid, and you can check any time." — source = independent entity, re-checkable, revocable, cross-comparable.

So the right question is not "is my schema written beautifully enough," but: "when someone takes my claim and tries to verify it, can they find it?"

4. The dividing line: issuer, subject, and a publicly checkable URL

Upgrading a "claim" to a "verifiable endorsement" requires three conditions to hold at once: a clear and self-verifiable issuer, a clear and matching subject, and a public verification endpoint that reflects live status. Miss any one and the evidence chain breaks.

Note the detail in the third requirement that is easiest to overlook: revocation must be reflected. A verification page that permanently shows "valid" is about as good as no verification page — it only proves "this was once issued," not "this is still valid now." A trustworthy verification endpoint must read live review status: if the issuer revokes today, the page must change today.

Wire the three requirements back into schema: the recognizedBy inside your hasCredential should point to the issuer's real URL, and the issuer's verification page should in turn state that you are the subject. The two ends point at each other, the names match, and only then does cross-verification actually work. This aligns with what we argued in Why Certified Brands Get Cited by AI: AI citations concentrate on entities that are "recognizable, matchable, and trustworthy."

5. What a trustworthy verification page looks like (with a counter-example)

A verification page is, in essence, the issuer's public window for checking. It should let a first-time stranger (or a crawler that does not run JavaScript) confirm on a single page: who issued the certificate, to whom, at what level, and whether it is currently valid.

A common counter-example: putting a "certification badge" image in your own site footer that links nowhere, or links to the issuer's homepage (rather than a verification page for your specific certificate). This approach misses all three requirements: the checker cannot find the issuer's specific endorsement of you, cannot match the subject, and cannot look up live status. The badge itself is not the problem — the absence of a re-checkable endpoint is.

6. How we do it: our public verification center and 3 certified companies (the honest version)

We built our own certification system to the three requirements above. The issuer is Chengtong Digital / TrueLink (registered legal entity: Chengtong Zhihui Co., Ltd.); the verification window is no-login, read-only, and public; credential data is generated from real review status, not self-reported.

Concretely, readers can open and check these right now:

• Public verification center (/verify/) — no login, read-only; anyone can verify a credential's authenticity and validity status.
• Certified directory (/directory/) — lists companies that passed KYC identity review, each entry corresponding to a real review record.
• hasCredential is generated from review status — a certified company's hasCredential data is built from our real review results (review level, review time); the issuer field says TrueLink, not filled in by the company itself; once a certification is revoked, it no longer shows as valid.

This is also why we treat "the issuer must be self-verifiable" so seriously: TrueLink's own organization info, registration number, and sameAs are all public and matching. The weight of a third-party endorsement ultimately depends on the third party's own verifiability — an issuer that is itself a phantom can issue a thousand certificates worth zero.

7. Three things you can do today