Shopify metafield structure for custom product options (AI-readable)

Model custom product options as metaobjects, link them to products with a single reference metafield, and emit them in Product schema as additionalProperty and offer specifications. That turns engraving, bundles, and configurators — normally invisible app data — into structured facts that both shoppers and AI engines can read and act on.

I am a senior Shopify developer in Delhi, and I build option-heavy stores — personalised jewellery, made-to-order furniture, configurable supplements — for D2C brands in India, the US, and the UAE. This post is the option-specific companion to my broader metafield strategy for AI-readable stores: that one covers product attributes; this one covers the choices a buyer makes.

Why custom options are invisible to AI

Shopify's native model handles two things well. Variants are stock-keeping combinations — size, colour, up to three option dimensions — that carry their own SKU, price, and inventory. Product attributes are descriptive facts, best stored as metafields. Both are readable: variants land in Product schema automatically, and attributes land there once you wire them in.

Custom product options are the third category, and Shopify has no native home for them. These are buyer choices that do not create a variant: engraving text, gift-wrap toggles, a build-your-own bundle, a "choose 3 of 8 flavours" configurator, a monogram, a made-to-order finish. Because there is no native slot, brands reach for an option app. And that is where the data disappears.

Most option apps store their configuration in the app's own database and inject the choices onto the page with JavaScript at runtime. To a crawler or an AI engine, the product page looks like it has no options at all — the choices only exist after a script runs, in markup no schema describes. So a genuinely rich, configurable ₹4,000 product reads to ChatGPT exactly like a plain one. The buyer sees ten thoughtful choices; the AI sees a name, a price, and an image.

There is a worse pattern still: options stored as free-text line-item properties with no definition anywhere. Those are readable by nothing — not your theme's schema, not analytics, not an AI engine, and barely by your own reporting.

The model: metaobjects for definitions, a metafield to link

The clean structure separates two concerns.

Metaobjects define the reusable option sets. A metaobject is a structured, typed, standalone record you define once and reference many times. "Engraving styles," "frame finishes," "bundle slots," "monogram fonts" — each becomes a metaobject definition with typed fields. Define the choices once; reuse them across every product that offers them.

A product metafield links the product to its option sets. On each product, one metafield of type "list of metaobject references" points at the option sets that product supports. No duplication, no per-product copy-paste, and one edit to a metaobject updates every product that references it.

Here is why this split matters for AI readability specifically:

Misusing variants for non-stock options is the trap I see most. If you turn "engraving: yes/no" into a variant dimension, you have burned one of your three variant slots, doubled your SKU count, and created inventory Shopify now thinks it must track. Variants are for things you stock. Options are for things a buyer specifies. Keep them apart.

Naming and types that stay AI-readable

The whole point is that a machine can map your option to a real buyer decision. Naming discipline is what makes that possible.

Namespace. Put everything under one stable, human-named namespace — I use custom_options. Not the app's namespace, which changes when you switch apps. Not custom.field_7, which means nothing.

Keys. Lowercase snake_case, describing the choice, not the mechanism. engraving_max_characters, not app_limit. bundle_slot_count, not qty3. A key an AI engine can read is a key that names the decision.

Types. Pick the tightest type the field allows. This is where most option data rots.

Strict types are not bureaucracy — they are what stops "₹200", "200 rupees", and "add 200" from all describing the same price delta three incompatible ways. A boolean cannot drift. An integer cannot become prose. The tighter the type, the cleaner the data an AI extracts.

If you have not internalised why typed structure beats free text for AI, product schema for AI shopping walks the schema half in depth, and how AI assistants recommend stores covers why enumerable, typed data is what gets a product surfaced as an answer.

Storefront exposure: options must exist before JavaScript runs

Defining metaobjects is half the job. If they are only read by an app's client-side script, an AI engine still sees nothing. The options have to be rendered by your theme, server-side, in Liquid.

Because the product references its option sets through a metafield, your theme can loop the referenced metaobjects and render them into the page markup directly — the choices exist in the HTML the moment the page loads, before any script. That does two things at once: shoppers on a slow connection see the options instantly (which matters for the low-bandwidth mobile speed most Indian D2C traffic runs on), and crawlers plus AI engines see the same markup a browser does.

This is also where an over-reliance on option apps hurts twice. Every app that injects options client-side also injects a script that runs on every product page, which is one of the app-overhead performance costs I most often strip out. Native metaobject rendering removes both problems: it is faster and readable.

Emitting options in Product schema

Now wire the option metaobjects into the JSON-LD your product page already emits. Two schema homes matter for options.

additionalProperty describes non-priced characteristics of the option — what fonts exist, what the character limit is, whether monogramming is available. Offer-level priceSpecification and PropertyValueSpecification describe options that change price or are required to purchase.

Here is a trimmed snippet. It assumes each referenced option-set metaobject exposes label, required (boolean), price_delta (money), and choices (list). Wire it into the same product-schema.liquid you already render.

{%- liquid
  assign option_sets = product.metafields.custom_options.sets.value
-%}
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "{{ shop.url }}{{ product.url }}#product",
  "name": {{ product.title | json }},
  "offers": {
    "@type": "Offer",
    "url": "{{ shop.url }}{{ product.url }}",
    "price": "{{ product.selected_or_first_available_variant.price | money_without_currency | replace: ',', '' }}",
    "priceCurrency": "{{ cart.currency.iso_code }}"
  }{% if option_sets %},
  "additionalProperty": [
    {%- for set in option_sets -%}
    {
      "@type": "PropertyValue",
      "name": {{ set.label | json }},
      "value": {{ set.choices.value | join: ", " | json }},
      "valueReference": {{ set.required.value | json }}
    }{% unless forloop.last %},{% endunless %}
    {%- endfor -%}
  ]{% endif %}
}
</script>

The two lines that do the AEO work are name (the option label an AI reads as "what can I choose?") and value (the enumerable choices). A buyer asking an assistant "can I get this engraved?" gets a yes extracted directly from your schema, not guessed from a description. That is the same extraction-beats-inference principle behind every page on my schema markup checklist.

Validate the output with Google's Rich Results Test and Schema.org's validator before you ship — malformed JSON-LD is worse than none, because it can suppress the valid parts too.

Priced and validated options: where Functions come in

Everything above works on any current Shopify plan. Metaobjects and metafields are standard features — you can do all of this on Basic (about ₹1,994/mo, roughly $24; annual billing knocks off around 25%; always verify on shopify.com/in/pricing).

Where the plan matters is enforcement. If a custom option must add ₹200 at checkout, or an engraving must be blocked over 20 characters, or a "choose 3" bundle must reject a 4th pick, that logic lives best in Shopify Functions, which are a Plus feature. Functions let you validate and price options natively at checkout instead of trusting an app to hold the line. I cover concrete patterns in Shopify Functions examples and checkout customization on Plus.

The AI-readability and the checkout-enforcement are separate jobs. You get the readable structure on Basic; you get validated pricing on Plus. Do not let an agency tell you that you need Plus just to have configurable products read correctly — you do not.

What this costs to build properly

This is scoped work, not a plug-in-an-app afternoon. The variable is how many option sets you have and how tangled the current app setup is.

USD is approximate at about ₹83 to the dollar. These sit inside my standard Shopify developer rates, and the wider build context is in what it costs to build a Shopify website in India. The recurring line is optional — many brands take the one-time build, populate option sets themselves, and only return when the catalogue grows.

The saving that pays for the work is not the developer fee. It is dropping the monthly option-app subscription, removing the script it injected on every page, and — the part brands underestimate — finally having configurable products that AI shopping engines can actually recommend, because the engine can finally see what a buyer gets to choose.

What's next

If your best products are your most configurable ones — and they usually are — and none of that configurability reaches Google or an AI assistant, that is a fixable gap. Tell me your store URL, which products carry custom options, and how they are built today (which app, or line-item properties), on the Shopify developer page or through the intake form at /start. I will tell you honestly whether it is a one-day metaobject job or a full migration, and give you a fixed number either way.

Related reads

• The Shopify metafield strategy that makes your store AI-readable — the attribute-side companion to this options post.
• Product schema for AI shopping — the full JSON-LD that AI shopping engines read.
• Shopify Functions examples — validating and pricing options natively at checkout on Plus.

Sources

• Shopify Help — Metaobjects
• Shopify Help — Custom data with metafields
• Schema.org — PropertyValue