An entity is a uniquely identifiable thing or concept, whether physical (the Eiffel Tower, Marie Curie), organizational (the University of Florida), or abstract (the element mercury), that exists independently of the words used to name it. In knowledge graphs, search engines, and natural language processing, an entity is the thing itself, with a stable identifier, rather than any of the strings that might refer to it. “Entity” also names a legal person in law (a corporation, a trust) and a table-like object in database entity-relationship modeling; those uses share the idea of a distinct, identifiable thing but are separate topics and are not discussed further here.

Entity definition

The definition has three parts, and each one does work.

A thing or concept. Entities are not limited to people, places, and organizations. Events (the 1903 Nobel Prize ceremony), works (the novel Middlemarch), products (a specific camera model), substances (mercury), and abstract ideas (photosynthesis) are all entities when a system needs to refer to them as distinct things.

Uniquely identifiable. There is one Marie Curie, and any system that talks about her needs a way to say “this one” without ambiguity. In practice this means an identifier: a Wikidata Q-ID, an IRI, a Google machine ID, a database key. Two records with different identifiers are two entities until someone establishes that they are the same.

Independent of its names. “Marie Curie,” “Maria Skłodowska-Curie,” and “the discoverer of polonium” all point to one entity. Conversely, “Mercury” points to at least three: a planet, a chemical element, and a Roman god. The entity is the referent, the names are strings, and the mapping between them is many-to-many. Google’s 2012 phrase for its Knowledge Graph, “things, not strings,” remains the most compact statement of the idea.

Entity vs. string vs. keyword

The three words describe different layers.

Term	What it is	Example
String	A sequence of characters in text	"mercury"
Keyword	A string that users type into a search box, treated as a unit of demand	“mercury element facts”
Entity	The thing a string or keyword refers to, with an identifier	Mercury (element), Wikidata Q925

A search engine operating on strings finds documents containing “mercury.” A search engine operating on entities first decides which Mercury the query means, then finds documents about that thing, whether or not they use the word. A page that says “the only metal that is liquid at room temperature” is about Q925 without spelling the name. Entity-based retrieval can therefore return results that keyword matching would miss and exclude results that share a word but not a referent.

Identifiers

The identifier is what lets two systems agree they are talking about the same thing. Several identifier schemes appear constantly in knowledge graph and search work.

IRIs. In RDF, every non-literal node is identified by an IRI (Internationalized Resource Identifier), a generalization of the URL. http://www.wikidata.org/entity/Q937 is an IRI for Albert Einstein. In linked data the IRI usually resolves, which allows a client to follow it and fetch more facts. See /concepts/linked-data/.

Wikidata Q-IDs. Wikidata assigns each item a number prefixed with Q. Q937 is Albert Einstein, Q7186 is Marie Curie, Q308 is the planet Mercury, and Q925 is the element mercury. Because Wikidata is public, multilingual, and heavily cross-referenced, Q-IDs have become a common neutral identifier for tying private graphs to a shared reference. Properties have P-IDs (P31 is “instance of,” P19 is “place of birth”).

Google machine IDs (MIDs). The Google Knowledge Graph identifies entities with strings such as /m/0jcx (Albert Einstein). IDs beginning /m/ were inherited from Freebase; newer entities receive /g/ IDs. The Knowledge Graph Search API returns these as kg:/m/0jcx. See /ecosystems/google-knowledge-graph-search-api/.

schema.org @id. In JSON-LD structured data on a web page, @id gives a node an IRI. A site can mint its own (https://example.com/#organization) and use it consistently across pages so that every mention of the organization is recognizably one entity rather than a fresh anonymous node on each page.

sameAs. Both schema.org and OWL provide a sameAs property whose value is another identifier for the same entity. It connects a site’s own @id to Wikidata, Wikipedia, or a social profile, and it is how a search engine learns that the organization described on a page is one it already knows. See /seo/sameas-schema/.

Attributes, types, and relationships

An identifier says which thing; the rest of the description says what is known about it.

Attributes (properties with literal values) describe the entity directly: a birth date, a population, a name in a given language. In RDF these are triples whose object is a literal.

Types or classes say what kind of thing the entity is. Marie Curie is an instance of Person (schema.org Person; Wikidata Q5, human). Types come from a schema or ontology, and an entity can have several: the Eiffel Tower is a tourist attraction and a lattice tower. Types determine which properties make sense (a Person has a birth date; a City does not), and search engines use them to decide which panel or rich result to show. See /concepts/ontologies/.

Relationships connect one entity to another: Marie Curie, place of birth, Warsaw; Warsaw, country, Poland. Each relationship is a typed edge, and the whole set of entities and edges is a knowledge graph. Because a relationship’s object is itself an entity, a query can travel from a scientist to a city to a country to a continent.

Named entities vs. concepts

Natural language processing draws a distinction that knowledge graph work often blurs.

A named entity is an entity with a proper name: a specific person, organization, location, product, event, or work. Named-entity recognition (NER) is the task of finding such mentions in text and classifying them into coarse types (PERSON, ORG, GPE, DATE), which is the default output of libraries such as spaCy and Stanford CoreNLP.

A concept is a general class or abstract idea referred to with a common noun: “photosynthesis,” “inflation,” “graph database.” NER systems usually ignore concepts, but they are entities in the knowledge graph sense whenever a system assigns them an identifier. Wikidata has an item for photosynthesis (Q11982) just as it has one for Marie Curie. Taxonomies and SKOS vocabularies are the usual tools for managing concepts; see /concepts/entity-linking-ner-and-extraction/.

For search and SEO, both matter. A knowledge panel is typically a named entity; the topics that Google clusters pages around are typically concepts.

Entity resolution and disambiguation

Two problems arise as soon as strings meet entities, and they run in opposite directions.

Disambiguation (one string, many entities) asks which thing a mention refers to. Compare:

• “Mercury is the smallest planet in the Solar System.”
• “Mercury is the only metal that is liquid at room temperature.”

The string is identical. The first refers to Q308, the planet; the second to Q925, the element. Resolving the mention requires context: “planet” and “Solar System” in the first sentence, “metal” and “liquid” in the second. Entity linking is the NLP task that maps a mention in text to an identifier in a knowledge base, and it depends on candidates having enough description to compare against the context.

Entity resolution (many records, one entity) asks whether two descriptions refer to the same thing. A customer database has “M. Curie, Paris” and “Marie Sklodowska Curie, 75005”; a product catalog has the same camera under two supplier codes. Resolution compares attributes (names, dates, addresses, identifiers) and decides whether to merge. Public graphs face the same problem: Wikidata regularly merges duplicate items.

Both problems are why identifiers are treated as non-negotiable in graph work. A string can be disambiguated once and then forgotten; an identifier keeps the decision.

How search engines use entities

Web search engines maintain a knowledge graph of entities and use it at several points in the pipeline.

At query time, the engine recognizes entities in the query. “curie nobel prize” is interpreted as a question about Q7186 and an award, and the engine can answer directly from the graph (a knowledge panel, a fact snippet) or use the entity to select and rank pages.

At indexing time, the engine identifies which entities each page is about. Structured data helps here: a Person node with @id and sameAs links tells the engine exactly which person, without inference. Entity linking over the page text does the rest.

At display time, entities determine which features appear. Knowledge panels and “people also search for” carousels are keyed to entities rather than to pages. A business that exists as an entity in the Google Knowledge Graph can be shown as one; a business that exists only as words on its own site cannot. Details at /ecosystems/google-knowledge-panel/ and /seo/what-are-entities-in-seo/.

How large language models relate to entities

A large language model does not store entities as identified records. It stores statistical associations among tokens, and “Marie Curie” is a pattern that co-occurs with “Nobel,” “radium,” and “Warsaw.” The model can usually answer questions about well-documented entities correctly, but it has no internal identifier, cannot be sure which Mercury a prompt means without context, and can produce plausible facts that are wrong.

Knowledge graphs are the usual remedy. Retrieval grounded in a graph (see /build/graphrag/) lets the model look up the entity, its identifier, and its verified attributes at answer time rather than reconstructing them from memory. In the other direction, language models perform extraction and entity linking over text and turn natural-language questions into SPARQL or Cypher. The model provides language; the graph provides identity. See /seo/knowledge-graphs-ai-search-and-llms/.

Worked example: a Person entity in JSON-LD

The following JSON-LD describes Marie Curie as an entity. The @id gives the node an identifier under the publisher’s control; sameAs connects it to public identifiers for the same person; the remaining properties are attributes and relationships.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.org/people/marie-curie#person",
  "name": "Marie Curie",
  "alternateName": "Maria Skłodowska-Curie",
  "birthDate": "1867-11-07",
  "birthPlace": {
    "@type": "City",
    "name": "Warsaw",
    "sameAs": "https://www.wikidata.org/wiki/Q270"
  },
  "award": "Nobel Prize in Physics (1903)",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q7186",
    "https://en.wikipedia.org/wiki/Marie_Curie",
    "https://www.nobelprize.org/prizes/physics/1903/marie-curie/facts/"
  ]
}

The @id means that a second page on the same site can refer to https://example.org/people/marie-curie#person and a processor will treat both as descriptions of one entity. The sameAs array declares that this node, Wikidata Q7186, and the Wikipedia article are the same thing, which is how a private identifier is anchored to public ones. And birthPlace is an object rather than a string: Warsaw is an entity with its own sameAs, not the six characters “Warsaw.” The award value is a string here, which is acceptable on a web page but would be a linked node in a full graph, as shown on the knowledge graph page. Person markup specifics are at /seo/person-schema/.

For developers

Treat identifier design as the first decision. Mint IRIs in a namespace you control, keep them opaque (avoid encoding names or types that may change), and never reuse one for a different thing. Store external identifiers (Q-IDs, MIDs, ISBNs, DOIs) as properties of the entity rather than as its primary key. Model anything you will ever need to attach a fact to as a node, not a literal; a country stored as the string “Poland” cannot have a population. For entity resolution, run deterministic matching on strong identifiers before probabilistic matching on names and addresses, and record every merge so it can be undone. Extraction pipelines are covered at /concepts/entity-linking-ner-and-extraction/ and practical code at /build/knowledge-graph-python/.

For SEOs

An entity-first approach to a site starts with a list of the things the site is about (the organization, its people, its products, its topics) and asks, for each, whether search engines can identify it. For the organization and key people, that means Organization and Person structured data with a consistent @id and sameAs links to Wikidata, Wikipedia (where an article exists), and official profiles. For topics, it means content that describes the concept with the attributes and related entities a knowledge graph would expect. Obtaining a Wikidata item, where notability criteria allow, is often the most useful single step toward being recognized as an entity. The full method is at /seo/entity-seo/, with knowledge panel specifics at /ecosystems/how-to-get-a-knowledge-panel/.

Common misconceptions

“An entity is a keyword with high volume.” A keyword is demand for a string. An entity is the thing referred to. Many keywords map to one entity, and some entities have no keyword at all.

“Adding schema markup creates an entity.” Markup describes an entity and helps a search engine recognize it. Whether the engine adds it to its own graph depends on corroboration from other sources.

“Entities are a Google concept.” The idea predates Google’s Knowledge Graph by decades, in database theory, information extraction, and the Semantic Web. Google popularized the term in search marketing.

Related pages

• What is a knowledge graph?
• Entity linking, NER, and extraction
• What are entities in SEO?
• Entity SEO
• sameAs schema
• Wikidata

FAQ

What is an entity in simple terms?

An entity is a specific, identifiable thing: a person, place, organization, product, event, or idea. It is the thing itself, not the word for it. “Paris,” “the French capital,” and “Q90” (its Wikidata ID) all refer to one entity. Computers work with entities by giving each one an identifier so it cannot be confused with anything else that shares its name.

What is the difference between an entity and a keyword?

A keyword is a string of text that people type into a search engine. An entity is the real-world thing that string refers to. The keyword “apple” is one string; it can refer to the fruit or the company, which are two entities with different identifiers. Search engines resolve keywords to entities so they can answer about the intended thing rather than matching letters.

What is an entity in SEO?

In SEO, an entity is a distinct thing (a brand, person, product, place, or topic) that a search engine recognizes and stores in its knowledge graph with a unique identifier. Entity SEO is the practice of making those things explicit through structured data, consistent naming, sameAs links to sources like Wikidata, and content that describes the entity’s attributes and relationships.

What is a named entity in NLP?

A named entity is a real-world object referred to by a proper name in text: a person (Marie Curie), organization (Wikimedia Foundation), location (Warsaw), date, or product. Named-entity recognition (NER) is the task of finding these mentions and labeling their type. Entity linking then maps each mention to an identifier in a knowledge base, resolving which specific thing the name refers to.

Sources and further reading

• Google. “Introducing the Knowledge Graph: things, not strings” (2012). https://blog.google/products/search/introducing-knowledge-graph-things-not/
• Google. “How Google’s Knowledge Graph works.” https://support.google.com/knowledgepanel/answer/9787176
• schema.org. Person. https://schema.org/Person
• schema.org. sameAs. https://schema.org/sameAs
• W3C. RDF 1.1 Concepts and Abstract Syntax (IRIs, literals, blank nodes). https://www.w3.org/TR/rdf11-concepts/
• Wikidata. Wikidata:Identifiers. https://www.wikidata.org/wiki/Wikidata:Identifiers