Few years back I got a message from a client that just said “the price is wrong, please fix asap.” Classic vague client message. I logged in, checked the product in admin, price was correct, saved it again just to be safe, refreshed the storefront… still wrong. Spent a good forty minutes convinced I’d somehow broken pricing logic before someone on a forum casually mentioned “did you reindex?” and I felt genuinely dumb.
That was my introduction to Magento indexing and honestly it’s one of those things nobody explains to you upfront, you just have to get burned by it once.
Okay but what is it actually
So Magento keeps all your product, category, pricing, whatever data in a normal relational database structure. Tables, joins, foreign keys, the usual. That’s fine for keeping data organized but it’s genuinely bad for speed when a customer’s sitting on your category page waiting for 200 products to load with prices and stock status.
Indexing is basically Magento pre-cooking all that data into flat, fast-to-read tables ahead of time so it doesn’t have to do a dozen joins on every single page load. Makes sense once you know it. The annoying part is that this “pre-cooked” data doesn’t update the instant you change something in admin. It updates when the indexer decides to run. And that lag is where 90% of the “why is my site showing wrong info” tickets come from, in my experience anyway.
The indexers you’ll actually run into
There’s a handful of them and you can list them out with
bash
bin/magento indexer:statusHonestly in day to day work I mostly deal with these:
- Product Price — this one’s the usual suspect for pricing weirdness
- Category Products — controls which products show in which category
- Product EAV — feeds into layered navigation filters
- Catalog Search — self explanatory
- Stock — inventory status
If someone tells me stock or price looks off, I don’t even open the code editor anymore, I just go straight to checking these two first.
Update on Save vs Update by Schedule (this setting matters more than people think)
You’ll find this under System > Index Management and it’s genuinely one of those settings people set once and forget exists.
Update on Save reindexes the moment you change something. Sounds great in theory right? Instant updates. Except I once watched a bulk import of like 4,000 SKUs basically crawl to a halt because every single save was triggering a full reindex in the background. What should’ve taken ten, fifteen minutes turned into over an hour. I remember just sitting there watching the terminal like it owed me money.
Update by Schedule batches everything and runs it through cron instead. This is what I use on pretty much every live store now, no exceptions really. It’s just better for anything with real traffic or bulk operations.
For my own local dev environment though I actually leave it on Update on Save, because I’m not importing thousands of products, I just want to see my change reflected immediately without thinking about cron.
When you just need to force it
Sometimes you don’t want to wait around, you just want it done now.
bash
bin/magento indexer:reindexThat hits everything. If you only need one specific indexer:
bash
bin/magento indexer:reindex catalog_product_priceAnd if something’s stuck or showing as “invalid” in the status output (which happens more than I’d like), reset it first then reindex:
bash
bin/magento indexer:reset
bin/magento indexer:reindexFair warning, on a big catalog this is not fast. I’ve had reindexes on larger stores take fifteen, twenty minutes easy. Don’t assume it’s frozen, just let it cook.
The mistake I kept making (yes, more than once)
Early on I’d make catalog changes and just… trust that the frontend would eventually catch up on its own. Which, fine, it does, if cron is actually running. If cron’s broken or misconfigured, which happens more often than you’d think especially after a server migration, nothing updates. Ever. Until someone notices.
So now whenever a client says something’s stale, before I touch anything else I check cron first:
bash
bin/magento cron:runMore times than I want to admit, the “indexing bug” was really just cron silently dying weeks earlier and nobody catching it.
Bottom line
If prices, stock, or category listings look wrong on a Magento 2 store, don’t go digging through code first. Check indexer status, make sure cron’s actually alive, and reindex manually if you need it fixed right now. Once it clicks that Magento’s doing this on purpose for performance, not because it’s broken, the whole thing stops being confusing and just becomes another thing you check first, like clearing cache.