PrestaShop product feed for Meta & Google (2026)

PrestaShop sits in a useful middle ground between two stores covered elsewhere on this blog. Magento ships no native feed at all, so it is extension-only. Shopify hands you a native channel sync but hides the feed URL. PrestaShop does both at once: it has official, first-party modules for Google and Meta that sync over an API and hide the URL, PLUS a deep third-party and uniquely-mature Czech-comparator module layer that DOES emit a real, copyable feed URL. So the PrestaShop decision is never "native versus nothing" and never "native-only-then-stuck." It is the official API sync, or a third-party module that hands you a URL. That URL is the thing you can hand to a comparison engine, a second ad channel, a validator, or an image tool. This guide walks the module options by price, the fields each destination needs, and the PrestaShop-specific gaps that get catalogs rejected.

The module options, compared

Two of these are official PrestaShop Corp modules that sync internally; the rest are third-party modules that generate a real feed file (XML, CSV, or JSON) and expose a fetchable URL. Prices are the vendor's own published figures, cross-checked in June 2026. The two solid one-time anchors are Knowband at 39.99 USD and the Czech comparator modules at roughly 499 to 599 Kc; the marketplace-listed PRO modules could not be machine-verified (the PrestaShop addons store blocks automated fetch), so treat those as "check the listing."

The honest headline: PrestaShop has one genuinely free native path (Marketing with Google), but it syncs over an API and gives you no URL. The moment you need a portable feed file, the cheapest credible third-party module with a real URL is the one-time 39.99 USD Knowband license, and for a Czech store feeding the comparators the 499 to 599 Kc comparator modules are the mature pick. Just do not expect any of these to design the image (none do, which is the structural gap further down).

The native path: free Google API sync, paid Meta

For a store that just needs a standard catalog into ONE Google account and ONE Meta catalog, the two official modules are genuinely enough, and the Google one is free. The catch is identical to Shopify and BigCommerce: no portable feed URL. You cannot paste an API sync into Heureka, a second ad channel, or a validator.

Google: "Marketing with Google" (free)

The official module is PrestaShop Marketing with Google, built by PrestaShop Corp and open source under the Academic Free License 3.0. It is free to install from the PrestaShop Addons marketplace. The mechanism is a Google Content API for Shopping sync, NOT a feed file: it connects the store to Merchant Center and synchronizes the catalog automatically, with price and availability updated every day. It covers Google Shopping (paid Product Listing Ads and the free listings on the Shopping tab) plus Performance Max, which reaches Search, YouTube, Gmail, Display, Discover and Maps. Because it is an internal API push, it exposes no copyable feed-file URL.

Meta: "PrestaShop Social" (paid)

The official Meta module is PrestaShop Social with Facebook & Instagram. It used to be free, but since 16 November 2023 it is paid at 9.99 EUR/month (excluding tax). It imports your product catalog into Meta Commerce Manager through the Facebook Business extension, so updates synchronize automatically once you associate the catalog through Business Manager. Like the Google module, this is a partner-platform catalog sync, not a scheduled-fetch feed URL.

The third-party path: when you need a real URL

This is the path that yields a copyable XML, CSV or JSON feed URL, the kind Emberfeed (and a comparison engine, and a validator) can actually import. PrestaShop's third-party module ecosystem is large; two parts of it are worth calling out by name.

• Knowband Google Shopping Integration is the cheapest credible third-party pick: a one-time 39.99 USD license (regularly 49.99), supporting PrestaShop 1.6 through 9.x. The store admin can copy the feed URL or download the merchant feed in JSON, XML, or CSV. It handles attribute groups (Color, Size, Gender, Pattern), EAN-13/JAN/UPC identifier exclusion, and manufacturer mapping.
• The Czech comparator modulesare a distinct, mature layer the English-CMS platforms simply lack. prestahost.eu sells an "export Heureka Zbozi varianty" module at 499 Kc covering Zbozi.cz, Heureka.cz, Heureka.sk, Glami and Google nakupy, with product variants and category mapping in the paid version. psmoduly.cz sells a "Komplexni XML export pro srovnavace" at 599 Kc covering Zbozi.cz, Heureka.cz/.sk, Google and Facebook, including variants, combinations and features, developed since 2014. These emit a per-engine XML feed in the SHOP/SHOPITEM shape the Czech engines expect.
• Mergado Pack is a free connector module that pipes the catalog into the Mergado platform, which then hosts feed URLs for Google, Heureka, Zbozi, Glami and 650-plus channels. The module is free; the Mergado service is the paid part. If you are weighing it against the standalone tools, the WooCommerce guide covers the same connector-is-free-service-is-paid pattern.

The fields each destination needs

Whichever module produces the feed, the destination spec is identical to every other platform. For the full per-attribute reference, the build-a-Google-feed-by-hand walkthrough goes attribute by attribute. The short version, and note that on PrestaShop the Czech comparators are first-class destinations, not a footnote:

• Google Merchant requires 7 on every product: id, title, description, link, image_link, availability, price. Then conditionally: brand (most new products), gtin (when a manufacturer GTIN exists), mpn (only when there is no GTIN), and condition (only for used or refurbished). google_product_category is optional and auto-classified if omitted. Missing identifiers trigger a limited-visibility warning, not an outright rejection.
• Meta catalog needs id, title, description, availability, condition, price, link, image_link, plus brand or gtin or mpn. Title caps at 200 characters (under 65 recommended), description at 9,999, and condition is locked to new, refurbished, or used. The apparel attributes (color, size, gender, age_group) are a Google rule, not a Meta one.
• Czech comparators use the SHOP/SHOPITEM XML shape, not RSS. Heureka strictly needs ITEM_ID, PRODUCTNAME, URL and PRICE_VAT, with IMGURL and CATEGORYTEXT strongly recommended. Zbozi.cz adds DESCRIPTION and DELIVERY_DATE (which accepts -1 for unknown availability). Glami needs CATEGORYTEXT with a gender path and expresses size and color only via PARAM blocks, with variants grouped by ITEMGROUP_ID.

The PrestaShop gaps that get feeds rejected

These come specifically from how PrestaShop models product data, and they are the part a generic feed article misses. Fix them at the source and most feed surgery disappears.

• Combinations (declinations) are your variants. PrestaShop calls variants combinations(a set of attribute values like "Size XL + Green"); older French docs call them declinations. The feed rule: id must be unique per combination, while item_group_id must be identical across all combinations of one product to group them. Good modules emit item_group_idautomatically. When "export combinations" is off, modules typically fall back to exporting the parent product once (default-combination price and GTIN, summed stock), which means a row of color variants can share one image.
• Feature versus attribute (the PrestaShop naming trap). In PrestaShop, features are intrinsic and identical across all combinations of a product (material, composition), so you CANNOT build variants from a feature. Attributes are what vary between combinations (size, color) and are the basis of options. So g:color and g:size map from attributes, while a fixed g:material maps from a feature. Mapping the wrong one is a common miss.
• Brand maps from the Manufacturer field. Google and Meta brand comes from PrestaShop's Manufacturer(Brands) entity, not a field literally called "brand." If Manufacturer is blank, brand is omitted, the classic Czech and Google disapproval-or-limited- visibility cause. Set a static brand or map it explicitly.
• GTIN maps from EAN-13, UPC, or ISBN. PrestaShop stores the barcode in the product's EAN-13 (or UPC, or ISBN) field. g:gtin maps from there; if empty, the identifier is missing. For products that legitimately have no GTIN (handmade, private-label), set identifier_exists = no plus a real brand. The Magento product feed guide covers the same identifier_exists trap.
• PNG thumbnails are not auto-regenerated (a real core bug). PrestaShop generates missing JPG thumbnails on the fly but does NOT regenerate missing PNG thumbnails automatically (open core issue #18769). After a theme change, a bulk import, or a failed "Regenerate thumbnails" run, the exact image size a feed references can be missing, which surfaces as a broken image_link.
• Friendly URLs can break images and links. Enabling the Friendly URL feature without regenerating .htaccess is a well-documented cause of products showing no images and links resolving wrong, which surfaces in the feed as a bad image_link or link. Fix: regenerate .htaccess and confirm the friendly-URL base.
• Multistore cannot set per-shop language or currency natively. PrestaShop multistore runs many shops from one back office, but by default you cannot set different languages or currencies per shop. Each shop's feed must carry THAT shop's base URL for link, its currency for price, and its language for title and description. A misconfigured multistore feed emits the wrong shop's URL or currency, which causes a Merchant Center URL or claim mismatch.
• Category mapping is manual. There is no native PrestaShop mapping to Google's taxonomy, so the module's mapping UI matches each PrestaShop category to the deepest Google node (and to the Heureka or Glami CATEGORYTEXT for the Czech engines). Optional for Google, effectively required for the comparators to pair the product.

The image gap (the structural one)

Here is the part no PrestaShop module solves. Every PrestaShop feed module copies the product-photo URL into image_link and moves on. None brand, overlay, resize for policy, add a sale badge, or composite a designed catalog image. PrestaShop adds its own twist via the combination that inherits the parent image, and via the PNG and friendly-URL breakage above. And the channel rules pull in opposite directions:

• Meta dynamic and Advantage+ catalog ads 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 an overlay it detects. Designed images live in additional_image_link or as a standardized clean primary. A badge on the Google primary is a hard disapproval.
• Heureka, Zbozi and Glami want a clean product IMGURL; Glami specifically prefers product-on-white without a model for the main image.

Where Emberfeed fits

Emberfeed sits at step 3, after a feed URL exists, not instead of it. On PrestaShop that URL comes from a third-party feed module (Knowband, the Czech comparator modules, Mergado, the legacy gshoppingflux), NOT from the native Marketing with Google or Social modules, which sync over an API and expose nothing to import. Emberfeed imports that URL and enhances it. It is not a PrestaShop module, it does not read the PrestaShop database or combinations tables, it does not generate a feed from a store with no feed module, it cannot read the native modules' internal API sync, and it is not self-hosted: it imports your URL and serves a new one.

What it adds on top of the URL 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 image clean). This also masks the combination-inherits-parent-image dullness and works for the Heureka, Zbozi and Glami IMGURL.
• Field rules. Patch brand (fallback from Manufacturer), GTIN and identifier_exists, composite titles, custom labels, or the multistore base URL at the feed layer, without editing hundreds of PrestaShop products or touching combinations.
• Per-feed validation against the live platform spec, including the Czech SHOP/SHOPITEM shapes, before you submit.
• A new served URLthat stays current on an hourly refresh, which you paste into Merchant Center, Commerce Manager, or a comparator's feed field.

For setup specifics on the PrestaShop side, the PrestaShop integration page walks through importing a module's feed URL. The BigCommerce product feed guide covers the opposite case, where the native sync hides the URL entirely.

FAQ

Do I still need a module if I use Emberfeed?

Yes. Emberfeed imports an existing feed URL, and on PrestaShop that URL comes from a third-party feed module, since the native modules sync over an API and expose nothing. They do different jobs: the module generates the feed, Emberfeed enhances it.

Can I just use the free native Google module?

For Google alone, yes: Marketing with Google is free and syncs the catalog straight into Merchant Center. But it gives you no feed URL, so you cannot point a Czech comparator, a second ad channel, a validator, or an image tool at it. The moment you need a portable URL, drop to a third-party module like Knowband or a CZ comparator module.

Why are my product variants not grouping?

Because item_group_id is probably not identical across the combinations. PrestaShop combinations need a unique id per combination but the same item_group_idacross all combinations of one product. Turn on "export combinations" in the module so it emits both correctly.

Can I put a sale badge on my Google image?

Only on an additional_image_link, never on the primary image_link. Google forbids promotional overlays on the primary image and will strip them. On Meta, badges and lifestyle frames are allowed and tend to help; for Glami, keep the main IMGURL a clean product-on-white.