How to Create Knowledge Graph Pages With Unique URIs or IDs for Site Entities

What is a knowledge graph page?

A knowledge graph stores things and the relationships between them: this product is made by this company, this person leads this team, this clinic offers this service. Google introduced its Knowledge Graph in 2012 with the phrase "things, not strings". A knowledge graph page is your site's version of one node in such a graph. It is a page that stands for one thing, says what it is, lists its facts, and links to the related things.

Most sites already have some of these pages: a product page, a team profile, a location page. What makes them work as a graph is discipline. There is exactly one page per thing, each with a stable identifier and consistent names, and every mention across the site links back to it. Tim Berners-Lee's principles for linked data describe the same idea. Use URIs as names for things, use HTTP URIs so people can look them up, provide useful information at that address, and include links to other URIs.

How entities help AI understand a site in general is covered in how entities and semantic structure help AI understand a website.

Which entities deserve their own page?

Give a thing its own page when it meets at least two of these tests:

• People ask about it by name, for example "What is [product] Pro?" or "Who is [person]?".
• It has facts of its own: a price, an address, credentials, specifications, a launch date.
• Several pages mention it, so a single reference point avoids repeating and contradicting facts.
• It is easily confused with something else, such as a plan name shared with a competitor or two locations in the same city.

Typical entity types:

How do you choose URIs and IDs?

Separate two things that are easy to confuse: the page's URL, which people visit, and the entity's identifier, which names the thing itself. A common pattern is the page URL plus a fragment:

• Page: https://example.com/team/ana-ruiz
• Person ID: https://example.com/team/ana-ruiz#person
• Organisation ID: https://example.com/#organization

Rules that save trouble later:

1. One identifier per entity, used everywhere. The same person referenced on 40 articles should carry the same @id on all of them.
2. Make identifiers stable. The W3C's old advice, "cool URIs don't change", applies doubly here. Do not build IDs from things that change, such as titles, campaign names or CMS database paths that a migration will rewrite.
3. Never reuse an identifier for a different thing. If a plan is retired and a new one launched under the same name, give the new plan a new ID.
4. Point IDs at real pages. JSON-LD does not require an identifier to resolve, but an ID whose page part leads to the entity's page is easier to maintain and check.
5. Keep the ID when the URL changes, or map it. When you rename a product, redirect the old page and either keep the old ID or record the change, so references do not split into two entities.

Some SEO plugins generate identifiers automatically. Yoast's documented approach, for example, joins every piece of its markup into one graph through @id values such as https://www.example.com/#/schema/Organization/1. Check what your plugin produces before adding your own markup, so you do not end up with two IDs for the same organisation.

What should an entity page show?

The visible page matters most. Tests of AI assistants fetching pages directly found they extracted visible text and ignored JSON-LD. So each entity page should say, in plain sentences and a short fact list:

• What it is, in one sentence that names the category: "Shiftmoor Rota is scheduling software for restaurants with 10 to 200 staff."
• Its key attributes, from the table above, stated as facts, not marketing.
• Its relationships, as links: made by, part of, located at, written by, works with.
• Evidence where it matters: registration numbers, certifications, publication lists.

A page that shows only a name and a photo is not an entity page. It gives search systems nothing to connect.

How do you mark it up?

On the entity's own page, describe it fully. On other pages, reference it by its identifier instead of describing it again:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Shiftmoor",
      "url": "https://example.com/",
      "sameAs": [
        "https://www.linkedin.com/company/shiftmoor",
        "https://www.wikidata.org/wiki/Q000000"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "@id": "https://example.com/products/rota#product",
      "name": "Shiftmoor Rota",
      "applicationCategory": "BusinessApplication",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

A blog post by Ana Ruiz would then set its author to { "@id": "https://example.com/team/ana-ruiz#person" }, with the full description living on the profile page. Keep the markup consistent with what the page shows. Markup describing facts that are not on the page can undermine trust rather than build it, as covered in whether schema that conflicts with page content can reduce AI trust or visibility.

How do you connect entities across the site?

• Link every meaningful mention of an entity to its page, with the entity's name as the link text.
• Build index pages for each type: all products, all team members, all locations. These let crawlers find every entity and show how they group.
• Use breadcrumbs that follow the relationships: Products › Rota › Pricing.
• Add a "related" block on each entity page that links to the connected entities.
• Use the same name every time. If the product is "Shiftmoor Rota", do not call it "the scheduler" on one page and "Rota Pro" on another.

How semantic HTML and structured data work together is covered in how to use semantic HTML and structured data to make a site easier for AI to parse.

Should you link to Wikidata and other external IDs?

Yes, when the external record is the same entity. Google's Organization documentation lists sameAs and identifiers such as ISO 6523 codes and NAICS among the properties that help it tell organisations apart. Good targets are your Wikidata item, LinkedIn page, Crunchbase profile and official registry entries. Do not point sameAs at pages about related but different things, such as a founder's profile from the company's markup. Do not create a Wikidata item just to have one either. Wikidata has notability criteria, and items that fail them get deleted. How to strengthen your brand's presence in Google's graph is covered in how to make your brand a clear entity in Google's Knowledge Graph.

What does this achieve, and what does it not?

Be realistic. Google says its AI features need no special markup. An Ahrefs study of pages that added structured data found no measurable lift in AI citations compared with similar pages that did not. So identifiers alone will not win you citations. What the approach does achieve is structural. There is one authoritative page for each thing, stating its facts where any system can read them, and there are consistent names and links across the site. Machine-readable markup then agrees with the text. That removes the contradictions and duplicate pages that lead answers to mix up products, people or locations.

What mistakes are common?

• Two pages for one entity, such as an old and a new product page both live.
• Identifiers that change with every redesign or CMS migration.
• IDs that point to pages that return 404 after a restructure.
• sameAs links to the wrong entity, such as a similarly named company.
• Entity pages with no facts, only a name, a logo and a button.
• Several plugins each outputting their own Organization with a different ID.

What might an illustrative case look like?

Consider an illustrative accounting software company whose AI answers regularly confused its two plans and credited a feature of one to the other. Its site described each plan on seven different pages, with slightly different names and prices. It created one page per plan with a fact list, redirected the older duplicates, and gave each plan a stable @id. It then linked every mention across the blog and help centre to the plan pages. Within two months, answers described each plan's features and price correctly in most runs.

What do people ask about entity pages and IDs?

Does the @id have to be a working URL?

No, but it is easier to manage if the page part resolves to the entity's page. Many sites use the page URL plus a fragment such as #product.

Do small sites need this?

A small site needs the principle more than the markup. One page per product, service or location, with consistent names and links, is most of the value.

Should every person on the team have a page?

Only those who author content, act as experts or lead the company. Others can be listed on a team page.

What if we rename a product?

Redirect the old page to the new one, mention the former name on the new page, and keep or map the identifier so references stay connected.