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.
Frequently asked questions about the entity pillar
These are the questions readers ask most often about the entity verification pillar of SQA-200. Each one is answered directly from the deposited specification, in a few sentences, so that the answer can be read, quoted and cited on its own without the rest of this page.
Can AggregateRating markup be added without real reviews?
No. Checkpoint P2.12 allows AggregateRating only for authentic customer ratings backed by proof. Google's review snippet guidelines also exclude self-serving reviews that a business publishes about itself, so invented ratings earn no stars and risk a manual action.
Why must the about and contact pages carry schema?
The about page is the canonical entity hub that links the brand's history and credentials, and the contact page declares a ContactPoint with the support channels. Checkpoints P2.13 and P2.14 make both pages part of the entity declaration, not just navigation.
Which dates must a page expose?
A page must expose an accurate datePublished and dateModified, both in the visible page and in the schema. Checkpoint P2.20 treats the dates as trust signals, so a modified date should change only when the content really changes.
DefinitionEntity verification is the second pillar of SQA-200, worth 40 points across 20 checkpoints, that helps search engines and language models identify a business as one named thing with a fixed address, a known author and outside corroboration.
How to audit and score the SQA-200 entity pillar
These steps help you check every identity declaration a business makes, align prose, structured data and external profiles, and score each of the twenty entity checkpoints at two points without rewarding markup the page does not support.
- Write one canonical NAP formFix one written canonical form of the business name, address and phone, and place it in the Organization schema and on the contact page so every listing copies from it.
- Reconcile every existing listingList every place the business appears, including directories nobody has updated since they were created, and correct each one until it is a 100% exact match of the canonical form.
- Use the full name in proseWrite the full proper name consistently in visible text and avoid pronouns where a machine would have to resolve who is speaking.
- Connect the structured data graphDeclare the Organization, Person, Service and ContactPoint nodes in a single connected graph, with author Person schema on every blog post and technical guide.
- Verify sameAs profiles point backPoint the sameAs array at official profiles and confirm each profile points back, because an array of profiles that do not link back is only an assertion.
- Score each checkpoint as binaryAward two points only when a declaration exists, is valid against the Schema.org vocabulary and agrees with every other declaration of the same fact, otherwise score zero.
- Record conditional items at zeroWhen a checkpoint cannot apply, such as LocalBusiness for a business with no physical premises, score it zero and record why, keeping it in the denominator.
FAQ about Entity verification
Direct answers to frequently asked questions about Entity verification, based on real-world implementation data, systematic technical audits, and verified production performance.
Why does a business name written several ways hurt entity verification?
A name written several ways makes machines unsure whether they see one organization or several, and their safest decision is to keep the records apart. Identity errors are silent and cumulative: a site can publish for years with an inconsistent name, get no warning in Search Console, and watch every earned mention accrue to a slightly different thing.
Why is a close NAP match not enough to pass checkpoint P2.04?
A close match fails because directory aggregators and knowledge graph builders compare records as strings before any human reviews them. A suite number written two ways creates two records, and those records then collect reviews and citations separately. Checkpoint P2.04 therefore asks for a 100% exact match of Name, Address and Phone across web properties and directories.
Why does a schema validator miss entity errors that still fail the audit?
A schema validator reports a node as valid without comparing it to the visible page. A checkpoint passes only when the declaration exists, is valid against the Schema.org vocabulary, and agrees with every other declaration of the same fact. That third condition fails most often and is the easiest to miss.
What goes wrong when a sameAs array points at profiles that never link back?
A sameAs array pointing at profiles that do not point back stays an assertion and never becomes a verification. External corroboration is the layer teams skip, yet it carries the most weight with a language model, because it is the only layer a site cannot write by itself.
How many points does the entity pillar carry and how are they split?
The entity pillar carries 40 points across 20 checkpoints, items P2.01 to P2.20, at two points each. That is the heaviest per-item weight outside the final pillar. An entity checkpoint is worth twice a technical one because identity errors are silent and cumulative.
Which layers does an entity audit check, and can one layer make up for another?
An entity audit checks three layers: prose, structured data and external corroboration. Prose means the full proper name used consistently in visible text. Structured data means Organization, Person, Service and ContactPoint nodes in one connected graph. Corroboration comes through the sameAs array. Passing one layer does not compensate for failing another.
How should a checkpoint be scored when it cannot apply to the business?
A conditional checkpoint is scored zero with the reason recorded, and it is never removed from the denominator. 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.
What happens to the score when structured data contradicts the visible page?
Markup that contradicts the page scores zero and is treated as worse than absence. Opening hours the site does not show, or an aggregate rating with no visible reviews behind it, misrepresent the business to both the reader and the engine, and put the credibility of the whole graph at risk.
What question does the second pillar of SQA-200 ask about a business?
The second pillar of SQA-200, entity verification, asks whether search engines and language models can identify a business as one named thing with a fixed address, a known author and corroboration outside its own website. Entity verification carries 40 points across 20 checkpoints, two points each, within the six pillars of Search Quality Assurance.
Does a business without physical premises still need entity schema?
Yes, a business without physical premises still needs entity schema in SQA-200. Organization, Person and ContactPoint declarations and sameAs corroboration still count, while the LocalBusiness and OpeningHours items become conditional. The framework scores those conditional items zero with the reason recorded and never removes them from the denominator.
How is entity verification different from Topical Authority in SQA-200?
Entity verification establishes who is speaking, while Topical Authority, the third pillar of SQA-200, turns an identified entity into a mapped body of work. Entity verification hands Topical Authority a named author and a named organization, because topical authority accumulates against an identified entity and content under an unresolved identity accrues to nothing.
Where should a business start with entity verification?
A business should start entity verification by writing one canonical form of its name, address and phone, then placing that form in the Organization schema and on the contact page. Entity verification then requires listing every place the business appears and reconciling each listing against that canonical form until it is a 100% exact match.