I recently had a conversation with Jarno van Driel, a structured-data practitioner whose work I’ve been reading for years. Jarno commented on my LinkedIn and X posts last week and was kind enough to call me and share his thoughts on the product with me.
Jarno was keen to point out a case study from 2014. In that study, Jarno documented how adding schema.org markup, including the about: property, produced a measurable lift in traffic. Jarno says that today, the same approach wouldn’t work. Google’s NLP is much more capable than it was a decade ago. If a tool ran Google’s own NLP against a page and put the results in about: and mentions:, it would be sending Google information Google has already produced or will soon produce itself. That framing shows up in Jarno’s 2024 piece on structured data and E-E-A-T. Markup doesn’t move the needle when it’s just re-narrating what Google’s NLP already reads.
During our conversation I think I did a poor job explaining that TopicalBoost doesn’t just run Google NLP on each page we analyze. So I wanted to use this a post to share more details on how our process works and how we provide visibility into what Google NLP does—and more important—what it doesn’t do.
TopicalBoost uses Google’s NLP API, but we also use an LLM layer to extract or infer additional Knowledge Graph topics from the text, and we allow the user to manually add entities, move topics from mentions: to about: or vice versa, and provide a host of other post-by-post and site-wide topic curation tools.
Let me give you a couple examples of why we created these controls and why we think they’re valuable.
NLP Regularly Misses Topics
Here’s an example of these controls in action from Illinois Policy, a customer who’s seen a 3x increase in their Google Discover traffic along with a 27% increase in organic traffic:
Here you can see what Google’s NLP detected on a post about the Chicago Teachers Union and its leader, Stacy Davis Gates, and their relationship with Brandon Johnson, Chicago’s Mayor. In this case, all of the central topics of the post were missed by Google NLP. Why? It’s hard to know for sure—Google NLP is a black box—but here are my best guesses:
- Brandon Johnson is a common name and also the name of four past and present professional athletes who have Wikipedia pages, so there’s an ambiguity issue.
- Chicago Teachers Union (CTU) has the same initialism as Colorado Technical University (CTU) and we’ve seen NLP falsely detect the latter on Illinois Policy’s site, so likely another ambiguity issue.
- Stacy Davis Gates is a bit of a head scratcher as she’s the only Stacy Davis Gates or Stacy Gates in Wikipedia and Illinois Policy consistently covers her by her preferred three-name moniker.
NLP does things like this a lot. We capture NLP-provided values like salience, a measure of relevance, and filter what TopicalBoost shows to users by that value. But in this case, low salience or relevance was not the problem; NLP simply refuses to identify some people, organizations, and other common entity types. This makes sense if Google really wants to err on the side of caution and avoid applying incorrect labels, but as you’ll see in the section below, it can sometimes betray its cautious nature.
Incidentally, in the ten months since Illinois Policy activated TopicalBoost, articles about the Chicago Teachers Union, Stacy Davis Gates, and Brandon Johnson have driven roughly 86,000 clicks from Google Discover alone. A single Chicago Teachers Union story drove nearly 59,000 of those on its own. Again, none of these three entities are reliably identified by Google’s NLP, but they all appear on Illinois Policy’s site thanks to TopicalBoost.
That lack of reliability is why we’ve added the LLM layer to our analysis pipeline along with the ability for editors to manually add topics to schema. Relying on Google to “figure it out” leaves traffic on the table.
NLP’s False Positives
NLP can also assign topics incorrectly, sometimes getting things incredibly wrong. For example, Search Engine Land regularly writes about Google Discover. But these posts are frequently flagged as “Discover Card” or “Discover Financial Services” by Google NLP despite them not featuring the words “card,” “finance,” or “financial.” In fact, Search Engine Land consistently refers to the service as “Google Discover” initially, only using the shorthand “Discover” for subsequent mentions.
TopicalBoost was quickly configured to correct these errors:
This relies on the same AI process I described above, but also site-wide topic blocking that can be set by editors. Other sites have seen false positives for “Getty Images” due to an image credit or Google NLP detecting formatting elements like em dash or non-breaking space as topics. Oddly, NLP can’t detect Brandon Johnson or Stacy Davis Gates, but it will consistently label Google Search Advocate John Mueller as political scientist John E. Mueller, even when John Mueller is discussed in the context of Google, search, and search engine optimization.
I don’t yet have telemetry stats on how often topics get blocked post-by-post or site-wide. But poking around a handful of sites, I saw hundreds of topics blocked at the site level. That’s a signal to Google that NLP is getting things wrong.
Good, but often wrong or incomplete
The examples above aren’t isolated incidents. We track this across all of our customers. Here are the stats fresh from our API monitoring tools as of the time of publishing this post:
We have over 380,000 topics in our system assigned to over 750,000 posts. From those we’ve created 6.8 million connections between posts and topics.
Breaking down those topic assignments, 4.97 million have come from straight-up Google NLP. Another 1.86 million have been derived from or classified by our LLM layer. Of those, 609k were topics the LLM found and verified as a Knowledge Graph entry, while the other 1.25 million were topics that NLP detected but the LLM layer reclassified as about: or mentions:.
So while Google’s NLP has gotten much better, it’s missing over a quarter of relevant topics. And this isn’t counting the topics that human writers and editors are manually adding to their posts, which would drive this number even higher.
Topic Controls
This is why we think Google NLP transparency is a crucial tool for publishers and why we’ve created both manual and algorithmic topic curation tools at both the post-by-post and site-wide levels. Here’s a quick way to understand those controls:
| Manual (human editor) | Algorithmic (machine) | |
| Post-by-Post | Hide topics, add topics, elevate a topic from mentions to about | LLM-assisted detection catches roughly one-third of applied topics that NLP alone misses |
| Site-Wide | Create aliases, merge topics, force-show a topic below its threshold, block a topic regardless of prevalence | Co-occurrence propagation model (in development) recommends which topics shouldn’t have topic pages or should be dropped from schema |
Merging topics came up, ironically, when we discovered that there are two Knowledge Graph entries for “search engine” and that Google’s NLP will assign posts to one or the other. Here they are as Wikidata entries:
The reverse has also been true. A foreign policy publisher found that Google’s Knowledge Graph did not distinguish between different types of missile systems, instead lumping them together under a “missile family,” mirroring how Wikipedia discusses the topic. So we built an ability to create “aliases,” a topic with a new name and description that still uses the same sameAs: relationship as another topic. This allows a publisher to be even more fine-grained with their topic taxonomy than the Knowledge Graph itself.
We’re also working on a way to curate topics site-wide in a way that doesn’t require a lot of boring manual review. Using co-occurrence propagation, we essentially build a graph like PageRank, but for how often one topic occurs with others. Editorial signals we already have, like dragging a topic to about: or manually adding a topic, serve as positive seeds. Actions like blocking a topic generate negative seeds. Scores then spread out to other topics based on how often they cluster with those positive or negative seeds. This enables us to put a short list of “recommended blocks” in front of editors so they can keep their taxonomy a relevant reflection of their coverage.
Where Jarno and I ended up
Two things. First, structured data that just repeats Google’s own NLP output back to Google is a waste of time in 2026. Jarno’s right about that. That’s why we’re focused on creating structured data that corrects errors in Google’s own NLP using human editorial judgment and smart algorithms informed by human editorial judgment.
Setting the entity work aside, Jarno acknowledged that the sheer volume of internal linking TopicalBoost produces at scale is undoubtedly a rankings factor on its own. Every article gets linked to the topic pages for the entities it covers. Every topic page acts as an internal index of the site’s coverage on that topic. This is what the New York Times, BBC, AP, and Reuters have been doing for years with in-house taxonomy systems.
That’s what TopicalBoost gives editors today: the ability to see how Google is likely to read a page and communicate corrections back in schema, post by post and site-wide, both by hand and with the help of algorithms, before the page goes live.
The next piece in this series will introduce TopicalDimension, the analytics layer we’re building on top of the topic layer. Rankings and Google Discover are two dimensions of what topics can do. Editors want to know which topics are actually driving impressions, clicks, and conversions on the pages they’ve already written, and where the coverage gaps are on the topics they should be publishing more about.