Why Spotlight keeps reindexing after every macOS update (and how to stop it)

You install a .x.0 release on Sunday night. Monday morning your Mac is warm, the fan is on, and Activity Monitor shows mds_stores near the top of the CPU list. Tuesday it is still there. The internet says "this is normal after an update", and that is half true — but only half. Spotlight does reindex after macOS upgrades by design. It is not supposed to take a week. And if the rebuild finishes but Spotlight returns empty results, the failure mode is different again — see Spotlight returns no results on Tahoe — fix.

This guide explains exactly which steps of an upgrade trigger a rebuild, how long each step should take in 2026, and when an extended rebuild is a real bug instead of patience-required behaviour.

What the upgrade actually does to Spotlight

macOS .x.0 releases ship new versions of the per-format importers — the small executables that extract metadata from PDFs, images, source code, mail messages, and the rest. Because the importer's schema can change between releases, the safest behaviour is to throw out the existing index and rebuild it. macOS does this automatically on first boot after the upgrade.

Point releases (.x.1, .x.2) usually do not trigger a full rebuild, but they can if a specific importer changed. The indexer's logic is conservative — when in doubt, rebuild.

Apple does not publish a per-release list of which importers changed. The community thread on MacRumors tracking Tahoe 26.0 beta-to-release changes keeps a running list of observed Spotlight behaviour, including which point releases triggered rebuilds in the wild.

How long it should take in 2026

A few rough benchmarks from machines I have access to or have seen reported:

M2 MacBook Air, 8 GB RAM, 256 GB SSD, lightly used: 15–30 minutes after a .x.0 upgrade.
M3 Pro, 18 GB RAM, 512 GB SSD, developer's machine with ~150 GB of code: 1–2 hours, mostly background.
M3 Max, 64 GB RAM, 2 TB SSD, content creator with large media library: 2–4 hours.
Intel Mac (any spec, still supported by Tahoe 26): noticeably longer; sometimes 4–8 hours.

If your numbers are inside those ranges, you are not seeing a bug — Spotlight is just doing its post-upgrade work. Plug into power, do not put the machine to sleep, and check back later.

If your machine has been chewing for more than 24 hours after a .x.0 upgrade, or more than a few hours after a point release, something has gone wrong upstream.

How to tell what stage it is in

mdutil reports per-volume status:

mdutil -s /
mdutil -s /System/Volumes/Data

Output you want to see:

Indexing enabled. — the volume is enabled for indexing. Good.
Indexing and searching enabled. — same plus the search side is up. Good.
Indexing in progress. — currently rebuilding. Expected after an upgrade.

Output that means something is off:

Indexing disabled. — somehow the volume's indexing got turned off, probably by you or by a previous failed rebuild. Re-enable with sudo mdutil -i on /.
"Indexing in progress" for more than 24 hours after a .x.0 — the rebuild is stuck. Move to the diagnosis steps below.

For more detail, watch what mds_stores is actually doing:

sudo log stream --predicate 'process == "mds_stores"' --info | head -40

If you see the same file or directory mentioned repeatedly, that is your culprit.

The three reasons a post-update rebuild gets stuck

Reason 1 — A single importer crashes on a specific file.

A PDF with an unusual font table, a video with a malformed codec header, a corrupted .pages document — any of these can crash the importer, get retried by the daemon, crash again, and turn the rebuild into an infinite loop. You find the file by tailing the log:

sudo log stream --predicate 'process == "mdworker_shared"' --info | grep -i error

When the path appears, move the file out of any indexed directory (or add the containing folder to Spotlight Privacy). The rebuild resumes immediately.

Reason 2 — A Privacy exclusion got dropped during the upgrade.

This is the most common cause in 2026. Major upgrades occasionally lose the Spotlight Privacy list, so a folder you excluded years ago — your node_modules-heavy dev tree, your Time Machine target, an external drive — is suddenly back in scope. The daemon happily starts indexing it, and you see a multi-hour rebuild followed by a multi-day re-import.

Check the list at System Settings → Spotlight → Privacy. If it looks shorter than you remember, you are probably in this case. Re-add the missing exclusions and the rebuild calms down within minutes.

Reason 3 — A new macOS version shipped a real bug.

This is what Michael Tsai's Spotlight running notes documented across multiple Sequoia point releases. Apple's own discussions thread collects user reports continuing into Tahoe 26 betas. When this is the cause, no amount of path exclusion will fully fix it — Apple has to ship a patch in the next point release.

The honest workaround in this case is to wait for Apple while keeping your daily workflow off the broken indexer. Excluding the noisiest paths reduces the symptom. A second launcher with its own index removes you from the symptom entirely.

How to force a clean rebuild from scratch

If you have audited Privacy, killed the stuck importer's input file, and the indexer is still flailing, the next step is a full clean rebuild:

sudo killall mds
sudo rm -rf /.Spotlight-V100
sudo mdutil -E /

This wipes the on-disk index folder at the volume root and triggers mds to rebuild from a clean state. Expect another hour or two of CPU. After it completes, run mdutil -s / again — you should see "Indexing enabled" with no "in progress" suffix.

OSXDaily's Spotlight fix-it guide documents the same sequence as the canonical recovery path on Sequoia, and it still applies on Tahoe 26.

Surviving a re-index without losing the day

Spotlight rebuilds are bad enough as a background load — they are worse when they break your daily launcher. A few mitigations:

Time the upgrade for a quiet window. Friday night or Saturday morning, plugged in, lid closed. By Sunday it is settled.
Don't depend on Spotlight as your only search. If your project tree lives somewhere indexed by Spotlight and you need it searchable today, install ripgrep and use that — rg "needle" ~/Developer is faster than a busy Spotlight on any machine.
Keep a second launcher. CmdSpace runs its own local Rust-backed index that is independent of mds. While Spotlight is rebuilding, CmdSpace keeps finding files at sub-25ms. It is $29 one-time, with a 60-day free trial; see our Spotlight-to-CmdSpace guide for the rebind. The same principle applies to Alfred, Raycast, Quicksilver — any launcher with its own index keeps working when mds does not.

What I do personally

On every .x.0 upgrade, in this order:

Upgrade Friday night, leave the machine plugged in.
Sunday morning, check mdutil -s / and mdutil -s /System/Volumes/Data. If both say "enabled" without "in progress", I move on.
If either still says "in progress" Sunday evening, I tail the mdworker_shared log for 60 seconds and look for repeated errors.
If I see a single offending path, I exclude it. If I see a generic "indexing wedged" pattern, I run the clean-rebuild sequence above.
Through all of this, my daily ⌘Space hotkey is on a launcher that does not depend on mds. The upgrade weekend is transparent to my actual work.

Steps 2 through 4 take about ten minutes a year. Step 5 is the one that matters most — it turns Spotlight rebuilds from an emergency into a curiosity.