Product feed – how to optimise it for Google Shopping

The product feed is, in practice, a database on the basis of which Google recognises what your product is and whether it can safely display it in Google Shopping. Not only product approval depends on the quality of the feed, but also how well it matches queries and how convenient it is to run campaigns later on. Day to day, work here centres on specific fields: titles, prices, availability, images, identifiers and categories. Even a technically correct feed can perform only averagely when the data is incomplete, inconsistent or written in the store’s language rather than the customer’s. Good optimisation therefore is not just about “sending a file to Google”, but about organising the data and continuously controlling its quality. This is an operational task that has to be managed alongside changes in the store, prices and assortment.

Product feed optimisation: basics and importance

Product feed optimisation is a set of activities involving improving the data sent to Google Merchant Center so that products are approved correctly, interpreted accurately by Google and genuinely useful in product campaigns. It is not only about meeting technical requirements, but also about ensuring the feed supports matching the product to the user’s intent. In practice, this means working on the data source, attribute mapping, product content and consistency of information with what appears on the store website.

The three most important areas are compliance with Google’s requirements, data completeness and their quality from a business perspective. A product may have all mandatory fields filled in and still perform poorly if the title is too generic, the image is not very clear, and the identifiers are incorrect or empty. The mere absence of errors in Merchant Center does not yet mean the feed has been prepared to support sales.

Google compares the feed with the product page in the store, which is why data consistency is crucial. The price, availability, variant, currency and product condition should match between the feed and the landing page. Discrepancies in these fields end in warnings, disapprovals or unstable product serving.

Feed optimisation also affects the operational side of the campaign. Well-organised data make it possible to segment the offer sensibly by category, margin, season, bestsellers or price ranges. This makes budgeting, analysis and later optimisation decisions easier, instead of working with a random, disorganised set of products.

It is also important that the feed is not a “set once and forget” setting. A change in the category structure in the store, a new product template, different pricing logic or an integration update can break previously correct mapping. The feed is worth treating as part of the e-commerce process, which requires regular diagnostics and adjustments, rather than a one-off implementation.

Key attributes in the product feed

Key attributes in the product feed are the fields that determine whether the product will be approved correctly, whether Google will interpret it properly and how accurately it will be matched to queries. Individual fields have different weight, but several of them directly affect visibility and delivery continuity. When the foundations are incorrect, campaign optimisation usually does not remove the source of the problem.

• id — should remain constant and be unique, because Google uses it to recognise the product in subsequent updates.
• title — should name the product directly using the words the customer uses when searching.
• description — allows you to specify the product’s parameters and distinguishing features, although it is usually less important than a well-constructed title.
• link i image_link — must lead to the correct page and to the current, clear product image.
• price, sale_price, availability, condition — values must be up to date and consistent with what appears on the landing page.
• brand, gtin, mpn — are used for identification and help Google match the product correctly.
• google_product_category i product_type — organise the assortment, but fulfil slightly different roles.
• item_group_id oraz atrybuty wariantów — are necessary when the product comes in, for example, several sizes or colours.

The title is one of the key elements of the feed, because matching to a query most often depends on it. A structure built from the product type, brand and the most important features, such as model, size, colour, material or compatibility, works well. Less effective are internal store names, abbreviations that are unclear to the user and marketing additions that do not help identify the product unambiguously.

Product identifiers are particularly important wherever they can be provided without errors. GTIN and brand strongly affect whether Google can identify the product unambiguously, so their absence or incorrect values usually limit match quality. If a product does not have a GTIN, this should be reflected correctly in the data instead of entering random numbers just to fill the field.

Price, availability, page link and image build the credibility of the offer. These fields must be updated consistently, because even short delays between the store and the feed can cause problems in Merchant Center. The most common practical mistake is not the absence of a field, but inconsistent data between the feed and the product page.

Google category and your own product_type are not interchangeable. Google Product Category helps Google understand what the product is within its taxonomy, while product_type primarily supports your business logic and campaign segmentation. The best practice is to use both fields in parallel: one for Google classification, the other for managing the offer.

Variants are worth describing separately when they differ in features that are important from the point of view of purchase. Separate records for size, colour or capacity make it easier to match the offer to the query and maintain consistency with the product page. Mistakes in variants often end up mixing prices, images and stock levels, which quickly reduces the quality of the entire feed.

Feed optimisation process: implementation steps

Feed optimisation is methodical work that starts with a data audit and ends with ongoing monitoring after publication. To begin with, you need to verify the feed source, the way it is generated, and the state of diagnostics in Google Merchant Center. This is usually where the problems that genuinely block serving come to light: rejected products, empty fields, incorrect links, price mismatches and missing identifiers. First remove critical errors and rejections, and only then refine the quality elements.

The next stage is attribute mapping, i.e. assigning data from the store or ERP to the fields required and recommended by Google. This is the moment for key decisions: which values to pull through directly, which to calculate with rules, and which to supplement from an additional source. When mapping is weak, even correct data in the store will not make it into the feed in a useful form. This often happens with automated integrations that export “what is there”, rather than “what is needed”.

After mapping comes data cleansing and enrichment. You need to tidy up inconsistent brand names, correct price formats, make sure separate records exist for variants, and fill in missing fields such as brand, GTIN, MPN, condition or google_product_category. The feed should present the product in the way Google and the user recognise it, not in the way the store system describes it.

Next, you refine product content and the offer structure for campaigns. In practice, this means better titles, sensible product_type, the right division of variants, and the use of custom labels to mark margin, season, bestsellers or priority. This is not cosmetic work, but preparing the data so it can be managed efficiently on the campaign side and in performance analysis.

After implementation, it is worth checking the feed again, once it has been processed by Merchant Center. What matters is not only whether the products are active, but also whether any new warnings, compliance errors or a drop in the number of approved items have appeared. Any major change in the store, prices, availability or product template can throw off a previously correct feed. That is why optimisation does not end with implementation, but moves into regular maintenance.

The role of commercial attributes and their impact on results

Commercial attributes determine whether a product will be correctly approved, properly interpreted and genuinely useful in a campaign. In practice, this mainly concerns price, availability, product condition, brand, identifiers, category, variants and promotional information. When these fields are left incomplete or do not match the content on the product page, warnings, rejections or poorer matching appear. This is precisely the stage at which the difference between a feed that “works” and a feed that is “effective” is most often visible.

The greatest operational importance lies with price and availability, because they must match the landing page. Google checks this consistency, and even small discrepancies quickly lead to publication issues. This also applies to currency, product condition and the sale price. If price or availability changes faster than the feed is refreshed, the risk of errors rises immediately.

Brand, GTIN and MPN are also highly important, because they make it easier for Google to identify the product unambiguously. Their absence does not always stop serving, but it often lowers match quality and the ability to compare the offer. It is worth avoiding data added “for the sake of it”, because an incorrect GTIN can be worse than having none at all. For variants, item_group_id and the size, colour or material fields are also important, because without them Google may incorrectly combine or split the offers.

google_product_category and product_type serve different roles, so it is worth keeping them separate. The first field helps Google understand the product type according to its own taxonomy, while the second organises the offer on your side from a business perspective. This matters for campaign segmentation, reporting and budget control. Do not replace your own sales logic with Google’s category, because it will make campaign management harder later on.

Commercial attributes should also include sale_price, promotion information, shipping and custom labels. Not all of them affect query matching directly, but they clearly translate into easier offer and priority management. Custom labels do not improve Google’s understanding of the product itself, but they do let you quickly separate high-margin, seasonal or clearance products. Simply describing the product well is not enough if you cannot later split and control it sensibly in the campaign.

The most common mistakes and how to avoid them

The most common mistakes include data mismatches between the feed and the website, missing key identifiers, mediocre titles and poorly handled variants. These are the issues that most often end in warnings, rejections or poor matching of products to queries. Usually the problem does not concern a single field, but the whole flow of information between the store, the feed and Merchant Center.

The most expensive issue is inconsistency of price, availability, product condition or variant between the feed and the product page. Google compares this information and quickly spots discrepancies, especially when prices or stock levels change more often than the feed is refreshed. If the store updates data dynamically, the feed refresh schedule must keep pace with the real changes.

Frequent problems include missing GTIN, missing brand or incorrect use of identifiers. In practice, this results in weaker product recognition by Google and sometimes also limited serving. If an identifier exists, it should be passed in the correct format. If it does not exist, this needs to be handled in line with the logic of the given range, rather than entering random values.

The second group of errors consists of titles and descriptions written for the store’s naming convention, rather than for the way users search for the product. A name such as “Super deal model X” adds little if the user enters the brand, type, size or compatibility. The title should first and foremost identify the product unambiguously, and only then describe it. In practice, a fixed category-dependent scheme works best, rather than arbitrary manually created names.

Variants can be a source of many operational problems. If colour, size or another feature influences the buying decision, each variant should have its own record and a consistent connection within the group. Mistakes in item_group_id, colours, sizes or variant links mean the user sees a different product from the one they clicked on.

Many stores lower feed quality by placing too much trust in the automatic export. A plugin or integration usually transfers the data technically, but does not solve the issue of poor titles, irrelevant categories, empty images or inconsistent branding. A feed is worth treating as a working layer that often needs to be refined with rules, additional sources or adjustments on the store side.

A separate mistake is ignoring warnings because “the products are still showing”. Warnings can be an early signal that data quality is declining and that the next change will bring disapprovals. It is safer to remove problems while they are still small than to react only after the number of active products drops.

Monitoring and iteration of the product feed

Monitoring and iteration of the product feed come down to regularly checking diagnostics, data consistency and the impact of changes on the number of active products and campaign performance. This is not a one-off implementation, but ongoing management of data that changes alongside the store’s offer. Even a well-configured feed loses quality if no one monitors changes on the store side, prices, stock levels and the assortment structure.

The starting point should be Merchant Center. You need to monitor the number of active products, fresh disapprovals, warnings and attributes that are missing or marked as inconsistent on an ongoing basis. Diagnostics are not an add-on in the report, but a list of actions to be carried out. First remove errors that block serving, and only then address issues that affect match quality and campaign structure logic.

The product status alone is not enough. It is worth regularly comparing the feed with the live product page, checking the price, availability, image, title, variant and URL. This is particularly important after changing the product template, implementing a new integration, modifying promotion logic or rebuilding categories in the store.

Iterations should result not only from technical faults, but also from performance data. If products are approved but still generate little traffic or have a low impression share, it is worth reviewing the titles, Google category, images and segmentation method. Good iteration means refining those feed elements that genuinely affect visibility and campaign control.

In practice, a simple workflow works best: regular review of diagnostics, monitoring changes on the store side and periodic fixes within selected product groups. There is no need to rebuild the entire feed every day, but you do need to react quickly to a drop in data quality. For a larger assortment, it is also worth tracking bestsellers, seasonal products, high-margin items and listings that are often disapproved.

Documenting changes is a good standard. When you modify the title rule, the category mapping method or the price source, note the date and scope of the implementation. Without this control, it is later difficult to determine whether a problem results from a new rule, a change in the store or an error on the data source side.

The key is an operational approach. The feed should be maintained, tested and corrected continuously, not “set once”. This makes it easier to stay aligned with Google’s requirements, reduce the number of disapprovals and respond faster when the offer or store structure changes.