The most important concept in entity development is also the one most teams skip. Individual entities — even well-defined, well-recognised ones — have limited value on their own. What creates exponential authority is the network of relationships between them.
A site that mentions its CEO, its products, and its founder as three separate entities with no explicit connections is showing AI systems three disconnected facts. A site that connects the CEO to the organisation through worksFor, the products to the organisation through brand, and the founder to the organisation through founder is showing AI systems a coherent entity graph. The difference is not subtle. It is the difference between scattered data points and a connected knowledge structure.
This post covers the six relationship patterns that form the foundation of entity networks, why the @id system makes those relationships traversable, and how bidirectional linking creates the authority transfer that makes connected entities more powerful than the sum of their parts. The full implementation — the schema templates with proper relationship markup, the validation patterns, the maintenance routines — is in the AI Search & LLMs course.
Why relationships matter more than individual entities
Three specific things relationships do for entity visibility that no amount of individual entity optimisation can replicate.
Authority transfer. When your CEO writes an article, the authority of that article does not just accrue to the article. If the Person entity is connected to the Organisation entity through worksFor, the article’s authority flows back to the organisation. If those connections are missing, the article remains an isolated piece of content with no graph-level impact.
Cross-reference confidence. AI systems cite content with more confidence when they can cross-reference entity claims. If the article says Jane Smith is CEO of Acme, and the structured data declares that Jane Smith works for Acme, and LinkedIn confirms Jane Smith is CEO of Acme, and Wikidata has the same relationship recorded — the confidence in citing Jane Smith and Acme together becomes high. Without the explicit relationships, each system has to infer the connection independently.
Query fan-out coverage. When AI search fans out into sub-queries around a topic, the system traverses entity relationships to decide which entities are relevant. A page about a product whose schema declares the product’s brand, manufacturer, target audience, and category attributes can be retrieved across many sub-queries. A page about the same product with no relationship markup can only be retrieved for narrow queries that explicitly mention the product.
The six relationship patterns that form an entity network
Most entity networks are built from a small set of recurring relationship patterns. Internalising these six is what makes everything else fall into place.
1. Person → Organisation (via worksFor or founder). This is the foundational relationship. People work for organisations. Founders found organisations. CEOs lead organisations. The worksFor property is the most commonly used; founder, employee, and member work for more specific roles.
2. Product → Organisation (via brand or manufacturer). Products belong to brands. Brands belong to organisations. The brand property declares which organisation a product is associated with. This connection is what makes product authority feed back into organisation authority.
3. Article → Person (via author). Content is written by people. The author property on Article schema points to the Person entity who wrote it. This is the relationship that builds person entity authority — every article authored by a Person entity strengthens that person’s recognition as an expert.
4. Article → Concept (via about or mentions). Content is about topics. The about property declares the primary concept the article addresses; mentions declares concepts referenced secondarily. These relationships are what connect content to broader topical entities and let AI systems understand the topical surface a brand covers.
5. Organisation → Location (via location or address). Organisations exist at places. The location property connects an organisation to its primary place, while address uses PostalAddress for the structured address details. This is critical for both local search and for entity disambiguation when multiple organisations share similar names.
6. Organisation → Audience (via audience). Brands serve specific audiences. The audience property declares the target audience for an organisation, product, or content piece. This relationship is increasingly important in AI search because audience signals shape how systems decide which content to surface for which user contexts.
These six patterns are the backbone. Other relationships exist and matter — isPartOf, isRelatedTo, knowsAbout, competitor, sameAs — but they extend rather than replace this foundation. Get these six right and you have an entity graph with structural integrity.
The @id system: what makes relationships traversable
Relationships are only useful if AI systems can actually follow them. This is where the @id system comes in.
Without @id, a relationship is a textual reference. Jane Smith works for Acme Corp in JSON-LD is parsed as a string. AI systems have to guess whether the Jane Smith mentioned on the homepage is the same Jane Smith mentioned on the about page. Without explicit ID references, those mentions are not connected.
With @id, every entity gets a unique URI identifier. Jane Smith on every page references the same @id. The fifty mentions become one entity. AI systems can follow the ID links to understand all relationships at a glance.
Standard URI structure: https://yourdomain.com/entity/person/jane-smith. Lowercase, hyphenated, and stable — it should never change after launching because that stability is what allows AI systems to maintain recognition over time.
The benefits compound across the relationship network. Every worksFor reference that points to the Acme @id strengthens the Acme entity. Every author reference that points to Jane Smith’s @id strengthens Jane Smith’s expertise. Every brand reference that points to Acme’s @id makes the product-organisation connection explicit. Authority accumulates because the system can traverse the graph rather than guessing at it.
This is not optional architecture. Without an @id system, you have isolated data points. With it, you have a knowledge graph.
The complete schema templates with
@idimplementation across all six relationship patterns are part of the BRIDGE framework. The course walks through the URI structure patterns that scale, the validation workflows that catch broken references, and the maintenance routines that prevent the graph from drifting over time.
Bidirectional links: why one-way relationships are not enough
A relationship declared in one direction is half a relationship. If Jane Smith’s Person schema declares she works for Acme, but Acme’s Organisation schema does not list her as an employee or founder, the graph is asymmetric. AI systems detect the asymmetry and treat the relationship as weaker than a fully bidirectional one.
The rule is simple: every important relationship should be declared from both sides.
- If a Person
worksForan Organisation, the Organisation should have that Person asemployeeorfounder - If an Article has a Person as
author, the Person entity should reference the Article throughmainEntityOfPageor similar - If a Product has an Organisation as
brand, the Organisation should list the Product through its catalogue or offerings
Bidirectional declarations make the relationship verifiable from either direction, which is what gives AI systems high confidence in the connection. They also create the graph structure that allows traversal in both directions — finding all articles by a person from the person entity, and finding the person who authored an article from the article entity.
This is the kind of thing that is easy to miss in initial implementation and hard to retrofit later. Building bidirectional from the start is significantly easier than adding it after the fact.
Common relationship failures and how to fix them
A few specific patterns show up repeatedly when teams audit their existing relationship markup.
Isolated entities. Schema is implemented for individual entity types but with no relationship properties connecting them. The fix is adding the worksFor, brand, author, about, and similar properties using @id references.
Text-only references. Relationships are declared using entity names as strings rather than @id references. The fix is establishing canonical @id URIs for every entity and using them consistently.
Asymmetric relationships. A Person worksFor an Organisation, but the Organisation does not list the Person. The fix is adding the reciprocal relationship.
Broken @id references. An @id points to a URI that does not actually resolve or that points to an entity definition elsewhere on the site that has changed. The fix is maintaining the @id URI as a stable identifier and validating that every reference resolves correctly.
Mismatched canonical names. The Person entity uses Dr. Emma Chan but article author bylines use Emma Chan. The fix is editorial consistency — the canonical form has to be the same everywhere — combined with schema that explicitly declares the canonical name and uses alternateName for variations.
These five failure modes account for the majority of relationship problems I see in audits. The good news is that all of them are fixable without major content rework — the fixes are mostly at the schema level and in editorial consistency rather than in fundamental content changes.
Where relationships fit in BRIDGE
The Relationships phase is the second step of the BRIDGE framework — the R. It sits between Blueprint (inventory) and Implementation (schema deployment).
The sequence matters. You cannot map relationships without first knowing which entities exist (Blueprint). You cannot implement schema correctly without first defining the relationships (Relationships). Trying to skip ahead to Implementation without mapping relationships first leads to schema that captures isolated entities rather than a connected network.
The phases that follow — Distribution (external presence), Growth (scaling the network), and Evaluation (measuring recognition) — all operate on the relationship structure established in this phase. Getting Relationships right is what makes the rest of the framework compound.
How to map your own entity relationships
A practical sequence for getting started on your own relationship mapping.
Step 1: List your Tier 1 entities. From your blueprint, pull the core entities — Organisation, founders, CEO, main location, flagship products. Five to ten entities is usually the right scope to start with.
Step 2: Draw the relationships. For every pair of Tier 1 entities, ask which of the six relationship patterns applies. Person to Organisation through worksFor. Product to Organisation through brand. Organisation to Location through location. Sketch this out on a whiteboard or in a diagram tool — visualising the connections clarifies them.
Step 3: Define the canonical names and @id URIs. Each entity gets one canonical name and one @id. Document these in a single source of truth — a spreadsheet, a configuration file, whatever format works for your team. This document becomes the reference for every schema implementation that follows.
Step 4: Implement the relationships in schema. Add worksFor, brand, author, about, location, and audience properties using @id references. Make sure relationships are bidirectional where applicable.
Step 5: Validate. Run the schema through Google’s Rich Results Test and the schema.org validator. Confirm that every @id reference resolves and that all relationships parse correctly.
Step 6: Maintain. Update relationships whenever entities change. New product launches need brand relationships. New hires need worksFor relationships. New articles need author and about relationships. The graph is a living system, not a one-time deployment.
Putting it together
Individual entities have limited value. Connected entity networks create exponential authority. The six relationship patterns — Person to Organisation, Product to Organisation, Article to Person, Article to Concept, Organisation to Location, Organisation to Audience — are the backbone of an entity network. The @id system is what makes those relationships traversable. Bidirectional declarations are what give them strength.
This is the kind of work that compounds. Once the relationship structure is in place, every new entity you add slots into a graph that already has shape. Every new article reinforces existing connections. Every external mention has a graph to anchor into. Authority accumulates because the system can traverse it.
Without the relationship structure, the same activity produces scattered signals. With it, the same activity produces a knowledge graph that AI systems can confidently cite.
Continue your learning (MLforSEO)
This post covered the Relationships phase of the BRIDGE framework — the six relationship patterns that form an entity network, the @id system that makes relationships traversable, why bidirectional declarations matter, the common failure modes and their fixes, and how to start mapping relationships for your own brand. The full implementation — including the complete schema templates with @id patterns, the relationship cheat sheet for every entity type combination, the validation workflows, and the BRIDGE framework that this phase fits into — is in the AI Search & LLMs: Entity SEO and Knowledge Graph Strategies for Brands course on MLforSEO.
Enrolling also gets you into the dedicated course channel inside the MLforSEO Slack community, where Beatrice Gamba and Lazarina Stoy answer course-specific questions and discuss ongoing implementation projects with course-takers. That is the best way to get personalised support as you map your entity relationships and move through the BRIDGE phases.
Beatrice Gamba
The future of search and content discovery will be dialogical, personalized and agent-mediated. Digital leaders need to start integrating these concepts in their strategies to be ready for what’s coming.
- Beatrice Gamba
- Beatrice Gamba
- Beatrice Gamba
- Beatrice Gamba
