Read the findings

How findings are grouped, what the severities mean, and why some products are deliberately not reported.

Reviewed 2026-09-15

Findings are grouped by check, then by product. That is the whole point of the screen: a product with two hundred variations missing a weight is one row, not two hundred.

Each check states what the fault actually costs you, not just what is missing. It says “shipping will be priced wrong”, not “weight is empty”.

Severities

Severity is about consequence, not about how many products are affected.

  • Error means the store loses money or the product cannot be bought. A shipped product with no weight is priced wrong on every order that contains it; a published product with no price cannot be added to a cart at all.
  • Warning means something will go wrong at fulfilment or in a product feed, but the sale can still complete. A missing SKU or GTIN is this.
  • Notice is worth knowing, but nothing breaks today. A virtual product carrying a weight usually means the product type is wrong.

Why some products are not reported

Several checks first ask whether your store uses that field at all:

  • Dimensions are only checked on stores that set dimensions somewhere. A store that prices purely by weight is never told its whole catalogue is broken.
  • SKUs, images, GTINs and categories work the same way, and SKUs are gated separately for products and variations because identifying parents but not variations is a normal way to work.
  • Shipping class is stricter still. Having none is correct on almost every product, so the check runs only where your rates charge per shipping class and set no cost for items without one, which is the configuration where an unclassified product adds nothing at all to the rate. Some product must also already carry a class; where none does, the fault is in your shipping settings rather than in the catalogue.

A variation that correctly inherits its parent’s weight is never reported.

Regressions

Findings are remembered between scans, and every product listed under a check carries a First seen date. That date is never moved, so a problem that was fixed and has come back is dated from when it first broke rather than from the scan that found it again. It reads as a regression, which is usually a sign that an import is overwriting good data rather than that somebody made the same mistake twice.

Still need help?

Tell us what you are trying to do and where you got stuck.

Contact support