Wix product feed for Meta & Google (2026)

Wix is the structural opposite of Shopify. Where Shopify gives you no native feed URL and traps you in an Atom format, Wix natively hands you a copyable product data-feed URL for both Google Merchant Center and the Facebook/Meta catalog, straight out of Marketing Integrations, with no third-party app required. That is the good news. The catch is the second half: the URL is easy, but the data inside it is the problem. The native feed's mapping is fixed, brand defaults to your store name, GTINs hide in a section the feed often ignores, and the images come from a CDN with a disapproval history. This walks through the exact native setup for each channel, the Wix-specific gaps that get catalogs rejected, and where an enhancement layer fits.

The three ways a Wix store gets a channel feed

Every Wix store produces a Meta or Google feed in one of three ways, and unlike Shopify, two of them are genuinely low-friction. This table is the whole mental model:

The honest headline that inverts the Shopify and Magento stories: the native Wix path does give you a real, importable feed URL, and that part is genuinely easier than either of those platforms. So the Wix problem is not "no native URL." It is that the native feed's data and images are thin and unfixable inside Wix, and the app tier patches the data but never the image.

Native path: Google Merchant Center

Wix builds the Google feed for you and exposes it as a URL. The verbatim flow:

• Dashboard, then Marketing Integrations, then click Connect under Google Merchant.
• Click Get Data Feed, then Copyto copy your data feed's URL, then Close.
• In Google Merchant Center, create a new feed and paste the URL, then set selling countries, languages, and the update schedule for Google to re-check.

Two things to be clear on. It is a copyable feed URL, not a real-time API sync: products refresh on the schedule Google fetches on, and you can force a pull with Fetch Now. And the prerequisites are stricter than people expect, including a Premium plan, Wix Stores installed, and the site verified with Google Search Console. Beyond that, Wix requires a payment provider, a Terms of Service with a refund policy, at least two of phone, email, or physical address, and product descriptions of at least 500 characters.

Native path: Facebook and Meta catalog

The Meta flow mirrors the Google one, and again it produces a URL rather than a partner-platform push:

• Dashboard, then Marketing Integrations, then click Connect under Facebook Catalog.
• Click Get Data Feed, then on the "Here's Your Facebook Catalog Feed" pop-up click Copy.
• In Meta Commerce Manager choose Enter URL, paste it, and set the schedule for how often the data feed updates.

This is a scheduled-fetch data-feed URL pasted into Commerce Manager, the same surface a feed app or an externally-served URL would target, not the near-real-time partner push. Wix auto-syncs the name, description, and price. The same product-type rule bites here too: per Wix, Facebook does not support the sale of digital products. For full Facebook and Instagram Shops, Wix has a separate App Market route (the Facebook Shops by GoDataFeed app) that builds the feed inside GoDataFeed instead of using the native Marketing-Integrations data feed.

Variants work correctly (this is not a gap)

Worth stating plainly, because it is the opposite of the Shopify and Magento variant pain: Wix handles variants correctly. Wix models them through its product-options system (size, color, material); each variant can carry its own price and SKU, and the feed submits variants as separate items, which is exactly what Google wants. You do not fight a parent-child collapse or a duplicate-item problem the way you do on those platforms. The Wix variant catch is narrower and lives in the gaps below: populating a per-variant GTIN, and the fact that variants often inherit the same parent photo.

The Wix-specific gaps that get feeds rejected

These come specifically from how Wix models product data and hosts images. This is the part a generic feed guide misses, and the part that justifies a downstream layer.

Brand defaults to your store name

This is the most commonly reported Wix mapping bug. Wix tells Google the brand is your shop name rather than the real manufacturer, and there is no clean native per-product brand override that the feed reliably reads. On branded goods that produces brand mismatches and identifier warnings. Treat this as commonly reported across the community, not an official Wix spec line, but it is real and it is the first thing to check.

GTIN is hand-entered and easy to miss

Wix Stores does have a product-identifier field, in the product's Additional Infosection, plus a "This product has a GTIN, ISBN or UPC Code" checkbox in the Google-Shopping prep flow. The trouble is that many merchants overlook it, and without a GTIN, products from known manufacturers trigger warnings and lose visibility. For products that genuinely have no GTIN (handmade, private-label), the correct move is identifier_exists = no plus a real brand, exactly as on the WooCommerce side, but the native Wix feed gives you no place to set that flag.

Wix CDN image URLs have a disapproval history

Wix hosts all media on static.wixstatic.com/media, and multiple community and Velo threads report the native feed emitting image URLs that Merchant Center flags as invalid or disapproves across an entire catalog. Frame this honestly: it is a recurring, community-reported issue, not a guaranteed failure on every store, but it is real and specific to how Wix serves images. It compounds with the variant point above, since variants frequently share the same parent photo.

No native feed rules, transforms, or DIY path

The native data feed has a fixed mapping. Inside Wix you cannot rename fields, set a fallback brand, force identifier_exists, build composite titles, or add custom labels. And unlike Shopify (Liquid) or Magento (XML templates), Wix has no hand-rolled-feed escape hatch at all. Your only native levers are the per-product fields Wix exposes; everything else needs an app or a downstream tool. A handful of smaller frictions ride along too: product URLs can break when a product is renamed, scheduled sale prices can lag, and image processing can drop an image below Google's minimum size.

The image gap (the structural one)

Here is the part no path above solves. The native feed and every feed app do the same thing with images: they copy the Wix product-photo URL into image_link and stop. None of them brand, overlay, add a sale badge, resize for policy, or composite a designed catalog image. On Wix this compounds with the CDN-URL fragility and the shared-variant-photo problem. And the channel rules differ sharply:

• Meta dynamic and Advantage+ catalog ads measurably benefit from richer creative (lifestyle shots, price or discount badges, branded frames) delivered through additional_image_link. This is where a designed catalog image earns its place.
• Google forbids promotional overlays and text on the primary image_link, and its Automatic Image Improvements will strip a detected overlay. So designed images have a narrower, rule-bound home on Google: additional_image_link, or a standardized clean primary (consistent crop, plain background, with the 500 by 500 minimum enforced from January 31, 2027). A badge on the Google primary is a hard disapproval.

The required fields each channel needs

These mirror the platform feed specs. For the full per-attribute reference, the build-a-Google-feed-by-hand walkthrough goes attribute by attribute. The short version:

• Google Merchant requires 7 on every product: id, title, description, link, image_link, availability, price. Brand, GTIN, and MPN are conditional on identifier logic; google_product_category is optional (auto-classified). Apparel adds color, size, gender, and age_group as a Google-specific rule.
• Meta catalog needs id, title, description, availability, condition, price, link, image_link, plus brand or gtin or mpn.

Native feed, feed app, or a layer on top

The native Marketing-Integrations feed is the lowest-friction default, and for many stores it is enough. Stay native when you sell physical products, your brand and GTIN data is clean, and you do not need rules or designed images. There is nothing to host and Wix keeps the mapping current.

Reach for a feed app when you need to rewrite the field mapping the native feed locks down: a fallback brand to escape the store-name default, forced identifier_exists, composite titles, or custom labels. Simprosys Google Shopping for Wix is one option (it can generate an XML feed URL in Google's product-data-specification format and submit to several channels); on price, its Wix listing has run as a free beta, so treat it as "ask the vendor" rather than a fixed number, the same treatment as on the WooCommerce side. None of these apps, though, touches the image.

Where Emberfeed fits

Emberfeed sits after the Wix feed URL exists, not instead of it. Wix (native Marketing Integrations, or a Wix App Market feed app) produces the feed URL; Emberfeed imports that URL and enhances it. It is not a Wix app, it does not read your Wix Stores database, it does not conjure a feed from a store with no feed URL, and it is not self-hosted: it imports your URL and serves a new one.

What it adds on top of the Wix feed you already have:

• Rendered images. Design one per-product template, and every image_link in the served feed becomes a rendered image, framed for Meta catalog ads and additional_image_link slots (keeping the Google primary clean), which also sidesteps the bland shared-variant photo.
• Field rules. Patch the brand-equals-store-name default, set GTIN and identifier_exists, build composite titles and custom labels, and normalize availability, at the feed layer, with no per-product editing in Wix.
• Per-feed validation against the live target-platform spec before submission, which catches the GTIN, brand, image-size, and overlay issues Wix cannot see.
• A new served URL kept current on an hourly refresh, which you paste into Merchant Center or Commerce Manager.