Shopify metafields or metaobjects: plan maintainable product content

Start with the content you already have

Inventory a representative simple product, a variant with different facts, an exception product and each market version before bulk entry. Record the current text exactly, its source document and approval state. Similar wording does not establish that two products can safely share one record.

Check native fields and category attributes, then matching standard definitions. Shopify lists a Product subtitle and a Care guide definition. Assess their purpose and constraints before making a duplicate custom field. A single approved care sentence might fit a standard field; a care card with a heading, body, evidence identifier and market scope is a different modeling requirement. Review the standard definitions.

Keep prices, titles and other facts already maintained in their authoritative place there. For a fact that changes by variant, record the variant as its intended owner rather than silently copying a product-level value. Put units, allowed values, blank behavior and the source of truth beside each candidate field.

Choose a resource property or a record with an identity

A metafield belongs to an existing resource. A metaobject is a standalone record with related fields. These can compose: a product metafield can point to a care-card entry. A definition is the shape of the care card; an entry is one card; a reference is the product-to-card assignment. Reuse is helpful, but a structured record does not need multiple consumers to justify its own identity.

The custom examples are recommendations to evaluate, not declarations that these definitions exist in your store.

Separate editorial permission from technical ownership

Name the person who may edit a record and the person who approves a change affecting several products. Also record technical ownership. Merchant-owned fields and app-owned fields have different controls; an app creating content does not, by itself, answer who can maintain or export it.

For each dependency, ask who owns the definition, who can edit entries, which apps write values, how approved records are exported and what the exact provider documents about removal. Keep an exit question open until that evidence exists. Do not assume every app-owned entry is merchant-editable or that all data will survive uninstall.

Record market scope explicitly. If US and UK instructions differ, use separately approved content and a documented selection rule. A generic market label alone is not a localization implementation. Ask who maintains translations, unit changes and approvals when the source revision changes.

Migrate assignments and preserve the old evidence

Build a source-to-target map before changing data. Keep a read-only snapshot of original values, source IDs, resource IDs and old display behavior. A rollback needs the old assignments and the old display connection as well as the old text.

Trial the map on the representative records first. Reconcile source rows, target records and product assignments; record intentional many-to-one merges separately from missing rows. Capture any correction made after the snapshot so rollback does not overwrite a later approved change. Only expand the migration after a content approver and the display reviewer accept the sample.

Prove storage and storefront display as separate outcomes

A correctly stored value can remain invisible. Shopify requires compatible types and storefront access for supported editor connections; theme code is another route. Check the exact block, setting, template and reading context rather than treating access as one universal switch. Check connection requirements.

Ask the implementer to show both a saved assignment and its rendered output at actual desktop and mobile widths. Test a missing reference, an unpublished entry where publication status is enabled, an unavailable source and an intentionally blank field. Agree whether to omit the whole card or show approved fallback text. Never substitute another product's instructions to fill a gap.

For larger catalogs, check capacity separately from rendering. The current limits page lists 128 merchant definitions for Basic, Shopify and Advanced, and 256 for Plus and Enterprise, with 40 fields and 1,000,000 entries per definition. Standard definitions/entries are excluded from those storage counts. A list can reference 1,024 metaobjects, while relevant Liquid loops without pagination return at most 50. Recheck the plan and render design before relying on these numbers; the source's Shopify label is not an assumed mapping to another plan name.

Keep the operating worksheet useful after migration

Use one row per content item with these fields: current location, native/category/standard candidate, resource owner, type and units, single value or record, reuse scope, definition/entry/reference IDs, source evidence, technical ownership, editor, approver, storefront consumer, fallback, migration source, expected affected products and saved acceptance evidence.

I would keep the assignment table beside the editorial workflow. Before editing a shared record, the approver should be able to list the affected products and market versions. After editing, the reviewer should compare that list with observed output. Structured storage supports a maintainable workflow; it does not establish product truth, search markup eligibility or a ranking outcome.