Footwear: the shoe data stack — Guides

Footwear inherits the apparel attribute stack and adds two layers that no other category has to model: width as a first-class attribute (equal weight to size) and sizing-system multiplication. A single shoe SKU sold globally has nine size systems × five widths × two genders = 90 distinct variant identities the catalog has to expose.

This guide is the footwear-specific stack: what the apparel guide shares, what footwear adds, and the attribute patterns that decide surfacing in fit-intent queries.

What “footwear” means here

Three sub-verticals with shared and distinct attribute needs:

Athletic and performance — running, training, court sports, trail. Activity-specific attributes (terrain, drop, stack height) matter alongside the standard fit attributes.
Casual and lifestyle — sneakers, loafers, slip-ons. Material and brand identity carry more surfacing weight than performance specs.
Dressy and outdoor — boots, dress shoes, hiking. Construction type (Goodyear welt, cement, stitched), waterproofing certifications, and use case drive surfacing.

Cross-cutting all three: the size + width + gender + age structure.

What footwear inherits from apparel

The eight apparel attributes (size, size_system, color, gender, age_group, material, fit, country_of_origin) all apply. See Apparel: the fashion data stack for the foundation pattern.

What footwear adds

Three attributes apparel doesn’t have:

1. Width

Footwear sizing is two-dimensional in a way apparel sizing isn’t. A “size 10” with no width attribute is incomplete — wide-foot buyers explicitly query width (“size 10 wide running shoes for women”). A catalog that doesn’t expose width loses those queries entirely.

Width values vary by region and brand:

US men’s: B (narrow), D (medium), 2E (wide), 4E (extra wide)
US women’s: AA (narrow), B (medium), D (wide), 2E (extra wide)
EU: standard width is implicit; wide options labeled “G”, “H”, “K”, “M” in different brands
UK: F (medium), G (wide), H (extra wide)

The schema mapping uses additionalProperty (no first-class Schema.org property for width):

"additionalProperty": [
  {
    "@type": "PropertyValue",
    "name": "Width",
    "value": "D (medium)"
  }
]

2. Construction type

For dressy shoes, boots, and casual leather: Goodyear welt, blake stitch, cement construction, etc. Buyers who care about resoleability search on construction type explicitly.

3. Activity (athletic)

For performance footwear: running surface (road, trail, track), sport, support level (neutral, stability, motion control). Without activity attributes, athletic shoes surface for generic queries but miss activity-specific intent.

The sizing-system explosion

The single biggest cause of footwear surfacing failures: a US-only catalog entering EU markets without size_system populated.

Each size-system × width combination is a separate variant for surfacing purposes. A US-only catalog where every variant has size_system: US will surface in US queries and fail in EU/UK/JP queries even when the products ship internationally.

The fix is GMC supplemental feeds — one row per size-system per variant. The same physical SKU appears multiple times in the feed, once per region, with the correct size value in each row.

The schema pattern for footwear

{%- assign variant = product.selected_or_first_available_variant -%}
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | json }},
  "sku": {{ variant.sku | json }},
  {%- if variant.barcode -%}
  "gtin13": {{ variant.barcode | json }},
  {%- endif -%}
  "brand": {
    "@type": "Brand",
    "name": {{ product.vendor | json }}
  },
  "category": "Apparel & Accessories > Shoes > {{ product.product_type }}",
  "color": {{ variant.option1 | json }},
  "size": {{ variant.option2 | json }},
  {%- if product.metafields.product.material -%}
  "material": {{ product.metafields.product.material | json }},
  {%- endif -%}
  "additionalProperty": [
    {%- if product.metafields.product.width -%}
    {
      "@type": "PropertyValue",
      "name": "Width",
      "value": {{ product.metafields.product.width | json }}
    },
    {%- endif -%}
    {%- if product.metafields.product.construction -%}
    {
      "@type": "PropertyValue",
      "name": "Construction",
      "value": {{ product.metafields.product.construction | json }}
    },
    {%- endif -%}
    {%- if product.metafields.product.activity -%}
    {
      "@type": "PropertyValue",
      "name": "Activity",
      "value": {{ product.metafields.product.activity | json }}
    },
    {%- endif -%}
    {%- if product.metafields.product.size_system -%}
    {
      "@type": "PropertyValue",
      "name": "Size system",
      "value": {{ product.metafields.product.size_system | json }}
    }
    {%- endif -%}
  ],
  "audience": {
    "@type": "PeopleAudience",
    "suggestedGender": {{ product.metafields.product.gender | json }}
  },
  "offers": {
    "@type": "Offer",
    "url": {{ shop.url | append: product.url | json }},
    "priceCurrency": {{ cart.currency.iso_code | json }},
    "price": {{ variant.price | divided_by: 100.0 | json }},
    "availability": {%- if variant.available -%}
      "https://schema.org/InStock"
    {%- else -%}
      "https://schema.org/OutOfStock"
    {%- endif %}
  }
}
</script>

Footwear-specific GMC feed structure

In addition to the apparel-required attributes, footwear feeds need:

Attribute	Format	Notes
`size`	Numeric or labeled	Use the value matching `size_system`
`size_system`	`US`, `UK`, `EU`, `JP`, `CN`, `AU`, `BR`, `MX`	Required
`size_type`	`regular`, `petite`, `tall`, `plus`, `maternity`	Optional for footwear; rarely used
`color`	Single normalized color	Required
`material`	Comma-separated for blends	Recommended
`pattern`	`solid`, `striped`, `floral`, `plaid`	Optional
`gender`	`male`, `female`, `unisex`	Required
`age_group`	`adult`, `kids`, `infant`, `newborn`	Required

Width is not a first-class GMC attribute. Encode it in product_detail (a key-value attribute):

product_detail: width:D (medium)

GMC’s product_detail accepts [section]:[name]:[value] triples; for width specifically, the convention that surfaces best is using the simple width name without a section prefix.

Q&A pairs as a sibling FAQPage block

Footwear has the densest pre-purchase Q&A of any category — fit, width comparison, sizing across regions, break-in, half-size handling. Render that content as a sibling FAQPage JSON-LD block alongside the Product block, not nested inside it. See Product schema for Shopify for the rendering pattern.

The contrarian take

Most footwear-SEO content recommends keeping all sizes in one variant grouping (one product, many size variants). For the storefront UX this is correct. For AI agent surfacing, particularly for fit-intent queries, separating wide and standard widths into their own products (not variants) often surfaces better.

The reason: AI agents that handle “wide running shoes” queries weight whether width appears as a top-level attribute on the matched product. A wide variant nested under a standard product sometimes gets matched to the parent (which doesn’t have wide as a top-level attribute) instead of the variant. Splitting into two parent products with explicit width in each title and additionalProperty fixes the misattribution.

The trade-off: the storefront UX is worse (two products instead of one). For catalogs where wide-fit traffic is meaningful, the surfacing lift outweighs the UX cost.

Where it breaks

Half sizes. US footwear ships in half-size increments (8, 8.5, 9, 9.5). Some markets don’t support half sizes. Mapping US half sizes to EU integer sizes is lossy; AI agents querying in EU sizes may miss half-size US products.
Brand-specific sizing quirks. Many footwear brands have documented sizing variations from category averages, and some use EU sizing exclusively. Catalogs that resell multiple brands need brand-aware size mapping or a published size-conversion table on the product page; failure to handle this surfaces poorly in fit-intent queries.
Custom and made-to-measure. Bespoke footwear breaks the variant model entirely. Use a single product with the customization options described in the description; AI agents won’t surface these for size-specific queries.

What to ship this week

Add a width metafield with structured values (D, 2E, etc.)
Backfill size_system for every variant.
Update the Liquid template to render additionalProperty with width and construction.
Configure the footwear-specific GMC feed with all required attributes plus product_detail for width.
For wide-fit-heavy catalogs, evaluate the split-product approach for top-revenue widths.