The Best and Worst Entity Models for SEO: Which Find the Words Google Uses, and Which Feed You False Positives

1. Background

“Cover the entities Google expects” has become standard advice in semantic SEO, and a small industry of tools now surfaces entity lists and entity gaps for any page. Underneath that advice sits an unexamined dependency: some model has to decide what the entities are. Tools build on general-purpose extractors (Google Cloud Natural Language, TextRazor, open-source NER) or increasingly on LLM prompting, and the resulting lists are treated as interchangeable ground truth.

They are not interchangeable, and this study measures how far apart they sit. It is also, plainly, a vendor study: one of the five contestants is the entity model behind our own products, and we publish the comparison because it wins. Two design choices keep the comparison honest. The referee is external to every contestant: not similarity to any model, but presence in what Google itself writes about each query. And every model is scored by one identical procedure, described in full below, so the test can be rerun against us [1].

2. Method

Population. From the 50-keyword, ten-vertical SERP capture used in our earlier studies [1] (July 15, 2026; US, English), we crawled the page-one organic results and kept the 275 pages that yielded clean article text; 166 pages across 48 SERPs were processable by all five models and form the comparison set.

Contestants. Four generic extractors ran on the same locally extracted text, truncated identically for every model: Google Cloud Natural Language's entity analysis [3], TextRazor's entity extractor [4], spaCy's en_core_web_sm English pipeline [5], and OpenAI's gpt-5-mini [6] given a single naive instruction to list the entities in the text, which is how inexpensive tooling typically wires an LLM. Our own model's entities come from the same scan reports our customers see, filtered to entities the report marks as present on the page; its internals are not described here beyond that, and this asymmetry in text source is noted in §5.

Referee. For each keyword we assembled Google's own query-side words from the same capture: the AI Overview's full text (shown on 49 of 50 SERPs) [2], every People Also Ask question, and every related search. An entity “appears in Google's words” when its normalized form occurs in that text. One normalization applies to every model: lowercasing, whitespace and edge punctuation cleanup, removal of purely numeric strings and strings under three characters, and crude depluralization. Matching is deliberately surface-level and identical for all contestants.

Measures. Extraction quality: the share of a model's entities (full set, and top-30 to neutralize verbosity differences) appearing in Google's words, and the false-positive rate, the share appearing in neither Google's words nor the text of any competing ranking page for the keyword. Recommendations: for our model, the entities its report recommends adding; for the others, the strongest available simulation of a gap analysis, entities the model finds on at least two other ranking pages but not on yours, ranked by cohort frequency; both cut to top-10 so list sizes match. Stability: gpt-5-mini was run three times on identical text for 50 pages. We also tested a rank-prediction referee (does entity coverage separate positions within a SERP); it was weak for every model, consistent with our earlier finding that little separates positions within page one [1], and we exclude it rather than publish a measure no model passes.

3. Results

Everything below scores the five models on those two axes. Accuracy is what you want more of: an extractor that surfaces the words that matter, the vocabulary Google itself uses when it answers the query. False positives are what you want less of: plausible-looking words with no support anywhere in the query's ecosystem, the ones that send optimization effort down the wrong path.

3.1 Accuracy: which models find the words that matter

The five models produce very different amounts of material: median entities per page run from 15 (spaCy) through 50 (gpt-5-mini), 69 (TextRazor), and 100 (ours, page-present entities) to 172 (Google Cloud NL). Volume alone says nothing about quality, so the primary comparison uses each model's top 30 entities per page.

Two things stand out. First, the spread is not subtle: 48.6% versus 16.4% at the top of each model's list is the difference between an entity list that mostly reflects how Google talks about the topic and one that mostly does not. Second, the ordering is not simply “bigger list wins”: Google Cloud NL extracts the most and lands second; spaCy extracts the least and lands last; the LLM sits in between on volume and near the bottom on alignment.

3.2 False positives: the words that lead you down the wrong path

The inverse question matters more for practitioners: how much of what an extractor surfaces has no support anywhere in the query's ecosystem? We count an entity as a false positive when it appears in neither Google's words for the query nor the text of any competing ranking page. A false positive is not necessarily wrong about the page; it is unsupported as an optimization target, because nothing Google shows for the query gives evidence it matters.

For the four generic extractors, between 46.6% and 65.1% of extracted entities were false positives. If a tool built on one of them hands you an entity checklist, roughly half of the list, or more, points at material with no footprint in the SERP you are trying to win. Our model's rate is 13.4%, which is expected behavior rather than magic: it is built to extract entities relevant to search cohorts, and this referee measures exactly that. The practical point is not that generic extractors are bad NLP; it is that they answer a different question than the one entity SEO asks.

3.3 Recommendation quality at matched size

Extraction is the input; what a tool tells you to add is the output. We compared top-10 recommendation lists: entities a model would surface as missing from your page but present in the competitive landscape. To keep the comparison fair, competitor recommendations were constructed by the strongest method their extractors support (entities found on at least two other ranking pages, absent from yours, ranked by frequency), and all lists were cut to ten.

This race is narrower at the top: 64.2% (ours) against 61.5% for a Google Cloud NL-based gap analysis. Two differences still separate the field. Coverage: our model produced a usable list on all 166pages, Google Cloud NL on 159, and spaCy on only 71, because a sparse extractor often cannot find enough consensus entities to recommend anything. And floor: a TextRazor-based gap analysis lands at 40.0%, meaning six of its top ten suggestions have no support in Google's own words for the query.

3.4 The LLM does not agree with itself

Determinism matters for a metric you track over time. Four of the five extractors return identical output for identical input. The budget LLM does not: across three identical runs on identical text, gpt-5-mini's entity sets overlapped an average of 61%. An entity checklist that rewrites two of every five items when you refresh it is not a stable optimization target, and any score built on it will move without the page changing.

4. Discussion

The result is best read as a statement about fit, not about NLP quality in the abstract. Google Cloud Natural Language, TextRazor, and spaCy are competent general-purpose systems, and gpt-5-mini is a capable model given an underspecified job. But entity SEO asks a narrow question: of everything on and around this page, which concepts does the search ecosystem for this query actually traffic in? A model tuned to that question beats models tuned to Wikipedia-style entity linking or generic salience, on the referee that matters to practitioners, by margins large enough to change what a user does next. That tuned model is ours, and the margin is not an accident: we have spent years building the extractor specifically for search, against ranking cohorts rather than encyclopedias, precisely because general-purpose NLP kept answering the wrong question. This study is the first time we have put that investment against the field under an external referee, and it is why a purpose-built model from a small team outscores a general-purpose API from Google itself.

The stakes are larger than tool trivia. In semantic SEO, the entity list is upstream of everything: content briefs, gap analyses, optimization checklists, and increasingly the prompts fed to writing tools all start from some extractor's idea of what the topic contains. A list that is half false positives does not merely waste effort; it steers a page away from the language the query's ecosystem actually uses, one plausible-looking wrong word at a time. A list aligned with Google's own vocabulary concentrates the same effort on relevance the ecosystem demonstrably traffics in. Whether that alignment also makes pages rank faster is the industry's operating assumption, not something this study measures; what it measures is the precondition, and the precondition is where the five models separate.

The false-positive rate is the number we would put in front of anyone buying entity-gap tooling. It bounds how much of a tool's to-do list can possibly pay off, whatever Google's ranking systems do internally. What this study shows is that the lists themselves, the starting point of all such work, differ radically in how much of Google's own language they reflect. The winning model is not a lab artifact: it is the production extractor behind our scan reports and API, and the availability note below describes how to run the same inspection on any page.

5. Limitations

One of the five models is ours, and we are publishing a comparison we won; readers should weigh that, and the method is specified so the test can be rerun against us. The referee is surface matching against Google's rendered words, not Google's internal entity understanding; paraphrases and synonyms are not credited, which penalizes all models equally but rewards extractors whose vocabulary matches Google's phrasing. Our model's entities come from our scan pipeline's own text extraction while competitors ran on an independent local crawl of the same URLs, an asymmetry we could not fully remove; competitor text used an identical truncation across models. Competitor recommendation lists are simulated gap analyses, not those vendors' commercial products, and are built only from crawlable ranking pages. The population is one day, one locale, 50 hand-built keywords, and the 166 pages all five models could process. gpt-5-mini represents one budget LLM under one naive prompt; better prompting or newer models may do better, and we make no claim beyond the configuration tested. A rank-prediction referee was tested and excluded because every model failed it (§2).

6. SEO Implications

For teams doing entity or semantic optimization:

• Ask what extractor sits under your entity tool. It is the single biggest determinant of what the tool tells you, and “we use NLP” can mean anything from a sparse NER pipeline to an unstable LLM prompt.
• Sanity-check any entity checklist against Google's own surfaces for your query: the AI Overview, People Also Ask, related searches, and the pages that rank. If a recommended entity appears in none of them, you are likely looking at a false positive.
• Distrust entity metrics that change when nothing changed. A stable page should produce a stable entity list; if your tool's list churns between refreshes, its extractor may be guessing.
• Keep expectations honest: an aligned entity list tells you what the query's ecosystem talks about. Whether covering it moves rankings, and how fast, is a separate question this study does not answer.

References

1. Lancheres, E. (2026). “Do AI Assistants Cite Original Content? 793 AI Citations Measured Against the Pages That Rank.” On-Page.ai Research (source of the SERP and AI Overview capture reused here). api.on-page.ai/research/ai-citation-study
2. “AI features and your website,” Google Search Central documentation. developers.google.com/search/docs/appearance/ai-features
3. “Analyzing entities,” Google Cloud Natural Language documentation. cloud.google.com/natural-language/docs/analyzing-entities
4. “Entity extraction,” TextRazor documentation. textrazor.com/docs/rest
5. spaCy, en_core_web_sm English pipeline. spacy.io/models/en
6. OpenAI API documentation (gpt-5-mini). platform.openai.com/docs/models