{"id":212,"slug":"rule-one-service-per-vertical-when-offerings-differ","title":"RULE: One Service schema per vertical when offerings genuinely differ. Multi-audience Service when offering is identical.","kind":"rule","scope":"business","status":"current","audiences":["claude-code","dev","candid-team"],"topics":["schema-org","information-architecture"],"reference_body":"**Rule:** Use **one `Service` schema entity per vertical** when verticals have genuinely different offerings (different SKUs, different regulations, different delivery patterns). Use **one `Service` with multiple `audience` values** when the underlying offering is materially identical across audiences.\n\n**Why:** Schema.org's canonical patterns ([[schema-org-service-audience-property]], [[schema-org-government-service-audience-canonical-pattern]]) support both shapes. The choice is a content-truth question, not a schema-style preference. If \"Agriculture Lubricant Supply\" and \"Construction Lubricant Supply\" are different products with different SKU lists and different OEM approvals, they're different services that happen to share a vendor — one Service entity each. If \"Bulk Lubricant Delivery\" is the same delivery operation regardless of who receives it, it's one service with multiple audiences.\n\nPer [[aubrey-yung-audience-vs-area-served]], `audience` captures *who*, `areaServed` captures *where* — these are independent dimensions.\n\n**How to apply:**\n- During IA planning, list the verticals and ask per service: \"is the underlying offering different per vertical, or just packaged differently?\"\n- Different = separate Service entities, one per vertical page\n- Same = single Service entity, multi-audience\n- Don't fragment schema where the underlying service is unified — search engines and AI consumers parse both shapes correctly, and over-fragmentation looks like spam","rationale_body":null,"metadata":null,"links":{"outgoing":[{"slug":"schema-org-service-audience-property","title":"Schema.org: Service.audience accepts Audience | PeopleAudience | BusinessAudience with audienceType as free-text","kind":"reference","scope":"business","link_type":"depends-on"},{"slug":"schema-org-government-service-audience-canonical-pattern","title":"Schema.org canonical pattern: one Service entity with audience: { type: Audience, name: ... } + areaServed","kind":"reference","scope":"business","link_type":"depends-on"},{"slug":"aubrey-yung-audience-vs-area-served","title":"Aubrey Yung: \"audience captures relevance; areaServed captures coverage\"","kind":"reference","scope":"business","link_type":"depends-on"},{"slug":"rule-schema-as-hygiene-not-growth-lever","title":"RULE: Always ship schema as hygiene. Never expect it alone to move AI citations.","kind":"rule","scope":"business","link_type":"relates-to"}],"incoming":[{"slug":"research-brief-ia-multi-vertical-service-business","title":"Research brief: Information architecture for service businesses with multiple verticals (piece 6 of 15)","kind":"reference","scope":"business","link_type":"relates-to"}]},"created_at":"2026-05-22T19:40:49.158Z","updated_at":"2026-05-22T19:40:49.158Z"}