What Is an Entity Graph? A Connected Map of Your Business

A business, a person and a service are different things

Here is a hypothetical example. Cedar Window Studio is the business. Maya is its founder. An in-home shade consultation is a service the studio provides in Post Falls. A project page shows the team fitting shades to a particular type of window. Each fact has a different role; the relationships explain how the facts belong together.

The business provides the consultation. Maya works for the business. The project page describes work by that business. Maya’s personal professional profile identifies Maya; the business profile identifies Cedar Window Studio. A manufacturer’s dealer page can support a dealer relationship, but it does not make the manufacturer the installer.

This is the practical idea behind “entity-first” content: connect the people, offer and evidence instead of repeating a company name. Our schema implementation guide shows how to turn that map into linked data.

Schema.org supplies vocabulary; JSON-LD supplies a format

Schema.org is a shared vocabulary of types and properties. JSON-LD is a standardized way to express linked data in JSON. They are commonly used together on websites, but neither is the business strategy itself.

The vocabulary includes types such as Organization, LocalBusiness, Person and Service. The implementation should choose types that genuinely describe the business. Specificity is useful when accurate; choosing a more prestigious type or adding unsupported properties does not improve the underlying facts.

Schema.org types and properties

Stable identifiers keep references consistent

A stable @id gives an entity an identifier that other objects can reference. A service can point to the same business identity that publishes an article. The author can point to the same person described on the About page. In JSON-LD, related nodes can be grouped in an @graph.

One giant block is not mandatory, and multiple blocks are not automatically wrong. What matters is coherent identifiers and relationships in the published data. Avoid creating contradictory versions of the same organization with different names, addresses or service areas.

W3C JSON-LD 1.1: identifiers and linked data

A useful graph starts with owner-approved facts

The owner’s identity and the business’s trading name should be clear. Services need scope and geography. Credentials belong to the actual holder. Awards need a recipient, issuer and date. External profile links should identify the same person or business, rather than unrelated pages with useful keywords.

The sameAs property is for identity links. It is not a generic place to put every authority website you would like associated with your brand. Other evidence may belong in visible citations or appropriately modeled relationships. Start with what a claim means, then choose how to represent it.

Evidence remains separate from assertion

A business can publish that it has an award. An issuing organization’s public record may corroborate the claim. Those are different sources. A good website makes that distinction understandable instead of treating its own markup as verification.

Some facts, such as current service limits, may be authoritative because the business itself sets them. Others need independent support. Maintain source links where possible and review them over time. A broken credential link or expired certification should trigger a check, not remain a permanent trust badge.

A graph supports understanding; it does not guarantee selection

AI systems can use ordinary text, search results, structured information and other sources. There is no universal rule that a graph is required before a business can be recommended. Different consumers use different parts of the web.

The graph’s practical value is to publish deliberate, consistent relationships that supported consumers can use. It can help reduce ambiguity, but it does not force a platform to accept every claim or grant a permanent position. Measure actual behavior without attributing every positive result to one technical feature.

The step from identity to capability

Once an assistant understands the business, its customer may ask it to do something. A description saying consultations are available does not tell software how to submit a request, what information to include or what the response means.

That needs an additional capability description and, where scoped, a working interface. It should define the action, conditions, permissions and outcome. The business model remains the source of the rules, while the action system enforces them. A personal assistant can then make a useful request without confusing it with a confirmed appointment.

How to review your own business map

Choose a service and follow the relationships from the customer’s question to the next step. Can you identify the provider, relevant person, service area, evidence and request process? Are the visible pages and structured data telling the same story?

• Check that repeated identities have consistent names and identifiers.
• Confirm that services and evidence connect to the correct business or person.
• Inspect facts that change: location, availability, price conditions and credentials.
• Test whether the next action is real, documented and accurately confirmed.

Ownership includes maintenance

An owned graph can travel with the website and be reused in future interfaces. It still needs an accountable person and an update process. A maintained representation of the business is sometimes called a digital twin; here, that means a useful model of the real business, not an autonomous replacement for its owner.

The work succeeds when customers and their assistants can understand the business more easily, make a better decision and take an appropriate next step.

Keep the map small enough to maintain. When adding or removing a service, update its page, related project links and structured data together. Start from an owner-approved website plan, not an automatic list of every property the vocabulary permits.