Two scenarios, same starting question:
Scenario A. A home-furnishing supplier wants to add author bio, reading-time estimate, and publication region to blog posts for SEO and UX. Every blog post has different values.
Scenario B. An artisan jewelry shop wants per-product shipping notes, delivery times, and handling instructions that differ per hand-made item.
Both sound similar. Both involve "extra data on a resource". The right answer is different: the first is a metafield, the second is also a metafield - but the framework that tells you which is which is the same, and it matters because the wrong choice creates a merchant headache down the line.
The framework in one rule
- Use a metafield when the data is intrinsically per-resource (one value per blog post, one value per product) and isn't reused elsewhere.
- Use a metaobject when the data is a reusable structured entity that multiple resources point to (one size chart referenced by 500 products, one author bio referenced by 50 blog posts).
Scenario A is metafield because each post's author bio, reading time, and region are unique to that post. Scenario B is metafield because each jewelry piece's shipping notes and handling instructions are unique to that piece.
Both look similar because both are per-resource. Neither is reused across many resources. That makes metafield the right call in both.
When metaobject becomes the right call
Same home-furnishing supplier pivots the request:
"We have 15 in-house authors who write multiple posts each. Author bio should be a shared record - edit once, update on every post by that author."
Now the data is reused. One author bio → many posts. This is a metaobject use case. Each author is a metaobject entry; each post references its author via a metaobject reference metafield.
Same jewelry shop pivots:
"We have 5 shipping tiers based on fragility. Tier 1 items all share the same shipping note. Tier 2 all share another. Five tiers total, applied across 200 products."
Now shipping config is reused. Five metaobject entries (one per tier); each product references its tier.
The data content didn't change - what changed is whether the same values appear across multiple resources.
The reuse test
Practical test when a merchant asks:
- Will identical values appear on many resources? If yes → metaobject.
- Will merchants want to edit a shared piece once and propagate? If yes → metaobject.
- Is the data truly unique per resource with no sharing? If yes → metafield.
- Is the data structured (sub-fields with their own types)? Metaobjects handle structured data better even for single use.
Edge cases resolve on test 4: even if only one resource uses the data, if the data has internal structure (rich-text description, related image, typed sub-fields), a metaobject can make sense for the admin UX alone.
Where teams get this wrong
Metafields used where metaobjects fit. A merchant creates per-product "brand story" metafield on 200 products, each duplicating the same brand story content. Three months later someone needs to update the story - 200 separate edits.
Metaobjects used where metafields fit. A merchant creates a metaobject for blog-post author bio and creates 50 entries (one per post author), but each entry is only ever referenced by one post. The metaobject layer adds no value; a metafield on the post would have been simpler.
Both errors produce functional systems. Both leave ongoing pain - editing overhead in the first case, unnecessary indirection in the second.
Rendering differences
In Liquid:
Metafield (per-resource):
<p>Reading time: {{ blog_post.metafields.custom.reading_time }}</p>
<p>By: {{ blog_post.metafields.custom.author_bio }}</p>
Metaobject reference (shared):
{% assign author = blog_post.metafields.custom.author_ref.value %}
<p>By: {{ author.name }}</p>
<p>{{ author.bio }}</p>
<img src="{{ author.photo | image_url: width: 100 }}" />
The metaobject pattern lets you reference multiple fields on the shared entity without duplicating data.
Admin UX
Metafields show up on the resource they belong to - product, blog post, customer. Merchants edit them inline while editing the resource.
Metaobjects have their own top-level admin section (Content > Metaobjects). Merchants edit shared entities once, and every resource that references them updates.
The UX difference matters for larger teams: content managers editing shared entities shouldn't have to open every product to push a change.
Combining both
The real pattern most stores settle on is mixed:
- Metafields for truly per-resource data
- Metaobjects for reused structured data
- Resource metafields that reference metaobjects when the resource needs to point at a shared entity
For a product: per-product metafields for unique attributes (SKU-specific info) + metaobject references for shared entities (brand, size chart, care guide).
What ships with good data model design
A well-designed Shopify data model has:
- Metafield definitions scoped per resource type with clear ownership
- Metaobject definitions for genuinely reused entities
- Reference metafields linking resources to their shared metaobjects
- Admin UX that matches how content managers actually work
- Theme code that renders both metafield and metaobject-reference data consistently
Get the framework right upfront. Migrations from "wrong-shape metafields" to the right structure are always more work than getting it right first.
