The Entity Authority Checklist

ClickRadius Institute · Published July 6, 2026

This checklist consolidates identity, source, authorship, reputation-evidence, content, and measurement controls into one working document. It does not assume Google AI Mode is a universal default, convert volatile industry estimates into client facts, or claim that completing the list makes an external engine name a business. Use it to produce inspectable records and comparable observations; providers retain control of crawling, indexing, retrieval, ranking, recommendation, and citation.

Two quotes frame why every item below exists. The architectural one:

"We've been working on an intelligent model — in geek-speak, a 'graph' — that understands real-world entities and their relationships to one another: things, not strings."

— Amit Singhal, then SVP of Search at Google, introducing the Knowledge Graph (2012)

And the evaluative one:

"Trust is the most important member of the E-E-A-T family because untrustworthy pages have low E-E-A-T no matter how Experienced, Expert, or Authoritative they may seem."

— Google Search Quality Rater Guidelines

The quotations provide historical and quality-evaluation context. They do not disclose a current ranking function, cross-provider trust score, or guaranteed effect for any check below.

Section 1: Foundation (checks 1–5)

1. Canonical fact sheet exists — one governed record with the applicable public name, legal name, address, phone, URL, category, founding date, founders, service list, geography, descriptions, source, owner, and review date. Later publication decisions use it as the approved internal reference while preserving legitimate source-specific formats. (Playbook, step 1)
2. Canonical public name and aliases recorded. Preserve legal names, brands, prior names, abbreviations, and platform-specific forms; correct false identity rather than erasing legitimate variance.
3. Entity home designated — homepage or About page that states in plain visible text who you are, what you do, whom you serve, where.
4. The entity home says it in the first paragraph — resolvable language, not slogans. "Powering tomorrow's growth" resolves to nothing.
5. A named owner for entity facts — one person accountable for every propagation when facts change.

Section 2: Declaration (checks 6–12)

6. Applicable entity JSON-LD on the entity home — select Organization, LocalBusiness, or another valid type from the real entity and intended consumer, then include only supported, applicable facts from the approved record.
7. Stable @id for recurring entities, with the applicable page-visible and provider-required facts included in each document that needs them. An identifier preserves identity; it does not guarantee remote property import or freshness. (sameAs guide)
8. Curated sameAs array — every URL passes the test: does this page unambiguously identify exactly this entity? Platform profiles, knowledge bases, authoritative directories, registries. No category pages, no dead profiles, no namesakes.
9. Identity references reviewed — each sameAs destination names the exact subject and remains stable. A backlink is useful provenance when present but is not required by the vocabulary and does not convert an assertion into independent evidence.
10. Markup matches the visible page — no JSON-LD asserting facts the page no longer shows.
11. Article schema where applicable, with author and publisher relationships that reference the actual documented people or organizations rather than a fabricated default.
12. Structured data checks are separated — parse syntax, validate vocabulary domains/ranges, compare visible factual parity, test the exact provider feature, and record public output. One green validator does not prove the other states.

Section 3: Corroboration (checks 13–21)

13. Google Business Profile reviewed against approved facts — exact subject, applicable category, current contact details and hours, with edit authority and public reread retained. Do not write a description as a promised AI answer. (GBP guide)
14. Bing Places and Apple Business Connect reviewed where relevant — record exact subject, fields, authority, submission, provider response, and public reread separately.
15. Applicable horizontal directories (for example Yelp, BBB, or national peers) — classify current, stale, conflicting, unavailable, not applicable, or unresolved rather than assuming universal coverage.
16. Relevant industry sources identified by claim — licensing boards for licenses, associations for membership, and directories for their own listings. A sampled engine citation is an observation for that prompt and run, not proof of universal source use. (Directory guide)
17. Relevant data aggregators reviewed — correct an authorized source when retained evidence shows the exact defect; observe downstream propagation instead of assuming a fixed wholesale-to-retail path.
18. Stale-data review recorded — search known old addresses, phones, and names; classify each result as exact subject/current, exact subject/stale, historical context, namesake, unavailable, or unresolved. Correct what the source owner permits and retain the outcome. (NAP guide)
19. Potential duplicates assessed — merge only when subject identity, edit authority, and platform policy support it; retain the provider result and treat review migration as unknown until observed.
20. Knowledge-base presence where eligible — Wikidata item with neutral description, referenced statements, external identifiers, and official-website loop; Wikipedia only if you genuinely clear notability. (Wikidata guide)
21. Substantive-conflict audit — classify every reviewed relevant source by subject, claim, date, and authority. Formatting variance can be legitimate; known factual conflicts and unreviewed or unavailable sources remain explicit.

Section 4: People (checks 22–27)

22. Responsible-person inventory done — record people whose authorship, review, role, or credential is actually claimed; preserve aliases and reconcile legacy bylines to the correct person. (Author entities)
23. Real bylines on every substantive page — "Admin" retired.
24. Author pages as entity homes — bio with checkable facts (degrees, licenses, years, work), photo, full article list, stable URL.
25. Person JSON-LD where applicable — publish only verified roles and relationships; use sameAs for exact identity, not as proof of credentials or expertise.
26. Person references reconciled — check whether employer, registry, speaker, and profile records describe the same person, with control and credential authority tracked separately. Reciprocal links are not a universal requirement.
27. External appearances recorded — preserve the exact podcast, panel, or press statement, its publisher, subject, date, and control. Publication is observable; later retrieval or use by an engine is separate.

Section 5: Reputation and mentions (checks 28–33)

28. Systematic, policy-compliant review cadence — no gating, prohibited incentives, fabrication, or unsupported testimonial claims; retain the exact platform and governing policy.
29. Owner-response policy documented — define responsible owners, review-platform rules, escalation needs, and evidence dates rather than promising one universal response window.
30. Observed retrieval map maintained — retain the exact query, engine/provider/model, mode, answer, cited source, date, and missing/error state. Set reread cadence by volatility and risk; a sampled source is not universally preferred.
31. Legitimate presence considered on relevant surfaces — record what each published page actually says and whether the subject controls it; do not promise later engine retrieval or use. (Mentions vs backlinks)
32. Approved facts used wherever you control copy — adapt format and length to the platform while preserving the same subject and substantive facts.
33. Mention evidence over link count — record what the page actually says, who controls it, which subject it describes, and whether it is independent; do not infer provider use from the link alone.

Section 6: Citable content (checks 34–37)

34. Quantitative claims supported where relevant — use real denominators, dates, methods, and limitations. The GEO study reports effects in its experimental benchmark; it is not a universal provider ranking contract.
35. Attributed quotations — verified wording, named speaker, source, date, and scope; use semantic HTML for readers, not as a parser guarantee.
36. Exact source citations — material factual claims link to the primary or otherwise authoritative source that supports that exact claim.
37. First-hand specificity — distinguish observed facts, participant reports, calculations, estimates, and unresolved questions. Provider selection remains separately measured. (E-E-A-T guide)

Section 7: Monitoring (checks 38–40)

38. Monthly answer-layer testing — ask ChatGPT, Gemini, Perplexity, Claude, and Grok a fixed identified question set. Retain answer, time, engine/provider/model, retrieval mode and sources, matching rule, presence/citation components, missing/error state, and tone only where measurable. Factual accuracy requires a separate dated reference and review.
39. Wrong answers classified before action — use attributed-source when a retained source supports the wrong statement; conflicting-source when retained sources disagree; retrieval-failed when expected source retrieval is absent or failed; model-generated when the output has no supporting retrieved source; provider-changed when a recorded provider/model or behavior boundary changed; non-attributable when the evidence cannot identify a source; and unresolved while required evidence is missing. Change or correct a source or record only when retained evidence establishes the exact defect and authority to edit it. Assign causal credit only from retained evidence or a controlled comparison, never from timing alone.
40. Re-audit rhythm scheduled — review affected declarations after a business change and set source/checklist intervals from volatility, risk, authority, and contractual cadence. Retain completed, overdue, unavailable, and unresolved states rather than treating a calendar entry as evidence of a reread.

Five failure patterns this checklist is designed to expose

These are operational failure modes the checks above can reveal; finding or correcting one does not establish an external-engine outcome:

• The ambiguous identity record (Sections 1–2): legal entity, brand, location, operator, and aliases are collapsed or undocumented.
• The substantively conflicting record (Section 3): current sources disagree about an address, phone, owner, category, credential, or status, and no source authority is retained.
• The unsupported author record (Section 4): the page names no accountable author/reviewer or publishes credentials without issuer, scope, and validity evidence.
• The link-only inventory (Section 5): a program counts URLs without recording what each source says, whom it describes, or who controls it.
• The fire-and-forget project (Section 7): source changes, failures, and provider context are not reread, classified, or compared on a defined schedule.

If one of these patterns is supported by your retained evidence, its referenced section supplies the next checks. Preserve unknowns and dependencies instead of assuming the first visible symptom identifies the cause.

How to use this document

Estimate internal work only after counting entities, locations, people, sources, conflicts, permissions, and review requirements. Third-party acceptance and external-engine treatment have no universal delivery window. A manual program can execute these checks if it retains the evidence and states; ClickRadius adds five-family readiness scoring, preparation of eligible corrections, and monthly citation observations across five supported engines. Applying an exact correction requires approval, current authority, a capable connection, provider receipt, and public-origin reread. Those receipts establish the publisher-side effect, not downstream engine use.

The deeper references, section by section

Each section of this checklist compresses a full article in this series; use them when a check needs the reasoning, the examples, or the exact markup. According to the reading order that makes the dependencies clearest: start with the entity primer and the build playbook (Sections 1–2), then the sameAs guide for declaration mechanics. For Section 3, the trio of NAP reconciliation, directory presence, and the GBP deep-dive, plus the Wikidata guide where you qualify. Section 4 is author entities; Section 5 is mentions vs backlinks and the off-site evidence; Section 6 is grounded in the E-E-A-T translation. Ten articles, one architecture.

Frequently asked questions

In what order should I work through the entity authority checklist?

Start with the governed identity and fact record, then reconcile owned declarations and relevant third-party sources. Work on people, reputation evidence, content, and monitoring where their inputs are ready. This is an operational dependency order, not a provider ranking formula.

How often should the checklist be re-run?

Review affected facts after a business change and set source-specific reread intervals based on volatility and risk. ClickRadius's supported answer-layer observations run monthly; failed, unavailable, and not-applicable cells remain visible rather than becoming negative measurements.

Can I do all of this myself, or do I need a platform?

You can execute the checks manually if you retain sources, approvals, public rereads, and measurement context. ClickRadius adds readiness scoring, preparation of eligible corrections, and separate monthly citation observations. External effects and engine outcomes keep their own evidence states.

Next step: see the site inputs ClickRadius can observe with the free AI Readiness Score, measured across five evidence families. Plans combine prepared eligible corrections with separate monthly citation observations across ChatGPT, Gemini, Perplexity, Claude, and Grok. Applying a supported site effect requires approval, current authority, a capable connection, provider receipt, and independent public-origin reread; otherwise it remains a draft, pending, or customer-implementation item.