Validating a Product Feed: Catching the Errors That Cost Listings

A product feed is the file a store sends to a shopping channel, a marketplace, or an advertising platform, listing its products with their titles, prices, availability, images, and identifiers. When the feed contains errors, the channel does not politely ask for corrections: it rejects or suppresses the affected listings, so products silently disappear from search results and advertising, and the store discovers the problem only when sales fall. The Product Feed Validator checks a feed you supply against the common requirements, reporting missing fields, malformed values, and inconsistencies, so errors can be fixed before submission rather than discovered from a sales report. It validates the feed text you supply; it does not submit the feed to any channel, and channel rules change, so a passing validation is a strong signal, not a guarantee of acceptance.

The most consequential fields are the identifiers and the availability data, because errors there affect whether a product can be listed at all. A missing or malformed product identifier, such as a GTIN, can prevent matching against the channel's catalogue, while a price that is missing, zero, or formatted with the wrong currency can cause rejection outright. Availability matters just as much: advertising a product as in stock when it is not leads to cancelled orders and account penalties, while marking a stocked product as out of stock removes it from sale for no reason. These fields deserve the first look in any validation report, before titles and descriptions, because a perfect title on a suppressed listing helps no one.

How it works

A validator parses the feed, whether it is XML, CSV, or another tabular format, and checks each product record against a rule set: required fields present, values in the expected format, prices numeric and positive, image addresses reachable in form, and category and identifier fields consistent. It typically groups findings by severity, distinguishing errors that will block a listing from warnings that may reduce its visibility, such as a short title or a missing optional attribute. The output is a list of affected products and fields, so the fix can be applied at the source, in the store's catalogue or feed generation, rather than patched in the feed file alone, where it would be overwritten at the next export.

How it works

Fixing at the source is the discipline that separates a one-time cleanup from a lasting improvement. A feed file is usually generated from a catalogue, so editing the file by hand fixes one export and leaves the next export broken in the same way. The correct workflow is to fix the catalogue data or the export mapping, regenerate the feed, and re-validate, confirming that the finding count falls to zero and stays there across exports. Keeping a short log of recurring findings, and the catalogue fields that caused them, turns validation from a chore into a catalogue-quality programme, which is what it should be.

Worked example

Worked example with sample values. Suppose a sample feed contains 200 products, and validation reports 24 findings: 8 products missing an image address, 6 products with a price formatted as text rather than a number, 5 products missing a GTIN, 3 products marked in stock with a price of zero, and 2 products with a title longer than the channel's limit. That is 8 plus 6 plus 5 plus 3 plus 2, which is 24 findings across 200 products, or 12 percent of products affected. Fixing the catalogue data and regenerating gives a second validation with 3 findings remaining: 2 titles still over the limit and 1 image address still malformed, which is a reduction from 24 to 3, or an 87.5 percent reduction, and the remaining 3 are fixed individually. These are sample values for illustration.

Worked example

The same example shows why severity matters more than the count. Suppose the 3 price-zero products are the store's best sellers, while the 8 missing images are slow-moving lines. By count, images are the bigger problem, but by revenue, the price errors matter far more, because a suppressed best seller costs more in a day than a suppressed slow line costs in a month. Reading the validation report by severity and by product importance, rather than only by finding count, is what prioritises the fixes correctly, and it is why a validator that groups findings by product is more useful than one that only gives totals.

Mistakes to avoid

One common mistake is validating once, at launch, and never again, while the catalogue changes daily and new errors creep in with every new product and every supplier import. Schedule validation before every submission, or automate it in the export pipeline, so a new error is caught in the same cycle that introduced it. Another is fixing the feed file instead of the catalogue, which guarantees the error returns. A third is ignoring warnings because they do not block listings, when warnings about thin titles or missing attributes quietly reduce visibility and click-through over months.

Mistakes to avoid

A further mistake is assuming that a feed that passes one channel's validation will pass another's, since each channel has its own required fields, formats, and limits. Validate against each channel's rules separately, and keep a per-channel checklist of the fields that differ, such as identifier requirements and title limits. Also avoid including test or internal products in a production feed, since a test product that reaches a channel can appear in search results, confuse customers, and, if purchased, create an order that cannot be fulfilled.

Putting it into practice

Add validation to the feed routine: generate the feed, validate it, fix the findings at the catalogue source, regenerate, and re-validate until the error count is zero, then submit. Track the findings over time to spot recurring catalogue problems, such as a supplier whose imports routinely lack identifiers, and address those at the import stage. A validated feed is not exciting work, but it is the difference between a catalogue that is actually for sale and one that merely exists in a file, and that difference is measured directly in revenue.

Related tools and reading: Related tools and reading: the Google Merchant Feed Optimizer and the Schema Markup Validator cover neighbouring needs that pair naturally with this one, and the guide at [/blog/google-merchant-feed-optimizer-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• Identifiers, price and availability errors suppress listings before titles matter
• Fix findings at the catalogue source, not by hand-editing the feed file
• Read findings by severity and product importance, not just by count
• Validate before every submission and separately for each channel

In short: i.dentifiers, price and availability errors suppress listings before titles matter

One habit ties all of this together: re-check after every change. A result is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.