Entities, Attributes, and Why Google Ranks Topics Not Keywords

Atamyrat Hangeldiyev

Systems Architect

January 27, 2026

The entity-attribute-value model is the way a search engine represents the world as identifiable things, the properties that describe each one, and the facts that fill those properties, which is why it resolves and ranks topics and entities rather than matching the keyword strings on a page, in the context of small and mid-sized businesses trying to be understood by search. It is not a keyword theory and it is not a synonym for "topics". It is a description of the data structure the engine builds before it ranks anything, and once you can see that structure, why coverage and clarity beat repetition stops being a slogan and becomes obvious.

A regional water-treatment company put its target phrase on a page two hundred and forty times and the engine still could not tell what the business was. The phrase was in the title, the first line, six headings, every image filename, the footer, and a sentence that repeated it four times in a row because a tool flagged the density as low. Read by a person, the page was unreadable. Read by the engine, it was worse than unreadable: it was uninformative. Nowhere did the page state plainly that this was a company, that it serviced commercial cooling systems, that it operated in a specific region, or what the relationship between those facts was. It said the same string over and over and asserted nothing. A two-person competitor published one page that used the phrase maybe three times and instead said, in plain sentences, that it was a water-treatment company, that it serviced industrial cooling towers, where it worked, and what a service contract covered. The engine understood the second page in a way it never understood the first, not because the second page repeated the words more cleverly, but because the second page named a thing, said what kind of thing it was, and stated what was true about it. The first page had the words. The second page had an entity. The engine ranks the second one, and the gap between having the words and having an entity is the entire subject of this guide.

This guide explains the model and hands the rest off at the seams. It explains what an entity, an attribute, and a value are, why an engine resolves and clusters them instead of matching strings, and how to look at your own business as a set of them, so a non-technical owner finishes able to see why a clearly stated, well-described thing beats a repeated phrase. It does not redefine what modern SEO now is, it does not re-explain the authority a clear site earns, it does not give the step-by-step procedure for turning entities into a topical map, and it does not teach the schema markup that encodes entities for machines. Each of those is its own guide, and this page links to them where the boundary falls. The job here is to make the model sharp enough that the rest of the pillar has a mechanism to point at.

Entities, attributes, and values: what Google actually ranks

The entity-attribute-value model is three connected ideas: an entity is a specific thing the engine can identify and tell apart from other things, an attribute is a property that thing can have, and a value is the actual fact that fills a property for that specific thing. The engine does not rank the words on your page directly. It reads the page to work out which things the page is about, what those things are, and what is true about them, builds that into a structure of entities with attributes and values, and ranks based on that structure. The words are how the engine gets to the structure. The structure is what it ranks.

This is the one model the rest of the pillar leans on, so it is worth defining each part with no jargon and a real example before anything else is built on top of it.

What an entity is, what an attribute is, what a value is

An entity is a specific, identifiable thing: this company, this service, this city, this person. Not the word for it, the thing itself. "Plumber" is a word. "A specific commercial plumbing company that operates in one metro area" is an entity, a thing the engine can pin down and distinguish from every other company. The test of whether something is an entity to the engine is simple: can the engine tell this exact thing apart from everything that resembles it. If it can, it has an entity. If all it has is a word that could point at thousands of unrelated things, it does not have an entity yet, it has a string.

An attribute is a property an entity can have: the kind of thing it is, what it does, where it operates, who runs it, what it costs, how it relates to other entities. Attributes are the slots. For a service business the slots include what category of business it is, which services it offers, which area it serves, what certifications it holds, what a typical engagement involves. An attribute on its own is empty. "Service area" is an attribute. It is a question the engine wants answered about the entity, not the answer.

A value is the fact that fills a slot for one specific entity. The value of the "kind of business" attribute might be "commercial plumbing contractor". The value of the "service area" attribute might be "one named metropolitan region". The value of the "services offered" attribute is the actual list of services. Values are where the meaning lives. An entity with named attributes and filled values is a thing the engine understands. An entity with no values filled is a name the engine cannot do anything with.

A topic, in the engine's terms, is not a fourth thing. A topic is what you get when a set of related entities, with their attributes and values, are connected to each other. "Commercial backflow testing" as a topic is the backflow-testing entity, connected to what a test checks, the assembly it is performed on, the regulation that requires it, the failure that makes it necessary, and the company that performs it, each of those an entity or an attribute with values. The engine "covers a topic" by assembling that connected structure. That is why later in this guide the move from a list of entities to a connected topic matters so much: a pile of unconnected entities is not a topic the engine can recognize, and connection is what turns the pile into one.

An example: the keyword-repeating page versus the entity-clear page

The fastest way to see the difference is to put the two pages side by side on one ordinary business, a two-location commercial HVAC company, and read each the way the engine does, by asking what entity it can identify and what it learns is true about that entity.

Same company, same query, same building manager searching it. The keyword-repeating page was written for a model that counted strings and is now a page that asserts nothing to a model that reads for things. The entity-clear page was written, intentionally or not, the way the engine actually reads: it names the entity, says what kind of entity it is, and fills in what is true about it. Nothing here is technical. It is the difference between a page that contains a phrase and a page that states a thing and its facts, and the engine ranks the second because the second is the only one that gave it a structure to rank.

The engine resolves things, it does not match strings

A modern search engine resolves the page to a set of entities and their attributes and values, then ranks against that resolved structure, which means it is not asking "does this page contain the query string" but "is the thing this page is about the thing the query is about, and does the page state what is true about it". This is the load-bearing claim of the guide. If it holds, and it does, then repeating a phrase is optimizing for a step the engine no longer performs, and stating entities clearly is optimizing for the step it actually performs.

The reason the engine moved from matching strings to resolving things is that string matching answered the wrong question. A person searching "is a cracked tooth an emergency" does not want the page that contains those five words the most times. They want the page that is genuinely about the cracked-tooth entity and states the values that decide their question. String matching could not tell a page that resolved that from a page that merely repeated it. Resolving the page to entities and facts can, because it is checking whether the page actually says true, specific things about the right thing, not whether the characters line up.

Why a clearly stated entity beats a repeated keyword

A clearly stated entity beats a repeated keyword because the engine ranks on the structure it can extract, and a clear statement of an entity and its values yields a rich structure while a repeated string yields almost none. Repetition adds nothing to the structure. The tenth occurrence of a phrase fills no new slot, distinguishes no thing, states no fact. A single plain sentence that says what the business is and what it does fills several slots at once. The engine is not rewarding the clear page for being pleasant to read. It is ranking it higher because it could actually build something out of it.

A niche industrial-supply shop selling specialty fasteners shows the asymmetry cleanly. One page repeats "specialty fasteners supplier" thirty times and the engine ends up with a vague entity and one weak value. Another page says, in ordinary sentences, that the shop is a specialty-fastener supplier, that it stocks corrosion-resistant fasteners for marine and chemical environments, that it cross-references discontinued part numbers, and that it ships from one regional warehouse. That is four filled attributes from four sentences. The engine now knows what the entity is, what it sells, the environments it serves, and a distinguishing capability. The repeated-phrase page handed the engine a word it already had. The clear page handed it a thing it can rank for the precise queries fasteners buyers actually run, which is the whole return.

How attributes and values let an engine cluster a topic

Attributes and values are what let an engine cluster a set of pages into a topic, because the engine recognizes a topic by seeing the same entities and attributes connected and consistently described across the pages, not by seeing the same keyword appear on all of them. A cluster of pages that all repeat a phrase looks, to the engine, like a cluster of pages that all repeat a phrase. A cluster of pages that each fill in attributes of the same connected set of entities looks like one coherent treatment of a subject, because the structure the engine builds from page two extends and agrees with the structure from page one.

Take a commercial-roofing company covering flat-roof replacement. One page states what the membrane-type entity is and its values: the types, what each costs to own over its life. Another states the tear-off entity and its values: what a tear-off involves, when it is required instead of a recover. Another states the warranty entity and its values: what is covered, what voids it. Each page names real entities and fills real attributes, and the entities overlap and connect across the pages: the membrane entity reappears when the warranty page explains what voids coverage, the tear-off entity reappears when the cost page explains lifetime cost. The engine assembles these into one structure and concludes the site covers the flat-roof-replacement topic, because the entities and their values connect into a single coherent thing. That assembly, the engine seeing connected entities and consistent values across pages, is precisely the machinery underneath the words "topic coverage", and it is why the model and not the keyword is the unit that matters.

Why this is the most useful model an SMB can hold

The entity-attribute-value model is the single most useful mental model an SMB can hold about modern SEO, because it is the only one that explains, in one structure, why complete coverage and clear statement beat repetition and volume, and why a small focused site can be the source on a subject a larger one is not. Every other piece of advice a small business gets ("write for humans", "cover the topic", "be the authority") is a consequence of this model. The model is the thing that makes those instructions mean something specific instead of staying vague.

This is also the precise point where this guide states a boundary and holds it. The model explains why an engine can recognize a complete, connected treatment of a subject as authoritative. It does not, here, explain the outcome that recognition produces, the durable visibility a small site earns by being that recognized source against larger competitors. That outcome is topical authority, and it is a full subject with its own guide: how a small site out-ranks big ones with topical authority. The relationship between the two is reciprocal and worth stating exactly, because the rest of the pillar depends on the seam being clean. That guide explains that complete, connected coverage earns authority and why it beats a bigger budget. This guide explains the entity model that is why the engine can read that coverage as authority at all. The authority guide is the mechanism a small business uses to win; this guide is the machinery that makes the mechanism work. Read that guide for the outcome and the competitive case; this one is the structure underneath it, and the two link to each other as halves of one answer rather than repeating each other.

Your business, written as entities, attributes, and values

Any business can be written out as a small set of entities, the attributes each one can have, and the values that fill them, and doing that on paper before touching the site is what turns the model from a concept into something you can act on. The decomposition is not technical and it does not require tooling. It requires answering three questions honestly about your own business: what are the things, what can be true about each thing, and what is actually true about it. The output is a short structured description of the business that the site's pages then have to state plainly.

The point of doing this first is that most SMB pages fail not because the writing is bad but because nobody ever decided what entities the page is supposed to make legible. The decomposition decides that.

Find the entities: the business, the services, the area served, the people

The first step is naming the entities, and for almost every SMB they fall into the same four groups. There is the business itself, one entity: the specific company, with a category, not a generic noun. There are the services or products, each a distinct entity: not "what we do" as a blur, but each offering as its own identifiable thing the engine should be able to tell apart. There is the area served, an entity for a business that operates somewhere specific: a named region or set of locations, not "your area". And there are the people where they matter to credibility: the named practitioner, the certified specialist, the owner whose expertise the business trades on.

A two-location commercial-cleaning company, decomposed, has the business entity (a commercial janitorial company, specifically, not "cleaners"), several service entities (recurring janitorial, post-construction cleanup, floor care, each distinct), an area-served entity (the two named metro areas it actually covers), and a people entity only where a named, credentialed person genuinely matters to trust. Listing them this plainly already does work, because it forces the question most pages never ask: which exact things is this site supposed to make the engine understand. A business that cannot list its entities cleanly has no chance of a site that states them cleanly.

Give each entity its attributes and values

The second step is giving each entity its attributes and filling in the values, which is where most of the real thinking happens, because a named entity with empty attributes is still invisible to the engine. For the business entity the attributes are at least: category, services offered, area served, credentials, who it serves, what an engagement involves. For each service entity: what it is, who it is for, what problem it resolves, how it differs from the adjacent service, what it typically costs or what drives the cost. For the area entity: exactly where, and any locations or constraints inside it. For a people entity: role, credentials, what they are specifically expert in.

The cleaning company's post-construction-cleanup service entity, filled in, is not "we also do post-construction cleanup". It is: a distinct service for general contractors and property developers, performed after a build or renovation before occupancy, covering debris removal, surface and fixture detailing, and a final inspection-ready clean, distinct from recurring janitorial in scope and timing, priced by site size and phase. That is one service entity with six attributes filled. A page about that service that states those values gives the engine a complete thing to rank for the queries a contractor actually runs. A page that just says "we do post-construction cleanup, contact us" gives it a named entity with every slot empty, which ranks for nothing because there is nothing in it.

Connect them so the engine sees one coherent thing

The third step is connecting the entities so the engine reads them as one coherent business and subject rather than a set of unrelated facts, because an engine recognizes a topic by seeing entities related to each other, not merely present on the same domain. The connections are the relationships you already know are true: this service is performed in this area, this service is delivered by this credentialed person, this service is the one chosen instead of that adjacent service under these conditions, this business is the entity that offers all of them. Stating those relationships, on the pages and through how the pages link, is what makes the structure cohere instead of scatter.

This guide names the connection step and stops exactly at its boundary, because turning "connect the entities" into an actual plan, the specific set of pages, the order to build them, and how the cluster is mapped before a word is written, is a disciplined procedure with its own guide: how to build a topical map for your business. That guide takes the entities and attributes you just listed and turns them into a sequenced map of pages. The boundary is clean and worth stating once: this guide gives you the entities, the attributes, the values, and the requirement that they connect; that guide gives you the procedure that turns the requirement into a built cluster. The model is here, the map is there, and the decomposition you just did is exactly the input that guide consumes.

The three ways an SMB page fails the entity model

SMB pages fail the entity model in exactly three ways: ambiguous identity, where the engine cannot tell what thing the page is about; missing attributes, where the thing is named but nothing is said about it; and disconnected values, where the facts are present but unrelated to each other. These are not three styles of bad writing. They are three specific structural failures, each one a different empty place in the structure the engine tries to build, and each one has a concrete fix at the page level. A page can fail one and pass the other two. Naming which one a page fails is what tells you what to actually change.

Ambiguous identity: the engine cannot tell what the page is about

Ambiguous identity is the failure where the page never states plainly what entity it is about, so the engine has to guess and usually guesses weakly or wrong. This is the most common and the most damaging failure, because every other part of the structure depends on the engine first knowing which thing it is reading about. A page can be full of correct, useful sentences and still fail here, if it never says, in plain terms, "this is a commercial plumbing company that does X in Y". The engine is left to infer the entity from scattered hints, and an inferred entity is a weak entity.

A regional pest-control company's services page that opens with "Pests can cause serious damage to your property and peace of mind" and continues in that register for four paragraphs has ambiguous identity. Nothing has stated that this is a pest-control company, what kind (residential, commercial, both), or where it operates. The fix is not more keywords. The fix is a plain statement of the entity early and unambiguously: this is a commercial pest-control company serving a named region, specializing in named problems. One clear sentence that names the thing does more for the page than any amount of keyword density, because it converts a guessed entity into a stated one, and the engine ranks the stated one.

Missing attributes: the entity is named but not described

Missing attributes is the failure where the page does name the entity but fills almost none of its slots, so the engine knows what the thing is and nothing true about it. This is the failure hiding inside most "we do X, contact us" pages. The identity is fine: it is clearly a roofing company. But the page never states the values, what kind of roofing, for what buildings, in what area, what a project involves, how the decision is made. A named entity with empty attributes ranks for almost nothing, because ranking is competition on what is true about the thing, and this page has stated nothing true to compete on.

A commercial-roofing company with a page that says "We are a trusted commercial roofing contractor. Quality workmanship. Contact us for a quote" has named the entity and filled zero attributes. The fix is to state the values that the decomposition already produced: which roof systems, which building types, which region, what a typical replacement involves, how a repair-versus-replace call is made. Each stated value is a slot filled and a set of real queries the page can now rank for. The page does not need to be longer for its own sake. It needs the empty slots filled with the facts that are already true and simply were never written down.

Disconnected values: the facts are present but unrelated

Disconnected values is the subtlest failure: the page states facts, but as an unrelated list, so the engine gets values it cannot relate to each other or to a coherent entity. The page has the pieces and no structure. It lists services in one place, a service area in another, credentials in a third, and never states the relationships, that this service is delivered in this area by this credentialed team, that this service is chosen instead of that one under these conditions. The engine receives a bag of true facts and no thing they describe together, which is closer to ambiguous identity than the page's authors realize.

A two-location electrical contractor whose page has a list of services, a separate "areas we serve" block, and a separate "our certifications" block, with no statement tying them together, has disconnected values. The engine cannot tell whether the certifications apply to all services, whether every service is offered in both locations, or how any of it relates. The fix is connective statements, not more facts: this licensed team performs these specific services across these two named areas, this service is the one chosen over that adjacent one in these conditions. The relationships are the structure. Stating them is what turns a list of true facts into one coherent entity the engine can rank as a source, and it is usually the cheapest of the three fixes because the facts are already on the page and only the connections are missing.

The entity model versus the things it gets confused with

The entity model gets conflated with four near-neighbors, and each conflation sends an SMB's effort at the wrong thing: a keyword, a loosely used "topic", the schema markup that encodes entities, and the topical authority the model produces. Each of those is a different thing owned by a different question or guide, and keeping them apart is what lets a business act on the model itself rather than on something that resembles it. Here is each one, what it actually is, and where it is owned.

Entities vs keywords

A keyword is a string a person types; an entity is a thing the engine identifies. They are not two versions of the same concept. The keyword was the unit of ranking in the model the entity replaced, when the engine matched the characters on the page to the characters in the query. The entity is the unit now, because the engine resolves the page and the query to things and compares those. The practical consequence is the whole reason this guide exists: optimizing for the keyword means making the string appear, which fills no slot in the structure the engine ranks, while optimizing for the entity means stating the thing and its values, which is the structure. A business still uses the words people search, because the words are how the engine reaches the entity, but the words are the entrance, not the thing being ranked. Treat the keyword as a signpost to the entity, never as the thing itself, and the rest of the model follows.

The entity model vs a loosely used "topic"

"Topic" used loosely means a vague theme, "we should have content about commercial HVAC". The entity model is the precise machinery underneath that word: a topic, exactly, is a connected set of entities with their attributes and values, recognized by the engine because the structure is consistent and connected across the pages. The reason this distinction is not pedantic is that "cover the topic" is unactionable until you know what a topic is made of. Decomposed through the model, "cover the commercial HVAC topic" becomes a specific instruction: name these entities, fill these attributes with these values, connect them this way. The loose word names the goal. The model is what makes the goal a set of concrete things to state. When a vendor says "we'll build out your topic", the model is the test of whether they mean a connected entity structure or just more pages with the phrase in them.

The entity concept vs the schema markup that encodes it

Schema markup, the structured-data vocabulary from schema.org, is the machine-readable way to state your entities and their attributes to a search engine in code, so the engine does not have to infer the structure from prose alone. It is not a different concept from the entity model. It is the entity model written in the format machines read most directly: the same business entity, the same attributes, the same values, declared explicitly rather than left for the engine to extract from sentences. The entity model is the concept; schema is one encoding of it.

This guide deliberately does not teach that encoding, because the markup, which schema types to use, how to express the business and its services and area as structured data, how to validate it, is a full implementation subject with its own guide: structured data that actually helps an SMB rank. The boundary is exact and worth stating once: the entity model here is conceptual, the thinking you do about what your entities and values are; the JSON-LD and schema.org implementation that states those entities to machines is owned entirely by that guide. Naming the entities is this guide's job. Encoding them in markup is that one's. Do the thinking here, then read that guide to make it machine-readable, and do not expect this guide to teach markup syntax it deliberately hands off.

The entity model vs the topical authority it produces

Topical authority is the durable visibility a site earns once its entities are legible and its coverage is complete and connected; the entity model is the explanation of why the engine can recognize that completeness in the first place. The model is the cause. The authority is the effect. This guide owns the machinery. The competitive outcome, why a small site that gets its entities clear and its coverage complete out-ranks a larger, better-linked one, and how that authority is built and held, is owned by how a small site out-ranks big ones with topical authority, which links back here for the mechanism.

What thinking in entities changes about your pages

Thinking in entities instead of keywords changes three concrete things about your site: how a page is written, what a content plan actually is, and what your structured data should say. These are the second-order consequences where the model stops being a way of seeing and becomes a set of changes on the site, and they are the reason this guide is an on-ramp to the rest of the pillar rather than the end of the subject.

How it changes the way a page is written, from repeating to stating

The most immediate change is at the sentence level: a page written for entities states the thing and its values plainly instead of repeating the string, which is a different writing discipline, not a heavier dose of the old one. Under the keyword model the instruction was "use the phrase enough times". Under the entity model the instruction is "name the entity unambiguously, then state what is true about it, then connect those facts". The page that results reads better to a person and ranks better to the engine for the same reason: both are trying to extract a clear thing and its facts, and the entity-written page is the one that hands them over.

This is the honest place to say where this work actually lands for most SMBs. Rewriting a site so every page states its entities clearly, fills the real attributes with true values, and connects them into a coherent structure is sustained editorial and structural work across the whole site, not a one-page edit, and it demands deciding what the business's entities are and then stating them with a discipline that is a job rather than a side task. It is not work a busy ten-to-two-hundred-person company typically has the in-house capacity to run well. Doing exactly that, making a site's entities legible to an engine that resolves things instead of strings, is what Iron Goo's SEO service exists to execute for companies that do not staff it internally. That is the contextually honest bridge: the model is simple to understand and genuinely demanding to apply across a real site, and the reason most SMBs do not apply it is not that they cannot grasp it, it is that nobody on the team owns the structural rewrite.

How it becomes a map you can actually build

Thinking in entities changes a content plan from a list of article ideas into a map of entities and attributes to cover, which is a more precise and more buildable thing. A keyword-era plan is a list of phrases to write pages for. An entity-era plan is the decomposition you did earlier, the entities, their attributes, the values, and the connections, turned into a sequenced set of pages that together make the structure complete and coherent. The plan stops being "topics we could write about" and becomes "the entities and attributes this site must make legible, in this order".

This guide takes you to the edge of that and hands it off, because turning the decomposition into an actual sequenced map of pages is a disciplined procedure owned by how to build a topical map for your business. The seam is clean and stated once: this guide gives you the entities and attributes; that guide gives you the procedure that orders them into a built cluster. The decomposition here is the raw input that guide consumes, and the reason the model comes before the map is that you cannot sequence entities you have not yet named.

How it becomes markup a machine can read

The last change is that thinking in entities gives you something specific to encode in structured data, instead of guessing which schema to add. Once you have the business entity, its attributes, and its values written out, the markup is no longer a mysterious technical add-on. It is that same structure, stated to machines in the format they read most directly. The model is what makes the markup meaningful: without the decomposition, schema is cargo-culted snippets; with it, schema is your actual entities declared explicitly.

The implementation of that, the schema.org types, the JSON-LD, the validation, is owned by structured data that actually helps an SMB rank, and this guide deliberately stops at the boundary rather than teaching markup it does not own. The point that belongs here is only the relationship: the entity decomposition you produce from this guide is precisely the input the markup encodes, which is why the conceptual model has to come before the structured data, not after it.

Where this leaves you, and the first entity to define clearly

The entity-attribute-value model is how an SMB earns durable search visibility in an era where the engine resolves things and ranks the source that is genuinely the clearest, most completely described thing on a subject, not the page that repeats the phrase the most: a search engine builds a structure of identifiable things, their properties, and the facts that fill them, and ranks against that structure, which is why a clearly stated, well-described entity beats a keyword repeated and why a focused small site can be the recognized source on a subject a larger one only mentions. That is the machinery, and it is the reason every other instruction in this pillar, cover the topic, be the authority, write for the engine that reads for meaning, means something specific instead of staying a slogan.

This page explained the model and held its edges on purpose, handing the authority outcome, the map procedure, and the schema markup to the guides that own them rather than blurring them. The two next reads follow directly from the model: how to build a topical map for your business turns the entities and attributes you just decomposed into a sequenced cluster you can actually build, and structured data that actually helps an SMB rank encodes those same entities so a machine reads them directly instead of inferring them. The most useful next action is not "rewrite your site" and not "add schema". It is narrower: take the single most important entity in your business, almost always the business itself, and write one honest paragraph that names exactly what kind of thing it is, the services it offers, the area it serves, and who it serves, with no phrase repeated for its own sake, then check whether your current homepage actually states that. For most SMBs it does not, and that gap, between the entity you can state in a paragraph and the entity your site actually communicates, is the whole job the rest of this pillar exists to close.