How to Build an Entity Map for SEO

An entity map is a structured graph of entities and their relationships, scoped to a single topic domain. You build one to plan content coverage, guide internal linking, and generate the about and mentions signals in your Article schema markup – the properties that tell Google which entities your content covers.

This guide walks through the full process: extracting entities, structuring relationships with the EAV model, connecting output to JSON-LD, and validating that Google extracted what you intended. If you need the broader context for how entity mapping fits into semantic SEO, start there. For the underlying concepts, see What Is Entity SEO?

What is an entity map (and how is it different from a topical map)?

An entity map is a knowledge graph scoped to your topic domain. The output is a structured document – a table or dataset – that drives two things: what your content covers and what your schema communicates to Google.

Every entity map has three components. Entities are the things themselves – concepts, people, products, technologies. Attributes are the properties that describe each entity: its type, its category, its defining characteristics. Relationships are the connections between entities: “is a,” “part of,” “used by.” These three components map directly to the entity-attribute-value model covered in a later section.

If you’ve built topical maps before, the distinction matters. A topical map organizes content. Pages, headings, clusters – it’s a site architecture plan. An entity map organizes concepts. It defines which entities exist in your domain, what properties they carry, and how they connect to each other. One tells you what to publish. The other tells you what each page should say and how your structured data should describe it.

A topical map can exist without mentioning a single entity. Fifty article titles in a spreadsheet, organized by search intent. That’s a valid topical map. An entity map can’t exist without relationships. Without edges between nodes, you have a list. Not a graph. That’s the fundamental difference.

How do you extract entities and map their relationships?

Entity extraction is a three-layer process. Each layer adds something the others can’t provide. You start with canonical entities from Wikipedia, add salience scores from Google’s NLP API, and generate relationship types with LLM assistance. The output is a scored, validated list of entities with typed relationships – the raw material for the EAV structure covered in the next section.

Semantic triples – the unit that makes entity maps work

Every relationship in an entity map is a semantic triple: subject, predicate, object. That’s the atomic unit. One triple, one fact.

Real examples from SEO:

• “JSON-LD – is a format of – structured data”
• “Schema.org – defines – Article type”
• “Google Knowledge Graph – stores – entity facts”

Each triple is a single edge in your graph. Triples compose into larger structures through shared nodes. “Schema.org defines Article type” and “Article type supports author property” share the node “Article type.” Two triples, three entities, one connected subgraph. Scale that to 30 or 40 triples and you have a working entity map.

This matters because Google’s Knowledge Graph represents entity facts as a graph – entities connected by typed relationships. When you build an entity map using semantic triple extraction, you’re producing a structure that mirrors how knowledge graphs represent information. Your map doesn’t just plan content. It mirrors the data structure your content needs to reinforce.

Three extraction methods – Wikipedia, NLP API, and LLM-assisted

Method 1: Wikipedia and Wikidata mining. Manual, but foundational. Open the Wikipedia article for your core topic. Every internal link on that page is a candidate entity. For “structured data” as a topic, the Wikipedia article links to JSON-LD, RDFa, Microdata, Schema.org, and knowledge representation – all entities that belong in your map. Then check Wikidata for each one. Wikidata gives you formal relationships (instance of, subclass of, part of) and machine-readable identifiers you’ll need later for schema output. When pulling identifiers, use the Concept URI (http://www.wikidata.org/entity/Q...), not the browser URL – the format difference matters for schema output, covered in the JSON-LD section below.

Method 2: Google Cloud Natural Language API. Programmatic and salience-scored. The API performs named-entity recognition – identifying and classifying entities in text, then scoring each by salience. Send a competitor’s page content, get back a structured entity list with Wikipedia URLs.

Working Python example (requires the google-cloud-language package and a GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to your service account key):

from google.cloud import language_v1

def extract_entities(text):
    client = language_v1.LanguageServiceClient()
    document = language_v1.Document(
        content=text,
        type_=language_v1.Document.Type.PLAIN_TEXT
    )
    response = client.analyze_entities(
        request={"document": document}
    )
    
    entities = []
    for entity in response.entities:
        if entity.salience > 0.01:
            entities.append({
                "name": entity.name,
                "type": language_v1.Entity.Type(entity.type_).name,
                "salience": round(entity.salience, 4),
                "wikipedia_url": entity.metadata.get(
                    "wikipedia_url", None
                )
            })
    return sorted(entities, key=lambda x: x["salience"], reverse=True)

Pass any text string – pull a competitor’s page content with requests.get() and extract the body text, or paste it directly.

You can also query the Knowledge Graph Search API to verify whether Google recognizes each extracted entity as a discrete Knowledge Graph entry.

Method 3: LLM-assisted extraction. Fastest, but needs validation. A structured prompt generates entity lists with relationship types from a topic description:

Topic: "Entity mapping for SEO"

List the 15 most important entities related to this topic.
For each entity, provide:
- Entity name
- Wikidata QID (if known)
- Relationship to the core topic (is-a, part-of, related-to, used-by)
- One defining attribute

The output gives you relationship types that Wikipedia and the NLP API don’t. The tradeoff: LLMs conflate entities. “Knowledge graph” the general concept (Q33002) and “Google Knowledge Graph” the product (Q648625) are different entities with different Wikidata QIDs. Don’t trust LLM-generated QIDs. Verify every one against Wikidata directly – LLMs hallucinate identifiers more reliably than any other output type. Every LLM-generated entity needs disambiguation against Wikidata before it enters your map.

These methods layer. They don’t replace each other. Wikipedia gives you the canonical entities. The NLP API gives you salience scores through named-entity recognition. LLMs give you relationship types. A production entity map uses all three.

Entity salience – what scores actually matter

NLP entity salience measures how central an entity is to a document’s meaning. Not frequency. Not keyword density. Salience reflects contextual weight – how much the document’s topic depends on that entity.

Threshold guidance based on testing across multiple content types: salience above 0.01 generally indicates Google treats the entity as relevant to the page. Above 0.05 means it’s a significant topic of the document. Below 0.01 is noise – the entity appears but doesn’t carry meaning.

The benchmarking technique that makes this actionable: run the NLP API on a top-3 ranking page for your target query. Extract the entity salience profile. Then run your draft through the same API. Compare the two profiles. Entities present in their profile but missing from yours are gaps – concepts you need to add or strengthen. Entities in your profile that aren’t in theirs might be differentiators or might be diluting focus. Context determines which.

You don’t optimize salience directly. There’s no setting to adjust. You shift it by adding contextual depth around an entity – a definition, a working example, a relationship to another entity in the same passage. Salience moves as a side effect of genuine coverage.

How does the entity-attribute-value model organize your entity map?

The entity-attribute-value (EAV) model gives your entity map an actual data structure. Without it, “map your entities” is an instruction with no format. EAV provides the format: every row in your map is either a relationship between two entities or an attribute of a single entity. That’s the entire structure.

Relationship types that matter for SEO

SEO ontology building starts with three categories of relationships:

Hierarchical – these define taxonomy. “JSON-LD is a serialization format” is an is-a relationship. “FAQPage is part of structured data” is part-of. Hierarchical relationships establish what things are and where they sit in a classification.

Associative – these connect concepts across categories. “Entity SEO relates to Knowledge Graph.” “Schema.org used by Google.” Associative relationships don’t define hierarchy. They define relevance between entities that exist in different branches of your map.

Definitional – these attach properties to entities. “Article schema has property author.” “Organization has property sameAs.” Each definitional relationship is one attribute-value pair in the EAV model.

These categories aren’t arbitrary. They map directly to how schema.org organizes its type hierarchy. The rdfs:subClassOf relationship is “is-a.” The domain/range pattern on properties is “has-attribute.” When you classify relationships in your entity map using these three types, you’re building a structure that translates directly to schema output. That’s what makes the map useful beyond content planning.

What the working document looks like

The entity relationship diagram SEO practitioners actually use isn’t a mind map. It’s a table. Six columns:

Entity	Type (@type)	Relationship	Related Entity	Attribute	Value
Semantic SEO	Thing	related-to	Knowledge Graph	–	–
Knowledge Graph	Thing	is-a	Knowledge base	–	–
Semantic triple	Thing	part-of	Semantic SEO	–	–
Semantic triple	Thing	–	–	structure	subject-predicate-object
Entity salience	Thing	used-by	Google NLP API	–	–
Topical authority	Thing	related-to	Semantic SEO	–	–
Article	CreativeWork	has-attribute	–	author	Person
Article	CreativeWork	has-attribute	–	about	Thing
JSON-LD	Thing	is-a	Serialization format	–	–
Schema.org	Thing	related-to	Structured data	–	–

Relationship rows connect two entities. Attribute rows describe a single entity. Both live in the same table. That’s the EAV model applied to SEO.

A terminology note: data scientists call these “attributes” in an EAV model. In the schema.org vocabulary, the same concept is a “property” – the author property of an Article, the name property of a Thing. Same structural role. Different terminology depending on which documentation you’re reading. This article uses both terms interchangeably.

How does an entity map connect to content and schema output?

Two translation layers connect your entity map to published output: content architecture decisions and JSON-LD structured data.

From entity map to content architecture

Your entity map contains a built-in decision framework for content structure. Entities with high relationship density – multiple connections to other entities, several attributes – need their own pages. Entities with moderate connections get H2 sections within a parent page. Entities with low salience and few relationships get inline mentions. The map makes these decisions mechanical, not subjective.

Content gaps become visible the same way. Walk through every entity in your map. If an entity has no corresponding page, section, or substantive mention anywhere on your site, that’s a gap. No audit tool required. The map itself is the audit.

Internal linking follows directly from relationship types. Hierarchical relationships (is-a, part-of) map to pillar-to-cluster links. Associative relationships (related-to, used-by) map to sibling cross-links between cluster articles. This is where the structure described in Topical Authority: How to Build It and Topic Clusters vs Content Silos connects to entity mapping.

Semantic density is not keyword density. Your entity map defines which entities belong in each piece of content. Coverage means mentioning the right entities with sufficient contextual depth – definitions, examples, relationships. Not repeating a target keyword.

From entity map to JSON-LD output

The about and mentions properties in Article structured data are the direct schema output of your entity map. Your primary entity goes into about. Supporting entities go into mentions. The map tells you exactly which entities belong in each property.

The PHP $entity_map pattern used on squin.org makes this connection explicit – a custom data structure stored in a Code Snippets snippet, keyed by post slug, and wired to Rank Math’s JSON-LD output through a theme-level filter. The map IS the schema input, not a separate document that someone manually translates into JSON-LD.

Working example – the entity map entry for this article:

'entity-map-seo' => [
    'about' => [
        '@type' => 'Thing',
        '@id'   => 'http://www.wikidata.org/entity/Q33002',
        'name'  => 'knowledge graph',
        'sameAs' => 'https://en.wikipedia.org/wiki/Knowledge_graph'
    ],
    'mentions' => [
        [
            '@type' => 'Thing',
            '@id'   => 'http://www.wikidata.org/entity/Q54872',
            'name'  => 'semantic triple',
            'sameAs' => 'https://en.wikipedia.org/wiki/Semantic_triple'
        ],
        [
            '@type' => 'Thing',
            '@id'   => 'http://www.wikidata.org/entity/Q3539533',
            'name'  => 'entity-attribute-value model',
            'sameAs' => 'https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model'
        ],
        [
            '@type' => 'Thing',
            '@id'   => 'http://www.wikidata.org/entity/Q648625',
            'name'  => 'Google Knowledge Graph',
            'sameAs' => 'https://en.wikipedia.org/wiki/Google_Knowledge_Graph'
        ]
    ]
]

A Rank Math rank_math/json_ld filter injects these values into the Article schema output at render time. The entity map array feeds directly into the JSON-LD your page serves to Google. The filter code that wires the array to Rank Math’s JSON-LD output is covered in the structured data pillar guide, with the full working snippet.

URI format matters here. Use http://www.wikidata.org/entity/QXXXXXX for @id – that’s the canonical Linked Data URI. Use https://en.wikipedia.org/wiki/ for sameAs. Don’t use https://www.wikidata.org/wiki/QXXXXXX (the browser URL) as the @id value. In strictly-typed systems, the https:// browser URL and the http:// entity URI resolve to different nodes, which creates duplicate entity references in your graph.

How do you validate that Google extracted your entities?

Validation closes the loop. Four methods, layered from immediate to long-term.

NLP API comparison. Run your published page through the Cloud Natural Language API – the same tool you used during extraction. Compare the returned entity list and salience scores against what your entity map predicted. Entities present in your map but missing from the API output didn’t get enough contextual depth in the content. You mentioned them, but not with enough definition, examples, or relational context for Google’s NLP to register them as significant. Entities the API found that aren’t in your map are unintentional signals. They may be fine, or they may dilute your topic focus. Either way, you want to know about them.

Rich Results Test. Validate that your JSON-LD about and mentions properties render correctly in Google’s Rich Results Test. Check that each Wikidata @id URI uses the http:// format. Check that sameAs URLs resolve to the correct Wikipedia pages. The most common failure: https://www.wikidata.org/wiki/QXXXXXX in the @id field instead of http://www.wikidata.org/entity/QXXXXXX. The Rich Results Test won’t flag this as an error, but it creates duplicate entity nodes in strictly-typed systems.

Search Console query monitoring. This one takes time. Entity-aligned content should attract queries beyond your target keyword – queries related to the entities in your map. If your entity map includes “semantic triple” but you never rank for triple-related queries after several months, Google may not be extracting that entity with sufficient salience from your content. That’s a signal to revisit the section where that entity appears and add depth.

Knowledge Graph API verification. Before adding an entity to your about or mentions, verify it exists in Google’s Knowledge Graph using the Knowledge Graph Search API. Query by entity name. If the API returns a result with a machine ID (the /m/ or /g/ identifier in the @id field), the entity exists as a node in Google’s Knowledge Graph. If it doesn’t, the entity may still be valid – Wikidata’s coverage exceeds Google’s Knowledge Graph – but your schema signal relies entirely on the Wikidata URI rather than Google’s own entity recognition. That’s useful information when deciding placement. Entities Google already recognizes are stronger candidates for about. Entities only in Wikidata may fit better in mentions.

This isn’t a one-time audit. Entity maps are living documents. Validation results feed back into map revisions – strengthening entities that underperformed, removing ones that created noise, adding ones the NLP API surfaced that you hadn’t considered. The map improves every cycle.

Common mistakes that break entity maps

Building the map but never connecting it to schema output. The map sits in a spreadsheet. The JSON-LD sits in a template. They never reference each other. Six months later, the map is outdated and the schema reflects whatever someone manually typed into a plugin field. The $entity_map PHP pattern exists to prevent this. The map IS the schema input. One source of truth, one place to update.

Confusing topical maps with entity maps. A spreadsheet of 50 article titles organized by pillar and cluster is a topical map. If your “entity map” contains no relationship types, no attributes, and no Wikidata identifiers, it’s a content plan with a fancier name. The test: does every row define a relationship between two entities or an attribute of one entity? If not, it’s not an entity map.

Stuffing mentions with every entity tangentially related to your topic. Five focused mentions with correct Wikidata URIs and matching content depth outperform twenty vague ones. Google’s entity recognition operates on precision thresholds. More is not better. Each entity in your mentions array should appear in your content with enough context for the NLP API to extract it at a salience above 0.01.

Treating entity salience as a target metric. You don’t “increase salience to 0.08.” That’s not how it works. You add contextual depth around an entity – a definition, a working example, an explicit relationship to another entity in the same passage – and salience shifts as a side effect. Optimizing the number directly leads to unnatural content patterns.

Over-relying on LLM extraction without Wikidata validation. LLMs conflate entities. “Knowledge graph” the concept (Q33002) and “Google Knowledge Graph” the product (Q648625) are different entities with different QIDs. Your schema needs to disambiguate them. Every LLM-generated entity gets checked against Wikidata before it enters your map or your JSON-LD.

Frequently Asked Questions

Where This Fits

Entity mapping is one implementation layer within your broader semantic SEO strategy. Two immediate next steps: Topical Authority: How to Build It for using entity maps to plan content coverage, and What Is Entity SEO? for the foundational concepts behind entity-based optimization.