RULE: One Service schema per vertical when offerings genuinely differ. Multi-audience Service when offering is identical.

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.

Why: Schema.org's canonical patterns (Schema.org: Service.audience accepts Audience | PeopleAudience | BusinessAudience with audienceType as free-text, Schema.org canonical pattern: one Service entity with audience: { type: Audience, name: ... } + areaServed) 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.

Per Aubrey Yung: "audience captures relevance; areaServed captures coverage", audience captures who, areaServed captures where — these are independent dimensions.

How to apply:

• During IA planning, list the verticals and ask per service: "is the underlying offering different per vertical, or just packaged differently?"
• Different = separate Service entities, one per vertical page
• Same = single Service entity, multi-audience
• 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