If you sell furniture and someone typed shopify metafields product specs into Google, here's the answer without preamble: create one namespace (we use specs), define every field before you enter any data, use Shopify's dimension and weight types for measurements, put materials and care regimes in metaobjects so they're written once and reused, and mirror anything you want to filter on into a list-of-single-line-text field with a controlled vocabulary. Then render the whole thing from one Liquid snippet, so a new spec field appears on 400 product pages the moment it's populated.
The reason furniture is worth doing properly is that specs are the product. A buyer looking at a βΉ58,000 three-seater is not comparing photographs. They're working out whether it clears the lift, whether the fabric survives a dog, and how long they'll wait. Every question you fail to answer on the page comes back as a WhatsApp message or a return.
Define the schema before anyone touches a product
The most common mess we inherit is a store where someone typed dimensions into the product description for two years, and a second someone added metafields called dimension, Dimensions and size (cm). Now nothing is queryable and nothing is filterable, and the only fix is a full data pass.
So: definitions first, in Settings β Custom data β Products. One namespace. Keys in lowercase with underscores. A description on each definition that tells the catalogue team exactly what goes in it, including the unit and the format, because in six months that person will be someone else.
A metafield schema for furniture product specs you can copy
This is close to what we set up on spec-heavy furniture catalogues. Trim it; don't extend it casually.
- specs.overall_width, specs.overall_depth, specs.overall_height β type dimension, stored in cm. Three separate fields, never one text field with an Γ in it.
- specs.seat_height, specs.seat_depth, specs.arm_height β dimension. Sofa and chair buyers ask about seat height more than overall height.
- specs.boxed_dimensions β three dimension fields or a list, per carton. Your ops team needs this more than your customer does.
- specs.cartons β integer. A dining set that ships in three boxes and arrives in two is a support ticket.
- specs.product_weight β weight type, kg. Keep it separate from the variant shipping weight, which includes packaging.
- specs.weight_capacity β integer, kg. Chairs, beds, wall shelves.
- specs.primary_material β metaobject reference. specs.secondary_materials β list of metaobject references.
- specs.finish β metaobject reference (Walnut, Natural, Matte Black).
- specs.upholstery β metaobject reference, with rub count and cleaning code as fields on the metaobject.
- specs.frame_construction β single line text. Kiln-dried hardwood frame, corner-blocked, that sort of thing.
- specs.assembly_required β boolean. specs.assembly_minutes β integer.
- specs.warranty_months β integer. Render as "3 years" in the theme; store the number so you can sort and compare.
- specs.lead_time_days β integer, for made-to-order. This one earns its keep on the PDP and in the order confirmation email.
- specs.care β metaobject reference to a care regime, not free text. More on that below.
- specs.filter_room, specs.filter_style, specs.filter_seats, specs.filter_width_band β list of single line text, controlled values. These exist purely for faceting.
Yes, the last group duplicates data. That's deliberate, and I'll explain why in the filters section.
Materials belong in metaobjects
If material is a text field, you will end up with Sheesham, sheesham, Sheesham Wood, Indian Rosewood (Sheesham) and Solid Sheesham across the same catalogue. Filters split five ways. Nobody notices for a quarter.
Define a material metaobject instead: name, one-paragraph description, a swatch image, a boolean for whether it's a natural material that will move with humidity, and a reference to a care regime. Reference it from the product. Now the material description on 90 product pages is edited in one place, and when your copywriter finally writes a good paragraph about mango wood, every page gets it.
Same for care. Define a care_regime metaobject with a title, a list of dos, a list of don'ts, and the cleaning products you actually endorse. You'll have maybe eight regimes across a full furniture catalogue: solid wood oiled, solid wood lacquered, veneer, cane, powder-coated metal, fabric upholstery, leather, marble. Assign, don't retype. The alternative is 400 rich-text fields, and the day your care advice changes, it changes on none of them.
Dimensions: store centimetres, render inches, add the diagonal
Store in cm, always, in the dimension type so the unit travels with the value. Render both units in the theme, because Indian buyers who own a measuring tape think in feet and inches. A 210 cm sofa is 210 Γ· 2.54 = 82.68, so print 82.7 in alongside it. Do the conversion in Liquid, not in a second metafield that will drift.
The number nobody publishes and everybody needs is the diagonal of the cross-section, because that's what determines whether the thing gets through a door. Take a sofa 95 cm deep and 85 cm high: β(95Β² + 85Β²) = β(9025 + 7225) = β16250 β 127.5 cm. Tilted on its side, it needs about 128 cm of clearance at the tightest turn. Standard Indian internal door frames are around 90 cm. That sofa goes through the door face-on but will not turn a tight landing, and telling the buyer that on the product page prevents a delivery refusal on a 96 kg item.
Compute it in Liquid from the two dimension metafields. Don't ask the catalogue team to calculate square roots.
The spec your logistics team wants and your PDP doesn't show
Volumetric weight. Most Indian surface and air freight is billed on the greater of actual and volumetric weight, commonly L Γ W Γ H in cm divided by 5000 for air. A boxed sofa at 220 Γ 100 Γ 90 cm is 1,980,000 cmΒ³. Divide by 5000 and you get 396 kg. The actual weight might be 62 kg. You will be billed on 396.
Once boxed dimensions live in metafields, that calculation stops being a spreadsheet someone maintains by hand. You can compute chargeable weight per SKU, flag the SKUs where freight exceeds your shipping allowance, and decide whether to zone-price them. We've seen a single wardrobe SKU quietly eat the margin on an entire collection because nobody had the cartons measured.
Wiring product specs to filters (and the cap you'll hit)
Shopify's Search & Discovery app can build filters from product metafields, provided the definition has storefront access and uses a supported type. In practice, lists of single line text and booleans behave predictably. Numeric and dimension types have been patchier for us across themes, which is why the schema above carries those filter_ fields.
So specs.overall_width holds 187 cm for display, and specs.filter_width_band holds "180β200 cm" for faceting. Populate the band with a bulk edit or a Flow rule keyed off the dimension value. It feels redundant. It gives you a facet that doesn't produce a filter with 140 single-product options.
Two warnings. Search & Discovery caps how many filters a collection can show, and on a furniture catalogue with room, style, material, finish, seats, width band, price, assembly and lead time, you reach the cap sooner than you expect. Prioritise: material, room, width band, price. Everything else is a spec table, not a facet. Second, filter values are only as clean as the vocabulary, which is the argument for metaobjects all over again.
If native filtering runs out of room β faceted search across a large catalogue, AI search that understands "3 seater sofa under 190 cm", filter counts that stay accurate β that's the problem our own FilterPro app was built for. It reads the same metafields; you don't restructure anything.
Schema markup: additionalProperty, and what it actually does
Output your specs as additionalProperty entries on the Product node in JSON-LD, each one a PropertyValue with a name and a value. Add material, width, depth, height and weight as QuantitativeValue objects with unitCode (CMT for centimetres, KGM for kilograms).
Now the blunt part: Google does not currently render additionalProperty in product rich results, and adding it will not move your rankings this quarter. It helps machines understand the entity, it's the right structure for shopping feeds and AI answer surfaces that read structured data, and it costs you one snippet once you have the metafields. Do it for that reason, not because a checklist tool told you your schema was incomplete. If you're choosing between clean structured data and a spec table that a human can actually read on a 5-inch screen, build the table.
Do keep the marked-up values identical to the visible ones. Mismatched schema is worse than no schema.
Where this breaks
Variant-level specs. A dining table in 4-seater and 6-seater has different widths, weights and carton counts. Those belong on variant metafields, and variant metafields are more awkward: less theme support, weaker filtering, and every bulk-edit tool handles them differently. Our default is to split genuinely different sizes into separate products with a size-swatch linking them, and reserve variants for colour and finish, where the specs don't change. It's less elegant and it works.
Multi-location stock. Lead time is not a single number if you fulfil from two warehouses. A metafield holding 21 days is a promise you may not keep. Either scope lead time per location in your ops system and surface a range, or state the worst case.
Made-to-order fabric. If upholstery is chosen at checkout, the material metafield describes the default, not what ships. Say so on the page.
We get the variant question wrong on the first pass maybe a third of the time, usually because the merchandising plan changes after the schema is built. Cheap to fix early, expensive after the data entry.
Getting the data in without typing it
Nobody should populate 400 products by hand in the admin. Export the catalogue, build the columns, import back. Shopify's own CSV handles metafield columns when the definitions exist first, and Matrixify handles metaobjects and variant metafields when it doesn't. If your specs currently live in a Magento or WooCommerce attribute set, that's a mapping exercise, and it's the part of a Shopify migration that takes the longest and gets budgeted the least β attributes rarely map one-to-one, units are inconsistent, and someone has to decide what "Wood Type: Assorted" means.
One pass we always insist on: a QA sweep on the sanity of every number. Width greater than 400 cm, weight under 2 kg, seat height above 60 cm. Sort each numeric field and look at the top and bottom ten rows. That's twenty minutes and it catches the decimal-point errors that otherwise reach a customer.
Start with one collection
Pick your highest-traffic category β sofas, most likely. Build the definitions, the material and care metaobjects, and one spec-table snippet. Populate that collection only, ship it, and read the support tickets for two weeks. The questions that still come in tell you which field you missed, and they'll be more useful than any schema someone plans in a document.
If you'd rather have the definitions, metaobjects, filters and JSON-LD built in one go, our team does this work regularly for spec-heavy catalogues β talk to a Shopify developer, or send us the store for a free audit and we'll tell you what your current data will and won't support.