If a legacy WooCommerce product widget shows the wrong bestsellers or ratings order, first confirm which widget is rendering and which product IDs it includes. Changing review scores to force the display into place can damage valid source data.
Identify the sorting source
WooCommerce 11.2 changed the legacy Products and Top Rated Products widgets to use product lookup data for sales and rating ordering. Stale lookup rows can therefore disagree with otherwise current product metadata. This is documented in the 11.2 developer advisories.
This guide is for those legacy widgets, not every Products block or a builder's custom query. Record the widget type, selected ordering, product limit and visibility settings. Use the catalog visibility guide when the issue is eligibility rather than sorting.
Build a three-product comparison
Choose three known products with clearly different relevant values. Record their IDs, published state, catalog visibility, stock status and the value you expect to determine their order. Avoid starting with tied ratings, where a secondary sort can hide the real issue.
Capture the displayed IDs in order on an uncached staging request. A title is not a reliable identifier when products have similar names. Compare that sequence with the widget's configured direction: ascending and descending are different tests.
Widget: Confirm legacy widget type. Sample: Three IDs without tied scores. Rebuild: Verify supported job completes. Future edit: New changes stay synchronized. Explanatory checklist, not a customer test result.
Locate the first disagreement
| Layer |
Compare |
Interpretation |
| Product eligibility |
Published, visible and permitted by widget filters |
Missing products may not qualify |
| Product source data |
Intended sales or rating value |
Confirm the business data is correct |
| Lookup data |
Matching product ID and derived value |
Divergence suggests a synchronization problem |
| Widget response |
Actual returned sequence |
Different order may be a query customization |
| Public page |
Same IDs after cache refresh |
Difference here suggests stale presentation |
Ask a developer to inspect lookup rows read-only, using the site's actual table prefix. Do not copy SQL from an unrelated site that updates all rows or assumes wp_ is the prefix. Keep backups before any repair operation.
Repair the data path, not the symptom
Use the supported WooCommerce data-regeneration tooling for the installed version when a lookup mismatch is confirmed. On a large catalog, plan for background work and verify that the job completes. Clicking a regeneration button is not evidence that every row has been rebuilt.
Afterward, compare the same three IDs again. If the values diverge immediately after a review or product update, trace the integration that writes the source data. A recurring repair job is a poor substitute for correcting an importer that bypasses the supported write path.
Once data and the uncached response agree, refresh only relevant page or widget caches. Retest logged-out output and the configured product limit. Do not clear unrelated sessions to repair a catalog-ordering problem.
Close with a reproducible result
Retain before-and-after ID sequences, the sorting setting and the successful regeneration result. Also test a new controlled review change on staging to ensure future updates stay synchronized. HandL WP can investigate the catalog data path when the order drifts again after a rebuild.
References reviewed October 16, 2026. Examples are explanatory, not customer test results.