Keyword overlap and entity coverage measure different layers of similarity. Keyword overlap tells you how much two query or term sets share. Entity coverage asks whether a page represents the people, products, concepts or other identifiable things required to answer a specific question. Relationship coverage goes one step further: it checks whether the important connections between those entities are actually stated. Source support then asks whether those relationships are backed by evidence you can inspect.
Use keyword overlap when you need to compare search footprints, vocabulary or query sets. Use entity coverage when you need to test whether a page represents the subject model required by the task. Use neither as proof of ranking, AI citation, commercial competition or authority. High overlap can hide a weak subject model; low overlap can hide two pages that explain the same thing with different language.
Choose the diagnostic in under a minute
Compare query footprints
Start with keyword overlap. Normalize the two query sets, calculate their intersection and union, and inspect which queries are shared or unique.
Check subject completeness
Start with entity coverage. Define the entities the question requires before examining the page, then record which are clearly represented.
Check whether the explanation holds together
Add relationship coverage. A page can mention every required entity and still fail to explain how they connect.
Check whether the claims are defensible
Add source support. A relationship stated without a reliable evidence locator is not the same as a supported relationship.
Do not choose the metric from the data you already have. Choose it from the decision question. Otherwise the easiest available metric becomes a substitute for the evidence you actually need.
Four layers that are often collapsed into one score
- Keyword or query
- A word or phrase used to represent search demand, a tracked ranking footprint or a research question. A keyword set is the bounded collection being compared; it is not automatically the complete query universe.
- Entity
- An identifiable thing or concept that must be resolved consistently enough for the analysis: for example an organization, product, person, process, standard or abstract concept. An entity mention is merely a textual occurrence; it does not prove meaningful coverage.
- Entity coverage
- In this article, an operational audit measure: the share of entities required by a defined question that are explicitly represented in the source after alias resolution. It is not a documented Google ranking factor and should not be presented as one.
- Relationship coverage
- The share of required subject-predicate-object connections that the source states clearly enough for a reviewer to identify. Example: “patient consent controls which reminder channel a dental practice may use.”
- Source support
- Whether a consequential relationship has an inspectable evidence locator such as official documentation, a primary dataset, a standard, a dated direct observation or another source appropriate to the claim.
Move from query strings to supported relationships
Most false conclusions happen because analysis jumps from the first layer directly to the last. The safer model keeps each layer separate and asks a different question at each step.
A later layer cannot be inferred from an earlier one. Shared words do not prove shared entities; shared entities do not prove the same relationships; stated relationships do not prove source support.
Calculate keyword overlap transparently
Two set measures are usually enough for an audit. Use them only after applying the same normalization rules to both sets.
| Measure | Formula | What it reveals | Important limitation |
|---|---|---|---|
| Jaccard similarity | |A ∩ B| / |A ∪ B| | How much of the combined normalized query universe is shared. | A large unique tail on either side lowers the score even when one set is mostly contained in the other. |
| Overlap coefficient | |A ∩ B| / min(|A|, |B|) | Whether the smaller set is substantially contained in the larger set. | It can look high when one set is tiny, so always show the set sizes and shared terms. |
Normalization should be declared before calculation. The comparator and workbook use the same English-language rule: convert tabs, line breaks and non-breaking spaces to normal spaces; trim; collapse repeated spaces; and lowercase. Unicode compatibility folding, stemming, singularization, synonym merging and intent clustering are not applied silently; if you use any of them, record the transformation and apply it to both sets before comparison.
Define entity coverage from the question, not from a tool's suggestions
An entity audit needs a denominator. First write the decision question, then list the minimum entities required to answer it. Only after that should you inspect the source. Otherwise every entity extractor can produce a different “coverage” score with no stable definition of completeness.
| Operational measure | Formula for this audit | Interpretation |
|---|---|---|
| Entity coverage | required entities observed / required entities | Whether the source represents the subjects the question requires. |
| Relationship coverage | required relationships observed / required relationships | Whether the source explains the connections needed to answer the question. |
| Supported-relationship coverage | required relationships with acceptable evidence / required relationships | Whether the important connections are not only stated but defensible. |
These are audit ratios, not ranking probabilities. There is no universal “80% entity coverage” threshold supplied by Google. Set any sufficiency threshold from the task, risk and evidence standard before seeing the result, and retain the required-item list so another reviewer can challenge it.
The four states that reveal where the shortcut fails
The highest-value output is often not the score but the disagreement between layers. “High” and “low” below mean above or below a threshold defined for the audit before interpreting the result.
Language and subject model broadly align. Next inspect relationships, sources and intent before concluding equivalence.
Possible lexical false negative. Different vocabulary may represent the same subject model. Check intent before rewriting to mimic competitors.
Possible lexical false positive. Shared phrases can hide missing subjects, attributes or relationships. Add the missing model, not more repetition.
Both language and subject model diverge. Confirm whether the pages even belong to the same query task before treating either as a gap.
Use the existing framework as the process map
The preserved framework visual shows the controlled sequence from defining the required model to rechecking changed evidence. The text below extends it with explicit formulas, relationship checks and source provenance rather than replacing it.
The seven-step comparison method
- Define the question and query universe. State the buyer or research question, locale, date, page set and what “same task” means. Do not begin from a competitor export with unknown scope.
- Normalize the query sets. Apply the same declared rules to both sides. Keep raw and normalized forms so transformations are auditable.
- Measure lexical overlap. Calculate Jaccard and, where containment matters, the overlap coefficient. Show intersections and unique terms, not only a percentage.
- Build the required entity model. Before reading the page, list the entities necessary to answer the question and resolve aliases that could create duplicate or ambiguous identities.
- Observe entities and relationships. Record which required entities are represented and which required relationships are stated. A mention without a useful connection remains a mention.
- Attach source support and diagnose the mismatch. For consequential relationships, retain an evidence locator and source role. Then use the four-state matrix to identify lexical false positives, lexical false negatives or genuine divergence.
- Route the next action and define reopening conditions. Decide whether the gap is language, missing entities, missing relationships, weak support, intent mismatch or a different commercial competitor set. Re-run when the query universe, locale, offer, entity model or evidence materially changes.
A dental CRM comparison where the layers disagree
This is a composite editorial example used to demonstrate the method. It is not a live benchmark and does not claim search or answer-engine outcomes.
Question: Which page better explains how a dental CRM turns an eligible patient-reminder event into a booked appointment while respecting consent and practice workflow constraints?
Scope: English-language product explainer pages for the same buyer question. The example query universe contains eight normalized queries.
| Layer | Page A | Page B | Interpretation |
|---|---|---|---|
| Normalized query set | dental CRM; patient reminders; recall automation; appointment reminders; dental software; patient reactivation | dental CRM; patient reminders; recall automation; appointment reminders; dental software; recall workflow | Five shared queries; one unique term on each side. |
| Keyword overlap | Jaccard = 5 / 7 = 0.714. Overlap coefficient = 5 / 6 = 0.833. | Lexical similarity is high for this bounded example. | |
| Required entities | practice, patient, CRM, reminder | practice, patient, CRM, appointment, consent status, communication channel, reminder, treatment plan | Page A names category objects but omits several entities required by the question. |
| Required relationships | “CRM sends reminders” | consent status → permits channel; appointment status → triggers reminder; patient response → creates booking; treatment plan → changes follow-up timing | Page B explains the operational connections instead of only the category. |
| Source notes | generic category assertions | product documentation and workflow evidence locators recorded | Support must still be evaluated for authority and currency; a citation count alone is not enough. |
Result: the keyword layer suggests the pages are close, while the required entity and relationship layers show a material difference for this question. The correct action is not “add more dental CRM keywords” to Page A. It is to decide whether Page A should answer this workflow question at all; if yes, add the missing entities and relationships with appropriate support.
Limitation: this result does not establish which page would rank, receive an AI citation, convert better or be treated as a commercial competitor. Those require separate evidence.
Counterexamples that catch false positives and false negatives
| Case | What looks similar | What actually differs | What to do |
|---|---|---|---|
| High keyword / low entity | Two pages repeatedly use “Tesla,” “battery,” “charging” and “EV.” | One explains battery chemistry; the other explains charging infrastructure. | Do not infer substantive similarity from shared nouns. |
| Low keyword / high entity | One page says “patient reactivation”; another says “recall automation.” | Both describe the same patient, consent, channel, appointment and follow-up relationships. | Test query-language alignment without rebuilding the subject model unnecessarily. |
| Same keywords / different intent | “CRM pricing” appears on both pages. | One is a pricing explainer; the other compares CRM categories for procurement. | Intent moderates whether overlap represents page conflict or useful adjacency. |
| Same entities / different commercial role | Both pages mention Salesforce, HubSpot, CRM, automation and sales teams. | One is a software vendor; the other is an analyst or publisher comparing vendors. | Shared entities do not prove direct commercial competition. |
Resolve identities before counting entities
Entity coverage becomes unreliable when aliases are counted as separate entities or ambiguous strings are merged without evidence. Record a canonical label, type and—where useful—an external identifier or authoritative URL. “Apple” may be a company, fruit or record label; “Mercury” may be a planet, element, deity or brand. The context required to resolve identity belongs in the evidence record, not in a hidden tool rule.
Person entities are only useful when the person's identity changes the task: authorship, accountability, expertise, ownership or another material relationship. Adding names merely because an NLP tool detects them is entity stuffing.
Entity mention is not relationship coverage, and relationship coverage is not source support
A list of names can be semantically thin. Suppose a page mentions “Google Search,” “structured data,” “AI Overviews” and “ranking.” That does not tell a reader whether structured data is required for AI Overviews, whether it affects ranking, or whether the page is merely listing related concepts. The meaning sits in the relationships.
Google's current documentation says structured data can provide explicit clues about page meaning and must match visible content. Google's AI-features guidance also says there is no special schema markup required to appear in AI Overviews or AI Mode. Those two statements can coexist: structured data can clarify meaning without being a special AI-citation ticket.
Search intent decides whether overlap is competition or coincidence
Keyword overlap is often used to identify competitors or cannibalization, but the shared queries must be interpreted through intent and page role. Two URLs may overlap because one teaches a concept and the other sells a product; they may coexist in a mixed SERP without being substitutes. Conversely, two pages with different vocabulary can compete for the same decision if they satisfy the same user task.
For commercial analysis, add a separate question: Would the same buyer realistically choose one offer instead of the other for the same job? Search-result competition and commercial competition are related but not interchangeable.
Schema can describe entities without creating entity coverage
Structured data is a machine-readable representation of information on the page. It can identify an organization, person, article or other typed object and express properties such as sameAs, about or mainEntity. But markup does not repair missing visible explanation. If a required relationship exists only in JSON-LD while the article never explains it, the reader-facing coverage remains incomplete and the markup may violate the principle that structured data should represent visible content.
Use schema for accurate identity and relationships that are genuinely present. Do not use it to manufacture a hidden entity graph or to claim entity coverage simply because many types and properties were added.
Inspect the two signals without merging them
The preserved interactive visual is useful as a memory aid: keyword overlap and entity coverage can intersect, but neither contains the other. Its “shared visibility” region should be read as a comparison surface, not as proof of shared intent, ranking or citation.
Entity Coverage × Keyword Overlap
How to read it: select a checkpoint to isolate that part of the method. The canvas shows the relationship; the inspector explains what the checkpoint changes in the decision.
Text equivalent: keyword overlap describes shared query language; entity coverage describes the required subject objects; the overlap between those observations can be large or small. Topical completeness still depends on relationships and evidence, which are separate layers.
Transparent keyword and entity comparator
Use this calculator when you have two bounded query sets and a predefined required entity/relationship model. It normalizes list entries, calculates set overlap, and shows operational coverage ratios. It does not predict rankings, authority or AI citations.
Shared and unique queries
Shared: -
Only A: -
Only B: -
Four-state interpretation
Add both thresholds to classify the keyword/entity mismatch without inventing a universal cutoff.
Next analytical action
-
Save the analysis so another reviewer can reproduce it
The workbook and PDF have different jobs. The workbook is for repeatable evidence collection, calculation and handoff; the PDF is a portable reference for explaining the method and its boundaries. Neither asset substitutes for the article or silently adds a ranking model.
What this analysis must refuse to conclude
- Keyword overlap does not establish commercial competition. Check buyer, job, offer and substitution.
- High keyword overlap does not establish substantive similarity. Inspect entities, relationships and intent.
- Low keyword overlap does not establish substantive difference. Different vocabulary can encode the same subject model.
- Entity mention does not establish entity coverage. A required entity must play a useful role in answering the question.
- Entity coverage does not establish relationship coverage. The connections may still be missing or ambiguous.
- Relationship coverage does not establish source support. A claim can be explicit and still unsupported.
- Entity coverage does not establish ranking or AI citation. Search and answer selection depend on additional systems and evidence.
- Schema does not equal entity coverage. Structured data should describe the visible page, not replace it.
- Shared entities do not establish the same search intent. Intent remains a separate moderator.
Reopen the result when the evidence universe changes
Record the comparison date and rerun the audit when any of the following materially changes: the query universe, locale, buyer question, offer, page role, canonical entity identities, required relationships, source evidence, search documentation, search-result format, answer-engine behavior or the tool methodology used to extract observations.
For unstable search observations, keep the date and surface in the record. A result from one prompt, engine, locale or day should not be promoted into a timeless rule.
Questions practitioners ask about entity coverage and keyword overlap
Is entity coverage a Google ranking factor?
No public Google documentation identifies a universal “entity coverage” score as a ranking factor. Google documents systems that understand concepts and meaning, but an audit ratio such as required entities observed / required entities is a practitioner-defined diagnostic, not a disclosed ranking probability.
How should I calculate keyword overlap between two pages or competitors?
First create comparable normalized query sets. Use Jaccard similarity to compare intersection against the union; add the overlap coefficient when you need to know whether the smaller set is largely contained in the larger one. Always show set sizes and shared terms because a single percentage can hide an asymmetric footprint.
Is mentioning an entity enough to count it as covered?
No. Count an entity as covered only when it is clearly resolved and materially helps answer the scoped question. A name dropped into a list can be an entity mention without contributing useful coverage.
Does schema markup create entity coverage?
No. Schema can make visible information more explicit and machine-readable, but it should represent what the page actually says. Missing explanation or relationships in the visible content are not repaired simply by adding JSON-LD.
Can two pages have low keyword overlap and still cover the same topic?
Yes. Synonyms, professional terminology, regional language and different phrasing can produce low lexical overlap while the pages represent the same entities and relationships. Check intent and the subject model before treating low overlap as a genuine topical gap.
Does strong entity coverage make AI citation more likely?
The comparison cannot establish that. Clear entities and relationships may improve the page's explicitness, but citation or inclusion depends on the answer system, query, index eligibility, source selection and other factors. Measure actual visibility separately.
When does keyword overlap indicate cannibalization?
Only after intent and page role are considered. Overlap can be harmless when two pages serve different jobs, and low overlap can still hide cannibalization when pages use different language for the same user task.
Continue through the evidence path
This page owns the comparison between lexical overlap and subject-model coverage. The neighboring analyses own the next questions, in order:
Primary references and methodological context
Technical references were rechecked on 16 August 2026. They support the boundaries and definitions below; they do not prove that any particular page will rank or be cited.
- Google Search Central - A guide to Google Search ranking systems: documents neural matching, RankBrain and other systems that connect words, concepts and meaning.
- Google Search Central - Introduction to structured data: explains structured data as explicit clues about page meaning and requires accurate representation of visible content.
- Google Search Central - AI features and your website: states that AI Overviews and AI Mode use ordinary Search eligibility and require no special schema markup.
- Google Search Central - Optimizing for generative AI features: reinforces foundational SEO and warns against unsupported AEO/GEO hacks.
- Schema.org - sameAs: defines a property for an unambiguous identity reference.
- W3C - PROV Data Model: provides a formal model for entities, agents, activities and provenance relationships.
- Saleiro et al. - Entity-Relationship Search over the Web: primary research showing why entity-and-relationship retrieval is a distinct problem from plain keyword matching.
- Borisyuk et al. - Semantic Search at LinkedIn: current primary research describing production retrieval that combines semantic relevance techniques rather than relying on lexical overlap alone.
Use the disagreement to choose the next evidence, not to manufacture a bigger score
Start with the question. If you are comparing query footprints, calculate keyword overlap. If you are checking whether a page can actually explain the question, define the required entities before reading the page, then test relationships and source support. The most useful finding is often the mismatch: high lexical overlap with weak entity coverage tells you that shared language is hiding a thin model; low lexical overlap with strong entity coverage tells you not to rewrite blindly just to look more like a competitor.
Next action: run one bounded comparison, save the raw query sets and required entity model, attach evidence locators to consequential relationships, and route the diagnosed gap to the neighboring analysis that actually owns it. Do not conclude ranking, citation, authority or commercial competition from this comparison alone.