PrestaShop product feeds for Google and Meta

What we would do

We would first reconcile a representative set of offers through the existing exporter, platform record, product page and checkout. The right route depends on your shop version, installed modules, supplier and ERP integrations, theme, combination data, markets and the team maintaining it. Keep a working connection if it can meet those requirements. A hosted feed is a practical starting choice when its generation and fetch schedules keep offers accurate; an API needs reliable submission, monitoring and recovery to earn its extra setup.

Rehearse exporter, mapping or identity changes on a staging copy with the live shop's relevant configuration. Stop the copy from submitting to live catalogues, emailing customers or triggering production integrations. Use local previews, then a supported isolated destination for submission tests where available. Compare the intended item IDs, public prices, variants and exclusions before a planned switch, with the previous settings and reversal steps recorded. A restored shop configuration does not instantly undo data already processed by a platform.

If offers are repeatedly rejected or recorded purchases disagree with shop orders, the PrestaShop Product Feed & Tracking Audit can document the discrepancies and their causes.

Understand the feed, catalogue and campaign

A feed supplies structured product data to a platform. Google Merchant Center processes that data for eligible shopping experiences. A Meta catalogue stores product records; a Shop presents eligible catalogue items through Facebook or Instagram.

Shopping ads use product data to identify relevant products and build listings. Titles, images, identifiers, price and availability matter, but campaign goals, bids, demand, budget, landing pages and measurement also affect results. A feed alone does not decide every auction.

Standard Shopping and retail Performance Max can use Merchant Center inventory. Performance Max also uses other assets and signals; do not treat every Performance Max placement as a feed-only Shopping ad. Text Search campaigns are another route, with their own keyword and creative controls.

Check product eligibility before increasing budget. Google Ads also exposes product status and diagnostics; a low-spend campaign can have bidding, demand or budget causes as well as rejected inventory.

This guide concerns outbound product data sent from your shop to advertising and listing platforms. A supplier feed imports data into PrestaShop; wrong imported stock or pricing must be repaired before export. Displaying Instagram or Facebook posts on your website is another task, covered in the social feeds guide. Neither a posts widget nor a tracking pixel exports a product catalogue by itself.

For the campaign workflow, see the Google Ads guide. This guide covers product data and its journey to the platform.

Create the Merchant Center connection

1. Create the Merchant Center account with accurate business details.
2. Verify and claim the store website using a method offered for your account.
3. Configure shipping, returns and the countries you actually serve.
4. Choose a data source and submit a small representative product set.
5. Review processing results and product destinations before expanding the export.

Use an offered HTML file, verification tag or eligible Analytics or Tag Manager ownership method. If the account already recognises your website ownership, the flow may be simpler. Keep the verification method in place. Do not assume a marketing module inserts a verification tag unless that feature is implemented.

Before creating a replacement account, check whether an agency or former employee already manages the website claim and data source. Recover the business's access and identify the existing owner rather than setting up a second integration without knowing what it controls.

For free visibility, confirm the Free listings marketing method, data-source participation, country eligibility and product status. Approval by itself does not confirm every setting or guarantee appearance. A Google Ads account is needed for paid campaigns, not simply to supply eligible free listings.

Use the current data-source workflow rather than looking only for the older Products, Feeds menu. For errors, open Products & store, Products, then the Needs attention tab.

Choose a file, connector, crawl or API

A dedicated module is one route to store-side control. Supplemental sources, data-source rules, API integrations and source-page changes can also improve data. If you already use a Google connector, check its compatibility with your installed PrestaShop release and its support for your required markets, combinations and fields.

Use Merchant API v1 for current API work. Content API for Shopping reached sunset on 18 August 2026, with intermittent failures beginning on 1 September for integrations without an active extension. See Google's migration timetable.

Google Merchant XML & API Integration provides XML generation and Merchant API synchronisation, with configuration for token-protected URLs, credentials, product selection, variant export, previews and a TEST-to-LIVE workflow. Use the module help linked below for the configuration details.

A local TEST preview validates an export but does not confirm that Google accepted it. Verify a real submission and the resulting platform status separately. Keep service-account credentials outside the public web directory and restrict their permissions.

Map product identities and genuine identifiers

Keep your catalogue item ID separate from a GTIN or MPN. The item ID is your stable key for updates and reporting. It must be unique within its intended scope and remain consistent across refreshes.

A product-and-combination scheme such as 4521-3 can identify one variant, while 4521 groups its family. Add shop scope when the catalogue design needs it. Product references can be empty, duplicated or changed, so use them as keys only after validating uniqueness and permanence.

Before changing an exporter or ID scheme, save the current mapping between platform item IDs, shop products and combinations. Compare it with the proposed output, including shop scope. Recreating the same offers under different IDs can break supplemental joins, reporting continuity and catalogue event matching. Plan any necessary identity migration with the campaign and tracking owners.

Modern PrestaShop has separate product and combination MPN fields. A reference or SKU is an MPN only when it really is the manufacturer's number. On older versions, explicitly map genuine MPN data from the field that stores it.

Submit assigned GTINs when required, with brand and other applicable identifiers. MPN is not a substitute for an assigned GTIN. Use the combination's own identifier when variants have different assigned codes.

Follow the category-specific identifier_exists rules. An empty GTIN, handmade item or private label does not automatically justify false. Supply genuine brand and MPN where applicable, and never invent a barcode to remove an error.

Write useful titles and descriptions

Put the distinguishing product information near the beginning of the title because displays can truncate it. Google does not publish a rule that the first seventy characters have a specific ranking weight.

For a generic item, a useful title might be Linear Shower Drain 800mm Stainless Steel Tile Insert, FlowLine. A known-brand product can start with brand and model, such as Geberit CleanLine60 Shower Channel 900mm Brushed Steel. Include the variant's relevant size, colour and material without repetition or promotional claims.

Google titles allow up to 150 characters and descriptions up to 5,000. Write enough to identify the item clearly; there is no universal 500-to-1,000-character optimum. Keep important details first, use accurate compatibility and dimensions, and avoid promotional text or irrelevant keywords.

You can use feed-specific text while keeping a concise storefront product name, provided both describe the same item. The product's short description can be a suitable base when it is complete and readable. Clean exported text and check escaped characters; the feed module strips HTML from its description resolver.

Preview templates against a product with missing optional attributes as well as a fully populated combination. Remove empty separators and unresolved placeholders. A title assembled from a parent product's size and a combination's colour can describe an offer you do not actually sell.

Template placeholders belong to the exporter you use; for the supported title, description, attribute, feature and custom-field resolvers, follow the module help and preview missing catalogue values before exporting.

Export combinations as distinct offers

Export separately purchasable combinations with distinct item IDs, appropriate shared family grouping and variant-specific attributes. Check colour, size, image, barcode, MPN, price and stock at combination level.

The link must select the advertised variant and show its actual price and availability. A correct variant record pointing to an unrelated default combination is still a poor landing experience.

This abbreviated Google XML example illustrates a blue medium variant. It is not a complete feed document, and applicable genuine identifier fields still need to come from the catalogue. For production, map description from clean product text, link from the URL that selects that combination and image_link from its main image; use additional_image_link for suitable extra views, and map condition where required as new, refurbished or used.

<item>
  <g:id>4521-3</g:id>
  <g:item_group_id>4521</g:item_group_id>
  <g:title>Cotton T-shirt, Blue, M</g:title>
  <g:color>Blue</g:color>
  <g:size>M</g:size>
  <g:price>29.99 EUR</g:price>
  <g:availability>in_stock</g:availability>
</item>

Generate the complete XML with the correct Google namespace and an XML serialiser. Test special characters in names, descriptions and URLs. Do not manually concatenate unescaped catalogue text.

Align prices, discounts, currency and stock

Compare the feed with the public landing page and checkout in the same shop, language, destination and currency context. Check tax treatment, specific prices, customer-group rules, quantity conditions and selected combinations.

For example, a regular 129.00 EUR offer discounted to 99.00 EUR can use price and sale_price with its real sale window. Use an accurate sale_price_effective_date when relevant. Sending a sale price does not guarantee a strike-through annotation.

For a suspected VAT mismatch, compare the amounts. A ratio such as 1.19 can suggest a nineteen-percent tax difference, but also check whether the same variant and discount were selected. Do not assume every mismatch is tax.

Use a supported currency consistently across the submitted offer, landing page and checkout. A local-currency feed is one route. Google's supported currency-conversion workflow can target other countries from an eligible submitted currency; one country does not inherently require a separate local-currency feed. See multi-country offers.

Match availability to fulfilment, not quantity alone:

• in_stock: you can accept and fulfil the order under the stated delivery conditions.
• out_of_stock: the item is unavailable for purchase.
• backorder: an existing item is currently unavailable but orderable for later shipment.
• preorder: an unreleased product is offered ahead of release.

Backorders and preorders require an appropriate availability_date, also visible on the page. Allowing orders at zero quantity does not automatically make the item in stock.

Some mismatches can be corrected through automatic item updates; others produce warnings, limitations, disapprovals or account action. Treat automatic updates as a safeguard and keep source data accurate.

Submit images that meet the dated requirements

Check the actual dimensions and content of each image URL. An image-type name such as home_default does not determine compliance; themes can define different sizes. Prefer a sufficiently large generated image that shows the item clearly.

As of October 2026, Google's legacy minimums are transitional. It has announced a 500 by 500 pixel minimum across categories and marketing methods, including additional images, with enforcement from 31 January 2027. Warnings are already active. See the 2026 specification update.

Use clean product images without promotional overlays or watermarks. Additional views can show details, use and installation. Keep URLs stable when the image is unchanged, and use the platform's supported update process when replacing an image.

After changing PrestaShop image-type dimensions, regenerate the required sizes in a controlled job. Verify that the generated URLs return real images, without login, blocked redirects or missing files.

Check robots rules, crawler access, hotlink protection and your WAF separately. Loading an image in a normal browser is useful, but it does not prove that Google's crawler is allowed through.

Use taxonomy, labels and supplemental data

google_product_category uses Google's taxonomy; product_type can express your own category hierarchy. Choose the most specific accurate category rather than an invented path. For a suitable drain, category 504636 is Hardware, Plumbing, Plumbing Fixture Hardware & Parts, Drains.

Use the current taxonomy and confirm that the category matches the actual product. Mapping a PrestaShop category once can simplify consistent export, but review exceptions.

Custom labels zero through four can carry business groupings such as margin tier, season, bestseller status, price band and clearance. For example, keep one label consistently assigned to high, medium or low margin rather than mixing unrelated classifications in the same field.

Custom labels support inventory and campaign management. They are not the only way to form product or listing groups; brand, item ID, condition, category and product type can also be useful. Keep any margin labels aligned with actual costs before assigning different targets.

A supplemental source keyed by the same item ID can add titles, labels or corrected identifiers. Data-source rules can perform supported transformations, such as combining text or normalising values. Test rule precedence and sample output so a later refresh does not undo a fix.

Rules are not a general translation or currency-conversion service. Use genuine translated source data and Google's designated conversion workflow where eligible.

Monitor every stage of freshness

There are several clocks: a catalogue change, export regeneration or API synchronisation, platform fetching or processing, and eventual listing or ad serving. None is guaranteed to happen immediately after a product save.

The feed module can reuse a valid cached file. A product update can invalidate state without submitting all changes to Google at that instant. API capability and the configured synchronisation cadence are separate.

1. Choose a job cadence based on how quickly stock, prices and campaigns change.
2. Configure a real server scheduler or the installed scheduling integration.
3. Check the last successful generation or API submission and its product counts.
4. Align the platform's fetch schedule with file generation.
5. Check ingestion errors and the processed values of representative products.
6. Before a scheduled sale, verify its effective dates and the complete update chain.

If a supplier import or ERP owns price and stock, generate the export after its successful update. Record which system owns each field so a manual correction is not silently overwritten by the next import. Check failed or partial imports before sending their results downstream.

Do not use visitor traffic as a substitute for a reliable job. Protect feed URLs as configured, keep them accessible to the platform, and update consumers if you rotate their access token.

Test removals as well as updates. Check what the installed exporter does when a product is disabled, deleted or excluded from selection. File and API routes can treat omitted items differently; confirm the supported removal procedure and the resulting platform record. Investigate an unexpected fall in export counts before allowing bulk removals, especially after an import or selection change.

Submitted product data generally expires thirty days after its last refresh. Products added directly in Merchant Center do not expire, and Google can refresh eligible data from your pages. None of these mechanisms is a freshness target for changing stock. A daily job can still serve stale data between runs or after a failure.

Resolve product and account issues systematically

Start in Products, Needs attention. Separate item problems, data-source failures and account policy issues. Work first on issues that affect many products or block the account, then inspect individual exceptions.

Configure free shipping explicitly as a zero-cost service where appropriate. Missing shipping information is not the same as free shipping. Keep Merchant Center settings consistent with what the selected PrestaShop carriers actually deliver.

On PrestaShop 1.7.8, site-wide HTTPS uses both Enable SSL and SSL on all pages. Later releases differ. Check insecure hard-coded resources separately; enabling SSL does not rewrite every image or script URL.

Fix the source or a deliberate persistent rule, regenerate or submit, verify the corrected artefact, and check platform processing. Request review only when the specified policy issue has been addressed. A correction does not guarantee approval within a day or two.

Work through one rejected combination

Use the blue medium T-shirt offer 4521-3 from the XML example. Suppose the exported offer is 29.99 EUR, but its link opens another default combination with a different price. Changing tax settings would not repair that selection error. Work through the same item throughout the investigation:

1. Save the exact issue message, affected destination, item ID, submitted link and the platform's processed price. Record the export and processing times so you can distinguish an old record from the latest output.
2. Open that link as a logged-out customer in the intended shop, language, currency and destination context. Follow redirects and note which colour and size are selected. Compare the page's visible offer, structured data and checkout price with the raw feed record.
3. On staging, correct the combination link or resolver that selected the default offer. Check its image, assigned identifiers, stock policy and family grouping at the same time. Keep the existing item ID if it still identifies that combination correctly.
4. After the staging checks pass, apply the corrected link or resolver to the live exporter during the planned switch, keeping the previous configuration for reversal. Then regenerate the live hosted file or run the configured live submission. Confirm the resulting record still describes Blue, M at the example price of 29.99 EUR, and that the platform can retrieve the updated source. A saved setting or local preview alone is insufficient.
5. Check the processed item after the platform ingests the change. Confirm its destination status and landing-page selection, then inspect other combinations using the same mapping. If a separate account policy issue remains, follow that issue's repair and review workflow.

Keep the before-and-after record and the processed result as completion evidence. A falling rejection count is inconclusive if the affected products simply disappeared from the source; reconcile the intended item list as well as the status totals.

Keep contact, shipping and return pages accessible and accurate. Audit final product structured data too, following the structured data guide.

Connect Meta catalogues and website checkout

Build a feed against Meta's current catalogue specification and your chosen catalogue type. Similar field names do not make Google's requirements, identifier rules or accepted values identical to Meta's.

1. Create or select the catalogue in Commerce Manager and choose its data source.
2. Check stable item IDs, titles, descriptions, URLs, images, prices, currencies, condition and availability against Meta's current validation.
3. Set the supported fetch or synchronisation schedule and inspect processing errors.
4. If eligible, connect the Page and Instagram account and create the Shop presentation.
5. Organise useful collections around bestsellers, seasonal ranges or a shared use case, and complete the account's review and policy steps.
6. Test the complete handoff to your website on a phone.

Choose the shop, language and currency that supply each Meta catalogue deliberately. Preview a translated combination and a sale item before a bulk export. Do not assume a Google-specific exporter also provides a Meta feed: confirm that the connector or template implements the selected Meta catalogue specification.

If Commerce Manager offers website checkout for your account, test the handoff through to an actual order and payment on your store.

Check current country, business and account eligibility in Commerce Manager. Do not promise a review deadline. Configure any requested checkout URL through your actual PrestaShop integration; another platform's checkout path is not a PrestaShop endpoint.

Keep catalogue IDs consistent with Pixel and Conversions API content IDs when using catalogue event matching. Include combination scope where required. Product approval rate and event-to-catalogue match rate are different measures.

For a catalogue matching fault, compare an actual product-view event's content ID with the exact item ID in Commerce Manager. For events with content_type=product, content IDs must match catalogue item IDs; events with content_type=product_group match the catalogue's item_group_id instead, so a parent-product ID can be intentional. Check the event's content type before changing the mapping. Separately check that browser and server reports of the same purchase use matching event names and event IDs; matching a product does not deduplicate a sale.

Pixel and CAPI serve measurement and selected advertising uses. They are not both prerequisites for every campaign objective or for merely creating a catalogue. Connect their data collection to the applicable consent rules. See the analytics guide.

Make the destination product page and checkout usable, with accurate offers, appropriate guest checkout and a working mobile payment path. Adding tracking parameters must not change the selected item or break the URL. Rehearse a Shop referral in the Facebook or Instagram in-app browser on a phone: preserve the selected combination through any redirect, verify the advertised price and delivery offer, and follow payment through to the resulting PrestaShop order.

Keep a practical catalogue review routine

• Compare selected product and variant records with the public landing page and checkout.
• Check export and platform last-success times and changes in item counts.
• Review Needs attention and Commerce Manager issues after imports, promotions or URL changes.
• Check languages, currencies, countries and shop context separately.
• Test newly generated images and changed shipping policies.
• Measure clicks, valid purchases, margin and campaign cost without assuming that feed edits caused every change.

For multiple markets, use sources or targets that preserve supported language, offer and shipping combinations. Separate feeds can simplify operations, but they are not universally required for every country. Keep source ownership clear so two integrations do not overwrite each other.

Rehearse the switch and agree the handover

Build the acceptance set from your own catalogue: a simple item, a combination with its own barcode, an active discount, a zero-quantity orderable item, an excluded product and an offer for each intended market. Keep the expected item ID, link, price, currency, availability and image beside each case. Include a product with special characters to expose serialisation or escaping errors.

1. Save the current exporter settings, source rules, schedules and item mapping. Agree which account and data source the replacement will update, and how updates and removals will be reversed if the switch fails.
2. Compare the acceptance set on staging and investigate unexpected count changes before submitting the full catalogue. Check that test exports contain the intended shop domain and that production output will use live product URLs.
3. Agree a switch window around imports and promotions. When the replacement takes ownership, stop the previous writer for the same offers so it cannot overwrite the new values. Preserve unrelated sources and supplemental rules that are still needed.
4. Verify a live generation or submission, platform ingestion and the processed acceptance set. Check the next scheduled run too; a successful manual export does not prove the scheduler works.
5. Hand over the evidence, alert destination and recovery instructions. Name the person who will inspect a failed job or changed rejection count, and state which failure should trigger the agreed reversal.

If you have chosen the module and want the agreed configuration installed and checked, the PrestaShop Module Installation & Configuration Service covers that setup; licences, additional modules and development are separate.

What to ask your developer or agency

• Which installed module release, theme and market contexts passed the acceptance set, and where is the evidence?
• Which source owns each field, including supplier imports, supplemental overrides and automatic updates?
• How do staff see a failed export, expired credential, fetch error or unexpected removal, and who responds?
• Which account, scheduler and credentials does the business control, and how will access be handed over if the maintainer changes?

Questions owners ask

Can I send only part of my catalogue?

Yes, use deliberate product selection for the intended destination and check it after catalogue imports. Exclude offers that cannot be bought under the advertised terms, such as a quote-only item without a purchasable public offer. Keep a record of intentional exclusions so staff can distinguish them from missing exports.

Does a product feed need customer or order data?

A product feed describes offers. Keep customer records, order exports and authentication credentials out of its public content. Purchase measurement is a separate integration with its own access and consent controls.

Can I pause paid adverts and keep free listings?

Pause the paid activity through the campaign controls and check free-listing participation separately. Removing a shared data source can disrupt destinations you still intend to use, so do not delete the catalogue just to stop advertising spend.

Should I compare title changes across the whole shop at once?

Keep a before-and-after export and change a defined product group first. Compare eligibility, impressions, clicks and valid purchases for the same offers while noting price, stock, budget and campaign changes. Treat the result as evidence for that group rather than a promised uplift for every product.