There's a comfortable assumption sitting inside a lot of technical SEO roadmaps right now: that entity SEO is one job with one deliverable. Map the entity, ship the schema, get the Wikipedia page and the Wikidata item squared away, watch the knowledge panel populate, and consider both Google and the AI engines handled by the same checklist. Duane Forrester — a former Bing and Yext search veteran who's been one of the more precise voices tracking the mechanical differences between search and LLM systems — spent a July 26, 2026 Substack post pulling that assumption apart. His piece, "Entity Mapping Works on Google. Does Any of It Reach ChatGPT?", is worth taking seriously because it isn't arguing entity work is dead. It's arguing you're running two different systems through one strategy, and one of those systems was never built to read the inputs you're feeding it.
The assumption: clean entity SEO equals clean GEO
Entity SEO, as a discipline, grew up entirely inside Google's world. It's the practice of making your brand, your people, and your products legible as distinct, disambiguated things — not just strings of text that happen to match a search query, but nodes with defined identities that a system can connect to other nodes. Structured data for organizations and products, consistent naming and disambiguation signals, a clean knowledge panel, presence on Wikipedia and Wikidata: all of it exists to feed a specific kind of system, one built around an explicit graph of entities and the relationships between them.
When generative engine optimization showed up as a discipline, a lot of teams — reasonably, on the surface — assumed the same inputs would just carry over. If Google already treats your brand as a well-formed entity, surely an LLM answering a question about your category would represent you the same way. That assumption is doing more work than it can support. It treats "being a recognized entity in one system" and "being reliably represented in another system" as the same achievement, measured by the same signals. Forrester's argument, and the reason it's worth building a whole comparison around, is that the two systems don't share a mechanism. They share a subject — your brand — but almost nothing about how that subject gets encoded, stored, or retrieved.
How Google's knowledge graph actually works
Google's knowledge graph is an explicit structure. It's been built and maintained for well over a decade as a graph database: entities get IDs, IDs get connected to other IDs through defined relationships, and the whole thing sits alongside the search index as a separate layer Google can query directly. When you ship schema markup identifying your organization, disambiguate a person's name against other people who share it, or keep your NAP (name, address, phone) consistent across every listing, you're feeding a system that was purpose-built to consume exactly that kind of structured, unambiguous input and store it as a discrete fact.
That's why knowledge graph SEO and structured data SEO have had a reliable, demonstrable payoff on Google for years. A knowledge panel populating correctly, a business showing up correctly disambiguated from a same-named competitor, rich results pulling the right fields from your markup — these aren't theoretical benefits. They're the direct, mechanical output of a system designed to ingest entity data and represent it explicitly. The practice and the platform were built for each other. That's also exactly why it's easy to assume the practice generalizes: it worked so cleanly, for so long, on the system it was designed for, that it started to feel like a universal law of "how machines understand brands" instead of a fact about one particular machine.
How an LLM represents your brand instead
An LLM doesn't have an entity graph in the same sense, at least not one it consults the way Google's search stack consults its knowledge graph. What it has instead is a statistical representation, built during training, of how your brand shows up across the text it was trained on — how often it's mentioned, in what contexts, alongside what other terms, described in what ways, by how many independent sources saying roughly the same thing. There's no ID lookup. There's a diffuse pattern spread across billions of parameters, shaped by the aggregate of everything the model read about you, weighted by how much of that text existed and how consistent it was.
Search-augmented modes — ChatGPT's browsing, Perplexity, Google's own AI Mode — add a retrieval layer on top of that trained representation, pulling in live pages at answer time. But even that retrieval step is closer to a search-and-summarize pass over the open web than a graph lookup. It's reading pages and extracting what looks relevant, not querying a store of pre-linked entity facts about your organization. Forrester's framing is blunt about the gap: there's no guaranteed 1:1 mapping between being a well-defined entity in Google's graph and being reliably represented or cited by an LLM, because the two systems aren't doing the same kind of work with the same kind of input.
This is the same underlying gap we've written about from a different angle: schema markup doesn't get you cited by an LLM, because the pretraining pipeline strips script tags before a model ever trains on them, per Mark Williams-Cook's analysis of how FineWeb's extraction tooling (trafilatura) discards boilerplate — including your JSON-LD — before the readable text is kept. His broken-JSON-LD experiment made the point directly: a model handed nonsensical, invalid schema still returned the correct answer, because it had been reading the plain visible text on the page the entire time, not parsing the structured data next to it. That's not a new finding here — it's the same mechanism showing up again, this time as one specific row in a broader comparison between what Google's entity system rewards and what an LLM's representation actually runs on.
What transfers and what doesn't
Put the two systems side by side and the picture gets specific fast. Some entity and structural practices are doing real work in both places. Some are doing real work in exactly one place and nothing you'd notice in the other. Here's the comparison worth keeping on a wall somewhere, grounded in what's actually been demonstrated rather than what sounds like it should be true.
| PRACTICE | MATTERS FOR GOOGLE | TRANSFERS TO CHATGPT / LLMS |
|---|---|---|
| Schema markup (JSON-LD for org, product, person) | Yes — feeds knowledge graph fields, earns rich results eligibility | No — stripped during pretraining extraction (trafilatura drops script tags); Williams-Cook's broken-schema test returned correct answers from plain text alone |
| Wikipedia / Wikidata presence | Yes — direct knowledge graph and knowledge panel source | Partial — the prose is readable training text, so it can shape a model's representation, but it's one corroborating source among many, not a guaranteed anchor the way it is for Google's graph |
| Knowledge panel accuracy (single source) | Yes — Google owns and displays the panel directly | No — a single accurate panel doesn't guarantee consistent LLM representation; Forrester notes even Google's own AI Overviews has contradicted its own Google Business Profile data within one company's stack |
| NAP consistency (name, address, phone) | Yes — disambiguates local and organizational entities in the graph | Weak / indirect — only matters to an LLM insofar as it appears as repeated, consistent text across many sources, not as a structured field it looks up |
| Disambiguation signals (distinct naming, sameAs links) | Yes — resolves entity collisions directly in the graph | Weak / indirect — an LLM infers disambiguation from context in surrounding text, not from an explicit sameAs declaration |
| Breadth of corroborating third-party mentions | Helpful, but not the primary mechanism — Google has its own graph | Yes — this is closer to the actual mechanism; consistent, repeated factual framing across many independent sources is what shapes a trained representation |
Read the middle column and the right column as two different jobs, not two versions of the same job. The middle column is what earns you a clean knowledge panel and correct disambiguation on Google — that work is real, it's cheap relative to its payoff, and nothing here argues for dropping it. The right column is what a growing body of evidence says actually shapes how an LLM talks about you, and it's a narrower list than most entity SEO checklists assume.
How much each signal shapes outcomes in each system (illustrative weighting based on sourced mechanics, not a published formula)
“Being a well-defined entity in Google's graph and being reliably represented by an LLM are not the same achievement, and they're not earned by the same work.”
What to build for LLM representation instead
If schema and single-source accuracy aren't the lever, what is? The evidence points toward volume and consistency of independent corroboration — the same pages, sources, and third-party mentions saying the same true thing about your brand often enough, in enough different places, that the pattern shows up clearly in whatever a model trained on or retrieved from. That's not a new idea for readers of this site — it's the same three-signal framework we've published before for what earns AI citations generally: extractable structure, demonstrated authority, and machine access. Entity representation is a specific application of the authority signal — corroboration from sources an engine already trusts is doing the heavy lifting, not a structured-data declaration you control on your own domain.
This is also where knowledge graph SEO and generative engine optimization genuinely need to run as separate workstreams inside the same team, not one retainer covering both by assumption. The technical SEO discipline that gets you a clean knowledge panel is real and worth keeping funded. The corroboration-building discipline that shapes LLM representation is a different set of activities — earning mentions, getting cited correctly by sources engines already trust, keeping factual framing consistent across the open web — and it doesn't happen as a side effect of the first one. We've seen the same disconnect show up in a related but distinct problem: AI engines disagreeing with each other on which sources to trust for the same query, which is a downstream symptom of exactly this — no shared entity graph means no shared, guaranteed answer about who you are.
It's also worth flagging where this connects to attribution, briefly, without retelling that piece here: Forrester's July 19, 2026 companion post on his Substack — on how ChatGPT-style logging changes have started resembling Google's 2011 shift to "not provided" search-term data — covers a related but separate mechanical shift, this time in how much visibility teams have into what's driving traffic at all. That's an analytics-and-attribution problem. This piece is about representation and structure specifically: whether the entity work you've already funded shows up in what a model says about you, not what you can measure about the traffic that follows. Worth reading both, but they're solving different problems.
One more place this shows up concretely: technical, product-heavy brands — the kind of company profiled across devtools-focused GEO work — often have the cleanest possible Google-side entity setup and the thinnest possible third-party corroboration, because the audience that would naturally write about them skews toward documentation, changelogs, and first-party content instead of the review sites, community threads, and press coverage that actually shape an LLM's impression. That's the exact profile where the gap between "clean entity SEO" and "clean GEO" shows up hardest, because the Google-side signals look great on an audit while the LLM-side representation stays thin or inconsistent.
Do this next
Pull your current entity SEO checklist and sort it into the two columns from the table above, honestly. Anything that only earns you knowledge panel accuracy or rich results — most schema, most single-source disambiguation work — keep funding it, but stop reporting it as a GEO win. Anything that builds breadth across independent third-party sources — reviews, press, community mentions, partner content that consistently describes you the same accurate way — move it up the priority list, because that's the signal with an actual mechanism behind LLM representation. Then run the audit that actually tells you where you stand: pick five to ten factual claims about your brand (what you do, who you're for, what you're not), search for how consistently those claims appear across sources outside your own domain, and fix the gaps you find before assuming your Google-clean entity setup is doing that job for you.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Tyler leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.