If Spotlight search on your Mac is returning stale results, missing files you know exist, or your fan has been running for hours while mdworker or mds sit at the top of Activity Monitor, the underlying cause is usually the same: the Spotlight index for that volume has gone stale or partially corrupted, and the fix is to force macOS to rebuild it. The command is sudo mdutil -E /. Before you run it, it helps to understand what that index actually is, where it lives, why rebuilding it is disruptive rather than routine, and why you rarely see it as a single line item even though it does take up real disk space.
What the Spotlight index is for
Spotlight is the search system behind the magnifying-glass icon in the menu bar, the search field in Finder, and the metadata lookups that power Quick Look, Mail search, and Time Machine's "which backup has this file" logic. To answer a query in a fraction of a second across an entire drive, it cannot scan every file live. Instead, background processes — mds (the metadata server) and one or more mdworker helper processes — continuously walk new and changed files, extract metadata (file type, dates, tags, and for many formats, indexed content like text inside a PDF or the artist tag on a music file), and write that into a per-volume index.
That index is what a search query actually hits. It is why Spotlight can tell you "3 PDFs mention invoice number 4471" in under a second on a drive with a million files: it already did the reading, once, in the background, and keeps doing it incrementally as files change.
Where the index lives, and why you rarely see it
The index is stored in a hidden, per-volume location that macOS manages directly — it is not a folder you are meant to browse, move, or back up by hand. Because it is not a single visible folder the way ~/Library/Caches/Homebrew is, and because macOS does not surface it as its own line item in the Storage screen, most people never realise it is taking up space at all. It usually sits somewhere in the low single-digit gigabytes to a few tens of gigabytes range depending on how much content-indexable data (documents, mail, photos with recognisable metadata) is on the volume — but you should not go looking for an exact folder to delete. The supported way to affect its size or behaviour is through mdutil, not manual file deletion.
Symptoms that mean the index is unwell
Two symptoms point specifically at Spotlight rather than at general disk pressure:
- Search in Finder or the menu bar returns results that are stale (renamed or deleted files still show up, or files you just saved do not appear for an unusually long time), or returns nothing for a file you can see is there.
mdsormdworker(sometimesmdworker_shared) show up in Activity Monitor consuming significant CPU continuously, well beyond the few minutes you'd expect after copying a batch of new files onto the drive.
A short burst of mdworker activity after connecting an external drive or restoring from backup is normal — that is indexing doing its job. A burst that runs for hours with no new files being added is the signal that something in the index itself is confused.
Forcing a rebuild with mdutil
The command to erase and rebuild the index for the root volume is:
sudo mdutil -E /
The -E flag tells mdutil to erase the existing index for the given volume and start indexing again from scratch. For an external drive or a second internal volume, point it at that volume's mount path instead, for example:
sudo mdutil -E /Volumes/MyExternalDrive
You will be asked for your administrator password, since this affects a system-managed index rather than user files.
Why this is a deliberate step, not routine maintenance
Rebuilding is disk- and CPU-intensive by nature: macOS has to read metadata for every indexable file on the volume all over again. On a drive with a modest amount of data this can finish in a matter of minutes. On a drive with hundreds of thousands of files, deep project trees, or a large Mail or Photos library, it can run for several hours, during which Spotlight search will be incomplete and your Mac may feel less responsive than usual.
For that reason, treat mdutil -E as a troubleshooting step you reach for when you have an actual symptom — stale results, a stuck reindex, or a support recommendation — not something to run on a schedule "to keep things tidy". There is no ongoing maintenance benefit to erasing a healthy index; you are only trading a temporary heavy re-scan for a problem you do not yet have.
Turning indexing off and on, and excluding folders
Two related commands are worth knowing. To stop Spotlight indexing a volume entirely:
sudo mdutil -i off /
And to turn it back on:
sudo mdutil -i on /
This is a coarse tool — it affects the whole volume — so it is mainly useful for external drives you do not need to search, or while diagnosing whether Spotlight itself is the source of a CPU problem.
For a more targeted case — say, a large directory of build artefacts or a project's node_modules tree that does not need to be searchable and would otherwise cost CPU cycles to index repeatedly — the supported approach is to exclude that specific folder rather than disable indexing system-wide. That's done in System Settings, under Siri & Spotlight, then Spotlight Privacy, where you can add folders to a exclusion list. Anything in there is skipped by future indexing passes, which both keeps searches cleaner (no build output cluttering results) and reduces the background work mdworker has to do.
Conclusion / VolumeLens tie-in
The Spotlight index is one of the more misunderstood pieces of storage on a Mac precisely because it does its job well when healthy: invisible, incremental, and fast. The moment it needs attention, the tools for fixing it are blunt but effective — mdutil -E to rebuild, mdutil -i to pause it, and Spotlight Privacy exclusions to keep it away from folders that don't need searching. None of this is something a storage-cleanup app should try to manage on your behalf; it is squarely in "tell the user, let them decide" territory.
That principle — tell you what's really going on instead of quietly acting on your behalf — is also why we built VolumeLens the way we did. It has no network code, makes no changes to your files beyond moving something to the Trash after you've reviewed it, and never touches system-managed stores like the Spotlight index or APFS snapshots. What it's good for is the part Spotlight and mdutil don't cover at all: showing you, visually, which of your own folders and files are actually consuming space, so you're not left guessing whether it was Xcode's build output, an old Docker disk image, or three years of Downloads that filled the drive.