The storefront is crawling, the catalog pages load half their products, and System > Index Management is a wall of orange “Reindex Required” statuses. A merchandiser swears the SKUs are in stock, the price rules look fine, and cron is running. This is where most Magento 2 indexing problems land in a developer’s lap, and the cause is almost never random. It is usually an index mode, a misconfigured rule, or a known bug with a known fix.
This guide walks through how Magento 2 indexing actually works, the two index modes, the full list of indexers, how to reindex from the admin and the command line, and the specific known issues we have debugged on production stores, with the fixes that resolved them. If you are weighing whether the platform is still worth investing in, the data in is Magento dying gives useful context before you commit engineering time.
🚀 Quick takeaway
Most Magento 2 indexing problems trace back to three things: the wrong index mode for the store’s data volume, misconfigured catalog price rules, or a known indexer bug already patched by Adobe. Fix the mode first, then the rules, then the bug.
Overview
- Magento 2 indexing transforms raw catalog, price, and inventory data into flat tables so the storefront reads fast instead of computing values on every request.
- There are two index modes, update on save and update by schedule, and choosing the right one is the single biggest lever on reindex stability under load.
- The most common production issues, products dropping out of categories, slow catalog rule reindex, and slow configurable price reindex, all have documented causes and fixes.
What is Magento 2 indexing?
Magento 2 indexing is the process of collecting catalog, pricing, and inventory data and writing it into optimized index tables that the storefront can read directly. Instead of recalculating prices, stock, and category membership on every page request, Magento reads the precomputed result, which is what keeps category and product pages fast at scale.
Each indexer watches a specific data domain. When source data changes, that data needs to be reflected in the index tables before shoppers see it. How and when that happens depends on the index mode, which is the part most teams get wrong.
Index modes: update on save vs update by schedule
Magento 2 has two index modes, and the difference between them decides how much load reindexing puts on your server and how fresh your storefront data is. Update on save rewrites the relevant index tables immediately whenever data changes, so the storefront is always current but every save carries the reindex cost in real time. Update by schedule batches those changes and processes them through cron, using MySQL triggers and the Mview changelog to track only what actually changed (Adobe Commerce Developer documentation).
For any catalog beyond a few hundred SKUs, update by schedule is the safer default. It spreads reindex work over cron runs instead of blocking an admin save or an API import, and it is the mode that keeps large stores responsive during bulk updates.
This default has moved in Adobe’s direction. As of Magento 2.4.8, new indexers default to update by schedule, and the Customer Grid indexer now supports both modes, defaulting to update by schedule where it was previously update on save only (Adobe Commerce Developer documentation). If you are on an older version, this is a setting you should verify rather than assume.
🚀 Quick takeaway
Update on save reindexes immediately and adds real-time server load. Update by schedule batches changes through cron and is the right choice for most production catalogs. Magento 2.4.8 makes update by schedule the default for new indexers.
What are the main Magento indexers?
Magento 2 ships with a set of core indexers, each responsible for one slice of storefront data. Knowing what each one does makes it far faster to diagnose which index is behind a given symptom.
- Category Products and Product Categories: map which products belong to which categories and the reverse, driving category listing pages.
- Product Price: precomputes final prices, including catalog price rule results, per customer group and website.
- Product EAV: indexes filterable and searchable product attributes.
- Stock: reflects inventory status so out-of-stock logic and salable quantity stay accurate.
- Catalog Rule Product: applies catalog price rules to the products they target.
- Catalog Search (Catalog Search Fulltext): builds the search index the storefront search reads from.
- Customer Grid: keeps the admin customer grid current.
When a storefront symptom appears, it almost always maps to one of these. Missing products in a category point to the category and product indexers. Wrong prices point to Product Price or Catalog Rule Product. Stale search results point to Catalog Search.
How to reindex in Magento 2 (admin and CLI)
You can reindex from the admin or the command line. From the admin, go to System > Index Management, select the indexers showing “Reindex Required”, choose the action and mode, and submit (Adobe Commerce admin documentation). This is the quickest route for a one-off fix when you do not have shell access.
For real control, use the command line. The core indexer commands available in current versions (2.4.7 and later) are:
bin/magento indexer:info
bin/magento indexer:status
bin/magento indexer:reindex
bin/magento indexer:reset
bin/magento indexer:show-mode
bin/magento indexer:set-mode {realtime|schedule}
bin/magento indexer:set-statusHere realtime is update on save and schedule is update by schedule (Adobe Experience League, Manage the indexers). To switch every indexer to schedule mode, run bin/magento indexer:set-mode schedule, then confirm with indexer:show-mode.
On large catalogs, parallel reindexing cuts full reindex time significantly. It is controlled by the MAGE_INDEXER_THREADS_COUNT environment variable, for example MAGE_INDEXER_THREADS_COUNT=3 php -f bin/magento indexer:reindex catalogsearch_fulltext. Parallelization is enabled by default for the Catalog Search Fulltext and Category Product indexers when PHP Process Control is available (Adobe Experience League indexer documentation). When reindex repeatedly fails or hangs despite correct mode and configuration, that is the point to bring in Magento support rather than keep restarting cron.
🚀 Quick takeaway
Reindex from the admin under System > Index Management for one-offs, or from the CLI with indexer:reindex for control. Use indexer:set-mode schedule to batch work through cron, and MAGE_INDEXER_THREADS_COUNT to parallelize large reindexes.
Known indexing issues and fixes
Beyond mode and configuration, a handful of issues come up again and again on production stores. These are the ones our team has diagnosed repeatedly, with the fixes that resolved them.
Products disappearing from categories during reindex
This shows up in older Magento 2 versions, where products briefly or persistently drop out of category pages while reindex runs. It happens for a few reasons: indexers that do not use a replica table to stage data before swapping it into the main table, older indexers that delete data from the index table before writing the new data without batching the work, and shared indexer processes such as category-product and product-category writing to the same table at the same time.
Adobe resolved these in the MDVA-30977 series of patches, which address shared indexes, add batching to the configurable inventory and price indexers, and add more replica usage. If you are seeing this on an older version, apply the patch series rather than working around the symptom.
Catalog rule reindex taking too long
Slow scheduled reindex of catalog rules is usually a sign of misconfigured rule conditions. Magento’s implementation produces a UNION call on the collection load for each individual condition added, so reindex performance degrades in proportion to the number of conditions on a price rule.
For example, instead of a single rule such as SKU is IN ..., ..., ..., teams sometimes build a long set of individual rules such as SKU is X, SKU is Y, SKU is Z, .... This is a common case, and we have seen too many conditions on price rules push an incremental scheduled reindex past half an hour, or many hours for a full reindex. Because the indexers share one cron group, a slowdown on one can delay or crash reindexing for the rest. Consolidating conditions into IN-style rules is the fix.
Configurable product price reindex taking too long
This happens when there are many stores and many variants on products. One known cause is a poorly formatted WHERE condition in the Configurable Price indexer, which hurts query performance when out-of-stock product display is turned on.
The method involved is:
Magento\ConfigurableProduct\Model\ResourceModel\Product\Indexer\Price\Configurable::fillTemporaryOptionsTableThe relevant conditions are:
if ($this->isConfigShowOutOfStock()) {
$select->join(
['si' => $this->getTable('cataloginventory_stock_item')],
'si.product_id = l.product_id',
[]
);
$select->where('si.is_in_stock = ?', Stock::STOCK_IN_STOCK);
}
// ...
if ($entityIds !== null) {
$select->where('le.entity_id IN (?)', $entityIds);
}That produces a SQL query with a filter like this:
WHERE (si.is_in_stock = 1) OR (si_parent.is_in_stock = 0) AND (le.entity_id IN (...)The grouping is wrong. Rewriting it so the OR is parenthesized correctly fixes the query:
WHERE ((si.is_in_stock = 1) OR (si_parent.is_in_stock = 0)) AND (le.entity_id IN (...))These issues are common and their fixes are uncomplicated, yet many developers leave them in place because they cannot tell where the slowdown is coming from. Knowing which indexer to look at, as covered above, is half the fix.
🚀 Quick takeaway
Three issues account for most production indexing complaints: products dropping from categories on older versions (fixed by the MDVA-30977 patch series), slow catalog rule reindex from too many rule conditions (fixed by consolidating into IN-style rules), and slow configurable price reindex from a mis-grouped WHERE clause. Each has a documented cause and a concrete fix.
Index management best practices
Once the known issues are out of the way, a few habits keep indexing stable in the long run. Run all indexers in update by schedule mode on production so reindex work batches through cron instead of blocking saves and imports. Monitor cron health, because update by schedule is only as reliable as the cron that drives it, and a stalled cron silently leaves indexes stale. Use parallel reindexing with MAGE_INDEXER_THREADS_COUNT for large catalogs so full reindexes finish inside a maintenance window.
Indexing does not live in isolation. A store that reindexes slowly usually has wider performance debt, and the fixes overlap, which is why our Magento performance optimization work treats index health as one input among database tuning, caching, and frontend delivery. On the frontend side, JS bundling addresses a different bottleneck that compounds with slow indexing on the storefront. For the broader operational picture, our guidance on keeping a Magento store stable puts index management in context with the other moving parts.
scandiweb runs one of the largest Magento-certified teams in the world, with 200+ Magento-certified developers and solution specialists who have debugged these exact indexing failures across hundreds of production stores. The patterns above are not theory, they are the recurring causes we resolve.
FAQ
How does indexing work in Magento 2?
Magento 2 indexing reads source catalog, price, and inventory data and writes it into flat index tables. The storefront then reads those precomputed tables instead of recalculating values on every request, which keeps category and product pages fast. Each indexer covers one data domain and updates either immediately or via cron, depending on its mode.
What are the index modes in Magento 2?
There are two: update on save and update by schedule. Update on save rewrites index tables immediately when data changes, adding real-time server load. Update by schedule batches changes through cron using MySQL triggers and the Mview changelog. Update by schedule is the recommended mode for production catalogs and is the 2.4.8 default for new indexers.
How do I reindex in Magento 2 from the admin?
Go to System > Index Management, select the indexers showing “Reindex Required”, choose the action and the index mode, then submit. This applies the reindex without shell access and is the fastest route for a one-off fix when you cannot reach the command line.
How do I reindex from the command line?
Run bin/magento indexer:reindex to reindex everything, or pass a specific indexer name to target one. Use indexer:status to check state, indexer:set-mode schedule to switch to scheduled mode, and indexer:reset to clear a stuck “working” status before reindexing again.
Why is my Magento reindex taking so long?
The usual causes are running in update on save mode on a large catalog, misconfigured catalog price rules that generate many UNION conditions, or a large number of store views and product variants stressing the configurable price indexer. Switch to schedule mode, consolidate rule conditions, and enable parallel reindexing to recover speed.
What is parallel reindexing in Magento 2?
Parallel reindexing runs index work across multiple threads, set by the MAGE_INDEXER_THREADS_COUNT environment variable. It is enabled by default for the Catalog Search Fulltext and Category Product indexers when PHP Process Control is available, and it shortens full reindex time on large catalogs.
Want indexing that just works under load, even during bulk imports and big rule changes? Fix your indexers with the most certified Magento team in the world.
Share on: