Why Furniture Dimensions Need a Text Version

Open a furniture product page and scroll to the dimensions. Often you'll find a line drawing of the piece with arrows and numbers: overall width, depth, height, seat height, arm height. It looks professional, it's how the supplier sent it, and it's exactly what a shopper wants to see.

It's also, to a machine, a picture. The numbers aren't numbers; they're pixels. An AI assistant asked "will this sofa fit in a 78-inch alcove" may not be able to tell, and a shopper who asks it that question gets a hedge or a different sofa.

Why the habit exists

Three honest reasons.

The supplier sent a diagram. Manufacturers produce dimension drawings as part of their spec sheets, usually as a PDF or image, and the retailer's page template has a slot for it. Uploading the image is one step; transcribing the numbers into fields is twenty, per product, with a chance of error.

It looks better. A clean line drawing with five measurements reads at a glance in a way a table doesn't, and furniture pages are designed to look good.

It's hard to get wrong on the page. A diagram is a single asset. Text dimensions live in fields that have to be right for every variant, and a 3-seater page showing the loveseat's width is a worse error than a diagram that's a bit small on a phone.

All three are real. None of them holds up well once there's a reader that may not see.

Who struggles with a diagram

AI assistants, which is the point of this series. An assistant working from your page or feed needs the width as a value with a unit. Some systems can read text out of images some of the time, and reliability drops with a low-resolution upload and small numbers. If the only place your width exists is the diagram, don't count on it being read.

Search engines, which can index images and documents but have long asked for product data as text and structured fields.

Screen readers, which means the diagram is an accessibility problem as well as a discoverability one. A shopper who can't see the image gets whatever alt text you wrote, which is usually "dimensions".

Shoppers on phones, a large share of traffic for many retailers, who are pinching and zooming to read a 24 in a drawing designed for a desktop.

Your own systems. If dimensions live only in an image, your feed to a marketplace, your comparison tool and your "will it fit" calculator have nothing to work from either. The image is a dead end for data.

What it costs

The effect is hard to isolate in analytics, which is one reason the habit persists. What you can check directly is whether marketplace dimension fields are blank, customer service still receives basic dimension questions, or an assistant cannot find a measurement that appears only in the diagram.

The simplest way to make it visible is the test in ask an AI assistant for a sofa. Ask about your own product's dimensions and see whether the assistant can answer. If it says the listing doesn't specify, and your diagram is right there, you've found a gap worth closing, whatever else went into the answer.

Keep the diagram, add the data

This is not an argument against diagrams. Shoppers like them. It's an argument that the diagram can't be the only copy.

On the record. Every dimension that appears in the diagram should be an attribute on the product record, per variant, with a unit. Overall width, depth, height; seat height, depth and width; arm height; leg height; weight; packaged dimensions if you ship direct. This is the source; everything else is a view of it.

On the page. A specifications table, as HTML text, with the same values. It can sit below the diagram, in a tab that's in the page HTML rather than loaded on click, or in a collapsible section. What matters is that it's text the page delivers, not an image and not a late-loading widget.

In structured data and feeds. Where your platform and destination support the relevant dimension fields, map the verified values to them. Keep the visible text aligned with the machine-readable version.

In the diagram's alt text. A small win: "Dimensions: 84 in W x 38 in D x 34 in H, seat height 18 in" as alt text makes the image itself carry the facts for readers that use it.

Why this is a catalog job

For one product, transcribing a diagram into a table is manageable. Across a deep range with several sizes, it becomes a project, and page-by-page work is easy to do inconsistently: some products complete, some half complete, some with the wrong variant's measurements.

The fix that holds is upstream. Dimensions come in from the supplier as fields (or get extracted from the spec sheet once, into fields), live on the product record per variant, and flow to the page, the feed and the structured data from there once each is mapped to the fields. The page template reads the fields. The diagram becomes decoration on top of data, which is what it should have been.

That's the shape of the fix for every fact in this series, not just dimensions. See being found by AI for the whole argument, and where furniture product data hides for the other places facts go to be hard to find.

This week

Pick your ten best-selling sofas. For each, check whether overall width exists as text on the page and as a field in your catalog. Count the ones where the answer is "only in the diagram". That number is your starting point.