Pet products: an emerging category with unsettled data standards

Reference guides: For the underlying schema patterns, see product schema for Shopify. Platform-agnostic structured data principles apply across the major ecommerce platforms — see the per-platform guides for the implementation patterns specific to each.

Pet retail is unusual among ecommerce categories in that it has no formal product-data standard. There is no equivalent of GS1’s apparel attribute work for sizing, no FDA-mandated nutrition panel for the human-food category. AAFCO publishes pet food labeling guidelines, which are widely used in product packaging, but there’s no corresponding Schema.org vocabulary that maps cleanly to them.

The result is a category where most product pages run on the default ecommerce platform’s product schema and don’t carry the category-specific attributes that distinguish a pet product from a generic catalog item. This post is a reference for the attribute fields that matter and the Schema.org patterns that work for them.

Category-specific attributes that don’t fit default Product schema

Three layers of attribute that pet products typically need beyond what a default Product block carries:

Animal and life-stage targeting

• Animal type: dog, cat, small pet, bird, reptile, fish
• Life stage: puppy/kitten, adult, senior, all life stages
• Breed size: small, medium, large, giant (for dog products)
• Weight or age range when relevant

Food, treat, and supplement specifics

• Ingredient list (full, ordered)
• Guaranteed analysis: protein, fat, fiber, moisture
• Calorie content per cup or per treat
• AAFCO statement (e.g., “complete and balanced for adult maintenance” — the standard phrasing AAFCO publishes)
• Country of origin and country of manufacture
• Grain-free, limited-ingredient, single-protein flags

Hard-good specifics (toys, beds, crates, accessories)

• Material
• Dimensions
• Weight capacity (for crates, carriers, beds)
• Washable or non-washable

None of these map to the default fields most ecommerce platforms ship out of the box. The implementation pattern is to model them as custom attributes (Shopify metafields, WooCommerce attributes / ACF fields, BigCommerce custom fields, Adobe Commerce EAV attributes) and then render them into structured data as additionalProperty entries.

The Schema.org rendering pattern

Product.additionalProperty is the Schema.org-defined way to attach arbitrary PropertyValue entries to a product. The structure is the same across every major ecommerce platform; only the templating language changes.

Shopify Liquid example:

"additionalProperty": [
  {
    "@type": "PropertyValue",
    "name": "Animal",
    "value": {{ product.metafields.pet.animal | json }}
  },
  {
    "@type": "PropertyValue",
    "name": "Life stage",
    "value": {{ product.metafields.pet.life_stage | json }}
  },
  {
    "@type": "PropertyValue",
    "name": "AAFCO statement",
    "value": {{ product.metafields.pet.aafco | json }}
  },
  {
    "@type": "PropertyValue",
    "name": "Calories per cup",
    "value": {{ product.metafields.pet.kcal_per_cup | json }}
  }
]

The point is that the data ends up in structured fields rather than only in the description prose. Schema.org defines additionalProperty as the catch-all for vocabulary that isn’t covered by the standard Product properties; that makes it the right home for category-specific attributes that AAFCO and similar bodies define but Schema.org doesn’t.

Where pet schema modeling gets harder

Several category-specific concerns worth thinking about explicitly, because the default product schema doesn’t cover them well:

• Bundles and multi-pet households. DTC pet brands often sell bundles (puppy starter kits, multi-pet packs). Modeling a bundle as a single product with a single life stage flattens the data. Schema.org has ProductCollection for explicit collections; bundle modeling is the harder unsolved part of pet schema.
• Subscription pricing. Most pet food catalogs run a subscribe-and-save discount. The Schema.org Offer block represents a single price; subscription pricing requires either rendering the headline price (and not the subscriber price) or using a more detailed OfferShippingDetails and PriceSpecification pattern that most catalogs don’t adopt. Inconsistency here can produce misleading price comparisons in any system that ingests the schema.
• Recall handling. Pet food and treat recalls happen periodically. Recalled SKUs should have availability: Discontinued and a notice in the description. Catalogs that leave recalled products at InStock create a downstream surfacing risk.
• Veterinary diet products. Prescription pet food is sold through a veterinarian gate. Surfacing it to general consumer queries is a poor experience. The Schema.org audience field is the right place to indicate the gated audience; a separate URL pattern for veterinary diet content can also help downstream consumers of the catalog distinguish the two.

A reasonable order of operations

For any pet catalog that’s mostly running on platform-default product data:

1. Add the animal, life stage, and breed size attributes as custom fields. These are the floor — without them, a pet product is structurally indistinguishable from a generic product entry.
2. Add the food and supplement attributes for the categories that need them: AAFCO statement, calorie content, guaranteed analysis. Most of this data already exists on the product packaging or in supplier feeds.
3. Sync the enriched attribute set to Google Merchant Center with the pet_lifecycle_stage and related attributes that GMC’s pet category supports.
4. Treat functional claims (joint support, dental health, calming) and certifications (Global Animal Partnership, MSC, Certified Humane) as a separate, later project. These don’t have settled structured-data patterns and benefit from the basics being in place first.

The pet category may eventually have a published structured-data standard. Until it does, custom attributes rendered through additionalProperty are the closest thing to one — and the implementation is mechanically the same regardless of which ecommerce platform the catalog runs on.