Entities, Knowledge Graphs, and SEO: A Conversation

A preserved conversation about identifying entities for a website, how they differ from keywords, and how to structure content so AI and search engines can read it. The thread gets into a crucial point: real knowledge is a multi-dimensional graph, but we present it as one snapshot at a time—so how do we choose which angle to take, and which entities to show, with the least sacrifice?

---

How do I identify the entities I need to target on this website?

I don't fully grasp the difference between keywords and entities. I understand that entities are interconnected—maybe embedding-based, maybe more about inherited meaning and intent—and that an entity doesn't depend on one particular keyword but is essentially a pool of keywords behind it. Then there's the idea that the entity is spatially related to other entities and has relationships in a structured, consistent, meaningful way even if abstract. How do I identify these different layers of meaning, these different hierarchies of semantic meaning, and how many do I need to pick to start building out a knowledge base on a website, specifically focusing on readability for AI and search engines?

You're very close to the correct understanding already. The main gap is separating three different layers that often get mixed together:

• Keywords
• Entities
• Entity relationships (knowledge graph layer)

Once you see these as three distinct layers, identifying what to target on a website becomes much easier.

1. Keywords vs Entities vs Entity Networks

Keywords

A keyword is just a phrase people type.

Examples:

"fasting app"
"intermittent fasting timer"
"fasting tracker"

These are query expressions, not concepts.

Entities

An entity is a concept with a stable meaning, independent of wording.

Examples:

Intermittent fasting
Autophagy
Zero Fasting Tracker
FastNow

Each entity represents a thing that exists in a knowledge graph.

Google, ChatGPT, Perplexity, etc. don't really rank keywords anymore — they rank entities and relationships.

Entity relationships (the knowledge graph layer)

Entities become powerful when they are connected.

Example graph:

Intermittent Fasting
 ├─ Fasting Timer
 ├─ Autophagy
 ├─ Ketosis
 ├─ Metabolic Health
 ├─ Circadian Rhythm
 └─ Insulin Sensitivity

A page that connects these concepts builds semantic authority.

2. How AI Actually Understands Websites

AI models convert text into embeddings.

Embedding vectors capture meaning such as:

fasting timer
fasting schedule
intermittent fasting tracker
fasting clock

These cluster around the entity: fasting timer software.

But the real semantic layer is:

Intermittent Fasting
    ↓
Fasting Protocols
    ↓
Metabolic Processes
    ↓
Health Outcomes

So AI reads your site as a semantic network, not a keyword list.

3. The 4 Semantic Layers Every Website Needs

Think of the site like a knowledge pyramid.

Layer 1 — Core entity (the product)

For your site:

Primary entity: FastNow

Layer 2 — Category entities

These define what the product is part of.

Examples:

Intermittent fasting
fasting timer
fasting tracker
fasting schedule
fasting app

Layer 3 — Supporting entities (mechanisms)

These explain why fasting matters.

Examples:

Autophagy
Ketosis
Insulin resistance
circadian rhythm
metabolism
fat oxidation

These build topical authority.

Layer 4 — User intent entities

These answer user problems.

Examples:

weight loss fasting
16:8 fasting schedule
fasting timer app
how long to fast
fasting benefits

These map to search queries.

4. The Method I Recommend (Entity Mapping)

Start by creating a semantic map.

Example for FastNow:

FastNow (product)

│
├── Intermittent Fasting
│     ├── 16:8 Fasting
│     ├── 18:6 Fasting
│     ├── OMAD
│     └── 24 hour fast
│
├── Fasting Tools
│     ├── fasting timer
│     ├── fasting tracker
│     ├── fasting reminders
│
├── Biology
│     ├── autophagy
│     ├── ketosis
│     ├── insulin sensitivity
│     └── metabolic switching
│
└── Outcomes
      ├── weight loss
      ├── metabolic health
      ├── longevity

Every cluster becomes a content hub.

5. How Many Entities Should You Start With?

For a startup website:

Ideal starting set: 20–40 entities

Breakdown:

Type	Count
Core entity	1
Category entities	5–7
Mechanism entities	8–12
Intent entities	10–15

This is enough for AI models to understand your semantic territory.

6. How To Identify Entities (Practical Workflow)

Step 1 — Identify the core concept

Example: intermittent fasting app

Step 2 — Extract entities from knowledge sources

Use: Wikipedia, Google Knowledge Graph, PubMed, Google "People Also Ask".

Look for:

intermittent fasting
fasting protocol
metabolism
ketosis
autophagy
circadian rhythm
insulin

Step 3 — Extract competitor entities

Look at apps like Zero Fasting Tracker, Life Fasting Tracker. See what concepts they mention repeatedly.

Step 4 — Build entity clusters

Example cluster:

Fasting protocols
  ├ 16:8 fasting
  ├ 18:6 fasting
  ├ OMAD
  ├ alternate day fasting

7. The Most Important Thing for AI Readability

AI prefers clear semantic structure.

Every article should follow this pattern:

H1: Intermittent Fasting Timer

H2: What is intermittent fasting
H2: How fasting timers work
H2: Fasting schedules (16:8, OMAD)
H2: Biological effects (autophagy, ketosis)
H2: Benefits of fasting
H2: Using FastNow

This mirrors the knowledge graph hierarchy.

8. The Real Goal

You are not building pages. You are building a knowledge graph around your product.

AI engines then understand:

FastNow
   ↓
intermittent fasting
   ↓
fasting schedules
   ↓
metabolic processes

Which creates entity authority.

Key mental model

• keywords = queries
• entities = concepts
• entity graph = authority

---

How do you pick and choose the H2s in that article structure?

Why did we include some entities (e.g. fasting schedules, biological effects) and not others (e.g. fasting reminders, insulin sensitivity, metabolic switching)? Where do you stop and start—or is it a judgment call?

Great question — you're hitting the exact place where most people misunderstand entity SEO.

The key point is this: You do NOT include all relevant entities in one article. You include only the entities that belong to that page's semantic scope.

Think of a page as a controlled slice of the knowledge graph, not the whole graph.

The Real Rule Behind Choosing H2 Entities

The rule is: Every page should represent ONE semantic node and its immediate relationships.

In knowledge graph terms:

Central entity
   ├ direct attributes
   ├ direct mechanisms
   ├ direct use
   └ direct outcomes

Everything else belongs on other pages.

Why I Chose Those H2s

The example page was implicitly: Topic: fasting timer

So the structure becomes:

Fasting Timer
   ├ definition
   ├ how it works
   ├ protocols it supports
   ├ biological effects it helps trigger
   └ tool implementing it (FastNow)

Each section answers a different relationship to the entity.

H2	Relationship type
What is intermittent fasting	definition
How fasting timers work	mechanism
Fasting schedules	usage context
Biological effects	causal outcome
Benefits of fasting	user outcome
Using FastNow	product implementation

So the structure is relationship-driven, not keyword-driven.

Why Some Entities Were Excluded

You mentioned: fasting reminders, insulin sensitivity, metabolic switching. These are valid entities. But the question is: Are they FIRST-DEGREE relationships to the page topic?

Example: insulin sensitivity

Relationship chain:

Fasting timer
   → intermittent fasting
      → metabolic effects
         → insulin sensitivity

That is two hops away. So it belongs in a deeper article like: How intermittent fasting improves insulin sensitivity.

Example: fasting reminders

This is a product feature, not a conceptual entity of fasting. So it belongs in: Fasting App Features or Best fasting reminder apps.

Example: metabolic switching

Chain:

Fasting timer
   → intermittent fasting
      → metabolic switching

Again two hops away. Better for a deeper guide.

The Core Principle: The 1-Hop Rule

The best rule for entity SEO is: A page should only contain entities that are ONE EDGE away from the main entity.

Example graph:

Intermittent Fasting
   ├ fasting schedule
   ├ fasting timer
   ├ fasting window
   ├ eating window
   ├ fasting duration
   └ metabolic effects

These are direct relationships. Everything deeper becomes new articles.

How to Decide the H2s Systematically

Instead of guessing, use entity relationship types. For most topics you need:

1. Definition — What the entity is.
Example: What is intermittent fasting

2. Mechanism — How it works.
Example: How fasting works in the body

3. Types / variants — Different forms.
Example: 16:8 fasting, OMAD, alternate-day fasting

4. Outcomes — What happens because of it.
Example: weight loss, metabolic health

5. Tools / implementation — How people apply it.
Example: Using a fasting timer

Why This Works for AI

LLMs and search engines learn entity structure like this:

Entity
 ├ definition
 ├ mechanism
 ├ variations
 ├ outcomes
 └ implementation

This pattern appears in Wikipedia, academic papers, textbooks, knowledge graphs. So when your content follows it, AI recognizes the structure instantly.

The Mental Model That Fixes Everything

Think of content like zoom levels in a map.

Zoom 1
Intermittent fasting

Zoom 2
fasting schedules | fasting benefits | fasting science

Zoom 3
16:8 fasting | autophagy | ketosis | insulin sensitivity

Each page sits at one zoom level only. Mixing zoom levels confuses search engines.

What Most Sites Do Wrong

They try to put everything on one page.

Example (semantic soup):

intermittent fasting
ketosis
autophagy
insulin
circadian rhythm
fasting reminders
fasting apps
weight loss

AI cannot determine the page's main entity.

A Better Structure for FastNow

Example site graph:

Intermittent Fasting
   ├ Fasting Timer
   │      └ FastNow
   │
   ├ Fasting Schedules
   │      ├ 16:8 fasting
   │      ├ OMAD
   │      └ 18:6 fasting
   │
   ├ Fasting Biology
   │      ├ autophagy
   │      ├ ketosis
   │      └ metabolic switching
   │
   └ Fasting Benefits
          ├ weight loss
          ├ insulin sensitivity
          └ longevity

Each node becomes its own page.

The Key Insight

Is this just a judgment call? Partially yes — but guided by graph distance.

The rule of thumb: Page entity + direct relationships = page content. Everything else becomes another page in the cluster.

One sentence summary: The H2s are chosen by entity relationship distance (1-hop rule), not by listing all relevant concepts.

---

Why does representing entities in 2D (e.g. Excel) feel so demanding?

And isn't "metabolic effect" related to many entities (biology, weight loss, extended fasting), not just one—so shouldn't it sit in a 3D cloud rather than under a single parent?

You're absolutely right about the core difficulty: a knowledge graph is multi-dimensional, but tools like Excel force you to flatten it into rows and columns. That's why it starts feeling mentally exhausting.

And you're also correct about your example: "metabolic effects" doesn't belong to only one parent. In a true knowledge graph, entities can have many relationships simultaneously. That's actually the key idea behind entities.

1. Knowledge Graphs Are Networks, Not Trees

Most people imagine entity structures like this:

Intermittent Fasting
 ├ Fasting schedules
 ├ Metabolic effects
 └ Benefits

That is a tree. But real knowledge graphs look more like this:

Intermittent Fasting
      │
      │ triggers
      ▼
Metabolic Effects
      │
 ┌────┼─────────┐
 │    │         │
 ▼    ▼         ▼
Ketosis  Autophagy  Insulin Sensitivity
  │        │            │
  └────────┼────────────┘
           ▼
       Weight Loss

Here the same entity can connect to many nodes. For example: Metabolism connects to intermittent fasting, ketosis, weight loss. So your intuition that entities live in a cloud of relationships is correct.

2. Why We Temporarily "Fake" a Tree for SEO

Even though the real structure is a network, websites must still be navigable. Search engines and users expect structure like:

Page
 ├ H2
 ├ H2
 └ H2

So we temporarily convert the network into topic slices. Each page becomes one perspective on the network.

Page A — "Intermittent Fasting"
Focus: intermittent fasting → fasting schedules, metabolic effects, benefits

Page B — "Metabolic Effects of Fasting"
Focus: metabolic effects → ketosis, fat oxidation, insulin sensitivity

Page C — "Weight Loss and Fasting"
Focus: weight loss → calorie deficit, metabolic effects, hormonal changes

Notice: metabolic effects appear in all three pages. That's normal. Because the underlying graph stays intact.

3. The Page = Perspective Model

Instead of thinking: Where does this entity belong?
Think: From which angle am I explaining it?

Example entity: Ketosis

It can appear in pages about: intermittent fasting, metabolism, weight loss, low-carb diets, diabetes. Each page explains ketosis from a different relationship.

4. Why Excel Feels Wrong

You noticed the exact limitation. Excel forces you into something like:

Entity | Parent | Parent | Parent

But knowledge graphs are actually:

Entity | Relationship | Entity

Example rows (triple model):

Intermittent fasting | triggers | metabolic switching
Metabolic switching | causes | ketosis
Ketosis | increases | fat oxidation
Fat oxidation | contributes to | weight loss

This is how real knowledge graphs are structured. It's called a triple model: Subject → Predicate → Object

Example:

Intermittent fasting → activates → autophagy

5. Why the 1-Hop Rule Still Works

The 1-hop rule for page structure doesn't mean an entity has only one parent. It means: A page should primarily discuss entities directly connected to its main topic.

Example page: Intermittent Fasting. Entities one hop away might include: fasting schedules, fasting duration, metabolic effects, hormonal changes, fasting benefits. But deeper entities like mitochondrial biogenesis, AMPK signaling, insulin receptor pathways would go on other pages.

6. The Mental Model That Makes This Easy

Think of your site as a knowledge graph with lenses. The graph itself:

               Weight Loss
                   ▲
                   │
Ketosis ◄── Metabolic Switching ──► Autophagy
                   ▲
                   │
           Intermittent Fasting

Each article is just a camera angle on that graph. Example pages: Intermittent fasting, Metabolic switching, Ketosis, Weight loss, Autophagy. Each page explores the neighbors of that node.

7. What AI Search Engines Actually Do

LLMs and search engines convert text into vector embeddings. They do not expect perfect hierarchies. They detect patterns like:

intermittent fasting
metabolism
ketosis
autophagy
fat oxidation

and infer a concept cluster. So even if your structure isn't perfect, the model still sees: fasting biology cluster.

8. The Simplified Rule for Building a Knowledge Base

When writing a page:

1. Pick one main entity — e.g. intermittent fasting
2. Add 5–8 strongly related entities — e.g. fasting window, fasting schedule, metabolic switching, ketosis, autophagy, fasting benefits
3. Link to deeper entities — e.g. ketosis guide, autophagy guide

This creates graph expansion over time.

9. Tools That Represent This Better Than Excel

If you want to visualize entities properly, tools like these help: Obsidian graph view, Kumu, Neo4j, GraphXR, Gephi. They show nodes and edges, not rows and columns. That's much closer to how knowledge graphs work.

Your intuition is correct: Entities do not belong to only one place. They exist in a network of relationships, and pages are just views into that network.

---

Of the five tools you mentioned, which is free, easy to access, and easy to use—and what kind of output does each provide?

Good question — because the tool you choose strongly affects how easy this process feels. Some graph tools are powerful but overkill for SEO knowledge mapping.

Below are the 5 tools, ranked by ease of use + accessibility.

1. Obsidian — Best Overall (Free + Easy)

Best choice for most people.

Why it's good: Completely free, very easy to start, visual graph view of entities, works with simple markdown files. You basically create one note per entity.

Example:

Intermittent Fasting.md
Ketosis.md
Autophagy.md
Metabolic Switching.md

Then link them:

Intermittent fasting triggers [[Metabolic Switching]]

The software automatically creates a knowledge graph.

Graph output: It generates something like:

Intermittent Fasting
       │
       ▼
Metabolic Switching
   │        │
   ▼        ▼
Ketosis   Autophagy
   │
   ▼
Weight Loss

Visually it looks like a constellation of connected nodes. This makes entity relationships very intuitive. SEOs love it because it mirrors exactly how Google's knowledge graph works: entity → relationship → entity.

2. Kumu — Best Visual Graph Tool

Very visual; slight learning curve. Kumu is designed for relationship maps.

Example entity entry:

Intermittent fasting
Relationship: triggers
Metabolic switching

You get beautiful network graphs. Nodes can be colored by category: biology, protocol, benefit, product. Very useful for large topic maps.

3. Gephi — Best for Big Data

Powerful; not beginner friendly. Gephi is used for social network analysis, academic graph analysis, large datasets.

You import data like:

source,target
intermittent fasting,metabolic switching
metabolic switching,ketosis
ketosis,weight loss

Then Gephi generates a force-directed network graph.

4. Neo4j — How Big Tech Does It

Real knowledge graph database; overkill for most SEO work. This is what companies use to build actual knowledge graphs.

Example data:

(:Fasting)-[:TRIGGERS]->(:Ketosis)
(:Ketosis)-[:CAUSES]->(:FatOxidation)

But it requires query language and database setup. So it's more for engineers or researchers.

5. GraphXR — Advanced Visualization

Good for exploring large graphs visually. But not beginner friendly and has paid features.

Practical Recommendation

For your purpose (entity SEO + knowledge mapping): Start with Obsidian.

Why: fastest learning curve, visual graph, free, perfect for entity notes.

Example Workflow in Obsidian

Create notes:

Intermittent Fasting
Metabolic Switching
Ketosis
Autophagy
Weight Loss
FastNow App

Inside Intermittent Fasting.md:

Intermittent fasting triggers [[Metabolic Switching]]
It can lead to [[Ketosis]] and increased [[Autophagy]].
Many people use fasting for [[Weight Loss]].
Tools like [[FastNow App]] help track fasting windows.

Graph view becomes:

Intermittent Fasting
      │
      ▼
Metabolic Switching
  │         │
  ▼         ▼
Ketosis   Autophagy
  │
  ▼
Weight Loss

This becomes your content blueprint.

What Output You Actually Use for SEO

From the graph you extract:

Content hubs — Each node becomes an article: Intermittent fasting, Metabolic switching, Ketosis, Autophagy, Weight loss.

Internal linking — Example: intermittent fasting → ketosis guide, Ketosis → metabolic switching, Metabolic switching → fasting biology. This mirrors the knowledge graph structure.

Simple takeaway: Start with Obsidian because it lets you build a visual entity network in minutes.