What is a product catalog audit?

"Audit" gets used for many things in an online store. Here it is not the SEO audit of the site, which crawls pages and looks at links, speed or redirects, or the warehouse stock count. It is the review of each product's data: the title, the brand, the identifiers, the attributes, the price, the availability, as you hold them in your product catalog and as they go out. It matters to you because that data is read at the same time by your product page, Google Merchant Center, the feed you send to ChatGPT and the assistants that recommend products, and an error in a template or an import repeats across hundreds of products at once.

What it checks

A catalog audit answers four questions, in this order, because each one assumes the one before.

Is the data there? This is the part that can be counted: catalog data coverage, fields with a value out of the fields that product should have. The destination supplies the list of fields. Merchant Center's specification splits them into required (if you don't send them, the product can't appear in ads or free listings), "depends" (on the product or the countries where it is shown) and optional.⁠^{[1]Google Merchant Center Help. Product data specification} OpenAI's feed for ChatGPT asks for nine required fields per row, and others only for specific uses.⁠^{[2]OpenAI, commerce documentation. Product feed specification: products}

Is the value usable? A filled-in field can be just as empty as a blank one. Merchant Center asks that a product that truly has no brand leave the field empty, and not accept values like "N/A", "Generic" or "No brand".⁠^{[1]Google Merchant Center Help. Product data specification} OpenAI asks not to use filler text such as null, unknown or n/a, except where unknown is expressly allowed.⁠^{[2]OpenAI, commerce documentation. Product feed specification: products} And identifiers have a format: an EAN code is a 13-digit GTIN.⁠^{[1]Google Merchant Center Help. Product data specification} This part needs per-field rules, and it is where an audit separates from a simple count.

Does it match everywhere? The same fact, the price for example, lives in the store's dashboard, on the page, in the structured data and in each feed. Google checks it: its crawler visits your product pages and compares the price in your feed with the one on the page or in the markup; if they don't match, the product can be rejected, and too many mismatches can lead to account suspension.⁠^{[3]Google Merchant Center Help. How to fix: Mismatched product price} For markup, Google also asks that it represent the main content of the page, that it not describe what the reader can't see and that it be up to date.⁠^{[4]Google Search Central. General structured data guidelines}

Does it reach the published page? Correct data in the catalog may not show up on the page because of the theme, an app or because it is added with JavaScript after loading. Checking that is publication verification, and an audit that leaves it out audits a copy, not what everyone else reads.

Google sums up well where the failures tend to be. In the Merchant Center specification it lists as common problems the wrong Google product category or GTIN, variant attributes that are missing or wrong (the group identifier, the color, the size), low-quality images and data that does not match between the feed and the site, and warns that they can keep your products from appearing in ads and free listings.⁠^{[1]Google Merchant Center Help. Product data specification} It is a good index to start the rules from.

Sample, rules and limits

What makes two audits comparable is not the tool, but three things written down before looking.

The rules. Each rule says what is checked, in which field, which products it applies to and where it comes from: from a destination's specification or from our own criterion, said as such. "The brand can't be 'N/A'" is a rule with a source; "descriptions have to be good" is not a rule until it says what good is.

The sample. Mechanical rules (whether a field is there, whether a GTIN has the right number of digits, whether the feed's price is the page's price) can be run over the whole catalog. The ones that call for judgment, such as whether a description describes the product or whether a photo shows it, run over a sample. The sample has to be repeatable: how many products, from which categories, how they were chosen. If only the best sellers go in, the result speaks for the best sellers.

The limits. The date of the export, the number of products, which destinations were looked at and what was left out. An audit run on Monday's export says nothing about what changed on Tuesday; that is what data drift is for.

The starting point is usually an export. In Shopify, from the products section of the dashboard, you can export to CSV all products or only those that match your search and filters.⁠^{[5]Shopify Help Center. Exporting products}

In a store

A mountain gear store with 1,200 products runs five rules over its full export. It is a fictitious example: the store, the counts and the failures are made up to show how the result is presented.

Three things the table shows. Each row has a source, so anyone can repeat it. Severity comes from what the destination says, not from an impression: availability that is missing or not recognized makes OpenAI reject the whole row,⁠^{[2]OpenAI, commerce documentation. Product feed specification: products} and a price that doesn't match can make Google reject the product.⁠^{[3]Google Merchant Center Help. How to fix: Mismatched product price} And there is no final grade: seventy-six failures across five rules say exactly what to fix first, while a "72 out of 100" says nothing of the kind.

How to check it

1. Export the catalog to CSV from your store's dashboard and note the date.⁠^{[5]Shopify Help Center. Exporting products}
2. Choose the destinations and copy their field lists: the Merchant Center specification and the OpenAI feed's, each with its requirement level.⁠^{[1]Google Merchant Center Help. Product data specification}⁠^{[2]OpenAI, commerce documentation. Product feed specification: products}
3. Write the rules before looking at the data, one per line, with their source and severity. Start with the problems Google lists as common.⁠^{[1]Google Merchant Center Help. Product data specification}
4. Run the mechanical rules over the whole catalog and the judgment ones over a sample you can repeat.
5. Open the published page for a few products with a failure and a few without and compare the price, availability and markup with the export.⁠^{[3]Google Merchant Center Help. How to fix: Mismatched product price}⁠^{[4]Google Search Central. General structured data guidelines}

Related concept: catalog data coverage

Catalog data coverage is a figure: what share of the applicable fields has a valid value. The catalog audit is the whole exercise, and coverage is only its first question. A store can have high coverage and a bad audit, for instance with every price filled in and six that don't match the page. Coverage says how much is missing; the audit says what is wrong, where and what to fix first. And neither tells you whether, after you fix it, you get cited more: that is measured outside the store, with a citation rate in a dashboard or with the search engines' reports.

To go further, the guide to auditing a product page goes down to the detail of a single page, and the measurement and verification reading path orders the rest of the terms.