Entity & Knowledge Architecture

Most brands with an entity problem are not missing from the engines. They are smeared across several half-formed versions of themselves. One source has the old company name, another has a former address, a third confuses you with a similarly named business two provinces over. The engine holds all three and commits to none.

You can see this without any tooling. Ask an assistant who your company is and read the answer closely. Hedging language, a wrong founding year, a competitor's service list attached to your name: each is the model telling you it could not resolve you cleanly.

Entity architecture is the work of collapsing those variants into one confident answer. Not more content. Fewer contradictions.

These two disciplines get sold as one thing and they are not, so it is worth drawing the line precisely.

Entity architecture answers who you are. It is identity work: the name, the founders, the location, the service list, the identifiers that tie your presence together, and the structured data that states all of it in a form a machine can parse without guessing. Its success condition is that an engine can resolve you to one thing with high confidence.

Semantic authority answers what you know. It is subject-matter work: the depth and interlinking of your coverage on a topic, and the experience and credentials behind it. Its success condition is that an engine treats you as a credible source on a subject.

The order matters. Authority attached to an unresolved entity leaks, because the engine cannot reliably decide which company earned it. We do identity first and depth second, and on most engagements the first month is entirely identity.

Structured data has been oversold as a citation lever and undersold as a disambiguation tool, which is close to backwards.

The published evidence is unhelpful for the citation claim. Ahrefs' controlled test found AI Overview citations declined after schema was added, and a controlled enterprise-retrieval study found JSON-LD barely moved accuracy while legible entity pages did. We take those results seriously.

What schema does do well is remove ambiguity. A correctly typed Organization node with a stable identifier, a Person node for the founder that every page references rather than re-declaring, a service list that matches the pages that exist: these give a resolver something unambiguous to bind to. That is a real job and it is worth doing properly.

The rule we hold to is that an entity gets declared once, with an identifier, and every later reference points back at it. Two inline copies of the same person on one site give a resolver no basis to merge them, which is the exact failure this work exists to prevent.

An entity gets solid when independent sources agree. That is why this work reaches past your own site almost immediately.

The practical list is short and unglamorous: a Google Business Profile with details matching your site exactly, a LinkedIn company page that agrees with both, directory and association entries with the same name and address strings, and where they exist, authority records such as Wikidata. Byte-identical is the standard. Suite 200 and Unit 200 are two different addresses to a matching algorithm.

We also look for what is actively wrong. A dead profile with a former address does more damage than a missing one, because it gives the engine a contradiction to reconcile rather than a gap to fill.

For small firms the founder is often the strongest entity available, and frequently the least well defined. Name collisions are the common case rather than the exception, and a model with two candidate people and no distinguishing detail will either hedge or pick wrong.

The fix is boring and effective: state the name with the role and the city together, consistently, everywhere. Attach the person to the organization in both prose and structured data. Point at the profiles that already exist and are verifiably theirs, rather than inventing a presence that is not there.

This is also where thin about pages cost the most. A founder page with 170 words and no name in the heading is not a disambiguation anchor, whatever the schema underneath it says. The markup can be perfect and still have nothing to resolve against.

The entity audit itself is quick — days, not weeks. We map every place your business is described on the open web, record what each one claims, and produce the contradiction list. That document is usually the most uncomfortable deliverable in the engagement and the most useful.

Fixes split into two piles. The ones on your own property are fast, because we control them. The third-party corrections are slower and involve claiming profiles, filing edits and waiting for recrawls, which is why entity work is measured in weeks and months rather than days.

It works as a standalone project with a clear end point, and it is the piece we recommend first when a business has never done it. Everything downstream compounds on top of a resolved identity, and very little compounds without one.

Once the individual entities are clean, the next job is the edges between them. An engine does not just need to know that you exist. It needs to place you: this company employs this person, offers these services, works in these places, served these clients, wrote these articles.

Each of those relationships is a path by which you can be retrieved. A founder who is a resolved entity in their own right, tied to an organization that is tied to a subject, gives an engine three routes to your name instead of one. That is why the founder work and the service-page work are not separate projects.

Google's confirmed patents in this area cover knowledge panel aggregation, disambiguation, query-entity association and entity-metric ranking. Those are the documented mechanisms, and they are what we build against. Several of the entity patents circulated in SEO commentary as Google's, including the GraphRAG work, belong to Microsoft and IBM, and building strategy on a misattributed patent is a good way to spend a quarter on the wrong thing.