Rebuild the Spotlight index in 2026: the only guide you need

A Spotlight rebuild is the macOS equivalent of "have you tried turning it off and on again?" — boring, slightly slow, and effective often enough to be the first real fix to try when search results stop matching reality. This guide is the long version. It explains what the index actually is, the two commands you really need, the four things that go wrong during a rebuild, and how to keep working while it grinds.

This is written against macOS Tahoe 26 but every step works identically on Sequoia and Sonoma. The shape of the indexer has not changed in years; only its bugs have.

What "the Spotlight index" actually is

On every mounted volume, Spotlight stores its index in a hidden folder called .Spotlight-V100 at the volume root. Inside that folder you will find one or more Store-V2 directories named with UUIDs, each containing store.db, live.0.shadow, and a small forest of journal files. The daemon mds reads and writes these files; the workers mds_stores and mdworker_shared populate them by handing files to per-format importers (mdimport).

A "rebuild" means erasing those store files and asking mds to scan the volume from scratch. It does not touch your data. It does not change your file permissions. The only thing on disk that changes is Spotlight's own index.

The two commands you actually need

sudo mdutil -E /
sudo mdutil -E /System/Volumes/Data

mdutil -E erases the index for the named path and immediately starts a rebuild. The first command rebuilds the whole system volume; the second is the narrower form that only rebuilds the Data volume (where your home folder lives). On Apple Silicon Macs you usually want the second — system frameworks and applications change rarely, and the Data rebuild is what fixes the bug 95% of the time.

If you need to rebuild an external drive:

sudo mdutil -E /Volumes/MyDrive

That is the whole command vocabulary. Everything below is troubleshooting and context.

When to actually run it

The rebuild is appropriate when you can confirm:

The file's metadata is missing or stale — check with mdls /path/to/file.
Re-importing a single file with mdimport does not fix the symptom.
The path is not on your Spotlight Privacy exclusion list.

If any of those are not true, a full rebuild is overkill. Spotlight has lighter mechanisms (mdimport, Privacy list audit) that solve specific symptoms without rebuilding everything. OSXDaily's Sequoia walkthrough covers the lighter options and is still accurate on Tahoe 26.

How long it takes

The honest answer is "longer than you want, shorter than you fear":

A clean 500 GB Data volume on an M-class Mac: about 20–40 minutes to functional, an hour or two to settled.
A developer's home folder with hundreds of thousands of small files: 1–3 hours.
An external drive on USB-C: usually 2–6x the equivalent internal time.

The rebuild is paced. mds_stores rarely consumes more than one CPU core, and it yields to interactive work. Plug into power, do not put the machine to sleep, and check back in an hour.

What goes wrong during a rebuild

Four failure modes account for nearly all "rebuild did not help" reports:

1. The rebuild loops. mdutil -s / keeps reporting "Indexing in progress" for days. Usually means a single importer is crashing on a specific file and the daemon keeps retrying. Find it with:

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

When you see the offending file, move it out of an indexed path (or add the containing directory to Privacy) and the rebuild resumes.

2. The new index does not stick. You rebuild, search works for an hour, then symptoms come back. Almost always a path on Privacy that has the wrong granularity — a parent excluded but a noisy child not, or vice versa. Audit the exclusion list line by line.

3. The rebuild does not start. mdutil -E / returns immediately and mdutil -s / reports "Indexing and searching disabled". The volume's indexing is turned off. Re-enable with sudo mdutil -i on /.

4. The store directory cannot be erased. Permissions on /.Spotlight-V100 got mangled — usually by a previous failed rebuild. The fix is the nuclear sequence:

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

Apple Support's thread on the topic collects user reports confirming the same sequence as the last-resort fix on Tahoe 26.

Working while it rebuilds

A rebuild that takes two hours is two hours your normal ⌘Space launcher is unreliable. You have three options:

Option A — Wait it out. Fine for non-urgent rebuilds. Make coffee. Read Michael Tsai's running notes on Spotlight while you wait.

Option B — Use Finder search with live scan. When Spotlight is rebuilding, Finder's search bar falls back to a live filesystem scan inside the current folder. Slower, but it works for known directories.

Option C — Keep a launcher with its own index. This is the pragmatic answer. CmdSpace, for example, runs its own Rust-backed local index that does not depend on mds. While Spotlight is rebuilding, CmdSpace keeps finding files at sub-25ms latency. It is $29 one-time with a 60-day trial; see our Spotlight-to-CmdSpace migration guide for the setup.

Option C is not a sales pitch as much as a working condition. Any launcher that maintains its own index — Alfred, Raycast, Quicksilver, Ueli — gives you the same property. The point is to have something that keeps working when mds does not.

After the rebuild

Once mdutil -s / reports "Indexing enabled" with no "in progress" suffix, verify:

mdfind -onlyin ~ "kMDItemDisplayName == 'something-you-know-exists.md'"

A result means the index is rebuilt and queryable. If you get an empty result for a file that absolutely exists on disk, run mdimport on it directly and try again.

Then write down what you did. Spotlight rebuilds tend to be one-time fixes, but if you find yourself doing it twice a year, the bug is on Apple's side and worth a Feedback Assistant report.

A short note on `.x.0` releases

Every macOS .x.0 release triggers a Spotlight rebuild on first boot. That is by design — the importer schemas can change, and the safest path is to throw out the old index. If you upgraded last week and search has been flaky ever since, you may not need to do anything; the daemon is finishing its post-upgrade work in the background. Give it 24 hours of being plugged in and awake before reaching for mdutil -E.