Choose an AI search audit when the problem appears on the store. Choose a product feed audit when the problem lives in a catalog file or export.

That sounds simple until a wrong price, missing product code, or unclear option appears in both places. The useful question is not which audit sounds broader. It is which source can show where the first confirmed break occurs.

If you are unsure, start with the customer-facing product page. It can reveal whether the store is reachable, whether visible facts match the information built into the page, and whether the next check needs private product data.

What an AI search audit checks

A site-focused audit checks what a shopper and an AI search tool can reach on the public store. It looks at product titles, prices, stock, options, product codes, images, seller details, and policy links. It also compares those visible facts with the structured product information built into the page.

This is the right starting point when a product page looks incomplete, a search tool shows an unexpected fact, or the store may be blocking important crawlers. The result should separate a confirmed merchant issue from a scan limit. A page the scanner could not retrieve is not proof that the page is defective.

  • Can important product and policy pages be reached?
  • Do visible and structured price, stock, and product facts agree?
  • Are sizes, colours, and other options understandable?
  • Can the seller and applicable policies be found?
Visible product pageSame product facts
Structured dataSame product facts
Source catalogSame product facts

What a product feed audit checks

A feed audit starts with a merchant-owned product file, such as a CSV, JSON, XML, or text export. It normalizes the submitted records into a consistent product model, then checks for missing, invalid, conflicting, or target-specific values.

This is where product codes, parent and child relationships, prices, stock values, image links, categories, attributes, regions, and inferred fields can be reviewed record by record. The result describes the submitted sample. It does not prove that the storefront or every external channel is ready.

  • Missing or invalid required fields
  • Broken option grouping or duplicate records
  • Price, currency, and stock normalization
  • Target-specific conversion failures
  • Values that were inferred and need merchant review
Source catalog
Clean feed
Readable store
Pathway fit

Use the location of the symptom as your first clue

If a shopper can see the wrong price on the product page, begin with the store. If the public page is correct but a submitted channel file carries the wrong price, begin with the file. If both are wrong, look upstream for the source that publishes to both places.

One example is a size option that exists in Shopify but disappears from a marketplace export. The public product page may model the option correctly while the export flattens every size into one row. That is a product-data mapping problem, not a page-markup problem.

One symptom can cross several systems

A wrong fact on a channel does not automatically mean the channel feed caused it. Confirm the first place where the fact becomes wrong.

Choose the smallest check that can answer the question

Use Site Scanner when the public store is the unknown. Use Catalog Scanner when you already have a representative product file and want field-level evidence. If the public symptom is credible but its origin is still unclear, a cross-channel root-cause audit can compare one store, one source export, and one selected feed or market.

The order matters. A quick public check can prevent unnecessary feed work. A file check can prevent unnecessary theme work. A deeper investigation should follow only when the earlier evidence cannot identify the correction owner.

Sources Checked