BigCommerce stores hit a familiar wall with Google Merchant Center. The native Google channel installs in five minutes, looks fine on day one, and then the rejections start: "Missing GTIN," "Mismatched product category," "Image does not meet quality requirements." You go into the BigCommerce admin to fix one product, fix it, push the sync, and three days later something else has drifted. The plugin moves data between systems, but it doesn't give you the controls to make sure the right data ends up in the feed.
This guide walks through what's actually required for a BigCommerce → Google Merchant Center integration that holds up over time — what the BigCommerce data model looks like, how its fields map to Google's spec, where the native channel falls short, and what a proper automated pipeline does differently.
How BigCommerce stores product data
BigCommerce has a cleaner data model than WooCommerce — products live in a single Catalog API resource — but it still has a few quirks that surface in feed work.
- Products — the Catalog API exposes products with name, description, price, sale_price, weight, brand_id, categories, custom_url, and a list of variants.
- Variants — each product has one or more variants. Variants have their own SKU, price, sale_price, calculated_price, inventory_level, image_url, option_values (the color/size selection that defines them), and
purchasing_disabledflag. - Brands — a separate resource with a
brand_idreferenced by products. Brand has a name, page title, meta keywords. You join onbrand_idto get the brand name. - Categories — a tree. Products can belong to multiple categories. Custom URLs and category IDs are the only signals about what the product is — there's no
google_product_categoryfield built in. - Custom fields — key-value pairs attached to a product. Stores commonly use these for GTIN, MPN, gender, age_group, and material because BigCommerce doesn't have first-class fields for them.
- Modifiers — these are not the same as variants. Modifiers are configurable add-ons (engraving, gift wrap). Don't ship modifier values as variants to Google.
- Inventory tracking levels —
none,product, orvariant. This determines whether availability comes frominventory_levelon the product or on the variant. Mistaking one for the other is a common bug.
That last point — inventory_tracking — is where a lot of BigCommerce → GMC setups quietly break. If a store switches from product-level to variant-level tracking and the feed wasn't built to handle both, availability starts lying.
What Google Merchant Center requires
Google's product data specification lists 30+ fields. The enforced subset is what gets you disapproved.
Required for all products
| Field | Notes |
|---|---|
id | Stable unique ID. Use BigCommerce variant ID for products with variants, product ID for single-variant products. Don't use SKU. |
title | Up to 150 characters. Append the variant axes for variants — "Acme Hoodie — Black, Large". |
description | Up to 5,000 characters. Strip BigCommerce's inline HTML to plain text or minimal HTML. |
link | Public product URL. Use BigCommerce's custom_url.url plus the storefront base. Must be HTTPS. |
image_link | Minimum 100×100 pixels (250×250 for apparel). Must be HTTPS. |
availability | in_stock, out_of_stock, preorder, backorder. Derive from inventory state — see below. |
price | Format as 19.99 USD — number, space, ISO 4217 code. |
brand | Up to 70 characters. Comes from the brand resource via brand_id. |
gtin (or mpn + identifier_exists: no) | See GTIN section. |
Required for apparel and shoes
| Field | BigCommerce source |
|---|---|
color | Variant option_values — find the option whose option_display_name is "Color." |
size | Variant option_values — find "Size." |
gender | Almost always a custom field. Map mens/womens/unisex → male/female/unisex. |
age_group | Almost always a custom field. adult, kids, toddler, infant, newborn. |
item_group_id | Use the parent product's id. All variants share. |
Strongly recommended
| Field | Why |
|---|---|
google_product_category | Use Google's product taxonomy. Auto-detection is unreliable for niche categories. |
product_type | Concatenate the BigCommerce category breadcrumb. |
sale_price + sale_price_effective_date | Required for strikethrough pricing. |
additional_image_link | Up to 10 alternate images from the product's image list. |
condition | new, refurbished, or used. Hardcode new unless you sell otherwise. |
Map BigCommerce fields to Google fields
This is the table most BigCommerce stores never quite get right.
| Google field | BigCommerce source | Gotcha |
|---|---|---|
id | variant.id (multi-variant) or product.id (single-variant) | Variant ID is stable; SKU is not. |
title | product.name + appended variant option values | Append in a consistent order — color before size, brand prefix optional. |
description | product.description | Strip inline <style> and <script> tags. Keep basic formatting. |
link | Storefront base + product.custom_url.url | Use the storefront URL, not the API URL. |
image_link | product.images[?is_thumbnail].url_standard or higher resolution | If a variant has its own image_url, use that for the variant. |
price | variant.calculated_price or product.calculated_price | calculated_price accounts for active sales. Don't use price directly if sale_price is active. |
sale_price | variant.sale_price or product.sale_price if active | BigCommerce doesn't expose sale start/end as easily — verify the sale is currently active before sending. |
availability | Compute from inventory_tracking + inventory_level + purchasing_disabled | See logic below. |
brand | Join product.brand_id → brand resource → brand.name | Two API calls; cache the brand list. |
gtin | Custom field commonly named gtin, upc, or barcode | BigCommerce has no first-class GTIN field. Map your custom field key. |
mpn | Custom field or product.mpn if you've added that field | If MPN is empty, fall back to variant.sku. |
condition | Custom field or hardcode | Most stores hardcode new. |
google_product_category | Custom field or AI-derived | BigCommerce category names rarely match Google's taxonomy. |
product_type | Concatenate BigCommerce category chain | "Clothing > Hoodies > Pullover". |
color, size, material, pattern | Variant option_values matching the option's display name | Check the display name, not the option ID — option IDs vary by store. |
item_group_id | product.id for all variants of one product | Use consistently. New variants must inherit the parent's ID. |
shipping_weight | variant.weight or product.weight | Format with unit: 2.5 kg or 5.5 lb. |
gender, age_group | Custom fields | Required for apparel. Map mens→male, womens→female. |
The availability logic
BigCommerce availability is not a single field. It's a function of three:
if product.purchasing_disabled or variant.purchasing_disabled:
availability = "out_of_stock"
elif product.inventory_tracking == "none":
availability = "in_stock"
elif product.inventory_tracking == "product":
availability = "in_stock" if product.inventory_level > 0 else "out_of_stock"
elif product.inventory_tracking == "variant":
availability = "in_stock" if variant.inventory_level > 0 else "out_of_stock"
When stores switch tracking levels, feeds built around the wrong field send stale availability for weeks. Audit your inventory_tracking value and confirm your feed reads the right level.
Sync method options
There are four real ways to get BigCommerce products into Google Merchant Center. Each has a different failure mode.
Option A: Manual CSV export
BigCommerce can export products as a CSV. You reformat to Google's spec, upload to Merchant Center.
Pros: Free, no plugin needed. Cons: Goes stale on export. Inventory and price changes don't propagate. Disapprovals from price mismatch follow within days because Google crawls the live site.
Useful only for one-time tests or genuinely static catalogs.
Option B: BigCommerce Google Shopping channel
The native Google channel is built into BigCommerce.
Pros: Free, OAuth setup is painless, handles standard fields and variants reasonably well. Cons:
- Limited mapping flexibility. Custom fields are not mapped automatically — your GTIN custom field, gender custom field, age_group custom field stay invisible to Google unless you push them via the Catalog API yourself.
- Sync cadence is opaque. Daily-ish for most stores, with no force-resync button.
- Auto-categorization is mediocre. Niche categories get bucketed into generic ones.
Fine as a starting point. Most stores running real Shopping ad spend outgrow it within a month.
Option C: Third-party feed app
Apps from the BigCommerce App Store generate hosted XML feeds Google pulls.
Pros: Mapping UI for custom fields, multi-channel from one app. Cons: Hourly cadence at best. No webhook-driven real-time sync. App pricing scales with SKU count.
Option D: External feed automation (SnowPipe and similar)
A platform pulls from the BigCommerce Catalog API or webhooks, transforms into Google's spec, and pushes via the Merchant API or hosted file.
Pros: Webhook-driven real-time sync, full mapping control including custom fields, multi-channel from one source. Doesn't run inside BigCommerce. Cons: Monthly cost, requires API credentials.
For stores running material Shopping ad spend or with frequent inventory turnover, this is where the math favors automation.
Common BigCommerce → GMC errors
"Mismatched price" / "Mismatched availability"
Google crawls the product page and compares to the feed. If your feed sends 19.99 USD and the page renders a different number because of a customer-group price override or a multi-currency setup, the product is flagged.
Fix: Use calculated_price from the API, not the raw price field. For multi-currency stores, generate one feed per currency targeting the right country.
"Missing required attribute: gtin"
BigCommerce has no built-in GTIN field. Some stores use a custom field, others the upc field on variants, others a third-party app. Until the feed maps that field correctly, GMC keeps warning.
Fix: Find where (if anywhere) your store stores GTINs, map that custom field key to gtin. For genuinely GTIN-less products (private label, custom-made), set identifier_exists: no and provide brand + mpn. See Google's GTIN policy.
"Missing google_product_category"
BigCommerce category names ("Hoodies", "Apparel") don't match Google's taxonomy ("Apparel & Accessories > Clothing > Outerwear > Coats & Jackets"). Auto-detection picks something generic.
Fix: Either add a custom field per product with the Google Product Category numeric ID, or use a tool that infers it from title and description with AI.
"Image does not meet quality requirements"
BigCommerce stores often render images at small sizes for performance. Google requires at least 100×100 pixels (250×250 for apparel) and rejects watermarks, promotional badges, or text overlays. See image requirements.
Fix: Use the url_standard or url_zoom image variant from the BigCommerce API, not url_thumbnail. Confirm no theme element is baking promotional badges into the image file itself.
"Variant not grouped"
Variants of one product don't share an item_group_id. Each variant is treated as a separate product. Ad sets miss new variants.
Fix: Set item_group_id to the parent product.id for every variant. Verify after each new variant is added.
How SnowPipe handles BigCommerce → Google Merchant Center
SnowPipe connects to BigCommerce via the Catalog API with OAuth, pulls products, variants, brands, categories, and custom fields, and pushes a Google-compliant feed via the Merchant API.
The pieces that matter here:
- Custom fields are first-class. Any BigCommerce custom field — GTIN, gender, age_group, material, condition — gets mapped through a visual mapper without code. The smart template handles the standard fields out of the box.
- AI Google Product Category assignment. SnowPipe assigns the correct Google Product Category from product title and description automatically, so you don't maintain a 6,000-row category map.
- Real-time and scheduled together. BigCommerce webhooks trigger immediate updates to Google for product changes; a scheduled full sync runs in the background to catch missed events. Both are wired by default.
- Variant flattening with
item_group_id. Variants come out as separate Google items with shareditem_group_idderived from the parent product ID. Each variant gets its ownimage_linkfromvariant.image_urlwhen set, falling back to the product image. - Inventory tracking aware. SnowPipe reads
inventory_trackingand computesavailabilityfrom the right level (product or variant), so switching tracking modes doesn't silently break the feed. - Brand join. The brand resource lookup is handled automatically — you don't write the join. Brand name lands in
brand. - Multi-channel from one source. The same BigCommerce connection feeds Google, Facebook Catalog, and TikTok Shop without re-mapping.
The platform runs outside BigCommerce, so large catalogs stream through with constant memory and don't hit any platform-side cron timeouts.
Ready to fix this for good?
Try SnowPipe free — connect your BigCommerce store and get an accurate Google Merchant Center feed in minutes. Or, book a 15-min demo and I'll walk you through your specific setup.