Entity Relationship Planning Workbook

Manually implementing schema.org structured data with proper entity relationships and @id references across organizations, people, articles, products, and concepts is complex and error-prone without systematic planning—this comprehensive Google Sheets workbook provides a step-by-step framework for mapping entity relationships, defining permanent @id URL patterns, and validating bidirectional connections before deploying structured data markup to ensure Google can understand your site’s entity graph. Created by Lazarina Stoy for MLforSEO, this planning template guides SEO professionals and technical implementers through the complete entity relationship design process across multiple interconnected tabs (Organization, People, Concepts, Products, Articles, Relationships, Validation, Implementation) that systematically build a coherent entity graph following schema.org best practices—ensuring every entity uses permanent @id references instead of text names, establishes bidirectional relationships (like Person → Organization and Organization → hasMember), maintains consistent URL patterns (data.yoursite.com/{entity-type}/{slug}), and connects each entity to at least two others for graph cohesion, eliminating the fragmented structured data implementations that fail to establish clear entity relationships and prevent Google from building comprehensive knowledge graph representations of your organization, content, and expertise.
The workbook implements an 8-step progressive planning methodology documented in the Instructions section. Users start with the Organization tab to establish the root entity by defining company details including legal name, logo, social profiles, and the organization’s @id URL. The People tab captures key team members (authors, executives, experts) with their roles, bios, and bidirectional relationships to the organization entity. The Concepts tab defines core topics, subject areas, or knowledge domains that content covers, establishing topical authority entities that articles can reference. The Products tab lists offerings, services, or solutions with specifications and relationships to relevant concepts and responsible team members. The Articles tab maps content to authors (via @id person references) and topics (via @id concept references), creating the content-author-topic relationship triangle. The Relationships tab provides a verification matrix showing all entity connections to identify orphaned entities or missing bidirectional links. The Validation checklist ensures adherence to critical rules before implementation: using @id references universally, maintaining permanent URLs, employing lowercase-with-hyphens slug conventions, establishing bidirectional relationships, and ensuring minimum 2-entity connectivity for each entry. The Implementation guide provides deployment instructions for adding the planned schema markup to pages.
The Key Concepts section establishes the @id URL pattern convention (data.yoursite.com/{entity-type}/{slug}) with concrete examples like https://data.example.com/person/john-smith, ensuring consistent entity identifier structure across all types. The Critical Rules checklist enforces schema.org implementation best practices: always using @id references rather than plain text names (preventing disambiguation issues), keeping @id URLs permanent (never changing them even if slugs or page locations change), using lowercase with hyphens in slugs for URL consistency, creating bidirectional relationships so Person entities reference Organizations while Organizations list hasMember arrays, and ensuring every entity connects to at least two others (preventing isolated nodes in the entity graph that Google can’t contextualize).
Use this for:
‧ Structured data architecture planning before implementation by mapping all entities and their relationships in a spreadsheet to identify gaps and inconsistencies early
‧ Entity graph visualization and validation ensuring every organization member, article author, product owner, and concept relationship is properly bidirectional and interconnected
‧ @id URL pattern standardization by establishing consistent identifier conventions across entity types before deploying schema markup to pages
‧ Cross-functional collaboration between SEO teams, developers, and content teams by providing a shared planning document that doesn’t require technical schema.org syntax knowledge
‧ Knowledge graph optimization for Google understanding by ensuring entity relationship density meets minimum connectivity requirements (2+ connections per entity)
‧ Author authority establishment by systematically linking Person entities to Organizations, Articles, and expertise Concepts for E-E-A-T signals
‧ Topical authority mapping by defining Concept entities that multiple Articles reference, demonstrating comprehensive coverage of subject areas
‧ Schema implementation quality assurance using the Validation checklist to catch common errors like text names instead of @id references or missing bidirectional relationships
‧ Permanent identifier management by planning @id URLs that remain stable even if content URLs or page locations change, preserving entity continuity
‧ Multi-site entity relationship planning for organizations with multiple domains or subdomains by establishing a centralized data subdomain (data.yoursite.com) for all entity identifiers
This is perfect for technical SEO specialists, structured data implementers, knowledge graph strategists, and enterprise SEO teams planning comprehensive schema.org deployments—particularly valuable when implementing organization-wide structured data that connects people, content, products, and expertise areas into a coherent entity graph, when migrating from simple page-level schema to interconnected entity-based markup, when establishing author authority through proper Person-Organization-Article relationships for E-E-A-T, when planning permanent @id URL structures that survive site redesigns or content migrations, or when coordinating structured data implementation across multiple stakeholders who need a non-technical planning tool before developers write actual JSON-LD code—all designed to prevent the common implementation failures where entities exist in isolation without relationships, use inconsistent identifier patterns, or rely on plain text references that Google can’t definitively resolve to unique entities.