A backlog, not a bug
The indexer follows the NTFS USN change journal, so every mass file event becomes indexing work. A Windows feature update that re-parses the system volume, a OneDrive or Teams sync pulling down thousands of files, a restored backup, or a developer's fresh node_modules tree can each queue hundreds of thousands of items. Indexing a single item is cheap; indexing a few hundred thousand of them takes hours, and that is exactly what you are watching in Task Manager.
The other classic is Outlook: a large .pst or .ost archive is indexed item by item through the same pipeline, and a 20 GB mailbox archive can keep the indexer busy for most of a workday. Open Indexing Options and read the status line — a huge "items remaining" count with a rising indexed total means a healthy indexer working through a backlog. An indexed count that never moves, or a database that grows to absurd sizes while CPU stays high, points instead at a corrupted index rebuilding in a loop, which is the one scenario that needs the Rebuild button.
- Classic Outlook with large .pst or .ost files — item-by-item indexing through the same service
- OneDrive, Teams or a backup restore syncing thousands of files down to the machine
- A Windows feature update re-parsing the system volume and re-verifying the index
- Developer trees: node_modules, build output and .git folders with tens of thousands of small files
- File-scanning tools that touch metadata on everything, re-queueing the whole disk
- A corrupted Windows.edb or Windows.db index that rebuilds, bloats and rebuilds again
Taming the indexer without breaking search
The high-leverage move is scope control, not service control. In Indexing Options, hit Modify and uncheck every tree you never search — build folders, media archives, the downloads pit — and let the change settle. For classic Outlook archives, index only the stores you actually search rather than every detached .pst ever mounted, and after any scope change give the indexer a night: a backlog that looks endless at 6 p.m. is often finished by morning.
Do not disable the Search service to solve a CPU spike. Explorer search in indexed locations, Start menu results and Outlook search all fall back to slow crawl modes when the index is off, and the service restarts the backlog the moment it is enabled again anyway. If the index is genuinely corrupt — the rebuilding-in-a-loop symptom — use Advanced and Rebuild in Indexing Options to delete and regrow the database once; that costs a few hours of CPU one time and ends the loop. On servers with many concurrent users, remember the indexer runs per user there, and several instances of SearchIndexer.exe are several separate backlogs.
Questions and Answers
Why is SearchIndexer.exe using so much CPU?
It is working through an indexing backlog — a new Outlook archive, a OneDrive sync, an update re-parsing the volume — and Indexing Options shows the queue size directly.
Should I disable Windows Search to stop the CPU usage?
No: search in Explorer, Start and Outlook slows to a crawl, and the backlog returns when the service is re-enabled; trim the indexed scope or rebuild a corrupt index instead.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]