AI Summary
Semantic SEO means planning content around entities and the relationships between them, rather than around a list of keyword strings. In practice it replaces "one page per phrase" with one hub per subject plus supporting pages for each distinct question, which removes the internal competition that keyword led planning creates.
- Start from the entity, its attributes and its relations. The keyword list becomes an output of that model, not the input to it.
- Four layers make coverage machine readable: topic model, on page terms, internal links, and schema.
- The most common failure is four thin pages competing for one intent. The fix is a merge, not another page.
- Semantic coverage is what makes a page quotable by AI answer engines, which extract claims rather than match strings.
Keyword led content planning has a structural flaw that shows up on every site that runs it for long enough. Export a keyword list, sort by volume, assign one page per row, and you end up with four pages about running shoes that differ only in the phrase in the title. Each is a partial answer. None of them is the best result for anything. Internally they compete, and externally they lose to a single competitor page that covered the subject properly.
Semantic SEO starts one step earlier. Instead of asking "what strings do people type," it asks "what is this subject made of, and what does someone need to understand about it." The strings still matter, because they are how you check your language against real demand, but they arrive as evidence rather than as the plan itself.
Model the subject before you plan the pages
An entity is a thing with attributes and relationships to other things. Modelling one takes about twenty minutes and it decides your entire page inventory.
| Layer | Question it answers | Worked example: running shoe | What it produces |
|---|---|---|---|
| Entity | What is the subject? | Running shoe | The hub page |
| Attributes | What properties does it have? | Cushioning, heel to toe drop, weight, terrain, stack height, pronation support | Sections within the hub, and supporting pages where an attribute is complex enough to carry one |
| Relations | What other entities is it connected to? | Gait analysis, injury type, race distance, running surface, brand, retailer | Supporting pages and the internal links between them |
| Questions | What does a real person need decided? | Which drop suits me, how often to replace, road versus trail, how to fit | The page inventory, in the order a buyer works through it |
Notice what happened to the keyword list. "Best running shoes," "running shoes for men" and "top running shoes 2026" are not four pages under this model. They are three phrasings of one intent, which is "help me choose," and they belong on one page that does the choosing well. The keyword research is still essential, but it now serves to confirm the vocabulary and reveal questions you missed rather than to generate the sitemap. That is the same research process described in keyword research fundamentals, applied at a different point in the workflow.
Understanding User Intent
Intent is where the entity model meets reality, because two queries can reference the same entity and require completely different pages. "Heel to toe drop" from someone comparing two models needs a spec comparison; the same phrase from someone who just read it on a box needs a definition and a recommendation. Same entity, same attribute, different job.
The practical test is to write down what the reader should be able to do after reading, in one sentence. If you cannot, the page has no intent and it will read like an encyclopedia entry that ranks for nothing. If two planned pages produce the same sentence, you have found a cannibalisation problem before you created it, and the fix is to merge them now rather than to discover the overlap in six months.
Semantic planning also changes how you read the results page. Rather than noting which competitor ranks, note which questions the ranking pages answer and in what format, because that is the engine telling you what it believes the intent requires. A results page dominated by comparison tables is a strong statement that the intent is evaluative, and publishing a definition against it will not work no matter how well the definition is written.
Quality and Comprehensiveness
Comprehensiveness in a semantic frame has a precise meaning that is easy to confuse with length. A page is complete when it covers the attributes and relations that the intent requires, and no more. That is the standard: no unanswered question the reader would reasonably have at that point, not a word count.
The entity model gives you a checklist for it. Take the attributes and relations you listed, mark which ones this page's intent requires, and check the draft against them. A "how to choose" page that never mentions pronation or terrain is incomplete regardless of length, while a definition page that stays at 500 words because the definition is genuinely settled is complete. Padding a complete page to hit an arbitrary target adds nothing extractable and dilutes what was already good.
This is also the mechanism behind visibility in AI answer engines. Systems that generate answers extract claims and attribute them, so they favour content where a specific question is answered plainly and self containedly. A clearly headed section that states an attribute and its consequence in two sentences is more likely to be quoted than the same information distributed across four paragraphs of preamble. Writing for extraction and writing for a knowledgeable human turn out to be the same instruction, which is convenient. It is why structured data and AI search visibility sit closer together than they first appear.
The four layers that make coverage machine readable
A topic model in your head is worth nothing to a search engine. Four layers make it legible, and skipping any one of them weakens the others.
- Topic model. The list of questions in the order a real person works through them. This is the page inventory and it should exist as a document before anything is written.
- On page terms. Name the attributes and related entities explicitly in the copy. A page about choosing a shoe that never says "pronation" cannot be understood to cover it. This is not keyword density, it is using the actual vocabulary of the subject.
- Internal links. Link the hub to each supporting page and supporting pages to each other where the relationship is real, with anchors that describe the destination. The link graph is how you assert relationships between your own pages, which is why it does more work in a semantic model than in a keyword one. The mechanics are covered in internal linking for topic clusters.
- Schema. State explicitly what the page is about using
aboutfor the primary entity,mentionsfor secondary ones, andsameAspointing at an authoritative identifier such as a Wikipedia or Wikidata URL. This removes the need for anything to be inferred.
"about": {
"@type": "Thing",
"name": "Running shoe",
"sameAs": "https://www.wikidata.org/wiki/Q1364259"
},
"mentions": [
{ "@type": "Thing", "name": "Pronation" },
{ "@type": "Thing", "name": "Gait analysis" }
]Validate whatever you emit rather than trusting the generator, since a block that fails to parse contributes nothing at all. The checking process is set out in validating and debugging structured data.
Content Lifecycle Management
An entity map is a living document, and this is where most semantic programmes quietly revert to keyword habits. Subjects acquire new attributes, relationships change, and questions that mattered three years ago stop being asked. If the map is never revisited, the cluster ossifies while the subject moves.
Review the map itself on a regular cycle, not just the pages. Two questions do the work: which attributes or relations have emerged that no page covers, and which pages now overlap because the subject shifted underneath them. The first produces new supporting pages that slot into an existing structure, which is far cheaper than starting a cluster from nothing. The second produces merges, and merging is the operation people avoid even though it is usually the highest return action available, because it converts two competing partial answers into one authoritative page.
When you merge, redirect the retired URL to the surviving page and update the internal links that pointed at it, so the link graph continues to assert the relationships you modelled. Running this as a standing process rather than an occasional cleanup is what a content audit process is for.
FAQ
It is planning content around things and their relationships rather than around search phrases. You define the subject, its attributes and the other subjects it connects to, then build pages that cover those properly. Keyword data still guides your vocabulary and reveals gaps, but it stops being the thing that decides how many pages you build.
They operate at different stages. Keyword research tells you what language people use and roughly how much demand exists. Semantic modelling decides what the subject is made of and therefore what pages should exist. Keyword led planning tends to create one page per phrase, which produces several thin pages competing for one intent.
It is not strictly required, since search engines extract meaning from text regardless. It is the cheapest way to remove ambiguity, particularly with about and sameAs pointing at an authoritative identifier for the entity. Treat it as making an explicit statement rather than as a ranking mechanism.
As many as there are distinct questions worth a dedicated answer, which the entity model tells you directly. If two candidate pages would leave the reader able to do the same thing, they are one page. Cluster size is an output of how complex the subject genuinely is, never a target to hit.
It helps, because answer engines extract and attribute specific claims rather than matching strings. Content that answers a defined question plainly, in a clearly headed and self contained section, is easier to quote accurately. The same structure that makes a page useful to a knowledgeable reader makes it extractable.
Merge rather than differentiate. Pick the page with the strongest existing signals as the survivor, fold in whatever the others uniquely contribute, redirect the retired URLs to it, and update every internal link that pointed at them. Attempting to rewrite near duplicates so they target subtly different phrases usually recreates the problem.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
