Becoming a Recognisable Entity (Not Just a Website)

What "Entity" Means to a Machine, Not a Marketer

When marketers use the word "entity," they usually mean "brand." When a machine uses the word "entity," it means something far more specific: a discrete, identifiable thing in the real world that can be distinguished from every other thing, assigned a type, and described by a set of attributes and values. A person is an entity. A business is an entity. A city is an entity. A product can be an entity. The question is not whether your business is an entity in the philosophical sense, because of course it is, but whether it exists as one inside the systems that generate answers about it.

The distinction matters because a machine does not understand your business the way a customer does. A customer sees your logo, reads your tagline, browses your services page, and forms an impression. A machine builds a structured record: a filing card with slots for name, type, location, services, founding year, owner, accreditations, and dozens of other attributes. Each slot is either filled or empty. Each filled slot contains a value that is either consistent with what other sources say, or in conflict with them. The completeness and consistency of that card determines how confidently the machine can reference your business when generating an answer, and whether it references you at all.

This structured record is called an Entity-Attribute-Value (EAV) model. It is the data architecture that knowledge bases, including Google's Knowledge Graph, use to represent facts about real-world things. Every business in Google's Knowledge Graph has an implicit EAV record, whether that business has ever heard of the term or not. Google fills the card by extracting facts from everywhere your business is mentioned online: your website, your Google Business Profile, your directory listings, your review platforms, your social profiles, news mentions, and structured data markup. The more slots that are filled with consistent, verifiable values, the more confidently the machine can resolve your identity and include you in relevant answers.

The filing card analogy

Think of your business as a filing card that a machine is trying to complete. Entity: your business name. Attribute: service type. Value: emergency boiler repair. Attribute: location. Value: Dallas, Texas. Attribute: owner. Value: John Smith. Every one of those is a fact slot. Google fills them, or leaves them empty, based on what your content and your wider web presence actually say.

Knowledge Graphs, Wikidata, and Structured Identity

A knowledge graph is a structured database of entities and the relationships between them. Google's Knowledge Graph is the most consequential one for search, but it is not the only one. Wikidata, the structured data project behind Wikipedia, is another major source. Bing has its own knowledge graph (Satori). Each of these systems stores entities as nodes, with attributes as properties and relationships as edges connecting nodes to each other.

For a business, "being in the Knowledge Graph" is not a binary state with a clear threshold. Some businesses have a full Knowledge Panel on Google: a dedicated box on the search results page displaying their name, logo, description, address, and key attributes. Others exist as partially resolved entities: Google knows enough to classify them and surface them in local results, but not enough to display a dedicated panel. Others exist as unresolved references: the name appears in documents and queries, but the machine has not yet connected those references into a single, coherent entity record.

The goal of the Entity pillar in ECHO is to move from unresolved or partially resolved to fully resolved. This means ensuring that every system that might reference your business, whether Google's Knowledge Graph, Wikidata, or AI answer engines drawing on retrieved sources, can confidently map the name they encounter to a single, well-defined entity with a complete set of attributes. The practical work of getting there is less glamorous than it sounds: it involves structured data markup, consistent directory listings, correct business profile information, and clear, factual declarations on your own website that make the machine's extraction job as straightforward as possible.

Wikidata deserves specific mention because it is an open, queryable knowledge base that many AI systems draw on, either directly or through its influence on Wikipedia content. For businesses large enough to meet Wikidata's notability requirements, having a well-maintained Wikidata entry with correct property-

value pairs (industry, headquarters location, founding date, key people) provides a persistent, structured anchor that reinforces the entity's identity across multiple AI systems. For smaller businesses that do not meet Wikidata's notability threshold, the equivalent work happens through Google Business Profile, schema markup, and authoritative industry citations, the platforms where the machine looks when Wikidata cannot help.

The Gap Between Having a Website and Being an Entity

This is where most businesses stall, and it is worth being direct about why. Having a website does not make you an entity. Having a well-designed, beautifully written website with strong organic traffic does not make you an entity. It makes you a website. The gap between the two is the gap between content that reads well to a human and content that fills extractable fact slots for a machine.

Consider a typical local business website. The homepage says something like: "We're a family-run business with 20 years' experience offering quality services across the greater Dallas area." To a human reader, that sentence is fine. To Google's fact extraction system, it is close to useless. No business name. No specific service. No verifiable location. No owner name. No founding year. That sentence fills zero slots on the entity filing card.

Now consider the alternative: "ABC Plumbing, owned by John Smith, provides emergency boiler repair and pipe installation in Dallas, Texas. Our team responds within one hour." Same business. Completely different signal. Every clause fills a slot: entity name, owner, service types, location, response time. The first version is marketing copy. The second is an extractable declaration. Both are readable. Only one builds an entity.

The entity home concept, a specific web page from which search engines and AI systems learn the entity's identity, attributes, and values, makes this distinction operational. Your entity home is the canonical document that defines who you are. It is the centroid within the cluster of web pages that reference your business, the page that the machine treats as the authoritative source for your identity. In practice, this is usually your homepage or your "About" page, but it only functions as an entity home if it contains clear, structured, factual declarations that the machine can extract, not just a narrative that the machine has to interpret.

The work of bridging this gap is not about rewriting your entire website in machine-friendly jargon. It is about ensuring that the first few hundred words

of your most important pages contain an EAV declaration block: a structured set of factual statements that declare your entity name, your entity type (what class of business you are), your primary attributes (location, services, specialisms, credentials), and the specific values for those attributes. One wellcrafted paragraph can do more for your entity resolution than an entire content hub of vaguely worded service descriptions.

What an EAV declaration block looks like

"Smith & Sons Plumbing is a Gas Safe registered plumbing company based in Camden, London, established in 2008, specialising in emergency boiler repair and Victorian-era pipework restoration." That single sentence declares: entity name, entity type, accreditation, location, founding year, and two specialisms: six attribute-value pairs that build the knowledge base entry.

Common Entity Mistakes Small and Mid-Size Brands Make

The mistakes that prevent businesses from becoming resolved entities are, in almost every case, mistakes of omission rather than commission. They are things not done and facts not stated. The most common ones, drawn from realworld case studies and practitioner experience, fall into predictable patterns.

The first and most damaging mistake is inconsistency across sources. Your website says one service area, your Google Business Profile says another, your directory listings show an old address. Every conflict introduces noise into your entity profile. When multiple independent sources confirm the same fact about your business, the machine's confidence goes up. When they contradict each other, confidence drops, and the machine ranks you less confidently, which means lower positions and fewer relevant appearances. The fix is not perfection across every directory on the internet; it is consistency on your most authoritative sources. Your Google Business Profile, your homepage schema, your primary industry citations: these must agree.

The second mistake is vague self-description. Businesses describe themselves in marketing language ("quality services," "innovative solutions," "customerfirst approach") rather than in extractable fact language. Every vague phrase is a missed attribute slot. The machine does not know what to do with "quality services" because it is not a fact. It is an assertion without a verifiable value.

"Emergency boiler repair with a one-hour response time in Camden, London" is a set of facts the machine can store and cross-reference.

The third mistake is missing structured data. Schema markup, whether LocalBusiness, Organization, Person, or the appropriate subtype, is the most direct way to tell a machine what your entity is. It is not a ranking factor in the traditional sense; it is an identity signal. Without it, the machine must infer your entity type from unstructured text. With it, you are declaring your type, your attributes, and your values in a format the machine is specifically designed to consume. Many small and mid-size businesses either have no schema at all, or have generic schema that declares almost nothing useful.

The fourth mistake is having no entity home. If no single page on your website functions as a clear, authoritative, comprehensive definition of your business, declaring who you are, what you do, where you operate, and what distinguishes you, then the machine has no centroid for your entity. It will attempt to construct one from whatever fragments it finds across the web, and the result will be less accurate and less favourable than what you would have chosen yourself. A real-world case study illustrates the risk vividly: a prominent professional's knowledge panel displayed an incorrect education attribute after someone edited a Google Business listing for the affiliated institution. That single change in one data source propagated into autocomplete, Google Trends, and the public knowledge panel before it was corrected, because the machine had no strong, consistent, canonical entity home to anchor the correct fact against.

The fifth mistake is treating entity building as a one-time task rather than an ongoing discipline. Entity identity is not static. Knowledge graphs update. Sources change. Competitors' actions can affect your entity resolution. Directory information drifts. The machine is constantly re-deriving its understanding of who you are from the latest available evidence. A business that built a clean entity profile two years ago and has not touched it since may find that its profile has degraded, not because it did anything wrong, but because the information ecosystem around it has shifted.