Shopify metafields for SEO

Shopify metafields exist because product fields ran out. Eight built-in attributes can’t carry a beauty product’s INCI list, an apparel product’s GOTS certification, or a supplement’s NSF status. Metafields close that gap. They also create the most common over-engineering trap in Shopify product data: catalogs build out elaborate metafield structures the storefront can’t expose, the schema doesn’t read, and the GMC feed ignores. The recommended discipline: do less, structurally.

This guide is the implementation pattern. Which metafields actually move AI surfacing, how to expose them through Liquid into structured data, and the metafield patterns that look productive but aren’t.

What a useful metafield looks like

Three properties:

1. Mapped to a Schema.org property — either directly or through a well-known mapping. A metafield that doesn’t have a schema home doesn’t reach AI agents.
2. Used by the storefront — visible in product page chrome, filters, or comparison tables. Metafields that exist only in the admin do not get crawled.
3. Synced into the GMC feed — either through the default integration or a feed-management app. A metafield that doesn’t reach GMC doesn’t reach roughly half of the AI surfaces a Shopify catalog targets.

A metafield that hits all three propagates everywhere. A metafield that hits one or two leaks visibility somewhere. The work is to design for all three from the start.

The same value, traced through the three places it has to land:

The teal pill is the same value showing up in all three places. Skip any of the three and AI agents only see the value where it does land.

The metafields that move AI surfacing

Ranked by impact-per-hour-of-setup. Definition format follows Shopify’s metafield definition syntax (namespace.key, type).

1. product.gtin (single-line text)

What it does: stores the GTIN-13 or GTIN-8 when the Shopify variant barcode field isn’t being used (some catalogs reserve barcode for internal SKU identifiers).

Why: gtin13 is the single most-weighted identifier in Schema.org Product markup. AI agents use it to deduplicate the product across storefronts and to verify it’s the canonical version.

Schema mapping: gtin13 (or gtin8).

{%- if variant.metafields.product.gtin -%}
"gtin13": {{ variant.metafields.product.gtin | json }},
{%- endif -%}

2. product.material (single-line text or list of single-line text)

What it does: structured material attribute. Apparel and home goods catalogs benefit most.

Why: material is a documented input to GMC and is parseable from structured data in a way prose isn’t. Material-intent queries (“merino wool sweater,” “solid oak dining table”) depend on the attribute being populated as structured data, not only mentioned in prose.

Schema mapping: material (or additionalProperty with name “Material”).

{%- if product.metafields.product.material -%}
"material": {{ product.metafields.product.material | json }},
{%- endif -%}

3. product.country_of_origin (single-line text)

What it does: ISO country code or country name where the product is manufactured.

Why: GMC’s product data specification documents country_of_origin for product attribute submission, and queries that include a geographic preference (“made in Italy leather goods”) depend on the structured field being populated.

Schema mapping: countryOfOrigin.

{%- if product.metafields.product.country_of_origin -%}
"countryOfOrigin": {
  "@type": "Country",
  "name": {{ product.metafields.product.country_of_origin | json }}
},
{%- endif -%}

4. product.certifications (list of single-line text)

What it does: array of certifications relevant to the product — “GOTS Certified,” “Fair Trade,” “NSF Certified,” “B Corp,” “USDA Organic.”

Why: certifications are increasingly weighted in shopping-intent queries that include trust signals. Most Shopify themes don’t expose certifications structurally; metafields fill the gap.

Schema mapping: additionalProperty array.

{%- if product.metafields.product.certifications.value.size > 0 -%}
"additionalProperty": [
  {%- for cert in product.metafields.product.certifications.value -%}
  {
    "@type": "PropertyValue",
    "name": "Certification",
    "value": {{ cert | json }}
  }{%- unless forloop.last -%},{%- endunless -%}
  {%- endfor -%}
],
{%- endif -%}

5. product.size_chart_url (URL)

What it does: link to a size chart hosted on the brand’s domain.

Why: Schema.org doesn’t have a clean size-chart property, but AI agents follow URLs found in product context for fit-related queries. Catalogs that link size charts surface better in fit queries than catalogs that embed them as images.

Schema mapping: additionalProperty with name “Size Chart URL,” value the URL.

6. product.care_instructions (multi-line text)

What it does: structured care instructions — “Hand wash cold,” “Dry clean only,” “Gentle cycle, line dry.”

Why: appears in shopping-intent queries with care constraints (“machine-washable wool sweater”). Care instructions in prose descriptions are read; structured care instructions are read more reliably.

Schema mapping: additionalProperty with name “Care Instructions.”

The metafields that look productive but aren’t

The patterns catalogs commonly invest in that don’t move AI surfacing:

“Marketing taglines” metafield

A free-text metafield used to store taglines like “The softest sweater you’ll ever own.” Surfaces in product cards on the storefront, sometimes indexed by search. Does not appear in any Schema.org property and is ignored by AI agents.

The fix: if the tagline is genuinely useful, work it into the product description. If it’s marketing fluff, delete the metafield.

”Product story” metafield

Long-form copy describing the brand’s relationship to the product — “Crafted in our family workshop in Tuscany since 1972.” A useful storefront feature; not weighted by AI agents in any observable pattern.

The fix: keep it for the storefront if it’s converting users; don’t expect it to move AI surfacing. Don’t waste structured-data weight on it.

”SEO keywords” metafield

A list of keywords intended to “tell search engines what the product is about.” This is keyword stuffing in metafield form — it doesn’t reach the rendered page, doesn’t enter schema, and does nothing.

The fix: delete. Spend the time on product titles and descriptions.

Per-variant metafields without per-variant exposure

Catalogs that define metafields at the variant level but only render the parent variant’s metafields in the product page. Each non-default variant carries metafield data that never sees a crawler.

The fix: if metafields are defined per-variant, the schema must render per-variant — the parent product’s JSON-LD won’t carry the variant metafield values automatically.

The implementation pattern

Three steps. A metafield that doesn’t complete all three doesn’t reach AI agents:

Step 1 — Define metafields with stable namespaces

Use product.* namespace for product-level fields, variant.* for variant-level. Avoid theme-specific namespaces (theme.*) — the metafields themselves persist when the theme changes, but if the new theme doesn’t reference those namespaces in its templates, the storefront will stop rendering them and they’ll effectively disappear from the public store.

Define in Shopify admin: Settings → Custom data → Products → Add definition.

Set the validation rules at definition time. A list-of-text metafield without max-length validation accumulates inconsistent data over time.

Step 2 — Render through Liquid into JSON-LD

Most themes ship a product.liquid template that generates JSON-LD. Modify it to read from the metafields. The pattern is uniform:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | json }},
  ...
  {%- if product.metafields.product.material -%}
  "material": {{ product.metafields.product.material | json }},
  {%- endif -%}
  {%- if product.metafields.product.country_of_origin -%}
  "countryOfOrigin": {
    "@type": "Country",
    "name": {{ product.metafields.product.country_of_origin | json }}
  },
  {%- endif -%}
  ...
}

The pattern scales — define the metafields once, render conditionally in the JSON-LD block, and add a check for empty values so absent fields don’t ship as null.

Step 3 — Map metafields into the GMC feed

Default Shopify-to-GMC integrations strip most custom metafields. The options:

• Feed-management app — DataFeedWatch, Feedonomics, or similar. Maps metafields to GMC attributes. Adds cost; saves manual work.
• Custom feed file — generate the feed from a Liquid template at a stable URL, point GMC’s scheduled fetch at it. More work upfront; full control. The recommended pattern for catalogs above 500 SKUs.
• Manual supplemental feed — Google Sheets feed updated weekly. Works for small catalogs; doesn’t scale.

The contrarian take

Most metafield content frames metafields as a flexibility tool — “add any custom data your store needs.” This is true and a trap. The catalogs that succeed treat metafields as a constrained, deliberate extension of the product data model: a small set of metafields, each mapped to a schema property, each rendered into JSON-LD, each synced to GMC. The catalogs that struggle are the ones that built out twenty metafields over two years, none of which propagate beyond the admin.

The reframe: every metafield is a commitment to render it three times (storefront, schema, feed). Don’t add a metafield without a plan for all three.

Where it breaks

• Apps that create their own metafields. Many Shopify apps create metafields in their own namespace without exposing them to Liquid. Those metafields exist only for the app’s UI; they’re not data the storefront can use. The fix is one-way: if the app’s data is needed in schema, copy it into a product.*-namespaced metafield through a webhook or scheduled job.
• Bulk metafield migration. Importing metafields via CSV through Matrixify or similar tools can produce malformed values that pass Shopify’s validation but break Liquid rendering. Validate the first ten products manually before bulk-applying.
• Metafield namespace renames. Shopify allows renaming a metafield’s namespace; existing values are preserved, but Liquid templates that reference the old namespace silently render empty strings. The fix: search the theme for every namespace reference before renaming.

What to ship this week

1. Audit existing metafields. Delete any that don’t reach a rendered surface.
2. Define the five metafields above (gtin, material, country_of_origin, certifications, care_instructions) if they’re not already in place.
3. Update product.liquid to render them into JSON-LD.
4. Validate one product end-to-end: admin → product page → Schema.org Validator → GMC feed.

That’s a half-day of work for an immediate gain in Description density — one of the four 20%-weight dimensions in Lumio’s AI Readiness Score. Metafields that flow into the description-rendering layer pick up the attribute density that dimension scores on.