Metaobjects for merchandising: lookbooks, guides and collections

Metaobjects get pitched as "structured content", which tells a merchandiser nothing. The three jobs they do well on a commerce site are specific.

Repeated editorial with a fixed shape. A lookbook, a buying guide, a fabric or ingredient entry, a designer profile, a store location. You will build dozens of these over a few years, each one the same fields in the same order. That repetition is what makes a schema worth writing — the fiftieth one costs nothing because the first one paid for the definition.

Content that has to appear in more than one place. A sizing panel that belongs on forty product pages, a delivery promise that appears on the product page, the cart and a policy page. Put it in a page and you have a copy problem; put it in a metaobject and the forty places reference one entry.

Merchandising surfaces a marketer assembles. The seasonal edit, the gift guide, the collection landing page that is more than a grid. The metaobject holds the content and the theme section holds the arrangement, which is the split that lets a merchandiser build the page without a developer and without inventing a layout.

What is not on the list: one-off campaign copy, anything with a deadline this week, and anything only one person will ever edit. A page is fine for those, and a page is quicker.

The whole pattern is a definition, a setting and — conditionally — a template. Getting the three in the right order avoids most of the rework.

The definition is your schema. Typed fields, and for merchandising content the useful ones are rich_text_field for body copy, file_reference with image validation for artwork, product_reference and collection_reference for the things being merchandised, metaobject_reference for a link to another entry and mixed_reference where an entry could be one of several types, plus the list.* counterparts. Worth knowing before you design: boolean, id, json, language, money, multi_line_text_field and rich_text_field have no list counterpart, so a repeating block of rich text is a nested metaobject type rather than a list field.

The section setting is how it reaches the page, and it is the part teams under-use. A metaobject setting "allows merchants to select metaobject entries of a designated type through a picker interface" and requires a metaobject_type attribute. Its list counterpart, metaobject_list, takes the same required attribute plus an optional limit — a maximum and default of 50 — and returns an array of metaobject objects with pagination support, or blank. So a single section schema of maybe a dozen lines gives a merchandiser a typed picker in the theme editor that cannot select the wrong kind of thing.

The template, only when the content is a destination. templates/metaobject/{type}.json, with the onlineStore capability enabled on the definition. Two behaviours to plan for: "the first template created for a metaobject must be the default template and will be automatically used by all active metaobject entries for that definition", and "the template is empty when it's initially created in the Online Store editor" — merchandisers have to add sections to it before it shows anything. Enable renderable too, which is what gives the definition the SEO fields a real page needs.

And the shortcut worth remembering: where the content is singular and permanent, skip the picker. Liquid reaches an entry directly as metaobjects.type.handle, so a deliberate, stable handle turns a lookup into a constant and removes a setting nobody was ever going to change.

This is the question to settle before any of the modelling, because it is the one that is expensive to reverse and the one that has SEO consequences.

A destination has a URL. A buying guide someone could plausibly search for, a store location page, a designer profile, a lookbook with a life beyond one campaign. Enable onlineStore and renderable, build the template, and treat it like any other page: it needs a title, a meta description, internal links pointing at it and a reason to exist. Then link it from the collections and products it relates to, because an orphan page with no inbound links is a page that gets crawled once and forgotten.

A fragment does not. A sizing panel, a care block, a returns promise, a hero for one collection. It exists to be embedded. Leave onlineStore off, reference it from a section setting or a product metafield, and it never has an address of its own.

Getting this wrong in the permissive direction is the common failure, and it is worse than it looks. Switch onlineStore on for a type with 300 entries and you have published 300 pages, most of them forty words of shared boilerplate, none of them linked from anywhere. That is a thin-content pattern generated by a checkbox, and it dilutes the crawl budget you would rather spend on collections.

One behavioural note that bites templates specifically: with the publishable capability enabled, only entries with active status are accessible in Liquid and a draft returns nil. That is exactly right for content someone is drafting, and it is a silently empty section if the template does not handle the nil case. Write the empty state, then set an entry back to draft and look at the page.

Worth working through, because the naive version — one type with twenty fields called image_1 through image_10 — is the version most stores end up with.

Two types, not one. A lookbook holds the title, the intro rich text, a hero file_reference, an optional collection_reference for the collection it merchandises, and a list.metaobject_reference to the second type. A lookbook_look holds one image, a short caption and a list.product_reference for the products in the shot.

That split earns its keep in three ways. The order of the looks is explicit, held in the parent's list, rather than being inferred from a timestamp. A look can be reused in a second lookbook without being copied. And the shoppable hotspots on each image have a real product reference behind them, so a discontinued product disappears from the look instead of linking to a 404.

The theme side is one section with a metaobject setting of type lookbook. A merchandiser adds the section to any page, picks the lookbook, and the section walks the list of looks. No developer involvement per lookbook, which is the entire point — if building the second one needs a ticket, the model has not paid for itself. Keep the lookbook and the collection as different objects doing different jobs, though: the collection is the grid and the filters, the lookbook is the editorial. Link them rather than merging them.

We would rather you used metaobjects than added a CMS — they are in the admin your team already uses, they cost nothing extra, and they are reachable from Liquid without an integration. But there are three points at which the honest answer is to stop modelling.

When the content is genuinely a one-off. A single campaign landing page, live for six weeks, written once. Building a definition, a section and a picker for that is an afternoon spent so a merchandiser can do in ten minutes what they could have done in eight in a page editor.

When the reads need search or faceting. The Storefront API cannot filter metaobjects by field, and sorting is limited to id and updated_at. A guide library with topic filters needs an index somewhere else — a search service, a headless front end, or pre-computation at build time. Find this out at the modelling stage, not when the front end is half built.

When nobody owns the content. The failure mode of a good content model is forty definitions, six of which have entries, and a merchandising team who were never shown the pickers. A merchandiser building next season's edit without opening a ticket is the deliverable — not the model.

• Shopify section library
• Metaobjects at scale: when content modelling becomes a system
• Collection pages are your best SEO asset