Pattern describes the visual design printed or woven into a product — striped, floral, polka dot, plaid — and is sent through the g:pattern tag in an XML feed or a pattern column in a CSV feed to Google Shopping and Meta Catalog. Like material, it's an optional attribute in most categories rather than a required one, but Google specifically lists it among the fields a retailer can use to define product variants, which is the main reason it shows up in feeds at all: a shirt sold in "Solid," "Striped," and "Plaid" versions needs some field to tell those rows apart. The value describes the design itself, not the color it's rendered in, so a "Striped" value should still carry its own color field alongside it.

Why it matters

A missing or vague pattern value rarely triggers a disapproval, but it quietly weakens two things: on-site style filters that let shoppers browse by pattern, and Google's ability to match a listing against pattern-specific search queries like "gingham shirt" when the word doesn't otherwise appear in the title. For retailers who use pattern as a variant-defining attribute, the bigger risk is inconsistency rather than absence — if one row says "Floral" and its sibling under the same item_group_id says "Floral Print," the platform may treat that as noise rather than a meaningful distinction, undermining the variant group it was meant to support. Pattern also tends to matter more in specific verticals — apparel, bedding, upholstery, dinnerware — than others, so its absence on a plain steel water bottle is expected, not a data gap.

How it works

Pattern takes a free-text value describing the design, and Google's documentation gives examples like "polka dot," "striped," "camouflage," and "paisley" as the kind of terms that work well; there's no enforced list, but shorter, shopper-recognizable terms outperform brand-specific print names a search engine won't match. It's grouped with color, material, size, gender, and age group as one of the recognized variant-defining attributes for item_group_id, meaning a retailer can build a variant set purely on pattern — a bedding set sold in three prints at the same size and price point, for instance — without color or size changing at all. When pattern and color both vary across the same variant group, both fields should be populated on every row so the platform can distinguish which dimension is driving which option.

Example

<item>
  <g:id>SHT-6630-SOL</g:id>
  <title>Poplin Button-Down Shirt - Solid, White</title>
  <link>https://example-shop.com/products/poplin-shirt-solid-white</link>
  <g:item_group_id>SHT-6630</g:item_group_id>
  <g:pattern>Solid</g:pattern>
  <g:color>White</g:color>
  <g:price>72.00 USD</g:price>
  <g:availability>in stock</g:availability>
</item>
<item>
  <g:id>SHT-6630-GNG</g:id>
  <title>Poplin Button-Down Shirt - Gingham, Blue</title>
  <link>https://example-shop.com/products/poplin-shirt-gingham-blue</link>
  <g:item_group_id>SHT-6630</g:item_group_id>
  <g:pattern>Gingham</g:pattern>
  <g:color>Blue</g:color>
  <g:price>72.00 USD</g:price>
  <g:availability>in stock</g:availability>
</item>

Both rows carry the same item_group_id but change pattern and color together, which is normal — a variant group can vary on more than one attribute at once as long as every row is internally consistent.

Related Concepts

Pattern is most useful when it's read alongside material and color, since the three together are what typically separate a base apparel or home-goods product into its full range of sellable options. Once a catalog has more than one of these attributes varying at once, keeping the variant logic clean becomes less about any single field and more about making sure every row in the group is complete and consistently formatted.