Building an entity: how a machine learns that your business is one thing

What is an entity, to a machine?

A thing with an identity that survives being mentioned in different places. People resolve that effortlessly: the Smith Plumbing on the van, on the website and in a neighbor's message are obviously one company. A machine has to do it from text, and it can only do it when the facts line up: the same name, the same address, the same phone number, the same trade. When they do, the mentions add up to one entity. When they do not, they stay separate claims that may or may not be about the same business.

This is why consistency comes up on every page of this site. In our audit of 9,483 small business websites (40 trades, 90 metros, September 2026), 43.1% contradicted themselves about who and where they are on their own homepage, contact page and about page. A business that cannot agree with itself on three pages gives a machine three candidate entities before it has read a single outside source.

The pieces a business entity is made of

Every property in the right-hand column is defined on schema.org's Organization and inherited by LocalBusiness and its subtypes. Google's organization documentation lists the ones it reads for a business's identity: name, url, logo, sameAs and contact points among them.

One node per thing, and an @id for each

The mistake that splits an entity inside the markup itself is restating it. A homepage says the business is at one address; the contact page carries its own LocalBusiness block with the address typed again, slightly differently; a service page carries a third. Three nodes, three versions. The fix is one node for the business, written once, with an @id, and every other block pointing at it by that identifier instead of repeating it.

JSON-LD gives a node an identifier with @id, conventionally a URL with a fragment: https://www.example.com/#business. A Service node on the drain-cleaning page then says "provider": {"@id": "https://www.example.com/#business"}, and a Person node on the about page says the same under worksFor. A parser that reads all three pages finds one business referenced three times rather than three businesses described once each.

<!-- homepage: the business, defined once -->
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://www.example.com/#business",
  "name": "Your company name",
  "url": "https://www.example.com/",
  "telephone": "+1 555 555 0100",
  "address": { "@type": "PostalAddress", "streetAddress": "100 Example Street", "addressLocality": "[City]", "addressRegion": "[State]", "postalCode": "[Code]", "addressCountry": "US" },
  "foundingDate": "[YYYY]",
  "sameAs": ["[your Google Business Profile URL]", "[your trade association listing URL]"]
}

<!-- a service page: the service, pointing at the business -->
{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Drain cleaning",
  "provider": { "@id": "https://www.example.com/#business" },
  "areaServed": ["[City]", "[Town]"]
}

sameAs: the property that joins the entity to the rest of the web

schema.org defines sameAs as a URL that unambiguously identifies the same thing elsewhere. For a business, that is the Google Business Profile, the listing on the trade association's member directory, the LinkedIn company page, a Wikidata item if one exists. Each one says to a machine: the business described on this page is the business described there.

Two rules keep sameAs from doing harm. List only profiles you have opened and that are unmistakably yours; a sameAs pointing at a different business with a similar name merges two entities into one, which is worse than leaving them apart. And list the profile, not a page that mentions you: a news article about the business is a mention, not the business. Mentions do their work in text; mentions and digital PR covers them.

The profiles have to agree with the node. A sameAs link to a directory listing that still carries last year's address tells a machine the two describe one entity and then shows it two addresses. Bring the profiles into line first, and link them second.

When your name is shared with another business

Many small businesses share a name with another one: another town's company, a software product, a person. A machine cannot tell them apart from the name alone, and it should not have to. Give it the other facts in the same place as the name: the trade in the first sentence, the town in the address, the founding year, the people. Write a one-sentence description that no other holder of the name could also use, and put it on the homepage and in the markup's description.

Where the confusion is persistent, say so plainly on the about page: which company you are, and which one you are not. Organization markup can carry a disambiguatingDescription for exactly this. It is an unglamorous sentence, and it is the one a machine needs when two entities share a string.

How to check the entity you have

1. View the source of the homepage, contact page and a service page, and count the business nodes. More than one full node is a split entity; make one the definition and point the others at its @id.
2. Read the name, address and phone in each node against the visible page and against each other. Any difference is a second version of the business.
3. Open every sameAs URL. Delete any that is not unmistakably you, and fix any profile whose facts disagree with the node.
4. Search your business name in quotation marks with your town and read the first two pages of results. Every page that describes you differently is a place where the entity splits; the Business Profile and the directories are usually first.
5. Ask ChatGPT, Claude, Gemini and Perplexity what they know about your business. An answer that mixes you with another company is the clearest sign that the disambiguating facts are missing.