Weight (as a Numeric, Unit-Declared Field)

Weight is one of the most commonly used filter attributes in categories where it matters, hiking and camping gear, luggage, baby products, pet products, cycling equipment, and one of the most consistently missing or imprecise attributes in those same catalogs. “Lightweight,” “ultralight,” and “extremely light” appear in descriptions everywhere. A typed numeric field containing “490g” appears far less frequently.

Why it matters beyond filtering: weight is a primary evaluation criterion for AI shopping agents in weight-sensitive categories. An agent fulfilling the query “hiking jacket under 500g” executes a structured filter. A product with “lightweight” in its description fails the filter. A product with weight: 490g passes. The same gap applies to luggage (cabin baggage compliance), cycling (gram-counting purchases), baby products (carrier weight limits), and pet products (crate weight ratings).

Fix: source weight from supplier data sheets or measure directly. Store as a numeric value with explicit unit (g, kg, lbs). Expose as a filterable attribute in your product data model. Include in product_details feed field and schema additionalProperty.

Compatibility Lists (Specific, Not Generic)

For electronics, accessories, automotive parts, cables, phone cases, screen protectors, and replacement components, compatibility is the primary purchase decision criterion. The shopper is not asking “is this a good phone case?” They are asking “does this phone case fit an iPhone 16 Pro Max?” A product that says “compatible with most smartphones” has answered neither question.

Most compatibility data in retail catalogs is generic at best and absent at worst. “Compatible with Apple devices” is not compatible list data. “Compatible with: iPhone 14, iPhone 14 Plus, iPhone 14 Pro, iPhone 14 Pro Max, iPhone 15, iPhone 15 Plus, iPhone 15 Pro, iPhone 15 Pro Max, iPhone 16, iPhone 16 Plus, iPhone 16 Pro, iPhone 16 Pro Max” is compatible list data.

The commercial implication: every specific device model that is missing from your compatibility list is a specific query your product cannot match. An agent evaluating “compatible with iPhone 16 Pro Max” against a catalog containing “compatible with most Apple devices” does not include your product, because the structured matching requires an explicit declaration, not an inference.

Fix: build a structured compatibility array for every product in categories where compatibility is a purchase criterion. Use exact make-model-year format. For automotive: Year/Make/Model/Engine. For electronics: exact device name as Apple, Samsung, and Google list them. For accessories: include connection type and version (USB-C 3.2 Gen 2).

Fit Type / Cut (Beyond “Regular”)

In apparel, “Regular Fit” is the canonical placeholder that appears when no one thought carefully about fit. It is also nearly meaningless, because “regular” means different things to different brands and different shoppers. The attributes that actually matter for apparel discovery and return rate reduction are specific fit descriptors: Slim Fit, Athletic Fit, Relaxed Fit, Oversized, Boxy, Tailored, Dad Fit, Cropped.

Beyond these base descriptors, fit data that is almost never structured but that frequently appears in description prose: rise (for trousers, high rise, mid rise, low rise), length (regular, short, long, particularly important for tall or petite shoppers), and model sizing notes (“model is 6'1" and wears a Medium,” this should be a structured attribute, not a sentence in a description).

Wrong size returns in apparel average 25–35% of total returns. A significant portion of these are fit-related rather than size-related, the shopper chose the right size label but received a fit that did not match their expectation. Structured fit data significantly reduces this return category by helping shoppers self-select accurately.

Sustainability and Environmental Certifications

Sustainability attributes have moved from a niche filter to a mainstream purchase criterion in a remarkably short time. Searches incorporating sustainability terms in outdoor gear, apparel, and home categories have grown significantly year-over-year. Google AI Overviews for queries like “sustainable hiking jacket” or “recycled polyester outdoor gear” are already live and already filtering products using structured sustainability attributes.

The attributes that matter are specific and verifiable: recycled material percentage (“58% recycled polyester”), certification body and standard name (“OEKO-TEX Standard 100 certified,” “Bluesign Approved,” “Fair Trade Certified”), packaging claims where verifiable, and repair/durability claims backed by warranty terms. What does not matter: “we are committed to sustainability” in the description.

Fix: if your products have sustainability credentials, declare them as structured attributes. Material composition by percentage. Certification names exactly as the certifying body lists them. Recyclability or end-of-life claims where you have documentation to support them. These are not marketing claims, they are structured data points with commercial and increasingly legal implications.

Delivery Time (as Structured Data, Not Marketing Copy)

Delivery time is a purchase decision criterion that most catalogs treat as marketing copy rather than structured data. “Fast delivery,” “ships within 24 hours,” and “express available” appear in descriptions everywhere. The structured shippingDetails schema field that makes delivery time machine-queryable by AI agents appears on fewer than 25% of DTC product pages.

The commercial case for structured delivery time is growing as AI shopping agents increasingly evaluate time-sensitive criteria. A shopper who asks an AI assistant to find a product that ships by Friday is making a time-bound purchase. An agent that can evaluate shippingDetails transitTime against that constraint will include products with specific delivery commitments and exclude those with vague ones. “Ships in 1–3 business days” as structured data is matchable. “Fast delivery” as marketing copy is not.

Fix: implement OfferShippingDetails schema on all product pages with specific transitTime minValue and maxValue in days. For products with multiple shipping options (standard, express), implement separate OfferShippingDetails entries per option. Keep delivery time data current, it should reflect actual warehouse dispatch capability, not an aspirational SLA.

Return Policy (as Machine-Readable Data)

Return policy is one of the most searched-for purchase-decision criteria that ecommerce teams most consistently fail to surface in structured data. Shoppers evaluating a purchase, particularly for high-value items, first-time purchases from an unfamiliar brand, or products with fit or compatibility risk, frequently check return policy as a purchase qualifier.

Most retailers have return policies on their website. Almost none have those policies declared in hasMerchantReturnPolicy schema, which makes the return policy machine-readable for AI agents evaluating purchase confidence. An AI agent making a purchase recommendation for a £200 outdoor jacket will include merchant reliability signals in its evaluation, and structured return policy data is a trust signal that improves confidence scoring.

Fix: implement hasMerchantReturnPolicy schema with returnPolicyCountry, returnWithin (as a QuantitativeValue with specific days), and returnMethod. This is a one-time implementation that serves every product page. The data is static (unless you change your returns policy), it does not need to be dynamically generated.

Usage Instructions and Care Data

Care and usage data, washing instructions for apparel, care instructions for furniture, usage limitations for electronics, storage requirements for food products, reduces a specific, underdiagnosed return type: products returned because the shopper discovered a care requirement they did not know about and did not want to comply with.

A shopper who buys a “dry clean only” jacket without knowing it is dry clean only will return it when they discover that fact. A shopper who knows it is dry clean only before buying has self-selected correctly. Care data is as much a return-prevention mechanism as a compliance requirement.

Fix: add care_instructions as a structured attribute field (not just a care label image or a description paragraph). For apparel: ISO care label symbols plus plain-language equivalents. For electronics: operating temperature range, moisture resistance level (IP rating if applicable), storage conditions. For food: storage method, refrigeration requirement, use-by guidance. These attributes are almost always available from supplier data, they are just rarely extracted into structured fields.

Bundle Contents and Inclusions

For any product that ships with accessories, components, or complementary items, electronics, tools, kitchen appliances, sports equipment, the “what’s in the box” question is one of the most common pre-purchase questions and one of the most commonly missing pieces of structured data. Most catalogs either omit the inclusions list entirely or bury it in description text where it is readable but not structured.

A structured inclusions list serves two functions: it reduces pre-purchase uncertainty (which improves conversion), and it reduces “not as described” returns caused by unmet expectations about what the product includes (a buyer who expected a cable that was not included, a buyer who expected batteries that were sold separately). Both of these are data quality failures.

Fix: add a box_contents or inclusions field as a structured array attribute. List each included item explicitly. This does not need to be comprehensive to the component level, “1× [Product], 1× USB-C charging cable, 1× quick start guide, 1× 24-month warranty card” is sufficient. Ensure this attribute is included in your product_details feed field and schema additionalProperty.

Age / Life Stage Suitability

For products with relevant age suitability, children’s products, supplements, educational materials, toys, sporting goods, age or life stage suitability is a primary filter attribute that most catalogs either omit entirely or express imprecisely.

The structured version: age_range: “3–8 years” or life_stage: “Toddler” as typed fields, not “suitable for young children” in the description. For supplements: age_group: “Adult (18+)” or specific contraindication language as structured data. For educational products: school_year, curriculum_level, or reading_age as structured attributes.

The safety dimension makes this attribute category non-optional for products where age suitability has regulatory relevance: toys (CE marking and age warning requirements), supplements (age-specific dosing), and infant products (weight and developmental stage recommendations). Age suitability as a structured field is both a commercial attribute and a compliance data point.

Colour as Both a Canonical Value and a Descriptive Name

This final entry is not about a missing attribute, colour is usually present. It is about a structural gap that affects both AI matching and SEO performance simultaneously.

Most catalogs store color in a single field, which means a choice must be made: use the canonical value that enables reliable filter matching (“Navy Blue”), or use the evocative product name that improves SEO and conversion (“Atlantic Night Blue”). Both are legitimate needs. Neither fully serves the purpose of the other.

The correct implementation is two fields: a canonical color field (mapped to the standard color taxonomy values used by Google Shopping and your website’s filter system), and a display color field (the commercial, brand-expressive name that appears on the product page and in the marketing copy). The canonical field is machine-readable and filter-queryable. The display field is human-readable and brand-consistent. They serve different purposes and should be separate data points. Fix: add a canonical_color attribute field alongside your existing color field. Normalize all canonical_color values to the standard taxonomy. Use the canonical field for feed submission to Google and for faceted navigation. Keep the display field for what the shopper reads.