Check applicability is the part of Catalog Health Scanner for WooCommerce Pro that decides which groups of checks make sense for your store, so a flat-rate store is never marked down for missing product weights and a store with no product feed is never marked down for missing GTINs. Catalog Health Scanner detects the answer from your own WooCommerce configuration, shows you the reasoning, and lets you override it per group.
Where applicability lives #
Go to WPFactory > Catalog Health, open Settings, and find the Applicability panel. If the shared WPFactory admin menu is not present on your site, the plugin falls back to its own top-level Catalog Health menu and the same Settings screen sits under it.
The panel is a three-column table: the check group, the state you have chosen, and what auto-detect currently says about your store in plain language. Your choices are stored in the wpfchs_applicability option.
Each category tab also shows the same verdict inline, next to the category heading, with a Change link that jumps straight back to this panel.
The four states #
Every group can be in one of four states. Two of them are the interesting ones: Not applicable removes the group entirely, and Report, but do not score keeps the findings visible without letting them move your health score.
| State | Stored value | Checks run? | Counts toward the score? |
|---|---|---|---|
| Auto-detect (recommended) | auto |
Only if your store configuration says the group applies | Same as above |
| Applicable | yes |
Yes, always | Yes |
| Report, but do not score | report_only |
Yes, always | No |
| Not applicable | no |
No | No |
Why “report, but do not score” exists #
Some findings are genuinely useful to see but are not something you are ready to be judged on. Feed readiness is the usual example: you may want the GTIN and brand gaps listed so you can work through them before you launch a shopping feed, without those gaps dragging the headline number down in the meantime. Set the group to report_only and the checks keep running, the issues keep appearing in the category tab, and the category shows Reported, not scored next to its heading. Nothing from that group reaches the score arithmetic, and it cannot trigger the critical score cap either.
The groups and what auto-detect looks at #
Eight groups can be switched. Everything else (purchasability, media, structure, content, and the non-cost pricing checks) always applies to every store and is always scored.
| Group | Key | Signal auto-detect uses |
|---|---|---|
| Inventory & stock | inventory |
Store-wide stock management (woocommerce_manage_stock) is enabled. |
| Shipping weight & dimensions | shipping |
At least one enabled shipping method in any zone is not flat rate, free shipping, or local pickup. Anything else (table rates, weight-based rules, carrier calculators) is assumed to need weight or dimensions. |
| Tax | tax |
Tax is enabled and more than the standard tax class exists. |
| Downloads | downloads |
At least one product has _downloadable set to yes. |
| Product feed readiness | feed |
A known feed plugin is active (Google Listings & Ads, Woo Feed, WooCommerce SEA, Rex, and similar), or a feed identifier meta key such as _global_unique_id, _alg_ean, or _wpm_gtin_code is populated on any product. |
| Cost of goods & margin | cog |
Cost data is present on at least one product (_alg_wc_cog_cost or _wc_cog_cost). |
| Product reviews | reviews |
Reviews are enabled store-wide (woocommerce_enable_reviews). |
| FAQ / Q&A content | faq |
Always applicable under auto-detect. Question-and-answer content on a product page is useful on any store, so there is no configuration signal to read. |
Category tabs map to these groups by name, so the Inventory, Shipping, Tax, Downloads and Feed Readiness tabs follow the group of the same name. The cog group covers the three cost and margin checks inside the Pricing tab, and reviews and faq cover one check each inside the Content tab, which is why those two tabs can be part scored and part report-only.
The setup wizard only asks about five of the eight #
The five-question setup wizard covers shipping, feed, cog, downloads and tax. Those are the groups where a store owner’s answer is likely to differ from what the configuration suggests, and each question arrives pre-answered with the auto-detect verdict. If your answer matches what was detected, the group is left on Auto-detect rather than being frozen into a manual override, so it keeps following your store as your store changes.
The other three, inventory, reviews and faq, are never asked about. They start on auto-detect and stay there until you change them on the Settings screen. That is not an oversight: stock management and reviews are unambiguous store-wide WooCommerce settings, and the FAQ group applies everywhere. If you want any of the three in a different state, the Settings panel is the only place to set it.
The detection cache #
Auto-detect answers are cached for one hour in the wpfchs_autodetect transient. That keeps the settings screen and every scan from re-running the same product probes over and over on a large catalog.
The cache is cleared automatically when you save settings, when a scan starts, and when a scan completes, so you should never have to wait an hour to see a configuration change reflected. If you change something outside the plugin, for example enabling a weight-based shipping method, and the Applicability panel still shows the old reasoning, save the settings once to force a refresh.
Overriding a group #
- Go to WPFactory > Catalog Health > Settings.
- In the Applicability panel, read the third column to see what auto-detect concluded and why.
- Change the dropdown in the second column for any group you want to control by hand.
- Click Save settings.
An override is absolute: Applicable runs and scores the group even when your store shows no sign of needing it, and Not applicable skips it even when auto-detect says otherwise. Leave a group on Auto-detect and it keeps following your store as your store changes.
Applicability is not the same as disabling a check #
Three different controls silence findings, and they are not interchangeable:
- Applicability works on a whole group and reflects a fact about your store. It is the right tool for “weights are irrelevant here”.
- Individual checks (the tick boxes below the Applicability panel, stored in
wpfchs_disabled_checks) turn one check off everywhere. Use it when you disagree with a single rule. - Ignore silences one check on one product, and nothing else.
All three leave the score honest in their own way: a non-applicable or report-only group leaves both sides of the score fraction, a disabled check does the same, and an ignored issue counts as passing and is declared next to the score. See how the health score is calculated for the arithmetic.
Partial applicability inside an applicable group #
Group applicability is the coarse filter. Individual checks then decide, product by product, whether they have anything to say. A check that does not apply to a product is not a pass and not a failure: that product is simply not counted for that check, on either side of the fraction.
| Checks | Only run on |
|---|---|
| Missing weight, missing dimensions, missing shipping class, implausible weight | Physical products (not virtual, not downloadable) |
| Virtual product with dimensions | Virtual products |
| Downloadable not marked virtual, and every Downloads check | Downloadable products |
| Variation SKU missing, attributes not used for variations, invalid variation attribute, variation count mismatch | Variable products |
| Invalid grouped children | Grouped products |
| Category not in a navigation menu | Stores that actually put product categories in a WordPress menu |
This is why a store of 500 downloadable products can have a perfect Shipping score without a single shipping field filled in: none of those products were ever asked the question.
Changing applicability recalculates your history #
If applicability only affected new scans, your trend line would break every time you changed it: the drop or jump would look like a change in your catalog when it was really a change in the ruler. Catalog Health Scanner does not do that.
When you save the Settings screen and the applicability states have changed, every completed scan is recalculated from the counters it recorded at the time, using the configuration you just saved. Nothing is re-scanned and no product data is touched: the raw “checked” and “failed” numbers each scan stored are simply re-scored under the new rules.
Scans whose score actually moved are marked. On the History tab their score carries a small *, with a tooltip reading “Recalculated after an applicability change; the trend stays comparable.” The original score is kept alongside the new one in the scan record, so the marker is a statement of fact rather than a quiet rewrite. See scan history and comparison for the rest of that screen.
Recalculation only touches scans whose stored counters still exist and whose score changed by more than a rounding margin. A scan that the new configuration does not affect is left exactly as it was, with no marker.
Developer hooks #
| Filter | Purpose |
|---|---|
wpfchs_applicability_resolve |
Final say on a group: receives applicable, scored, reason, source. |
wpfchs_applicability_auto_detect |
Overrides one auto-detect verdict and its reason before it is cached. |
wpfchs_dimensionless_shipping_methods |
Shipping method ids that never need weight or dimensions. |
wpfchs_feed_plugin_signals |
Class names and constants that identify a product feed plugin. |
wpfchs_feed_meta_keys |
Product meta keys that count as a populated feed identifier. |
More hooks are listed in the developer reference.
Need help? #
If a group is being detected in a way you cannot explain, or a check is running on products you expected it to skip, contact WPFactory support with a screenshot of the Applicability panel.