DEV Community

Joseph Anady
Joseph Anady

Posted on • Originally published at steelesolutions4u.com

Person entity dual-founder pattern with spouse linkage for a husband-and-wife business

#seo #webdev #schema #beginners

Person entity dual-founder pattern with spouse linkage for a husband-and-wife small business

Husband-and-wife co-founder businesses are common. The Schema.org graph for them rarely captures the relationship explicitly. Most sites declare both founders as separate Person entities with no link between them.

The denser pattern declares the spousal relationship inside the graph itself using the spouse property, then uses both ＠id references to make the entities reciprocally addressable.

This is the pattern I built for Steele Solutions, a husband-and-wife merchant services brokerage in Branson, Missouri.

The standard mistake

Two separate Person nodes, no relationship between them:

{
  "@graph": [
    {"@type": "Person", "@id": "https://example.com/#founder1", "name": "Jim Steele"},
    {"@type": "Person", "@id": "https://example.com/#founder2", "name": "Kim Steele"}
  ]
}
Enter fullscreen mode Exit fullscreen mode

Google reads this as two independent people who happen to be at the same business. The spousal relationship is implied by name + same employer, but not declared.

The reciprocal-spouse pattern 

{
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://steelesolutions4u.com/#jim",
      "name": "Jim Steele",
      "givenName": "Jim",
      "familyName": "Steele",
      "jobTitle": "Co-founder and Principal, CSSI National Account Executive",
      "spouse": {"@id": "https://steelesolutions4u.com/#kim"},
      "worksFor": {"@id": "https://steelesolutions4u.com/#organization"}
    },
    {
      "@type": "Person",
      "@id": "https://steelesolutions4u.com/#kim",
      "name": "Kim Steele",
      "givenName": "Kimberly",
      "additionalName": "Kayleen",
      "familyName": "Steele",
      "alternateName": ["Kim Steele", "Kimberly K. Steele", "Kimberly Kayleen Steele"],
      "jobTitle": "Co-founder and Principal, ATM Placement Program Lead",
      "spouse": {"@id": "https://steelesolutions4u.com/#jim"},
      "worksFor": {"@id": "https://steelesolutions4u.com/#organization"}
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Both Person entities reference each other through spouse. The graph is reciprocal. Google reads the relationship as a fact.

What the additionalName + alternateName pattern adds

The Schema.org Person type has three name-related properties:

  • name — the canonical display name
  • givenName — first name
  • familyName — last name
  • additionalName — middle name (or names)
  • alternateName — array of alternative names

For Kim Steele:

{
  "name": "Kim Steele",
  "givenName": "Kimberly",
  "additionalName": "Kayleen",
  "familyName": "Steele",
  "alternateName": [
    "Kim Steele",
    "Kimberly K. Steele",
    "Kimberly Kayleen Steele"
  ]
}
Enter fullscreen mode Exit fullscreen mode

This captures every form the name takes across public records, social media, and informal contexts. Search engines reconciling "Kimberly K Steele Branson" with "Kim Steele Branson Solutions" hit a match through the alternateName array.

Cross-references to Organization

Both Person entities also reference the Org as worksFor:

"worksFor": {"@id": "https://steelesolutions4u.com/#organization"}
Enter fullscreen mode Exit fullscreen mode

The Org entity reciprocally lists both as founder:

{
  "@type": ["LocalBusiness", "FinancialService", "ProfessionalService"],
  "@id": "https://steelesolutions4u.com/#organization",
  "name": "Steele Solutions",
  "founder": [
    {"@id": "https://steelesolutions4u.com/#jim"},
    {"@id": "https://steelesolutions4u.com/#kim"}
  ]
}
Enter fullscreen mode Exit fullscreen mode

Now the graph forms a complete triangle: Jim ↔ Kim (via spouse), Jim → Org (via worksFor), Kim → Org (via worksFor), Org → Jim + Kim (via founder array).

Per-founder differentiation

Husband and wife at the same business often have different domains of expertise. The schema captures the differentiation through knowsAbout and hasCredential:

{
  "@id": "https://steelesolutions4u.com/#jim",
  "knowsAbout": [
    "Merchant Services",
    "POS Systems",
    "Credit Card Processing",
    "Cost Segregation",
    "Banking",
    "Small Business Lending"
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "CSSI National Account Executive",
      "credentialCategory": "Professional Designation"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "name": "Indiana University Business Graduate",
      "credentialCategory": "Bachelor's Degree, Business"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

For Kim, a different knowsAbout:

{
  "@id": "https://steelesolutions4u.com/#kim",
  "knowsAbout": [
    "ATM Placement",
    "Merchant-Owned ATMs",
    "Free ATM Placement Program",
    "Operations",
    "Client Onboarding",
    "Merchant Services Account Management"
  ]
}
Enter fullscreen mode Exit fullscreen mode

Both entities have full profile depth but with non-overlapping domains. The search engine can rank Jim for sales-side queries and Kim for operations-side queries.

What this signals

For a husband-and-wife co-founder business:

  1. Explicit relationship: Google's Knowledge Graph treats the reciprocal spouse link as a verified fact rather than an inference
  2. Disambiguation: when multiple Jim Steeles exist online, the spouse link to Kim Steele provides additional triangulation
  3. AI engine clarity: ChatGPT and Claude treat the explicit relationship as a citation-worthy fact when describing the business
  4. Knowledge Panel reconciliation: Google may eventually build a Knowledge Panel for the business that names both founders correctly

For Steele Solutions, the complete dual-founder graph is at https://steelesolutions4u.com/entity.json.

References

Top comments (0)