If you’ve searched this problem before, you’ve seen the folklore: registry hacks, half-understood service disables, “just delete the index folder” advice that causes more harm than good. This guide is the opposite — the fixes that actually work, in the order that actually works, each one targeting a real, verifiable cause of SearchIndexer.exe running hot.

The indexer is a librarian doing heavy work. When the library is corrupt, infinite, or full of books that rewrite themselves, the librarian never sleeps. Fix the library, and the indexer goes quiet.

Why this happens

  • Corrupted index database: Damaged entries cause endless retry loops instead of completion.
  • Impossible scope: Entire drives, network locations, or external disks added to the index.
  • Churn folders: Logs, caches, and temp folders that change constantly, never letting indexing finish.
  • Stuck initial indexing: An interrupted first build that restarts from zero repeatedly.
  • Huge file counts: Photo libraries and dev trees with hundreds of thousands of files.
  • Post-update resets: Feature updates invalidating the index and forcing full rebuilds.
  • Disk problems: A failing disk making every index read slow, stretching the job indefinitely.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Check status and let legitimate indexing finish

Open Control Panel → Indexing Options and read the status line: if it says “Indexing in progress” with a count that’s decreasing, the indexer is working, not broken — give it plugged-in idle time to finish (up to 24 hours for huge libraries). Check what’s included via Modify while you’re there; note anything surprising. Only proceed if the status never completes, the count never moves, or indexing “completes” and immediately restarts. Patience first, surgery second. The best-practice indexer guide starts from the same status check.

  1. Open Indexing Options and read the status line.
  2. Note included locations via Modify.
  3. Allow up to 24 hours of plugged-in idle if genuinely progressing.
  4. Proceed only if it’s stuck or endlessly restarting.

Fix 2: Exclude churn folders and trim the scope

The most common real cause: the indexer can never finish because it’s indexing folders that never stop changing. In Indexing Options → Modify, uncheck: temp folders, browser caches, log directories, VM folders, game libraries, download archives, and any folder with tens of thousands of tiny files you never search. Keep Documents, Pictures, and your actual working folders. Every unchecked location is work the indexer never has to do again — and for many users, this single step ends the problem permanently because the “infinite” folder was the whole issue.

  1. Open Indexing Options → Modify.
  2. Uncheck churn folders, caches, VMs, and game libraries.
  3. Keep only folders you actually search.
  4. Watch indexer CPU over the next few hours.

Fix 3: Rebuild the index cleanly

For corruption — the troubleshooter found problems, or the index “completes” then restarts — rebuild: Indexing Options → Advanced → Rebuild. This deletes the damaged database and builds a fresh one from your trimmed scope (do Fix 2 first so the rebuild is lean). Allow several hours of plugged-in idle. A clean rebuild on a sane scope is the definitive fix for database corruption, and the indexer should idle quietly afterward. Microsoft documents the rebuild in the Windows support hub .

  1. Trim scope first (Fix 2), then Advanced → Rebuild.
  2. Leave the laptop plugged in and idle for hours.
  3. Don’t judge CPU during the rebuild itself.
  4. Verify quiet idling the day after.

Fix 4: Run the Search and Indexing troubleshooter

Settings → System → Troubleshoot → Other troubleshooters → Search and Indexing — run it and apply everything it suggests. It checks service state, permissions on index locations, and database integrity, fixing the bureaucratic causes (a location the indexer can’t read, a service stuck in a bad state) that manual steps miss. It’s genuinely useful here, not placebo — run it after the rebuild if problems persist, since it catches post-rebuild permission issues. The community-asked variant covers the same troubleshooter path.

  1. Run the Search and Indexing troubleshooter.
  2. Apply all suggested repairs.
  3. Reboot after it completes.
  4. Monitor indexer CPU for a full day.

Fix 5: Check disk health and free space

An indexer fighting a failing disk looks exactly like a stuck indexer. Run chkdsk C: /f from an elevated prompt (schedule at reboot if asked), and ensure 15–20% free space on indexed drives — a full disk cripples the database writes indexing depends on. If you index an external or network drive, disconnect it as a test: network hiccups and sleeping externals stall indexing indefinitely, and they’re the stealth cause of many “indexer never finishes” cases. Local SSD, healthy, with free space — that’s the environment indexing needs.

  1. Run chkdsk on indexed drives from an elevated prompt.
  2. Free space to 15–20% on indexed drives.
  3. Disconnect external/network locations as a test.
  4. Re-evaluate indexer behavior.

Fix 6: Restart the service cleanly — and know when to limit it

If the indexer is wedged in a bad state, restart its service properly: services.msc → Windows Search → Restart (not Disable). A clean service restart clears stuck worker threads without the side effects of disabling. As the last resort — only for machines where file search truly doesn’t matter — you can set the service to Disabled, accepting slow file search and broken Outlook search. But try everything above first: a fixed indexer gives you instant search at near-zero idle cost, which beats no search at all. The 24H2 indexer guide covers the newest build’s behavior.

  1. Restart the Windows Search service in services.msc.
  2. Observe for 24 hours before judging.
  3. Only disable as a last resort, knowing the tradeoffs.
  4. Prefer a working indexer over no indexer.

Closing

The indexer myths persist because the real fixes sound boring: trim the scope, exclude the churn, rebuild what’s corrupted, check the disk. But boring works — these six steps resolve the overwhelming share of SearchIndexer.exe cases, and they leave you with fast search instead of broken search. Skip the registry folklore; fix the library.

Frequently asked questions

Why does the Windows Search indexer use 100% CPU or disk?
The indexer catalogs your files so searches are instant — and cataloging is genuinely heavy work: reading every file, extracting text, building the database. It’s supposed to be heavy temporarily (after setup, updates, or big file additions) and quiet afterward. Nonstop high usage means it’s stuck: corrupted database, an ever-changing folder it can never finish, or a scope far larger than it should be.
Is it safe to disable Windows Search indexing completely?
Safe but costly: Start menu search still finds apps, but file-content search becomes painfully slow and Outlook search breaks. Most people regret full disabling within a week. The better fixes — rebuilding a corrupted index, limiting scope, excluding churn folders — keep fast search while ending the resource burn. Reserve disabling for machines where search genuinely doesn’t matter.
How long should indexing take on a new laptop?
On a typical laptop with an SSD and a normal file collection, the initial index completes in 1–4 hours of plugged-in idle time. Machines with hundreds of thousands of files, large photo libraries, or HDDs can take a day or more. If it’s still going hard after 48 hours of idle plugged-in time, it’s not slow — it’s stuck, and needs the fixes below.
What's the difference between SearchIndexer.exe and SearchHost.exe?
SearchIndexer.exe is the background engine that builds and maintains the search database — the librarian. SearchHost.exe is the Start menu search interface you interact with — the front desk. Indexer CPU means the database build is the problem; SearchHost CPU means the interface or its queries are. They often suffer together when the index is corrupted, which is why both get fixed here.