Metaobjects

Why it matters

Metaobjects removed the main reason Shopify stores used to need a second CMS. Before them, anything that was not a product had nowhere sensible to live: store locations went into a hardcoded Liquid snippet, size guides were duplicated across every product description, and author bios sat in a page template nobody could edit.

The practical gain is that shared content stops being duplicated. One size guide, authored once, referenced by four hundred products. When it changes, it changes everywhere — and the merchandising team makes that change themselves.

The strategic gain is that content becomes queryable. A metaobject is real structured data, so it can be filtered, referenced, and read through the Storefront API, which matters the moment the store goes multi-channel or headless.

How it works on Shopify

You define a metaobject type in Settings → Custom data: a name, and a set of fields with types, exactly like defining metafields but on a resource of your own invention. Entries are then created and edited in the admin as ordinary content.

The connection back to commerce is the reference metafield. A product gets a "Size guide" metafield whose type is a reference to your size guide metaobject, and the theme renders whatever that entry contains. References can also point from one metaobject to another, which is how you model an author who belongs to several articles.

Metaobject types can be given their own storefront pages with a URL handle, so a store location or a designer profile becomes a real page rather than a fragment embedded elsewhere.

Access rules mirror metafields: storefront visibility has to be enabled explicitly, or the data will not appear over the API.

Common mistakes

• Modelling by page instead of by thing. A metaobject called "homepage banner block" is a section setting wearing a costume. Model the entity — a location, a designer, a material — not the place it is displayed.
• Referencing by text. Storing an entry's handle as a string reintroduces the dangling-link problem that references exist to prevent.
• Using them for one-off content. A single page of copy is a page. Metaobjects earn their keep through reuse.
• Forgetting storefront access. The same silent failure as metafields: it works in the theme editor and returns nothing over the API.
• Skipping validation. Fields without required flags or type constraints fill up with inconsistent data, and cleaning it later is manual.

When you need help

The point to bring someone in is the modelling, not the setup. Deciding what becomes a metaobject, what stays a metafield, what belongs in a PIM, and how those things reference each other determines how much manual work the content team carries for years. It is difficult to change once entries exist and templates depend on them.

The other case is migration: moving content out of a separate CMS or out of an app's proprietary storage into metaobjects, in bulk, without losing the relationships between records. That is scripted work against the Admin API, not admin work.