GEO for Apparel Brands: Winning the Fit and Sizing Question AI Cannot Answer from a Product Page

Ask an AI engine whether a brand's jeans run small and you will get an answer. It will be assembled from Reddit threads, a review aggregator, and possibly a YouTube transcript. It will almost never come from the brand that made the jeans, even though that brand knows the exact finished measurement of every size it cuts.

This is the defining GEO problem in apparel, and it is not a content-volume problem. Apparel brands publish enormous amounts of content. They publish it in a format retrieval cannot use, and they omit the one dataset that would answer the question outright.

Fit is where apparel is won. It drives the purchase, it drives the return, and it is the question shoppers ask before any other. This guide covers why product pages structurally cannot answer it, what to publish instead, and how to model sizing so an engine understands that 40 SKUs are one garment.

Why Fit Is the Query That Decides the Sale

Apparel queries divide into four groups, and only one of them is served well by a conventional product page.

Fit and sizing questions dominate. Does it run small, what size should I order, is it true to size, will it fit a 34 inch chest, does it stretch, is the rise high enough. These are asked constantly and they are asked in the shopper's own body vocabulary rather than in yours.

Comparison questions come next. How does this compare to a competitor's equivalent, is the fabric heavier, is the cut more relaxed.

Occasion and styling questions follow. What do I wear this with, is it appropriate for a given setting, will it work in a given climate.

Availability and price questions are last, and they are the only group a standard product page answers cleanly.

The structural problem is that a product detail page describes one garment in isolation. A fit answer is comparative by nature. Does it run small relative to what, is the only sensible reading of the question, and a page describing a single item has no reference point. The shopper is asking the brand to locate its garment on a scale, and the page never does.

That is why the answer migrates. Reddit answers it because a hundred people posted what they ordered and whether it worked. A review aggregator answers it because it aggregates exactly that comparison. The brand does not answer it because the brand published a photograph of a table.

Where Fit Answers Currently Come From

Run the queries and the citation pattern is consistent across engines. Four source types carry apparel fit answers.

Community threads carry the most weight. A subreddit thread where 40 people report their usual size and what they ordered is, functionally, a dataset with an n of 40. It is exactly the comparative evidence the question needs, and no brand publishes anything equivalent.

Review aggregators and marketplace review sections come second. Where a review interface includes a structured fit slider, that slider output is machine-readable and gets used.

Editorial and affiliate reviews come third. A writer who tried three sizes and reported the outcome has produced first-hand experience content of the kind Google's helpful content guidance asks for.

Brand sites come last, and usually only for the price and the product name.

The uncomfortable implication is that your fit reputation is currently being written by strangers, from a sample you did not choose, describing garments you may have since re-cut. A brand that re-cut its pattern 18 months ago and moved its size medium by 1.5 inches is still being described by threads written 3 years ago, before the change.

Get the Size Chart Out of the Image

This is the single highest-return change in apparel GEO and it takes an afternoon.

The standard implementation is a size chart rendered as a PNG or JPEG, sometimes inside a modal that only loads on click. Both patterns make the data unreachable. An image is not text, and content behind an interaction is frequently not rendered by crawlers that do not click.

Publish the chart as a real HTML table on the product page.

• Use genuine <table> markup with header cells, not a grid of styled divs. The header row is what tells a machine that the column of numbers is a chest measurement.
• Include units in the header, and give both imperial and metric. A chest column reading 38 is ambiguous; 38 in / 97 cm is not.
• Label rows with your actual size names, including any lettered and numbered equivalence.
• Add international conversions as their own columns where you sell across markets, since a UK 12 and a US 8 being the same garment is a question people genuinely ask.
• Put it in the rendered HTML rather than behind a click. If design requires a modal, render the table in the DOM and hide it visually rather than fetching it on demand.

One structural note that matters more than it sounds. Put the table on the product page, not on a single site-wide sizing page. A retrieval system extracting a passage about a specific garment gets what is on that garment's page. A chart two clicks away does not exist for the query being asked.

Garment Measurements Versus Body Measurements

Most brands publish one of these and the shopper needs both. The distinction is the most commonly confused thing in apparel sizing.

A body measurement chart says what body a size is designed to fit. A 38 inch chest fits our size medium.

A garment measurement chart says what the finished item actually measures. Our size medium has a 42 inch chest circumference when laid flat and doubled.

The gap between them is the ease, which is the design intent. Four inches of ease is a fitted cut. Ten inches is oversized. A shopper who knows a garment they already own measures 44 inches and likes it can place your medium instantly if you publish the finished measurement, and cannot if you publish only the body chart.

Publish both, labelled clearly, with the ease stated where it is meaningful. Then add the measurements that decide fit in your category specifically.

• Tops: 5 measurements, being chest, length from high point of shoulder, sleeve length, shoulder width and hem circumference.
• Bottoms: 6 measurements, being waist, hip, rise, inseam, leg opening and thigh.
• Outerwear: all of the above plus across-back and cuff.
• Intimates: band, cup depth, wire width, gore height, wing height.
• Footwear: insole length, width at the ball, heel height, shaft circumference for boots.

For a brand like Eby selling seamless intimates, band and cup behaviour under stretch is the whole question, and it is a measurement no size chart conveys. Publishing the unstretched and stretched band measurements answers a question the category never answers.

Every one of those numbers is data you already hold in your tech pack. The cost of publishing is transcription, and the return is owning an answer that currently goes to a forum.

Writing Fit Intent as Plain Text

Numbers alone do not answer the question people actually type. They type does it run small.

That phrasing is not a measurement request, it is a request for a judgement relative to a norm, and only the brand can make it authoritatively. Write it in sentences.

• State the fit relative to standard sizing, in the shopper's words: runs small, runs large, true to size, or true to size with a note.
• Give the between-sizes recommendation explicitly. Somebody whose 38 inch chest sits between your medium and large needs to be told which way to go and why.
• Describe the intended silhouette. Fitted through the chest with a straight body, or relaxed through the hip with a tapered leg.
• Say what the fabric does. A 4 percent elastane content behaves differently from 12 percent, and a garment that relaxes half an inch after 3 wears is a different purchase from one that does not. State the shrinkage on first wash as a figure rather than a warning.
• Cover body-type variation where it genuinely differs, such as a longer torso, a broader shoulder, a fuller bust.
• State whether it has been re-cut. If a pattern changed in 2025, say so, because the internet is still describing the old one.

That last item is worth dwelling on. Community fit reputation is sticky and stale. A brand that quietly improved its sizing has no mechanism to correct the record except publishing the correction itself, which is exactly the situation our post on correcting AI hallucinations about your brand addresses.

Write these as prose in the product description, not as a bullet buried in an accordion. Retrieval works on passages, and a passage that opens with the claim is usable in a way a fragment inside a collapsed panel is not. Our guide to content chunking covers why.

Model Measurements and the Size Worn

This is the most requested missing datapoint in apparel and it costs nothing to add.

A photograph tells a shopper how a garment looks on one body. Without knowing that body's measurements and which size it is wearing, the photograph is decorative rather than informative.

Publish, on every product page, the model's height, the relevant body measurements for the category, and the size they are wearing. For a top that means height, chest and usual size. For jeans it means height, waist, hip and inseam.

Two refinements separate a good implementation from a token one.

Show more than one body. A brand photographing a single size on a single model has answered the question for perhaps 15 percent of its customers. Shooting 3 models across the size range makes the data genuinely useful and makes the brand look like it has thought about the customer it claims to serve.

State whether the sample is the production cut. Photography is frequently shot on samples that differ from what ships, and where that is true the honest note is worth more than the omission.

This data is text, it lives on the product page, and it is directly quotable. An engine answering will this fit me has an actual reference body to reason from.

Returns Data as a Trust Signal

Apparel has the highest return rate of any ecommerce category, and fit is the dominant reason. Brands treat this as a number to conceal. In generative search, publishing it works better than hiding it.

The mechanism is the same one that operates in every other vertical where a brand stays silent. The question gets answered regardless, from complaint threads and review sites, and the resulting answer carries no context.

Publish the returns policy as structured, retrievable content, and use Google's merchant listing properties to make it machine-readable.

• The return window in days, as an integer in merchantReturnDays rather than a sentence. A value of 30 is a fact; within a reasonable period is not.
• Who pays return shipping, through returnFees, because free returns is the single most decisive fact in apparel purchase hesitation.
• Whether exchanges for a different size are handled differently from refunds, which is the specific thing a fit-anxious shopper wants to know.
• The condition requirements, stated plainly.
• Any category exclusions, particularly for intimates and swimwear where hygiene rules apply and shoppers expect to be told.

The strategic argument is straightforward. A brand offering free size exchanges has removed the risk that stops the purchase, and that fact is only useful if a machine can find it. Buried in a footer link, it does not exist.

Mining Reviews for the Fit Vocabulary

Your reviews already contain the fit answers. They are unstructured, scattered across hundreds of entries, and invisible as a body of evidence.

The work is to extract the pattern and republish it as content the brand owns.

• Read the fit comments across a garment and find the recurring reports. If 30 of 210 reviewers independently say to size up for the shoulders, that is a finding with a denominator.
• Publish it as a fit note in the brand's voice, with the basis stated. Customers consistently report sizing up one for a broader shoulder is a citable sentence.
• Quantify where you honestly can. If your review platform captures a fit slider, the distribution is real data and publishing it is stronger than characterising it.
• Use the vocabulary customers use rather than the vocabulary the design team uses. Nobody searches for a dropped shoulder with a relaxed body; they search for boxy.
• Update it when the pattern changes, and date it.

This is the closest thing apparel has to original research, and Google's helpful content guidance explicitly asks whether content provides original information rather than rewriting other sources. Our post on original data as citation bait covers why that class of content gets quoted disproportionately.

One caution. Do not fabricate the pattern or smooth it into marketing. Our guide to synthetic reviews and AI trust covers how engines detect review patterns that are too clean, and a fit note that contradicts the visible reviews underneath it is worse than no note.

Modelling Variants Without Creating 40 Entities

Apparel has the worst variant problem in ecommerce. One garment in 8 sizes and 5 colours is 40 SKUs, and the default implementation publishes 40 competing product entities. Add a second colour drop and it is 56.

The consequence is entity fragmentation. An engine resolving your product finds 40 near-identical objects with different identifiers, no clear parent, and reviews split across them. It cannot confidently say what the product is, and reviews attached to a single colourway do not accrue to the garment.

Google's product variant documentation covers the correct structure.

• Declare the garment as a ProductGroup with a stable productGroupID.
• Attach each SKU as a variant through hasVariant, each a Product with its own sku and offers.
• Use variesBy to state which properties differ, normally size and color.
• Express sizing with SizeSpecification, using sizeGroup for the system such as regular, petite or tall.
• Attach aggregateRating at the group level so reviews accrue to the garment rather than to one colour.
• Carry finished measurements as PropertyValue entries under additionalProperty, which makes the numbers machine-readable rather than only visible.

Two failure modes to check for. A canonical pointing at one variant while all 40 emit full product markup produces a contradiction between what you indexed and what you described. And missing productGroupID leaves the variants unlinked, which is the fragmentation this structure exists to prevent.

Our guide to product schema covers the base implementation, and our post on DTC brands and AI recommendation engines covers the wider recommendation mechanics this sits inside.

Common Mistakes

• Size chart as an image. The most common and most costly error in the category. The data exists and cannot be read.
• Sizing on a single site-wide page. A chart two clicks from the garment does not answer a query about that garment.
• Body measurements only. Shoppers compare against a garment they already own, which requires finished measurements.
• No model measurements or size worn. Makes every photograph decorative rather than informative.
• Fit notes hidden in a collapsed accordion. Retrieval takes the passage, and a collapsed panel frequently is not in it.
• Returns policy in a footer link. Free size exchanges is the fact that closes the sale and it needs to be findable.
• 40 variants as 40 products. Fragments the entity and splits the reviews.
• Stale fit reputation left uncorrected. If the pattern changed, publishing the correction is the only mechanism you have.

Implementation Sequence

Work in this order. The first two items produce most of the gain and neither requires development beyond a template change.

1. Convert every size chart from an image to an HTML table on the product page, with units in the headers and metric alongside imperial.
2. Add finished garment measurements per size, from the tech pack, labelled as garment rather than body measurements.
3. Write fit intent as prose on every product page: relative sizing, between-sizes guidance, fabric behaviour, and any re-cut history.
4. Add model height, measurements and size worn to every product page, ideally across more than one body.
5. Publish returns terms as text and implement MerchantReturnPolicy with real values for window and fees.
6. Mine reviews per garment for the recurring fit pattern and publish it as a dated fit note in the brand's voice.
7. Restructure variant markup as ProductGroup with hasVariant, variesBy, and group-level aggregateRating.
8. Re-run your fit queries against the engines quarterly and check whether the cited source has changed.

Brands running this alongside a wider programme should read our guide to what generative engine optimisation is for the framework, and our post on merchant listing schema for the shipping and returns properties in full.

Frequently Asked Questions

Why do AI engines cite Reddit instead of my brand for fit questions?

Because a thread where 40 people report their usual size and what they ordered is comparative evidence, and a product page describing one garment in isolation is not. Fit questions ask where a garment sits relative to a norm, and most brands never publish the finished measurements that would let an engine answer.

Is a size chart image really invisible?

For retrieval purposes, yes. Text inside an image is not extractable in the way HTML is, and charts loaded only on click are frequently not rendered at all. Converting the chart to a real table with header cells is the single highest-return change available in apparel GEO.

Should I publish garment measurements or body measurements?

Both, clearly labelled. Body measurements state what body a size is designed for; garment measurements state what the finished item measures. Shoppers compare against something they already own, which needs the finished number, and the difference between the two is the ease that defines the silhouette.

Does publishing return information increase returns?

The evidence in generative search runs the other way, because the question gets answered regardless. If your policy is not published, an engine answers from complaint threads with no context. Free size exchanges is frequently the fact that closes an apparel sale, and it only works if a machine can find it.

How should I handle 8 sizes across 5 colours in schema?

As one ProductGroup with a stable productGroupID, each SKU attached through hasVariant, and variesBy naming size and colour. Put aggregateRating at the group level so reviews accrue to the garment rather than splitting across colourways.