How ChatGPT Resolves Local Business Entities: Google Place IDs, lbe1 and schema:hasMap

We traced ChatGPT’s local-business identifiers to real-world Google Place identities, observed how lbe1 powers the entity experience, and found that selecting an entity can shape the next search and conversation.

In our previous research on ChatGPT’s named entities and OpenAI’s emerging semantic layer, we showed that ChatGPT increasingly operates on structured entities, not just pages.

Our latest experiments expose another part of that layer: local businesses.

We can now observe this chain:

Publisher entity
      ↓
Google CID
      ↕
Google Place ID
      ↕
ChatGPT local-business entity
      ↓
lbe1_...
      ↓
Entity panel
      ↓
Entity-scoped conversation

The relevant AI visibility question is becoming:

Does the AI correctly identify the real-world entity behind the page — and carry that identity forward into the conversation?

ChatGPT has a structured local-business layer

Using the ChatGPT Search Observatory, we captured the Server-Sent Events generated during local search.

For:

“Best ski location near Mariapfarr”

ChatGPT represented Fanningberg as:

category: local_business

entity_lookup_id:
lbe1_N0fAahpRpdylU3ed4w5PuLQQ

name:
Fanningberg

address:
Fanningberg 151, 5573 Weißpriach, Austria

rating:
4.7

review_count:
1596

website:
fanningberg.info

The same lbe1 was then reused in the map widget.

We observed the same pattern for Großeck–Speiereck and Obertauern.

ChatGPT currently uses lbe1_... identifiers as entity_lookup_id values for objects classified as local_business.

This goes beyond Named Entity Recognition. ChatGPT materializes an operational place object with coordinates, address, category, website, phone, opening hours, reviews and images.

Independent research points in the same direction.

GPTSpy has documented ChatGPT entity references containing local-business IDs, coordinates and addresses.

RESONEO has shown that ChatGPT local results frequently contain Google Place IDs and Google-compatible ratings, categories, reviews and images.

Our experiment adds the bridge between ChatGPT’s lbe1 identifier and the external place identity.

Connecting lbe1 to Google Place IDs

For Fanningberg, ChatGPT gives us:

lbe1_N0fAahpRpdylU3ed4w5PuLQQ

The independently resolved Google place is:

ChIJ9c_cfw7ccEcRRc3dZpNRT4w

Both records match on name, address, phone, website, rating and review count.

We repeated the comparison across multiple places:

Entity	ChatGPT entity_lookup_id	Google Place ID	Google CID
Fanningberg	lbe1_N0fAahpRpdylU3ed4w5PuLQQ	ChIJ9c_cfw7ccEcRRc3dZpNRT4w	10110389381997907269
Großeck–Speiereck	lbe1_KpAdgJIp2gFh01ouRBpJ3XqR	ChIJLYQiDpjccEcRR4XhFPCesh0	2139947526934070599
Obertauern	lbe1_QJOd0CsvlGXSwcFbxel9KlKF	ChIJw4rPjr3XcEcRrC57dz_Epjg	4082165889124478636
AlpiNest Feriendorf Lungau	lbe1_R-wKU8fgyRChtCD4m9iN8QpD	ChIJZXvYPP7dcEcRqCiPOdTEjAk	688141258858637480

lbe1 is not an encoded Google Place ID or CID. We found no reversible transformation between them.

A better model is:

Google Place identity
CID / Place ID
        ↓
entity reconciliation
        ↓
ChatGPT local-business object
        ↓
lbe1_...

Different identifier systems can refer to the same real-world entity.

Google CID and Place ID

For AlpiNest:

Place ID
ChIJZXvYPP7dcEcRqCiPOdTEjAk

CID
688141258858637480

These are two representations of the same Google place identity.

RESONEO provides a useful technical explanation in its research on Google Maps, Geostore, Place IDs and CIDs.

This matters because publishers can reference the CID directly in structured data.

schema:hasMap as an identity assertion

On alpina.travel, AlpiNest Feriendorf Lungau is represented as a LodgingBusiness:

{
  "@type": "LodgingBusiness",
  "@id": "https://data.wordlift.io/wl01855/alpinest-feriendorf-lungau",
  "name": "AlpiNest Feriendorf Lungau",
  "hasMap": "https://www.google.com/maps?cid=688141258858637480"
}

That gives us:

Alpina Knowledge Graph
        ↓
schema:hasMap
        ↓
Google CID
688141258858637480
        ↕
Google Place ID
ChIJZXvYPP7dcEcRqCiPOdTEjAk
        ↕
ChatGPT reconciliation
        ↓
lbe1_R-wKU8fgyRChtCD4m9iN8QpD

The publisher does not need to know ChatGPT’s private lbe1.

It needs to make the real-world identity unambiguous.

What changed with Samspitze 4

We have been tracking Samspitze 4, an apartment inside AlpiNest Feriendorf Lungau.

Earlier in the experiment, we observed:

Samspitze 4
↓
lbe1_hwcHov-PU9_ML4mChU2YPuVB

We then strengthened the Alpina entity graph with:

• an explicit relationship between Samspitze 4 and AlpiNest;
• a stable identity for AlpiNest;
• clear review provenance;
• a schema:hasMap link to the parent resort’s Google CID.

Later, we observed:

AlpiNest Feriendorf Lungau
↓
lbe1_R-wKU8fgyRChtCD4m9iN8QpD
↓
Google Place identity explicitly linked by Alpina

The important finding is not simply that an opaque ID changed.

The new ChatGPT entity can be reconciled to exactly the external place identity asserted by the publisher.

hasMap is useful, but not required

Fanningberg gives us a useful control. SalzburgerLand represents Fanningberg as a well-defined ski-resort entity, but in the structured data we inspected it does not expose a Google hasMap CID.

ChatGPT still resolves it correctly.

Therefore:

schema:hasMap does not create the entity and is not required for ChatGPT to resolve one.

Entity resolution can use multiple signals:

name
address
coordinates
phone
website
category
external sources

hasMap provides something more explicit:

a publisher-controlled assertion of which external real-world place the entity represents.

lbe1 powers the entity experience

The next question was whether lbe1 was merely response metadata.

Our HAR capture shows that it is operational.

When we clicked Fanningberg, ChatGPT opened the entity sidebar using the same:

entity_lookup_id:
lbe1_N0fAahpRpdylU3ed4w5PuLQQ

The entity experience then exposed:

Fanningberg
├── images
├── rating
├── description
├── Directions
├── Website
├── Call
└── Follow up

This gives us a stronger conclusion:

lbe1 is not only attached to the answer. ChatGPT uses it to retrieve and render the local entity experience.

There is, however, no public ChatGPT entity URI that we could observe.

The panel is created through an internal authenticated request rather than a stable URL such as:

chatgpt.com/entity/lbe1_...

So lbe1 should not be used as schema:sameAs.

A cleaner model is:

Publisher @id
   ├── hasMap → Google CID
   ├── sameAs → durable public identity pages
   └── identifier → observed OpenAI lbe1

For publishers, lbe1 is useful as an observability identifier, not as a canonical URI.

The entity becomes conversational context

The Follow up action revealed an even more consequential behavior.

After opening Fanningberg, we asked: “How many ski slopes are there?”

The visible question contains no entity name.

But the request carried:

targeted_reply: Fanningberg

ChatGPT also injected context equivalent to:

The user is referring to this in particular:
Fanningberg

The subsequent search became:

Fanningberg ski slopes number pistes km lifts official

The observable flow is:

Entity selected
      ↓
Entity context injected
      ↓
“How many slopes are there?”
      ↓
Fanningberg-specific fan-out
      ↓
Answer

This lets us make a much stronger statement than before:

Once a user selects a resolved entity, ChatGPT can carry that entity into the next turn and use it to contextualize subsequent retrieval.

We are not claiming that the literal lbe1 string is inserted into the search query.

The important finding is that entity selection shapes the semantic context of the follow-up search.

The entity is becoming the interface

Put these observations together:

User query
   ↓
Entity resolved
   ↓
lbe1
   ↓
Entity panel
   ├── Directions
   ├── Website
   ├── Call
   └── Follow up
           ↓
      Entity-scoped conversation
           ↓
      Entity-specific retrieval

Once ChatGPT has resolved the business, the website is no longer necessarily the primary interaction surface.

The entity itself becomes the interface.

That changes the meaning of AI visibility.

Getting the entity wrong can affect more than a map result or mention. It can influence the context from which subsequent questions are understood and searched.

What businesses should do

For local businesses, AI visibility increasingly becomes an identity engineering problem.

Focus on five things:

1. Give every important entity a stable @id.
   Do not model stores, hotels, branches, venues or products as anonymous page content.
2. Model relationships explicitly.
   An apartment is not its resort. A store is not its parent company. Connect them.
3. Keep identity signals consistent.
   Align name, address, coordinates, phone, website and business type across your website, Knowledge Graph and authoritative platforms.
4. Use schema:hasMap when a canonical map identity exists.
   A CID-based Maps URL points to a specific entity instead of forcing the resolver to infer one from a name.
5. Measure entity resolution, not only mentions.
   Track:
   • entity_lookup_id;
   • resolved entity name and category;
   • generated searches;
   • citations and map widgets;
   • entity-panel actions;
   • follow-up context;
   • subsequent retrieval.

The monitoring question becomes:

Which entity did the AI believe you were; and did it carry that identity into the conversation?

From Local SEO to identity engineering

AI systems increasingly reconstruct the web as a network of things, not simply pages.

Pages provide evidence.

Knowledge Graphs connect identities.

External identifiers support reconciliation.

AI systems build operational entity layers on top — and those entities can become conversational context.

The optimization question therefore changes from:

“Can ChatGPT find my page?”

to:

“Can ChatGPT correctly identify my entity and carry the right identity forward?”

Structured data may not materially improve retrieval across every AI system. But its impact on the underlying entity layer is becoming increasingly clear. It is becoming identity infrastructure. Our findings are deliberately narrow:

Structured data does not create the entity. It gives the publisher a way to declare which entity it means.

And once ChatGPT resolves that entity, it can become part of the user interface and the context for what happens next.

Review your entity landscape

Most organizations have dozens or thousands of entities represented differently across their website, structured data, Google, industry platforms and AI systems.

Book a demo with our Customer Success team and we’ll review the entity landscape of your business.

We’ll identify conflicting identities, missing relationships and opportunities to make your key entities easier for AI systems to resolve and represent correctly.

→ Review your entity landscape with WordLift

Methodology and further reading

These findings come from browser-level captures of our own ChatGPT sessions using the WordLift ChatGPT Search Observatory. We inspect Server-Sent Events, generated search queries, content_references, local-business objects, entity_lookup_id values, entity-panel requests and follow-up context.

These are observations of the current ChatGPT web client, not a public OpenAI API contract.

Related WordLift research

• The Hidden Entity Layer of ChatGPT: From Named Entities to Products
• OpenAI’s Emerging Semantic Layer
• Why SEO Success Now Depends on Entity Architecture, Not Volume
• How to Make Your Own SEO-Friendly Machine-Readable Entity IDs
• What Is a Knowledge Graph?

Independent research

• RESONEO — ChatGPT Search Architecture
• RESONEO — Google Maps, Geostore, Place IDs and CIDs
• GPTSpy — ChatGPT entity references

We connect ChatGPT’s lbe1 identifiers to externally verifiable Google Place identities, show that lbe1 powers the local entity experience, and observe that selecting a resolved entity can turn it into semantic context for subsequent retrieval and conversation.