Entity architecture: being recognized as an entity.
Entity architecture is how a site establishes who it is, what it knows and what it relates to, in a form machines can recognize as an entity.
Search engines moved from words to entities long ago. A query is no longer answered by text matching alone but by understanding which entity the query is about. Answer engines carry that logic further — when composing an answer, they derive which source is an authority on which topic from entity connections.
The practical consequence: a site being “an expert on X” is established not by using the word often but by being recognized as an entity related to that topic. Entity architecture is the work of building that recognition.
Three questions
A machine’s recognition of an entity depends on answering three questions. All three can be answered on the site itself, and all three are missing on most sites.
- Who — identity as an organization or a person. Name, type, contact, logo, founder, employee.
- What it knows — areas of expertise. On which topics it claims authority.
- What it relates to — which other entities it is connected to. The articles it writes, the services it offers, the work it has done, the verifiable profiles.
Together the three form a graph, and the graph’s value is in its connections. An isolated organization node is a business card; an organization node connected to services, articles and projects is a map.
Identity: one node, referenced from everywhere
The most frequent mistake is making separate, unconnected identity declarations on every page. Machines then cannot tell whether these are ten different organizations or ten declarations of the same one.
The correct pattern defines the identity once and references it from everywhere. The organization is defined once and receives a stable identifier; every page points to that identifier. The graph becomes a single-centered structure instead of a scattered pile.
That is exactly how the graph is built on this site: the organization, person and website nodes are defined with stable identifiers, and the service, article, case and page nodes connect to them by reference. On a service page eight nodes stand together, all interconnected.
Saying what it knows
Declaring areas of expertise in the schema is an item most sites skip, and its cost is writing a list. That list feeds the model’s “who is this and what do they know” matching directly.
What matters when writing the list is honesty. You list the areas where the site actually produces content and does work; you do not list areas you would like to claim but cannot back. An unbacked claim of expertise works in reverse, because it contradicts the rest of the site.
The same logic applies to the person node: title, areas of expertise and, where they exist, verifiable profiles. In a one-person studio, connecting the organization and the person to the same entity — declaring one as the founder and employee of the other — keeps the graph consistent.
An unbacked claim of expertise works in reverse, because it contradicts the rest of the site.
The no-fabrication rule
Some entity fields point at verifiable external data: address, phone, social profiles. If they really exist, they are written; if not, they are NOT. Pointing at a profile that does not exist or declaring an unused address makes the graph untrustworthy.
On this site that rule is enforced in code: because the owner has shared no social profiles, the field is not rendered at all, and the verification suite checks on every run that no fabricated profile link has been added. The field stays empty, but it does not lie.
The same discipline covers measurement claims. A number is written only if it was measured; an unmeasured result enters neither the schema nor the text. Because answer engines cross-verify, an unverifiable claim does not increase trust — it reduces it.
The order of building the graph
Entity architecture is not built in one pass; it grows layer by layer, and each layer leans on the previous one. Skip the order and the later layers run on empty, because there is no center for them to connect to.
- One — the identity node. Organization or person, with a stable identifier, defined in a single place.
- Two — the website node and the page nodes. Every page carries its own node and connects to the identity.
- Three — the content nodes. Articles, services, projects; all connected to the identity and the pages.
- Four — expertise and relationship fields. What it knows, where it appears, what it rests on.
- Five — external verification. Profiles, records, third-party mentions.
The fifth layer lives outside the site and is the most neglected. An entity existing only on its own site means there is a single source about it — and models treat single-source information with caution. The same identity appearing in the same form elsewhere provides verification.
On this site the first four layers are in place; the fifth depends on the owner and stands empty on purpose. When profile addresses arrive, the field will fill by itself — and until they do, nothing will be invented.
Auditing the graph
The way to know whether a built entity graph really works is to read it like a machine. Google’s and schema.org’s validation tools extract the structured data on a page and show the node list; what you look for is not whether there are errors but whether the resulting structure describes what the site actually is. An error-free but meaningless graph is technically valid and useful for nothing.
Three questions to ask in the audit. One: are the identity nodes single, or redefined on every page? Two: are the nodes actually connected, or independent blocks standing side by side? Three: is everything in the graph also on screen? The third is the most critical, because violating it both breaks search engine rules and puts the page in contradiction with itself — and when the model notices a contradiction, trust does not rise; it falls.
Finally, the graph has a maintenance side. As pages are added and content changes, the nodes must change too; hand-written schemas drift from reality within a few months. Generating the schema from the build — exactly as with the map file — makes that drift structurally impossible.