Semantic SEO: Topics, Entities & Meaning Over Keywords

Semantic SEO is the practice of planning and writing content around topics, entities, and the relationships between them, rather than around keyword strings, on the reasoning that search engines interpret what a query means before they retrieve anything. It is a response to a documented change in how search works: a query is parsed, its intent classified, its terms expanded to related meanings, and its entities resolved, all before a single document is scored. Content that matches the meaning of a question outperforms content that matches its wording, and the two are no longer the same thing.

What semantic search changed

Google documents four shifts in its own descriptions of how Search works, and each has a direct consequence for writing.

Query interpretation. Google states that Search applies language understanding models to work out what a query is asking, including spelling correction, and that it does not simply match the words entered. The named milestones are real and datable: Hummingbird in 2013, RankBrain in 2015, neural matching in 2018, BERT applied to search in 2019, and MUM announced in 2021. The internal details aren’t public, but the direction is clear: less string matching, more interpretation.

Synonymy and term expansion. Google’s own description of Search includes a synonym system, so that a query for “how to change a lightbulb” also retrieves pages about “replace a light bulb.” A writer no longer needs to include every variant to be eligible for it. Repeating variants for their own sake produces worse prose and no additional coverage.

Intent. The same words carry different needs. “python” from a developer wants documentation; from a zoo visitor it wants a snake. “best crm” wants a comparison, not a product page. Ranking systems appear to classify a query’s dominant intent and prefer page formats that satisfy it, which is why a definitional page rarely wins a query whose results are all comparison tables, no matter its keyword coverage.

Passage-level relevance. Google announced in 2020 that it had improved its ability to identify and rank individual passages from a page, not only the page as a whole. A page can therefore be retrieved for a question it answers in one section without being about that question overall. Well-structured sections with self-contained answers are the practical consequence.

What is documented and what is inference

The topic attracts confident invention, so the boundary is worth stating.

Documented: that language understanding models are applied to queries; that a synonym system exists; that passages within pages can be ranked; that structured data is used to understand content and to determine eligibility for specific result features; that Google maintains a Knowledge Graph and generates knowledge panels from it.

Observable from outside: that near-synonymous queries return overlapping result sets; that result formats cluster by intent; that a page can rank for a phrase it does not contain; that entity-keyed features such as knowledge panels appear independently of any single page’s optimization.

Inference: that “topical coverage” or “entity completeness” is scored as such. No search engine documents a coverage metric, no NLP score is exposed, and the various vendor scores sold as proxies are the vendors’ own models. The behavior those models approximate appears to be real, which is why the planning method below is worth using, but the numbers attached to it are not measurements of anything Google computes.

Topics and entities as the unit of planning

A keyword list is a list of strings, and strings collapse under interpretation. Two hundred keywords for a subject area usually resolve to a few dozen distinct questions about a few dozen distinct things.

The alternative unit of planning is a pair: the entity the reader is asking about, and the question they are asking about it. “graph database pricing,” “how much does neo4j cost,” and “neo4j license cost” are one pair (Neo4j, cost). “neo4j vs neptune” is a different pair involving two entities and a comparison. “what is a graph database” is a third involving a concept and a definition.

Planning at that level produces a different content map. Each pair becomes one page or one clearly bounded section, and the near-duplicates disappear before they are ever written. It also exposes gaps a keyword list cannot show, because a question with no search volume attached still needs answering if a reader will hit it. The site-level version of this argument, and how internal links express it, is at /seo/topical-authority/.

Planning coverage by entities and relationships

The concrete method: take the topic, list the entities it contains, list the relationships between them, then decide which relationships a page needs to explain. This is the same exercise as sketching a small knowledge graph of the subject.

Take “graph database” as the topic. The entity space includes:

Products: Neo4j, Amazon Neptune, TigerGraph, ArangoDB, Memgraph.
Query languages: Cypher, Gremlin, SPARQL, GQL.
Data models: labeled property graph (LPG), RDF.
Adjacent categories: relational databases, document databases, vector databases.
Concepts: node, edge, property, traversal, index-free adjacency.
Use cases: fraud detection, recommendation, knowledge graphs, network management.

The relationships matter more than the list. Neo4j implements Cypher and uses the LPG model; Neptune supports both Gremlin and SPARQL, so it spans both data models; SPARQL queries RDF, not LPG; GQL is an ISO standard graph query language whose design drew on Cypher. A reader who understands those edges understands the category. A page that lists the same products without the edges covers the vocabulary and explains nothing.

The coverage decision then becomes tractable. A page introducing graph databases needs the data model distinction, at least one query language, the comparison to relational storage, and two use cases, because those are the edges a reader traverses immediately. It does not need every product, because product selection is a different question and belongs on its own page. Where relationships already have pages, the links carry the structure: property graph vs RDF and knowledge graph vs graph database are the two edges most readers of that topic need next.

The craft

Four habits do most of the work, and none of them require a tool.

Answer the question in the first sentence. A page titled “what is index-free adjacency” should define it before it does anything else. This serves readers who will not scroll; it gives passage ranking a clean, self-contained answer to retrieve, and it is the form that featured snippets and AI Overviews draw from. Background, history, and caveats work fine in the second paragraph.

Cover the adjacent entities a reader will need. Someone reading about Cypher will want to know what implements it and how it relates to GQL. Answering those in two sentences, with links, is better than either ignoring them or writing a separate page for each. The test is whether a reader has to leave and search again to finish the thought.

Make internal links express real relationships. A link from a Cypher page to an LPG page states that the two are related in a specific way, and the anchor text should say which. Link because the relationship exists, not to distribute equity: a page linked from every other page on the site with the same anchor tells a reader and a crawler nothing about how the topic is organized.

Restate the page’s facts in structured data. Markup does not add information and is not documented as a ranking factor. What it does is put the facts a page already asserts into a form that needs no interpretation, and, through @id and sameAs, say which known things the page is about. Formats are compared at /languages/json-ld-vs-microdata-vs-rdfa/; the identity properties are covered at /seo/sameas-schema/.

A short worked example of the fourth habit, for a page defining a concept:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/graph-databases/#article",
  "headline": "What Is a Graph Database?",
  "about": [
    { "@type": "Thing", "name": "Graph database", "sameAs": "https://www.wikidata.org/wiki/Q595971" },
    { "@type": "SoftwareApplication", "name": "Neo4j", "sameAs": "https://en.wikipedia.org/wiki/Neo4j" }
  ],
  "mentions": {
    "@type": "Thing",
    "name": "Cypher",
    "sameAs": "https://en.wikipedia.org/wiki/Cypher_(query_language)"
  }
}

The about and mentions split is doing real work: about names what the page is primarily concerned with, mentions names something it refers to in passing. Both properties exist on schema.org and both take entity nodes rather than strings, which is what makes the sameAs links possible. This is the linked data pattern applied to an ordinary web page.

What semantic SEO does not mean

Four misreadings are common enough to name.

It is not synonym stuffing. Adding “semantic keywords,” LSI terms, or a list of related phrases to a page is keyword stuffing with a newer vocabulary. Term expansion happens on the query side; a page does not need to contain the variants to be eligible for them.

It is not an NLP score to maximize. Tools that return an entity count, a “semantic density” figure, or a coverage percentage are reporting their own model, not a search engine’s. Those numbers can be useful as a rough check on whether a draft omits something obvious. They are not targets, and optimizing to them produces text that mentions everything and explains nothing.

It is not writing for a grader. A page that satisfies a content-scoring tool and leaves a reader without an answer has failed at the only thing the method is for. Where the tool and the reader disagree, the reader is the authority.

It is not the same as covering more words. Length correlates with coverage only until it stops. A 3,000-word page that restates one idea six times covers less than a 900-word page that answers the question and explains three relationships.

For developers

The planning artifact of this method is a graph, and you can store it as one. A small RDF or labeled property graph (LPG) of the topic (entities as nodes, relationships as typed edges, pages as another node type linked to the entities they cover) makes gap analysis a query rather than a spreadsheet exercise: find entities with no covering page, find pages covering more than one primary entity, find relationships asserted in prose but never linked. Public catalogs give the node identifiers for free, and the Wikidata Query Service will return the entity space for many topics directly. Extraction of entities from existing drafts is the pipeline described at /concepts/entity-linking-ner-and-extraction/.

FAQ

What is semantic SEO?

Semantic SEO is the practice of planning and writing content around topics, entities, and the relationships between them rather than around keyword strings. It follows from how search engines work: a query is interpreted, its intent classified, its terms expanded, and its entities resolved before documents are ranked, so matching meaning matters more than matching wording.

How is semantic SEO different from keyword SEO?

Keyword SEO treats each string as a separate target and optimizes pages to contain it. Semantic SEO treats the question and what it is about as the target, collapsing many near-identical keywords into one page and exposing questions that keyword tools miss. Keyword data is still useful as evidence of demand; it is no longer the unit of planning.

Are semantic keywords a real thing?

Not as a category search engines recognize. Term expansion and synonym handling happen when a query is interpreted, so a page does not need to contain every variant to be eligible for it. Lists of “semantic keywords” or LSI terms added to a draft are keyword stuffing in newer language. Cover the entities and questions a topic contains instead.

Does semantic SEO require structured data?

No. Search engines extract entities and meaning from page text without markup. Structured data restates the facts a page already states in a parseable form and, through @id and sameAs, identifies which known things the page describes. Google does not document it as a ranking factor, and it does not compensate for content that fails to answer the question.

Sources and further reading

Google. “How Search works: ranking results.” https://www.google.com/search/howsearchworks/how-search-works/ranking-results/
Google. “Understanding searches better than ever before” (BERT, 2019). https://blog.google/products/search/search-language-understanding-bert/
Google. “How AI is powering a more helpful Google” (2020, includes passage ranking). https://blog.google/products/search/search-on/
Google. “MUM: A new AI milestone for understanding information” (2021). https://blog.google/products/search/introducing-mum/
Google Search Central. “Intro to how structured data markup works.” https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
schema.org. about. https://schema.org/about