Proving You're Real

The short version

Guide 1 introduced five things AI systems check before they trust a business, including identity clarity (one consistent description of you, everywhere) and ecosystem validation (other sources independently confirming what you say about yourself). This guide is the deep dive on those two: the actual mechanics of building an identity an AI system can verify, not just read.

The short version of the mechanics: schema declares, corroboration convinces. Putting Person markup on your about page tells a machine who you claim to be. It doesn't tell the machine you're telling the truth. That comes from an independent record — a business registry, a professional profile, a press mention, a credential from a real issuing body — that says the same thing your site says, in a place you don't control. One voice describing itself is a claim. Several independent voices repeating the same facts is evidence.

This tracks the ranking from Guide 1 directly: mentions beat backlinks, backlinks beat schema. Schema is table stakes — get it right once and move on. The corroborating graph around it is the actual lever.

---

Why "the person is the hub, not the website"

Search and AI systems increasingly don't resolve web pages in isolation — they resolve entities: people, organisations, and the works they've produced. A page is evidence for an entity, not the entity itself. That reframing changes what you build first.

Four ideas follow from it, and they're worth holding onto before you touch any schema:

• The named person is the anchor, not the brand. A business is more easily faked than a specific human with a checkable history. If you (or a named expert on your team) has one canonical profile page — one stable identity everything else points back to — the business inherits that person's verifiability.
• One fact-set, everywhere. Name, title, dates, credentials, employer history — identical across your site, LinkedIn, any directory listing, any bio you've supplied elsewhere. Wording can vary by context; the underlying facts cannot. Every discrepancy is friction a machine has to resolve, and uncertain machines default to not citing you.
• Evidence, not adjectives. "20 years of experience" is a claim anyone can type. A registry record, a published paper with a DOI, a speaker page from a named conference, a employer's own staff page — those are checkable. Treat a bio as an evidence repository, not a brochure.
• Scarcity keeps the signal meaningful. Put a named reviewer's byline on the pages where their credential is genuinely exact — not on everything you publish. A name on every page reads as decoration; a name on the right pages reads as editorial judgement.

---

The seven-layer model (formal label: the entity graph)

This is the full shape of what "proving you're real" actually requires, end to end. Not all seven layers need building on day one — see the sequencing at the end of this guide — but knowing the whole shape stops you from mistaking "I added schema" for "I'm done."

1. Person entity. One canonical profile page per named person you want an AI system to trust — full bio, photo, credentials, a dated career history, links to verifiable evidence. This page carries a permanent identifier (see below) that every other mention of that person references back to. This is the anchor everything else corroborates.
2. Organisation graph. Machines resolve people partly through the organisations they're attached to. Declare the chain explicitly: person → founder/employee of → organisation → the sites or products that organisation operates. A registered business number on the organisation node makes the chain checkable, not asserted.
3. Publication graph. Every piece of content declares its people by reference — author, reviewedBy — pointing at the person's canonical identifier, not just a name in plain text. Named, defined roles (written by / reviewed by / published by) bind many pages to a handful of trusted, verified entities instead of leaving each page to fend for itself.
4. Evidence graph. The proof stack linked from the profile: published research, press coverage, speaking engagements, registry records, credentials with their issuing bodies named. This is what shows built, launched, advised, published, tested — not what a bio merely claims.
5. Relationship graph. The edges between entities, declared explicitly in schema rather than left for a machine to infer: employer, founder, occupation history, credentials held, areas of expertise, memberships. An undeclared relationship forces a guess; a guess an AI system isn't confident in doesn't get used.
6. Technical layer. One unified structured-data block per canonical page, with every property cross-referenced by the same identifier. Server-rendered HTML, because most AI crawlers don't execute JavaScript — content that only appears after client-side rendering may as well not exist to them. Clean sitemaps and canonical URLs so there's no ambiguity about which page is authoritative.
7. Ecosystem reinforcement. Independent sources repeating the same facts — professional network profiles, an official registry, press bylines, directories, a verified business listing, and eventually Wikidata once the groundwork exists. The goal is a closed loop: your profile links out to an external, independent source, and ideally that source links back.

---

The building block: one identifier, frozen forever (formal label: the canonical @id)

Every layer above only holds together if every reference to a given person or organisation uses the exact same identifier, called an @id in schema.org markup. Pick the format once and never change it once it's live — changing an @id after the fact resets whatever trust an AI system had already built around it, because as far as the machine can tell, the old entity vanished and a new one appeared.

A workable convention:

https://www.yoursite.com/team/<slug>/#person

Use the resolvable canonical form consistently (decide once whether that's www or not, and 301-redirect the other) and keep it stable even if the page's visible URL structure changes later.

---

Copy-paste schema templates

These are genuinely reusable — adapt the names, drop in your own facts, and the structure holds. This is a worked example for a fictional business, Larkspur Bookkeeping, and its founder, Maya Torres.

Hub template — the unified structured-data block on the canonical profile page:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://www.larkspurbooks.com/team/maya-torres/#person",
      "name": "Maya Torres",
      "description": "Bookkeeping and small-business finance specialist; formerly Senior Bookkeeper at a regional accounting firm. 15+ years in small-business finance. Founder of Larkspur Bookkeeping.",
      "url": "https://www.larkspurbooks.com/team/maya-torres/",
      "image": "https://www.larkspurbooks.com/img/maya-torres.jpg",
      "worksFor": {
        "@type": "Organization",
        "name": "Larkspur Bookkeeping",
        "url": "https://www.larkspurbooks.com/"
      },
      "hasOccupation": [
        { "@type": "Occupation", "name": "Founder, Larkspur Bookkeeping" },
        { "@type": "Occupation", "name": "Senior Bookkeeper, [Prior Employer]" }
      ],
      "knowsAbout": ["Small-business bookkeeping", "Cash-flow forecasting", "VAT compliance"],
      "sameAs": [
        "https://www.linkedin.com/in/mayatorres-example/",
        "https://www.larkspurbooks.com/"
      ]
    },
    {
      "@type": "ProfilePage",
      "@id": "https://www.larkspurbooks.com/team/maya-torres/#profilepage",
      "mainEntity": { "@id": "https://www.larkspurbooks.com/team/maya-torres/#person" }
    },
    {
      "@type": "Organization",
      "@id": "https://www.larkspurbooks.com/#organization",
      "name": "Larkspur Bookkeeping",
      "url": "https://www.larkspurbooks.com/"
    }
  ]
}

Spoke template — on every article this person writes or reviews elsewhere on the site:

"reviewedBy": { "@id": "https://www.larkspurbooks.com/team/maya-torres/#person" }

Pair it with a compact, local Person node carrying the same @id, name, url and sameAs values, so the reference resolves correctly even for a crawler that only reads that one page.

sameAs hygiene: keep the list short and high-authority — a professional network profile, an official registry record, the person's own company site, a genuine speaker page, Wikidata once it exists. Don't pad it with directory listings or anything scraped. A curated sameAs list binds the identity together; a padded one dilutes it, and a link to a dead or hijacked page is actively worse than no link at all — check the destinations periodically.

---

Making the "reviewed by" claim checkable (formal label: editorial roles)

"Expert" is a claim. "Reviewer" is a role a machine can verify actually happened, if you back it with a real, named responsibility and a policy page that explains what the role means.

A disclosure template you can adapt per site:

[Reviewer Name] provides independent reviews of [Site]'s [topic] content.
They are not an employee of [Site]. Reviews draw on [X years] in [field],
including [named credentials or prior roles]. The editorial team retains
control of the final content.

This needs somewhere to point. Any "reviewed by" claim and any publishingPrinciples schema property is only as credible as the editorial-policy page it links to — a page explaining who reviews what, and why. If that page doesn't exist yet, build it before rolling bylines out further; a byline that references a broken or missing policy page is a red flag, not a trust signal.

Byline scarcity applies here too. Put a reviewer's name on the pages where their credential is genuinely exact, not site-wide. Past employers belong in the bio as career history, not as an implied endorsement from that employer.

---

Same graph, different doors — how each engine verifies you

The underlying graph doesn't change per platform. What changes is which corroborating path each one actually walks to check your claims.

---

Wikidata: the universal anchor, built deliberately last

Every major engine consumes Wikidata in some form, which makes it the single strongest sameAs target available — and also the easiest one to damage if you move too early. Wikidata items without independent references get flagged or deleted, and deleting and recreating an item breaks whatever resolution had built up around it. So this is sequenced last, after the supporting evidence already exists elsewhere.

Sequencing rule: anchor any real published work with a persistent identifier first, earn independent mentions second, and only then create the Wikidata item — with every statement in it backed by a reference, not left bare. For any additional named person you're building an identity for, the same order applies: their item waits until their profile, media links, and reviewer role (if any) are already live and independently citable. A thin, unreferenced item is worse than no item.

---

Onboarding a new named expert or reviewer — the sequence

If you're adding a named person to your site as an author or reviewer (not just yourself), this is the order that actually works. Skipping steps to get a byline live faster tends to produce exactly the inconsistency that undermines the whole exercise.

1. Verify the footprint first. Real, checkable credentials: a professional network profile, a registry record if they run their own business, a speaker page, press mentions. If none of it holds up to a five-minute check, stop — a decorative byline is worse than none.
2. Have the consent conversation. Be plain about what you're asking for: a named bio, a photo, links to their own profiles, and their agreement to genuinely review the content that will carry their name — not just lend their name to it.
3. Agree one canonical fact-set before publishing anything. One job title, one base bio, exact dates and organisation names. The facts need to be identical everywhere this person appears — their own site, their professional profile, your pages, Wikidata later. The wording can flex by context; the facts can't. Reconcile any existing mismatch (their LinkedIn says something different to what you're about to publish) before you go live, not after.
4. Build the canonical hub page. Bio, photo, dated career timeline, credentials with named issuers, links to real evidence, the unified structured-data block with a frozen @id, a curated sameAs list. Get their sign-off before it goes live.
5. Add scoped bylines, not a site-wide rollout. A lightweight on-site profile plus "reviewed by" only on the pages where their credential is exact, with reviewedBy schema referencing the canonical @id. Confirm the editorial-policy page for that site is live and linked.
6. Close the loop from their side. Get the reverse edge — a link from their own site or professional profile back to the page you've built for them. This single reverse link is often the strongest verification signal in the whole sequence, because it's evidence you don't control.
7. Grow the evidence graph over time. Keep a media/mentions section current, add speaking engagements or published research as they happen. Evidence density is what gets cited; a profile built once and never touched again starts to look, and eventually reads to a machine, like it was abandoned.
8. Add Wikidata only once steps 4–7 have given the item something to reference. Not before.
9. Check it periodically. Links go dead, employers change, schema drifts out of sync with the bio. A stale graph reads as an abandoned one — put a standing reminder in your own calendar to re-check every named profile a few times a year.

---

The mindset shift underneath all of this

The goal isn't "get ranked." It's "become verifiable." Build the graph — the person, the organisation, the evidence, the relationships, the closed loop back from an independent source — and citations follow as a side effect of a machine being confident in you, not something you can chase directly by adding more markup.

---

Where to go next

This guide covered the mechanics of proving a business or the people behind it are real and checkable — the schema, the identifiers, the corroborating graph, engine-by-engine. Guide 6 covers where your brand actually needs to show up across the web for that graph to have anything to point at.

---