The Windows Search indexer is supposed to be invisible. It crawls your files in the background, builds its catalog, and gets out of the way — and on a well-configured system, that is exactly what happens. But when the index corrupts, the scope balloons, or something keeps churning your files, SearchIndexer.exe turns into a permanent CPU tenant, and search results do not even improve for the trouble.
There is a “best way” to fix this because the causes stack in a predictable order. Randomly toggling settings wastes an afternoon; working the stack top-down fixes it in one pass. That is what this guide does: diagnose the state, shrink the workload, rebuild cleanly, and lock in settings that keep it quiet.
Why this happens
- Corrupted index database: A damaged catalog makes the indexer re-crawl the same files endlessly, burning CPU without ever finishing.
- Indexing scope far too broad: Whole drives, program folders, and cloud-synced directories multiply the crawl workload far beyond what search needs.
- Constant file churn underneath it: Cloud sync, backups, developer tools, and chat apps modifying files continuously force endless re-indexing.
- Post-update rebuild loops: A failed or interrupted rebuild after a Windows update leaves the indexer retrying the same batch forever.
- File-type handlers misbehaving: Broken IFilters for PDFs, archives, or email stores make the indexer hang on individual files, spiking CPU per file.
- Antivirus fighting the crawler: Real-time scanning of every file the indexer touches doubles the work and can deadlock the crawl on large files.
- Outlook’s massive data files: Huge PST/OST files get re-indexed in large chunks, and a corrupted mail store keeps the indexer busy for days.
How to fix it
Work through these in order — diagnose first, then act.
Fix 1: Check the indexer’s actual state
- Open Control Panel → Indexing Options and look at the top line: it should say Indexing complete. If it says Indexing… with a count that never decreases, the crawl is stuck.
- Open Task Manager and confirm SearchIndexer.exe (or Microsoft Windows Search Indexer) is the process holding CPU.
- Note how many items are indexed — anything over 200,000 on a typical laptop suggests the scope is too broad.
- If indexing claims to be complete yet CPU stays high, the database is likely corrupt — proceed to Fix 3 after scoping down in Fix 2.
Fix 2: Shrink the indexing scope to what you actually search
- In Indexing Options, click Modify.
- Uncheck entire drives, Program Files, Windows, Downloads, and any cloud-synced folders (OneDrive, Dropbox). These are the biggest CPU sinks and the least useful to search.
- Keep only your real document locations: Users folders for documents and pictures, plus Start Menu and Offline Files defaults.
- Click OK. Fewer locations means a smaller database, faster rebuilds, and permanently lower CPU.
- For the search host process that surfaces these results, our SearchHost.exe fix is the companion piece when the host — not the indexer — is the hot process.
Fix 3: Rebuild the index cleanly
- In Indexing Options, click Advanced → Rebuild under Troubleshooting, and confirm.
- Plug in the charger — the rebuild is CPU and disk intensive, and you do not want the laptop sleeping mid-rebuild.
- Let it run to Indexing complete. Do not judge CPU during the rebuild; judge it for a full day after.
- If the count stalls at the same number for hours, a specific file is hanging the crawler — note the count, then move to Fix 4.
Fix 4: Remove problematic file types and locations
- In Indexing Options → Advanced → File Types, uncheck extensions tied to broken handlers — especially PDF, ZIP, and email archive types if you installed third-party filters for them.
- If you use Outlook with a huge mailbox, consider unchecking Microsoft Outlook under Modify → Show all locations, and rely on Outlook’s own search instead.
- Exclude folders with constant churn: code repositories, build output folders, game mod directories, and download staging areas.
- Rebuild once more after these exclusions so the database drops the problematic entries.
Fix 5: Stop the antivirus feedback loop
- Add
C:\ProgramData\Microsoft\Searchto your antivirus exclusions — this is the index database location, and scanning it during writes creates a costly loop. - If you run a third-party suite, check whether it has its own “search integration” or file-shield feature interacting with the indexer, and test with it briefly disabled.
- Windows Security’s built-in exclusions guidance is documented on the Microsoft support site if you need the exact steps.
- Restart the Windows Search service (
services.msc→ right-click → Restart) after changing exclusions and observe for an hour.
Fix 6: Set the indexer to back off properly
- In
services.msc, double-click Windows Search and set Startup type to Automatic (Delayed Start) so indexing waits until boot settles. - In Indexing Options → Advanced, uncheck Index encrypted files if you do not use EFS — encrypted files cost extra CPU per file.
- On laptops, go to Settings → Privacy & security → Searching Windows and set Find my files to Classic instead of Enhanced — Classic indexes far fewer locations by default.
- These three settings together are what “well-behaved indexing” looks like on a laptop.
Fix 7: Nuclear option — reset the search database files
- Stop the Windows Search service in
services.msc. - Navigate to
C:\ProgramData\Microsoft\Search\Data\Applications\Windowsand delete the contents (database files only — your documents are untouched). - Start the service again; it rebuilds the catalog from zero with your trimmed scope from Fix 2.
- If even a clean database with a minimal scope still burns CPU, the cause is external churn — check cloud sync clients and backup tools, and see our 100% disk guide for the disk-side version of this same investigation.
Closing
The indexer is a good servant and a terrible master. Scope it to the files you actually search, rebuild it cleanly once, exclude the database from antivirus scans, and let it back off at boot — and SearchIndexer.exe goes back to the background where it belongs, with search staying instant.
