Google Merchant Center feed optimization: the PrestaShop store owner's complete guide

Reviewed for PrestaShop 1.6, 1.7, 8.x and 9.x against the current Merchant Center (Next) interface. Field names (title, description, gtin, sale_price, custom_label_0–4) and the 30-day feed-expiry floor are current; "data sources" replaced "feeds" in the Merchant Center menu, so match by purpose if a path has moved.

Here is the thing most PrestaShop merchants miss about Google Shopping: there are no keywords to bid on. In a Search campaign you write the ad and choose the queries. In Shopping, Google decides which searches trigger your products, and it makes that decision entirely from the data in your feed. Your product titles, descriptions, categories and attributes are your keywords. So the single highest-leverage thing you can do for Shopping performance is not adjust bids or budgets. It is fix the feed. This guide is about exactly that: turning PrestaShop's product data into a Merchant Center feed that wins the right searches, on real back-office fields and feed tags, not generic cross-platform advice.

This is the feed-optimization spoke of a larger cluster. If you still need to get your products into Merchant Center in the first place, start with how to get your products into Google Shopping; for the strategic picture of how Merchant fits your wider PPC, see harnessing Google Merchant for PrestaShop PPC. This post assumes your feed already exists and you want to make it good.

Your feed is your ad creative

When a Shopping ad appears, the shopper sees the image, the exact price and the product name before they click. That is the opposite of a text ad, where you have to earn the click on a headline. The practical consequence: a blurry image, a generic title or a stale price are visible up front, not after the click. A poorly optimised feed fails three ways at once, your products show for the wrong searches (wasted budget), don't show for the right ones (missed revenue), and look worse than the listing next to them (lower click-through). Every fix below targets one of those three failures.

PrestaShop's data model is flexible enough to support a rich feed, but most feed modules simply dump whatever sits in the database, untouched. The product name written for a human browsing your category page is rarely the title that wins a Shopping query. Closing that gap between "what's in the database" and "what Google needs" is the whole job.

Where the feed comes from in PrestaShop

Before optimising fields, know which fields you're even working with. A Merchant feed is built from these PrestaShop sources, and the mapping is not always obvious:

So what? Once you can see the mapping, every "Google rejected my product" problem becomes a specific PrestaShop field to fix, not a mystery. The rest of this guide walks the fields in order of impact.

Product titles: the field that decides which searches you win

Google weighs the first words of your title most heavily when matching to a query. A title that opens with your brand name spends those critical first positions on a word almost nobody searches. Front-load the searchable terms instead.

Title structure by product type:

• Generic / unbranded: Product type + key attribute + size + material + colour + brand. Example: "Linear Shower Drain 800mm Stainless Steel Tile Insert, FlowLine"
• Known brand: Brand + product type + model + key attribute. Example: "Geberit CleanLine60 Shower Channel 900mm Brushed Steel"
• Apparel: Brand + gender + product type + attribute + size + colour. Example: "Nike Men's Running Shoes Air Max 270 Black/White"

The rules that keep titles live:

• Up to 150 characters, but Google shows ~70. Put the deciding terms in the first 70.
• Use the exact words shoppers type, "shower drain", not "drainage solution". Mine Search Console queries and Google autocomplete for the real phrasing.
• Include dimensions both ways where they fit. "800Mm" and "80cm" are different searches.
• No promo text and no ALL CAPS, "Best Price", "Free Shipping" and shouting all trigger disapproval.
• Don't keyword-stuff. Every word must add unique information, or Google flags it.

The PrestaShop problem, and the fix: by default your feed title is just the product name, written for a human reading your category page, not for a Shopping match. The robust fix is a feed generator that builds the title from a template assembling the name with attributes (size, colour, material) automatically, so 2,000 products get keyword-rich titles without 2,000 manual edits. Our MPR Google Merchant module is built around exactly this: you compose feed titles and descriptions from product, attribute, feature and combination tags, so the on-site name stays customer-friendly while the feed title is optimised for search. If you can't or won't change titles in PrestaShop at all, the supplemental-feed override below is the no-touch alternative.

In practice that template is just a string of tags the module fills in per product. A title template like the one below turns a friendly storefront name into a front-loaded Shopping title across the whole catalogue at once:

Title template:  {product_type} {attribute:size} {attribute:material} {color} – {brand}

  Storefront name:  Aurora Drain
  Feed title built:  Linear Shower Drain 800mm Stainless Steel Brushed – FlowLine

Description template:  {summary} {attribute:material} {attribute:finish}. Fits {feature:compatibility}.

The point: you write the template once, and every product inherits a keyword-rich title assembled from its own attributes, no per-product editing, and your customers still see "Aurora Drain" on the storefront.

Descriptions: your long-tail keyword space

Titles are the primary signal; descriptions let Google match the long-tail queries that won't fit in 70 characters. Most stores export the full HTML product description as-is, either a single thin sentence or a wall of marked-up page content.

• 500–1,000 characters is the sweet spot, enough signal, still focused.
• Lead with attributes, material, size, use case, compatibility. Write what someone would type to find this exact item.
• Seed synonyms, if the title says "shower drain", the description should also carry "floor drain", "channel drain", "linear drain". This is where you capture the queries the title can't.
• Plain text only, the feed spec requires HTML stripped. Verify your module does this; many leave tags in.
• No promotional language, same rule as titles.

PrestaShop-specific: the product has both a Summary (short description) and a full Description. For the feed, the Summary is usually the better source, concise and free of the heavy HTML formatting that lives in the long description. If your Summaries are empty, that's the first thing to fix: write a 2–3 sentence, attribute-rich summary per product. A feed generator that lets you choose which field (or a custom description tag) feeds the description attribute saves you from rewriting your on-site copy to satisfy Google.

Product identifiers: GTIN, brand and MPN, and the variant trap

Google matches your products against its global catalogue using unique identifiers. Submit a GTIN whenever the product has one, and submit brand too. If there is no GTIN, submit brand plus MPN where available, or set identifier_exists=false only for genuinely identifier-free products.

• GTIN, the EAN-13 barcode in Europe, UPC in the US. In PrestaShop this is the "EAN-13 or JAN barcode" field.
• Brand, maps to the Brand (formerly Manufacturer) field.
• MPN, the manufacturer's part number; maps to the Reference field.

The rules that bite: if a product has a GTIN you must send it, and it must pass Google's check-digit validation. A random 13-digit number is rejected. For genuinely unique or handmade items with no GTIN, set identifier_exists to false so Google treats the product as legitimate rather than incomplete. Never reuse one GTIN across variants.

The PrestaShop trap that disapproves whole catalogues: PrestaShop stores the EAN-13 at both the product level and the combination (variant) level. A naive feed exports the parent EAN for every colour and size, so Google sees five "different" products sharing one GTIN and flags them. Your feed must export the combination-level EAN where one exists. This is precisely why combination-aware export matters: MPR Google Merchant resolves GTIN, reference, price and availability per combination, so each variant ships its own correct identifier instead of inheriting the parent's.

Images: the first impression that drives the click

Shoppers scan images before they read titles. Google's image rules are strict, and breaking them is a fast route to disapproval:

• Aim for 800×800 or larger. The minimum is 100×100 (250×250 apparel), but bigger images look better and unlock zoom.
• Main image on a white/light background, no watermarks, logos, text or promotional overlays.
• Product fills 75–90% of the frame, no tiny item floating in white space.
• No placeholder "image not available" graphics, instant disapproval.
• additional_image_link carries up to 10 extra shots, angles, close-ups, lifestyle, installation, which lift engagement.
• Keep image URLs stable, changing them forces Google to re-crawl and re-process.

PrestaShop-specific: PrestaShop generates several image sizes (small, medium, large, etc.) from each upload. The feed must reference the largest generated size or the original, never a thumbnail. Check Design → Image Settings and confirm your largest type is at least 800px wide; if it caps at 600, regenerate thumbnails after raising it, or the feed has nothing large enough to send.

Price and availability: where the page and the feed must agree

Google crawls your product page and compares its price and availability against your feed. Any mismatch disapproves the product, and this is one of the most common feed failures merchants hit.

• Feed price must match the landing-page price exactly, including tax treatment. In the EU your page and feed both show VAT-inclusive prices; in the US, typically tax-exclusive. A feed that strips VAT while the page shows it is a guaranteed mismatch.
• Currency must match the target country, sell to Germany, send EUR.
• Availability must be honest. Out of stock on the page means out_of_stock in the feed.
• Use sale_price and sale_price_effective_date for discounts, not by editing the base price, so Google can show the strike-through.

The strike-through that lifts click-through comes from keeping the base price intact and adding the sale on top, with a date window Google can enforce. From a PrestaShop Specific Price, that resolves into feed tags like this:

<g:price>129.00 EUR</g:price>
<g:sale_price>99.00 EUR</g:sale_price>
<g:sale_price_effective_date>2026-11-27T00:00:00+0100/2026-11-30T23:59:00+0100</g:sale_price_effective_date>

PrestaShop-specific: if you run sales through the Specific Price feature, your feed must read that active price into sale_price with the correct date range. And watch customer-group pricing. The feed must export the public price a non-logged-in visitor sees, never a wholesale or VIP rate, or the crawl will disagree with the feed. Because PrestaShop prices and stock move, feed freshness is what keeps these matching, see update frequency below.

Google product category: be as specific as the taxonomy allows

Google's taxonomy contains thousands of categories. Add the most specific google_product_category wherever possible, it is required in some cases and always improves classification, and specificity decides how well Google understands the item.

The common mistake: picking a broad parent like "Home & Garden" instead of the precise "Home & Garden > Bathroom Accessories > Shower Drains". Google uses the category both to understand the product and to apply the right required-attribute rules.

• Always choose the deepest available subcategory.
• Use the numerical category ID, not the text path. IDs are language-independent and less error-prone.
• Also send product_type with your own PrestaShop category breadcrumb (e.g. "Bathroom > Shower Accessories > Linear Drains"). It's separate from google_product_category and gives Google extra classification.

Mapping hundreds of PrestaShop categories to Google IDs by hand is the tedious part; a feed module that lets you map a PrestaShop category once and inherit it across its products turns a week of spreadsheet work into an afternoon.

Custom labels: segment so your campaigns can be managed

Merchant Center offers five custom-label fields, custom_label_0 through custom_label_4. They don't affect matching. They exist purely so you can carve up products inside Google Ads. A useful scheme:

• custom_label_0, margin tier: high / medium / low. Run separate campaigns with different ROAS targets by profitability.
• custom_label_1, seasonality: spring / summer / evergreen / christmas. Push budget toward in-season stock.
• custom_label_2, performance: best_seller / new_arrival / slow_mover / clearance.
• custom_label_3, price band: under_50 / 50_to_200 / 200_plus.
• custom_label_4, your own grouping that differs from Google's taxonomy.

PrestaShop-specific: custom labels have no native home in PrestaShop. They must be populated by your feed module from attributes, features, categories or a rule. MPR Google Merchant maps custom-label tags from product attributes and features so a "best_seller" feature or a margin attribute flows straight into custom_label_2/0. Without this, you simply cannot bid differently on your high-margin lines, the data to split them never reaches Google.

Supplemental feeds and feed rules: fix data without touching your store

Two Merchant Center tools let you correct feed data without changing PrestaShop at all. Invaluable when editing the export is impractical or you need a fast fix.

Supplemental feeds are a secondary source keyed on product id that enriches or overrides your primary feed. Common uses:

• Override titles, a sheet of just id + title replaces your on-site names with keyword-rich Shopping titles, no store edits.
• Add custom labels in bulk when your module can't.
• Bulk-fix GTINs from a supplier spreadsheet you haven't imported to PrestaShop yet.
• Attach promotion IDs for Merchant Promotions.

Google Sheets is the easiest supplemental source. It auto-updates and suits small catalogues that need manual tweaks.

Feed rules (in Merchant Center, the feed rules for your selected data source) transform data after upload, stored in Merchant Center rather than your store, so they survive every feed refresh. Useful rules: append brand to title; map product_type values to google_product_category IDs by pattern; set price-0 items to out_of_stock; extract colour/size out of titles into their own attributes; and normalise messy values ("SS", "Stainless", "Stainless Steel" → "Stainless Steel"). Treat both as triage. They keep you live while you fix the data properly at the source in PrestaShop.

Feed update frequency: how fresh is fresh enough

Google expires feed data after 30 days, so that's the floor, but for an active store, stale data is what creates the price and availability mismatches above. Match the cadence to how fast your store moves:

PrestaShop-specific: a feed that regenerates on schedule is the practical default, and a token-protected, cron-driven file feed is exactly what MPR Google Merchant produces, the file rebuilds on your scheduler so the URL Google fetches is always current, without you exporting by hand. For stores where stock genuinely changes hour to hour, the module also syncs via the Merchant Products API so changes push to Google rather than waiting for the next crawl. The faster the feed reflects reality, the fewer disapprovals you collect.

Multi-language and multi-country feeds

If you sell across the EU, you need a separate feed (or feed target) per country/language combination, each with the right language, currency and shipping.

• One feed per country, the cleanest approach: correct language, currency and shipping baked in.
• One feed, multiple targets. Only works when language and price are identical across targets.
• Feed rules for localisation, transform a single feed (currency, translation) per target.

PrestaShop-specific: PrestaShop's multi-store and multi-language architecture makes per-language feeds straightforward, but your feed module must respect the language and shop context and export titles, descriptions and URLs in the right language. Exporting German titles into a feed targeting France is a classic, silent quality killer. Generate one feed per language context and confirm the URLs resolve to the matching localised product page.

Structured data: let your pages back up your feed

Product schema markup (JSON-LD) on your pages is not a replacement for the feed, but it does two useful things: it helps Google confirm your feed matches the landing page, reducing the price and availability disapprovals above, and it earns rich product results in organic search. At minimum your PrestaShop product pages should carry a Product object with name, image, description, sku, gtin13 and brand, an Offer with price, priceCurrency, availability and url, and AggregateRating if you have reviews. Many themes ship partial schema (missing GTIN or availability); validate with Google's Rich Results Test and close the gaps.

Free listings: the same feed, no click cost

Merchant Center isn't only for paid Shopping. Approved products may be eligible for free listings across Google surfaces such as the Shopping tab, Search and Images, subject to your Merchant Center settings and policies. They're ranked on relevance and data quality rather than bids. Which means every optimisation in this guide improves your free visibility at the same time it improves paid. For many PrestaShop stores that's meaningful traffic at zero click cost, and it's the strongest argument for treating feed quality as foundational rather than optional.

Frequently asked questions

What's the single highest-return change I can make to my feed?

Titles, by a wide margin. Google weights the first ~70 characters most heavily when deciding which searches your product matches, so front-loading product type, key attribute, size, material and colour, instead of leading with your brand or a friendly storefront name, pulls you into auctions you were never entered into before. Do titles first, then images, then identifiers, then price/availability accuracy, then custom labels for segmentation.

Do I have to rename my products in PrestaShop to fix my feed titles?

No, and you shouldn't, because your storefront name should stay human-readable. A feed module that builds titles from a template keeps "Aurora Drain" on the page while sending "Linear Shower Drain 800mm Stainless Steel, FlowLine" to Google. If you can't change the export at all, a Merchant Center supplemental feed (a sheet of id + title) overrides titles without any store edits. The feed title and the storefront name are deliberately allowed to differ.

Why did Google disapprove all my variants for a duplicate GTIN?

Because PrestaShop stores the EAN-13 at both product and combination level, and a naive feed exports the parent EAN for every colour and size, so Google sees several items sharing one barcode and flags the lot. The fix is a combination-aware feed that exports each variant's own EAN and ties the family together with item_group_id. For genuinely identifier-free items (handmade, custom), set identifier_exists=false rather than inventing a number.

My feed price and page price look the same but Google says they mismatch, why?

Almost always a tax-treatment difference. In the EU both your page and feed must show VAT-inclusive prices; a feed that strips VAT while the page shows it mismatches to the cent. The other common cause is customer-group pricing: your feed must export the public price a logged-out visitor sees, not a wholesale or VIP rate. And if a sale just started, a stale feed shows the old price until the next fetch. Which is why freshness matters.

Do custom labels help me show up for more searches?

No, custom labels don't affect matching at all. They exist purely so you can split your catalogue inside Google Ads: bid a higher ROAS target on high-margin lines, push budget toward in-season stock, separate best-sellers from clearance. They're a campaign-management tool, not a visibility one. But without them populated (from PrestaShop attributes or features via your feed module), you simply can't bid differently on different slices of the catalogue, because the data to split them never reaches Google.

What this guide deliberately doesn't cover (and where to go)

Feed optimisation is the foundation, but it sits inside a wider Shopping workflow. To keep each topic deep rather than diluted, the neighbouring pieces live where they belong:

• Products getting disapproved? The full diagnosis-and-fix walkthrough for every common rejection is in fixing Google Merchant feed errors.
• Running the campaigns on this feed. Performance Max is the main way to spend against your Shopping feed. Audience signals, bidding and the search-term workaround are covered in Performance Max for PrestaShop and when to use Performance Max.
• Search alongside Shopping. Text ads don't need Merchant approval and can run within hours, useful while your feed is in review, in Google Search Ads for e-commerce, and the niche-keyword case in why exact keywords are gold.
• New to Google Ads entirely? Start with Google Ads for beginners and don't overspend before the feed is right, see choosing the right Google Ads budget.

The bottom line

Your Merchant Center feed is not a box to tick. It is the lever that decides which queries trigger your products, how they look, and how they perform against the listing beside them, across both paid Shopping and free listings at once. The work has a clear order of return: fix titles first, then images, then identifiers, then price/availability accuracy, then custom labels for segmentation. On PrestaShop specifically that means knowing which back-office field feeds which Merchant attribute, exporting combination-level data so variants don't collide, and refreshing the feed often enough that the crawl never catches it lying. The stores that invest in feed quality consistently outperform the ones that throw money at bids while the data foundation stays broken.