Entity verification is the second pillar of Search Quality Assurance (SQA-200)™ and carries forty points across twenty checkpoints, two points each. It asks whether search engines and language models can identify this business as one named thing with a fixed address, a known author and corroboration outside its own website.
What entity verification covers in SQA-200
Entity verification covers everything that answers the question of who is speaking: the Organization declaration, the people attached to it, the physical and contact details, the services offered, and the links that connect all of it to profiles the site does not control. Twenty checkpoints carry two points each, the heaviest per-item weight outside the final pillar.
The weighting says something the framework means literally. An entity checkpoint is worth twice a technical one because identity errors are silent and cumulative: a site can publish for three years with an inconsistent business name and receive no error message, no warning in Search Console and no visible symptom, while every mention it earns accrues to a slightly different thing.
The identity problem this pillar solves
The identity problem is that a business usually knows it is one company and the web does not. The name appears four ways across the homepage, an invoice footer, a directory listing and a conference biography; the phone number carries a country code in two places and not in the others; the founder is credited by a full legal name in one article and a nickname in the next.
None of that is dishonest and all of it is expensive. A machine assembling an entity from those signals has to decide whether it is looking at one organization or several, and its safest decision is to keep them apart. The twenty checkpoints in this pillar exist to remove that decision, by making every declaration of identity identical and by pointing each one at the same canonical anchor.
The three layers of an entity declaration
An entity is declared on three layers, and this pillar audits all three because passing one does not compensate for failing another. The first layer is prose: the full proper name used consistently in visible text, with pronouns avoided where a machine would have to resolve them. The second layer is structured data: the Organization, Person, Service and ContactPoint nodes in a single connected graph.
The third layer is external corroboration, declared through the sameAs array and verified by the profiles it points at. This is the layer teams skip, and it is the one that carries the most weight with a language model, because it is the only layer the site cannot write by itself. A sameAs array pointing at profiles that do not point back is an assertion, not a verification.
NAP consistency and why an exact match is the standard
Name, Address and Phone consistency is checkpoint P2.04 and its verification standard asks for a 100% exact match across web properties and directories, not a close match. The strictness is not pedantry. Directory aggregators and knowledge graph builders match records by string comparison long before any human reviews them, and a suite number written two ways produces two records that then accrue reviews and citations separately.
Auditing NAP consistency means listing every place the business appears, including the ones nobody has updated since they were created, and reconciling them against one written canonical form. The canonical form itself belongs in the Organization schema and on the contact page, so that any future listing is copied from a single source rather than retyped from memory.
The twenty entity checkpoints
Below are the twenty itemized checkpoints of pillar two, each carrying two points. Several of them are conditional in practice: a business with no physical premises cannot pass the LocalBusiness and OpeningHours items, and a business with no genuine review corpus must not pass the AggregateRating item. The framework's rule for a conditional item is to score it zero and record why, never to remove it from the denominator.
| Item | Checkpoint | Weight | Verification and execution standard |
|---|---|---|---|
| P2.01 | Organization JSON-LD | 2.0 pt | Inject valid Organization Schema on homepage declaring legal name, logo, and official URL. |
| P2.02 | SameAs Social Connection | 2.0 pt | Link Organization Schema to official social profiles, Wikidata, and Wikipedia via sameAs array. |
| P2.03 | LocalBusiness Spec | 2.0 pt | Declare LocalBusiness Schema with physical street address, phone, and geo-coordinates. |
| P2.04 | NAP Consistency Audit | 2.0 pt | Verify 100% exact match of Name, Address, and Phone across web properties and directories. |
| P2.05 | Founder / Person Schema | 2.0 pt | Link Founder/CEO Person Schema with credentials, publications, and author ORCID. |
| P2.06 | Employee / Expert Schema | 2.0 pt | Declare technical staff and content reviewers with Person Schema on team rosters. |
| P2.07 | Service Schema Markup | 2.0 pt | Embed Service Schema on money pages specifying serviceType, provider, and areaServed. |
| P2.08 | Price Specification | 2.0 pt | Disclose transparent price range or offer terms inside PriceSpecification Schema. |
| P2.09 | AreaServed Region Spec | 2.0 pt | Specify geographical service boundaries using AdministrativeArea in Service Schema. |
| P2.10 | OpeningHours Specification | 2.0 pt | Declare business operating hours using OpeningHoursSpecification format. |
| P2.11 | FAQPage Schema Nesting | 2.0 pt | Nest FAQPage Schema matching visible Q&A accordions on transactional landing pages. |
| P2.12 | AggregateRating Markup | 2.0 pt | Nest authentic customer review ratings via AggregateRating Schema when backed by proof. |
| P2.13 | AboutPage Entity Anchor | 2.0 pt | Establish /about/ as the canonical entity hub linking brand history and trust credentials. |
| P2.14 | ContactPage Specification | 2.0 pt | Declare /contact/ with explicit ContactPoint Schema including customer support channels. |
| P2.15 | Person Author Schema | 2.0 pt | Attach author Person Schema to all blog posts and technical guides with bio URLs. |
| P2.16 | MainEntityOfPage Spec | 2.0 pt | Specify mainEntityOfPage canonical reference inside Article and Service schemas. |
| P2.17 | BreadcrumbList Schema | 2.0 pt | Inject BreadcrumbList Schema matching visible breadcrumb trail on all interior pages. |
| P2.18 | Article / BlogPosting | 2.0 pt | Classify editorial guides with Article or TechArticle Schema including headline and image. |
| P2.19 | DefinedTerm Entity Linking | 2.0 pt | Declare proprietary terminology using DefinedTerm Schema linked to glossary hubs. |
| P2.20 | Date-Modified Transparency | 2.0 pt | Expose accurate datePublished and dateModified timestamps in meta and Schema markup. |
How to score the entity pillar
Scoring the entity pillar is twenty binary decisions at two points each. A checkpoint passes when the declaration exists, is valid against the Schema.org vocabulary, and agrees with every other declaration of the same fact. The third condition is the one that fails most often and is easiest to miss, because a schema validator reports a node as valid without comparing it to the visible page.
The scoring rule for markup that contradicts the page is unambiguous: it scores zero and is treated as worse than absence. Structured data asserting opening hours the site does not show, or an aggregate rating with no visible reviews behind it, is a misrepresentation to both the reader and the engine, and it puts the whole graph's credibility at risk rather than just that node's.
What entity verification hands to Topical Authority
Entity verification hands the next pillar a named author and a named organization to attach content to. Topical authority is not accumulated by a website in the abstract; it accumulates against an identified entity, and content published under an unresolved identity accrues to nothing. The author Person schema of checkpoint P2.15 is what makes the third pillar's output attributable.
Continue to pillar three, Topical Authority and Content Hub, which turns an identified entity into a mapped body of work.