An Entity Graph in Generative Engine Optimization

In this context, an entity is any clearly identifiable thing. Examples include:

• A person (e.g., Elon Musk)
• A company (e.g., Tesla)
• A place (e.g., Paris)
• A concept (e.g., Artificial Intelligence)

Each one is a distinct, well-defined node in the world — not just a keyword.

An entity graph is like a map that connects entities together based on relationships. For example:

• Elon Musk → CEO of → Tesla
• Tesla → produces → electric vehicles
• Electric vehicles → are part of → sustainable energy

Instead of seeing your content as just words, AI sees a web of meaning.

GEO is about optimizing content so AI systems can understand it deeply, trust it, and use it when generating answers. An entity graph helps in three concrete ways:

Instead of writing:

"Tesla makes cars."

An entity-optimized version builds relationships:

"Tesla, led by Elon Musk, manufactures electric vehicles and energy storage solutions as part of the global shift toward sustainable energy."

Now the AI can connect:

• Tesla ↔ Elon Musk
• Tesla ↔ electric vehicles
• Electric vehicles ↔ sustainability

An entity graph usually links things like:

• Your organization
• Your authors or experts
• Your services or products
• Related topics, partners, and sameAs references

These connections help generative systems see your site as a coherent entity, not just a set of isolated pages.

Think of an entity graph as a web of interconnected nodes. Each node is an entity, and the lines connecting them (edges) represent the relationships between them.

Generative models don't just look for matches for a query — they synthesize an answer based on their internal map of the world. Three things determine whether your brand makes it into that answer:

To optimize for an entity graph, creators move beyond simple text and focus on:

• Structured data (Schema markup): Explicitly telling engines, "This is an entity of type Organization, and it is the parent of this other entity."
• Consistent citations: Ensuring name, address, and core offerings are consistent across the web to strengthen the node in the graph.
• Contextual linking: Linking to other high-authority entities to show where you sit in the ecosystem.

For an ecommerce store, the entity graph approach is: stop treating your site as a pile of pages and start treating it as a connected graph where every entity (Organization, Person, Brand, Product, Collection, Material, Topic) has a stable @id URI, and every schema block references those @ids instead of redefining the entity each time.

1. Map your nodes first

Before writing any schema, list the entities that actually exist for your store. For a polish brand that might look like:

• Organization: the company
• Person: the founder(s)
• Brand: separate node from Org so you can attach it to products
• Product: each SKU
• ProductCollection: seasonal or finish-type groupings
• DefinedTerm: branded concepts like "Polish with Purpose," "10-free," "women-founded"
• Place: manufacturing origin if relevant

Each gets a permanent URI like https://example.com/#organization, https://example.com/#founder, or https://example.com/products/[handle]#product.

2. One global @graph block in theme.liquid

Put a single server-side JSON-LD @graph in your theme.liquid <head> so it loads on every page. This is your spine:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "{{ shop.url }}/#organization",
      "name": "Your Brand",
      "url": "{{ shop.url }}",
      "logo": "{{ 'logo.png' | asset_url }}",
      "founder": { "@id": "{{ shop.url }}/#founder" },
      "brand":   { "@id": "{{ shop.url }}/#brand" },
      "sameAs": [
        "https://www.instagram.com/...",
        "https://www.tiktok.com/@...",
        "https://www.wikidata.org/wiki/Qxxxxx"
      ]
    },
    {
      "@type": "Person",
      "@id": "{{ shop.url }}/#founder",
      "name": "Founder Name",
      "jobTitle": "Founder",
      "worksFor": { "@id": "{{ shop.url }}/#organization" }
    },
    {
      "@type": "Brand",
      "@id": "{{ shop.url }}/#brand",
      "name": "Your Brand",
      "slogan": "Polish with Purpose"
    }
  ]
}
</script>

The @id URIs are what stitch the graph together — they don't have to resolve as live URLs, they just need to be unique and consistent.

3. Reference, don't redefine, on product pages

In product.liquid, the Product schema should point back to the Brand and Organization by @id instead of restating them:

{
  "@type": "Product",
  "@id": "{{ shop.url }}{{ product.url }}#product",
  "name": "{{ product.title }}",
  "brand":        { "@id": "{{ shop.url }}/#brand" },
  "manufacturer": { "@id": "{{ shop.url }}/#organization" },
  "offers": { ... }
}

Same pattern for collection pages — link the collection back to the Brand and to any DefinedTerms it represents.

4. Link to external entities (the unlock for LLMs)

The sameAs array on your Organization and Person nodes is where you anchor your graph to the wider web. Include verified social profiles, Crunchbase, LinkedIn, and — most importantly — a Wikidata Q-number if you can get one. Wikidata is the canonical reference LLMs lean on for entity disambiguation.

Validate at two layers: