Sorting Magento category pages by what actually sells

Say you sell outdoor gear. The Bags category was arranged when the range launched: the new flagship rucksack first, then the rest roughly by price. Two years later the flagship still sits in the top left corner, although it hardly sells any more. The second bag on the page has been out of stock for a fortnight. The backpack that sells best of all is on page three, because it was added later and nobody gave it a number.

Nobody decided this. The order simply stayed put while everything around it changed.

The short answer is that Magento shows category products in a fixed order that people set by hand, and nothing in Magento Open Source updates that order from your sales. To fix it you look at a few numbers per product, decide a new order and write it back into the category. You can do that yourself for a handful of categories. For many categories it becomes a job that never gets done, which is the gap our AI Merchandising module is built for.

How Magento decides the order today

Unless a shopper picks another sort option, a category page is sorted by Position. That is Magento's default for "Default Product Listing Sort By"¹. Position is a number stored for each product in each category (the position column of catalog_category_product, which defaults to 0)², and you edit it in the Products in Category section of the category. The other sort options are attributes marked for sorting, such as name or price. None of them looks at what sells.

Two details matter. Positions are global, so one order is used by every store view. And a product added without a number gets 0 like any other unnumbered product, so new arrivals end up wherever the tie happens to put them.

Adobe Commerce has more here. The Visual Merchandiser, for drag and drop and rule-based category assignment, is available only in Adobe Commerce and not in Magento Open Source³. With Live Search, Adobe Commerce also offers Category Merchandising, which can rank a category by, for example, what was purchased most in the previous seven days⁴. If you run Adobe Commerce with Live Search, try that first.

Why the order drifts, and what to look at

Stock runs out and comes back. Seasons change what people want. A product that looked good at launch turns out to be viewed a lot and bought rarely. Meanwhile the first row of a category is the most valuable space you have, and it keeps whatever you put there last time.

When you sort a category on purpose, these are the numbers worth having per product, over the same period:

• units sold and revenue (with the sales of a configurable product's options added up to the parent you show in the category);
• salable stock, so that products nobody can buy do not hold the first row;
• margin, which needs the Cost attribute filled in;
• views and conversion (orders per view), to spot products that get attention but not orders;
• age, so new products get a fair chance before they have sales.

Views are the one Magento may not have. The Reports module only records product views when reports are switched on, and that setting is off by default⁵ (Stores > Configuration > General > Reports).

Doing it by hand

For a small category this is honest, useful work. Pull sales for the last 90 days, check stock, look at the products on the first page and ask why each one is there. Put proven sellers that are in stock near the top, move out-of-stock products down, give one or two new products a visible slot, and type the new positions into the category. Write down the old order first, because Magento does not keep it for you.

It stops working when you have dozens of categories, configurable products whose sales sit on child SKUs, or a team that changes the range every month. The analysis takes long enough that it is done once a year, and by then it is out of date again.

What our module does

AI Merchandising does that analysis for one category at a time and shows you a proposal. Nothing on the storefront changes until you approve it.

For each product it collects units sold, revenue (net of discounts, excluding tax), orders, refund share, salable stock, margin from the Cost attribute (shown as "unknown" when there is no cost, never invented), views, wishlist and cart adds, conversion, age and current position, over 30, 60, 90 or 180 days. A score from 0 to 100 combines them with weights you can change (out of the box: units 30, revenue 20, margin 15, conversion 15, stock 10, newness 10). A few rules sit on top: out-of-stock products go last, new products get a boost while they are a minority in the category, products you pin stay where you put them, and no product is ever removed from the category.

The proposal page shows the current and the proposed order side by side, with badges such as Best seller, Low conversion and Out of stock, and a "Why here?" note for every product built from its numbers. It also lists findings: products with plenty of views and weak conversion, products without sales on the first page, best sellers below the first page. You can drag products, pin them and save your own order.

Before applying, Preview shows the first two pages as shoppers would see them, and gives you a link per store view that opens the real category page with the proposed order for one hour. Those preview pages are never stored in the full page cache.

Approve & Apply writes the order into Magento's own category positions, in one transaction, and keeps the previous positions. History lists every apply, and Revert restores the previous order exactly. We chose to write plain Magento positions rather than add a separate sorting layer, so the result works with any theme and is ordinary Magento data. You can also let it analyse chosen categories every night; new proposals then wait for review, and automatic applying is off by default.

The AI part is optional. The whole analysis works without it. If you switch it on (through our AI Core module, with your own Anthropic or OpenAI key), an anonymised summary of the category and its top products, 40 by default, is sent to the model. No customer data is sent, and margins only if you allow it. The model may adjust the order and write short notes. Its answer is checked strictly, and if anything is wrong the module falls back to the score order and tells you why.

Limits, and when you do not need it

Because positions are global, you cannot have a different order per store view; that is a Magento limitation. The "potential uplift" figure on the proposal page is an indicator of how much better strong products are placed, not a revenue forecast, and we make no promise about extra sales. Conversion needs Magento's reports switched on, and margins need costs. The order is the same for every shopper, not personalised. Applying to an anchor category assigns products from its subcategories to it directly (Revert removes them again), and very large categories with several thousand products make the proposal page slow.

If you have a few small categories that someone reviews every month, or you arrange a category on purpose to tell a story, a spreadsheet and the Products in Category grid are enough. The module earns its place when there are too many categories to look at regularly.

AI Merchandising is not on sale yet. We are testing it on our demo store at the moment.

Sources

1. Magento Open Source 2.4.9 source code, app/code/Magento/Catalog/etc/config.xml (default_sort_by is position), checked 10 October 2026. ↩
2. Magento Open Source 2.4.9 source code, app/code/Magento/Catalog/etc/db_schema.xml (table catalog_category_product, column position, default 0), checked 10 October 2026. ↩
3. Adobe Commerce Admin documentation, "Visual Merchandiser overview", https://experienceleague.adobe.com/en/docs/commerce-admin/marketing/merchandising/visual-merch/visual-merchandiser, checked 10 October 2026. ↩
4. Adobe Commerce documentation, "Category Merchandising", https://experienceleague.adobe.com/en/docs/commerce/live-search/live-search-admin/category-merch, checked 10 October 2026. ↩
5. Magento Open Source 2.4.9 source code, app/code/Magento/Reports/etc/config.xml (reports/options/enabled is 0), checked 10 October 2026. ↩