What a feed file can be checked against

Google publishes several hundred pages of product data requirements. A file cannot prove all of them, and we do not pretend otherwise. What follows is the part that can be established from the file itself, plus the two areas that need one network request: the images and the robots rules. What a file cannot say is a separate page, on purpose.

Can we read the file at all

This runs before any value is looked at, because a value check on a badly parsed file is worse than no check: it is a confident answer about the wrong data. The delimiter is chosen by which one gives a consistent field count, not by which appears most often. Encodings other than UTF-8 are read and transcoded. A byte order mark is stripped before anything downstream sees it. XML is tested for well-formedness, for the Google namespace, and for the presence of item elements.

Where a file is ambiguous in a way that would move data between columns, the scan stops rather than guess. With the wrong delimiter, prices land in the availability field and every finding after that is fiction. Where rows are merely dropped, the count says so in plain numbers: a report on 48 of 50 products that presents itself as complete is the one failure a customer cannot catch, so it is the one we refuse to produce.

Prices and currency

Comma decimal separators, a missing currency code, and mixed thousands and decimal separators are all caught. The genuinely ambiguous case is stated plainly rather than guessed: 1.234 is 1234 in continental notation and 1.234 in English, and nothing in the file decides which. We refuse it rather than reprice a product by a factor of a thousand.

Beyond format, the scan reads the relationships between price fields: a sale_price in a different currency from price, a sale window with no sale price in it, a member or loyalty price sitting in the ordinary price field, and unit pricing measures drawn from a different family than the base measure, kilograms against litres. A price of zero is flagged only outside the cases Google actually allows it, such as a mobile device sold with a contract. The full reasoning is on the price and currency page.

Product identifiers

Every GTIN is checked against the GS1 mod-10 check digit, and the ones that can be repaired, an ISBN-10 to ISBN-13, a UPC-E to UPC-A, are repaired. The checks almost nothing else does are the restricted prefixes: a barcode with a correct check digit that Google still rejects because it begins 2, 02 or 04, or because it is a coupon prefix read off the zero-padded 13-digit form. That distinction matters: a 12-digit UPC-A beginning 98 normalises to 098, a perfectly legitimate company prefix, so the raw string is the wrong thing to test.

Excel's scientific notation (8,71234E+12) is caught, a missing brand is separated from a missing MPN because they satisfy different rules, and an identifier_exists: no that contradicts a supplied GTIN or brand-and-MPN is reported. The identifiers page works through why a valid-looking barcode gets refused.

Titles and descriptions

Promotional text that gets a product disapproved, free shipping, the word SALE, a percentage, a price in the title, is flagged. Over 150 characters is reported as a warning rather than a disapproval, because Google truncates and serves the product with its title cut off, which is a different and quieter cost. Shouting is de-capitalised without flattening real acronyms like USB, LED or XL. Descriptions are checked for HTML, for the 5,000 character limit, and for being too thin for Google to understand what the product actually is.

Stock, dates and availability

Dutch, French and German stock wording is mapped onto the four values Google accepts, and limited_availability, which no longer exists in file feeds, is retired. Availability is derived from a stock quantity column when the status field is empty. Every date field is held to ISO 8601, an expiration_date more than 30 days ahead is caught (the 30-versus-365 day confusion), and a sale_price_effective_date that is not exactly two dates, or whose end falls before its start, is reported.

Stock contradictions, in_stock with a quantity of zero, are reported rather than repaired. Which field is right depends on whether the shop or the warehouse is the authority, and a file cannot say. Guessing would either hide stock the merchant has or advertise stock they do not.

Variants and attributes

Hex codes and numbers in a colour field are caught; colours run together, ZwartWitGrijs, are split, but only when every segment is a recognised colour, so MidnightBlue is left as one colour. A pack quantity sitting in the size field (6-pack) is flagged, closed value lists for size_system, size_type, gender and age_group are enforced, and apparel variants that differ only on size or colour with no shared item_group_id are reported, so each size stops competing against its own siblings. A condition claim is only acted on when the merchant's own text states it without negation: "geen tweedehands" means the opposite and does not count.

Images, video and robots.txt

The main image of every product is actually fetched, sixteen at a time. A spreadsheet never shows you that 212 of 3,400 images return a 404, and that is the finding merchants react to. Each image is checked for its response, its pixel dimensions against both the current minimum and the 500x500 that becomes mandatory on 2027-01-31, its true format against the extension it claims, and megapixel and byte ceilings. Video links are validated for shape, including the common mistake of pointing at a page with a player rather than at the raw video file.

Then robots.txt is read, one request per domain, with three user agents checked separately: Googlebot, Googlebot-image and AdsBot-Google. This is a sample rather than exhaustive coverage: at most three domains and five landing-page paths per domain. The reason all three are checked separately is that AdsBot-Google ignores the wildcard group, which produces the single most confusing disapproval there is.

Shipping, returns and EU compliance

This is the part tools built for the US market tend to leave out. Shipping and returns are composite attributes whose sub-attributes live in the column header and whose values are positional, and both are validated against the syntax Google actually documents. A single item-level shipping price can switch off the account shipping settings for that location, so the scan raises a file-level note whenever one appears. Returns values are upper-case and closed, and a right value in the wrong case is reported with the case named as the cause.

On the EU side: unit pricing where the price indication directive is likely to apply, EPREL certification shape, and energy_efficiency_class restricted to CH, NO and GB since April 2025. In all, 15 composite attributes are supported, with content validation on 11 of them and 57 hard character and value limits declared from the constants rather than typed by hand.

Every one of these is a line in the full checks list, and the number at the top of that page is read from the code at build time. To see which of them your own file trips, run a scan.