Google Shopping and Merchant Center 2026 on PrestaShop: Product Feed, GTIN, Performance Max

Google Shopping in 2026: the most poorly exploited acquisition layer by PrestaShop stores

On the mid-market PrestaShop stores we audit, Google Shopping accounts for an average of 18% of acquired revenue. When the feed is well done. When it isn’t — and that’s the default situation — it’s 3% or less, with acquisition cost soaring and products disapproved by Merchant Center without anyone noticing.

The gap plays out at three levels: feed quality (required attributes, GTIN, unique identifiers), campaign strategy (Performance Max vs Standard Shopping), and Merchant Center compliance (2024-2026 policies, Comparison Shopping Services, reference price). The three are distinct and technical topics. This article covers them in the order they appear in the pipeline of a merchant launching or rebuilding their Shopping channel in 2026.

What changed at Merchant Center in 2024-2026

Three major shifts redefine the playing field:

Merchant Center Next replaces the old interface

Since 2024, Google has migrated all accounts to Merchant Center Next — a redesign that flattens hierarchy, simplifies feed creation, and more strictly enforces policies. Practical consequence: feeds that quietly passed 18 months ago are now disapproved en masse, particularly on missing shipping and tax for non-EU merchants.

The end of Comparison Shopping Services positioning on the EU side

Following the European decision and its 2023-2024 adjustments, EU merchants can go through Google directly or via a partner CSS with an effective 20% discount on CPC. On Shopping budgets above €5,000/month, going through a partner CSS (Adwise, KelKoo Group, Productsup, etc.) is profitable. It’s an optimisation that costs nothing to set up but that 80% of PrestaShop merchants don’t activate.

Return and shipping attributes have become near-mandatory

Since late 2024, Google requires explicit shipping and return_policy on the vast majority of Shopping pages. Without these, ads run but with degraded visibility and a falling Quality Score. This aligns with Schema.org Product 2026 properties (hasMerchantReturnPolicy, shippingDetails) that Google has already imposed on rich results.

Anatomy of a compliant product feed in 2026

The Google Shopping feed is a file (XML, CSV, or via Content API) that describes each product to Google. Twenty-five attributes are possible, ten are mandatory, and their correct handling makes the difference between a healthy Merchant Center account and a permanent-warning account.

The ten mandatory attributes — and PrestaShop pitfalls

The “optional but critical” attributes

Four attributes are not marked mandatory but their absence severely degrades performance:

• shipping: shipping rates table by country/region. Without it, Google applies often-wrong defaults. To populate finely, especially for multi-country stores.
• tax: applicable tax. Required for US merchants. For the EU, the tax-inclusive price is in price and VAT is implicit but can be declared.
• google_product_category: Google category (3 to 5 levels). Without it, Google guesses — often wrongly. To map from the official Google taxonomy (5,600 categories).
• product_type: your own taxonomy, useful for campaign segmentation.

Variants and combinations: the PrestaShop complexity

On PrestaShop, a product page with variants (size × colour) is a product with multiple id_product_attribute. On Google Shopping, each variant must be a distinct line in the feed, with:

• id unique per variant (typically {id_product}-{id_product_attribute}).
• item_group_id common to all variants of the same parent product (typically id_product). This is what lets Google group variants in the buyer interface.
• Variation attributes: color, size, material, pattern, gender, age_group — depending on category.
• GTIN per variant (often a different EAN per size or colour).
• Stock per variant.

The most common mistake: sending a single line per parent product with an average price and aggregated stock. Google blocks immediately. The Google Shopping PrestaShop module handles this variant explosion natively, with mapping of PrestaShop attributes to Google attributes.

GTIN: friction #1 and the solution

The GTIN (Global Trade Item Number) is the universal product identifier. EAN-13 in Europe, UPC-A in the US, ISBN for books. Google requires the GTIN for all products that natively have one (known brands, manufactured products). For products without a GTIN (artisanal creation, exclusive private label, services), you must explicitly mark identifier_exists: false.

Two common pitfalls:

1. Invalid EAN-13s

The thirteenth digit is a check digit, computed on the first twelve via the Modulo 10 algorithm. Many stores import manufacturer references with truncated or invented EANs. Google rejects them en masse. Validation should be done at import time, not discovered three weeks later when Merchant Center disapproves 800 pages.

2. GTIN shared between variants

Classic mistake on PrestaShop: the EAN is stored on the parent product (ps_product.ean13) instead of the variant (ps_product_attribute.ean13). Result: all variants share the same GTIN, Google detects the duplication and disapproves.

The right pattern: store the EAN at the variant level when it has its own reference (typical case: different sizes of the same model), and at the parent product level only for single-variant pages.

Performance Max vs Standard Shopping in 2026

Since 2022, Google has pushed Performance Max (PMax) as the default campaign. It’s an automated campaign combining Shopping, Display, YouTube, Discover and Search into a single optimisation logic. The algorithm decides where to place ads and to whom. The advertiser provides the asset groups (text, images, audience signals) and the budget.

When PMax is profitable

• Large catalogue (1,000+ references) with varied category coverage.
• Solid conversion data (50+ conversions / 30 days per campaign, ideally 100+).
• Margins that support a CPA optimised by the algorithm (between +15 and +30% CPA vs Standard, but volume × 2 to × 5).
• Capacity to analyse segments via asset group and audience signal reports (limited but improving reports since 2024).

When Standard Shopping remains preferable

• Specialised catalogue (fewer than 200 references) where granular per-product-group control is critical.
• Tight margins requiring strict CPA and stable ROAS.
• Regulated categories (CBD, vape, certain supplements) where PMax may broaden targeting in a non-compliant way.
• Learning phase: better to structure in Standard Shopping for 3 months to measure per-segment performance, before switching to PMax with those learnings.

The 2026 hybrid stack

The pattern that works today: Standard Shopping on the top 20% of the catalogue generating 80% of revenue, PMax on the long tail. This combines control (top strategic products) and at-scale automation (long tail where manual optimisation cost isn’t profitable).

PrestaShop feed export: three architectures

Architecture 1 — Regenerated static XML/CSV feed

A PHP cron (hourly, or nightly depending on catalogue rhythm) regenerates an XML or CSV file exposed at a fixed URL. Merchant Center pulls this file at configured frequency. Simple, robust, but several hours of latency between a change and its reflection in Shopping.

Architecture 2 — Content API push

The module pushes changes in real time via the Google Content API. Ideal for stores where prices move frequently (flash sales, dynamic pricing) or for limited inventory. More complex to implement, requires a Content API quota and fine error management.

Architecture 3 — Real-time feed via Merchant Center Next

Since 2024, Merchant Center Next supports real-time inventory updates for critical attributes (price, stock, availability). It’s a dedicated endpoint, independent of the main feed. The recommended pattern in 2026 is to combine: a static feed for stable data (title, image, description) and real-time push for price and stock.

The DataFirefly module implements the static architecture with a price/stock push option — covering 95% of merchant cases without API gateway complexity.

Merchant Center compliance: the 2024-2026 policies that disapprove

Four policies are behind 80% of disapprovals in 2026:

1. Reference price — Omnibus directive and aligned Google policy

If you display a strikethrough price (“£99 instead of £149”), the reference price must comply with the Omnibus directive: lowest price practised in the last 30 days. Google has aligned its policy: a non-compliant reference price = disapproval, and it’s tracked across the entire account.

2. Restricted and prohibited products

Tobacco, weapons, adult content, prescription medication: prohibited. Food supplements, vape (without nicotine), CBD: restricted, with per-country rules. Disapproval of a single restricted product can lead to account suspension if repeated — always filter on the PrestaShop feed side to exclude these categories from export.

3. Inconsistent availability

Feed says in_stock, page displays “Out of stock” or a disabled button. Google compares and disapproves. The solution: synchronise the feed with real stock per variant, with a threshold (e.g. availability = out_of_stock if quantity ≤ 0 and allow_oosp = false).

4. Undeclared return and shipping policy

Since 2025, Google explicitly requires return and shipping policies. Either via Merchant Center account settings (global per-country policies), or via shipping and return_policy attributes in the feed. Without these: permanent warning and Quality Score degradation.

Measuring performance — beyond Merchant Center ROAS

The ROAS displayed by Google Ads is the surface metric. To steer correctly, three other readings:

• Net ROAS = (gross revenue × margin rate) / ad cost. Google’s ROAS doesn’t account for product margin. A ROAS of 8 on 15% margin products is less profitable than a ROAS of 4 on 45% margin products.
• Incrementality: how many of those sales would have happened without Shopping (via organic SEO, brand return, other channel)? Test: pause PMax for 14 days on a segment and measure revenue delta. Hard to do properly, but critical for budgets above £20K/month.
• New vs returning acquisition cost. Shopping converts massively on new (acquisition). To measure LTV, cross with PrestaShop CRM/back-office over 6 to 12 months.

Server-side GA4 tracking implementation has become essential in 2026 to reliable these measurements, with third-party cookie erosion and Consent Mode v2.

Linking with other SEO/AEO signals

Google Shopping doesn’t live in isolation. AI agents — Google AI Overviews, ChatGPT Shopping, Perplexity — read the Shopping feed (via Merchant Center API), the page’s Schema.org structured data, and the site’s semantic content. Three mutually reinforcing optimisations:

• The llms.txt file serving as an index for LLMs.
• Complete Schema.org Product (with hasMerchantReturnPolicy, shippingDetails, aggregateRating) for organic matching.
• Compliant Shopping feed with rich attributes (GTIN, brand, gender, material, age_group).

On stores investing in all three, we observe a strong correlation between Shopping feed quality and AI citations in AI shopping agents.

Realistic budget to launch in 2026

For a mid-market PrestaShop store launching Google Shopping:

• Feed module: €149 perpetual licence, or €30 to €80/month for SaaS alternatives.
• Initial setup: 1 to 3 days of work (Google taxonomy mapping, GTIN validation, shipping/tax parameterisation). The DataFirefly module automates 80% of this setup.
• Ads budget: start at €30-50/day, scale to €200-500/day as ROAS stabilises. PMax learning sweet spot is around 50 conversions / 30 days.
• Partner CSS: −20% on effective CPC, free to activate after account opening. Profitable from €5,000/month budget.

With this setup, the 12-month target ROAS is 4 to 8 on 30-40% margins, with setup payback within the first two months.

FAQ

Do you need a Google Ads account to use Merchant Center?

For paid Shopping ads, yes. But Merchant Center alone also enables free listings (free ads in the Shopping tab and on Search). These listings don’t convert as well as paid, but it’s free traffic no store should leave on the table.

Can you run Shopping ads in B2B?

Officially, Shopping is intended for B2C. But B2B PrestaShop stores expose their public catalogue on Shopping to generate leads — it works as long as the page allows direct purchase. Prices must be displayed tax-included (or with “excl. tax” mention); 100% ex-VAT stores with pro validation aren’t eligible.

What causes Merchant Center account suspension?

Three main causes: multiplication of disapprovals without correction (Google considers you don’t respect policy), repeated account creation to bypass previous suspension (suspension is tracked by domain, IBAN, tax identity), or presence of a prohibited product (weapons, prescription medication). In case of suspension, the appeal procedure requires a documented fix, not an excuse.

How to handle promotions and sales via Shopping?

Google Merchant Promotions allows attaching promo codes to ads. The code must be valid, applicable to minimum basket, and compliant with the Omnibus directive for the strikethrough price. For calendar sales (Black Friday, summer sales), prepare ads 7 to 14 days ahead via the feed, and plan the PMax campaign with × 2 or × 3 budget over the period. See also our Black Friday checklist.

Should the feed be bilingual/multi-country?

Yes, but with a distinct feed per targeted country/language. The same product in France and Spain is declared via two entries in Merchant Center: one with language=fr, feed_country=FR, EUR price, FR shipping; one with language=es, feed_country=ES, EUR price (or different if strategy justifies), ES shipping. Never declare a product in multiple countries with a single feed: it breaks matching and disapproves.

In summary

Google Shopping in 2026 isn’t a channel you activate in 30 minutes. It’s a product-data infrastructure requiring rigour on GTINs, cleanliness on taxonomy mapping, regulatory compliance (Omnibus, return, shipping) and alignment with SEO/AEO signals from the rest of the site. For PrestaShop stores that make this investment, it’s typically 15 to 25% of acquired revenue with a ROAS of 4 to 8 and setup payback over 60 days.

The DataFirefly Google Shopping PrestaShop module automates the most time-consuming elements: per-variant extraction, GTIN validation, Google taxonomy mapping, XML/CSV export, Content API integration. For stores wanting to go further, a complete Shopping channel audit identifies compliance leaks and quick wins.

Not to forget in parallel: Google Search Console integration to track organic performance alongside paid, and semantic internal linking to strengthen the catalogue’s topical authority independently of the Ads budget.