When SearchIndexer.exe misbehaves, it does so in recognizable patterns — and each pattern points at a different fix. Constant moderate CPU for days means something different from violent spikes every hour, which means something different from 100% CPU that never ends. Troubleshooting indexing is therefore pattern recognition first, intervention second.

This walkthrough covers the full diagnostic ladder: identifying your pattern, checking index health, hunting the files that trigger re-indexing, resolving software conflicts, and — when everything else fails — the clean-slate options. Work it top to bottom without skipping the diagnosis steps.

Why this happens

  • Corrupted index database: The most common root cause; triggers endless re-crawl loops.
  • Over-broad indexing scope: Indexing locations that should never be indexed.
  • Churn loops: Applications constantly modifying indexed files (builds, syncs, logs).
  • Outlook/PST indexing: Large mail stores with corruption cause notorious indexer hangs.
  • Encrypted or permission-blocked files: The indexer retries what it cannot read.
  • Third-party search tools conflicting: Everything, Listary, or Copernic fighting Windows Search over the same files.
  • Damaged Windows Search service state: The service itself wedged, independent of the index data.

How to fix it

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

Fix 1: Identify your CPU pattern

Open Task Manager and characterize the behavior over 30 minutes. The pattern determines everything that follows — write it down before touching settings.

  1. Watch SearchIndexer.exe (or Windows Search service) CPU for 30 minutes of normal use.
  2. Pattern A: constant 15–40% that never ends → likely corruption or scope problem.
  3. Pattern B: spikes to high CPU every 10–60 minutes → likely churn loop from an app.
  4. Pattern C: 100% since a recent update → likely legitimate rebuild; give it a night first.

Fix 2: Check index health and status

Windows reports what the indexer thinks it is doing. A healthy index shows a stable file count; a sick one shows counts jumping, errors, or perpetual ‘indexing in progress.’

  1. Go to Settings > Privacy & security > Searching Windows.
  2. Check the indexing status line and excluded-folders list.
  3. Open Advanced indexing options and note the total items indexed.
  4. Revisit after an hour: a healthy count barely moves; a looping count swings wildly.

Fix 3: Find the files triggering re-indexing

For Pattern B (spikes), something is modifying indexed files on a schedule. Resource Monitor shows exactly which files the indexer touches during a spike — follow that trail to the churning application.

  1. During a spike, open Resource Monitor > Disk tab and filter by SearchIndexer.exe.
  2. Note which files it reads/writes repeatedly.
  3. Trace those files to their owner app (build folders → IDE; mail stores → Outlook; sync folders → cloud app).
  4. Exclude that folder from indexing or calm the app’s write behavior.

Fix 4: Rebuild the index as the corruption fix

For Pattern A, rebuilding is the definitive treatment: it discards the damaged database and re-crawls cleanly. Do the scope narrowing first (Fix 5) so the rebuild produces a lean index.

  1. Narrow indexed locations first (see Fix 5).
  2. Advanced indexing options > Advanced > Rebuild; confirm.
  3. Allow 1–3 uninterrupted hours on AC power.
  4. After completion, verify Pattern A is gone over a full day.

Fix 5: Narrow scope and exclude problem locations

Whether or not you rebuild, scoping is permanent prevention. Remove everything you never search and everything that churns.

  1. In Modify, untick whole drives, program folders, and archives.
  2. Exclude: build outputs, VM disks, Downloads-in-progress, sync working folders, Outlook PST locations if mail search is unused.
  3. Keep: Documents and specific project folders you actually search.
  4. Let the indexer settle for an hour, then re-observe.

Fix 6: Resolve Outlook and third-party conflicts

Outlook’s mail indexing and third-party search utilities are the two classic conflict sources. Each has its own fix, and both are common enough to check explicitly.

  1. If Outlook is installed: File > Options > Search > Indexing Options — verify Outlook is indexed without errors; repair the PST/OST if indexing stalls there.
  2. If you run Everything/Listary/Copernic: ensure only one tool indexes the same locations, or disable Windows file indexing where the third-party tool covers it.
  3. After changes, restart the Windows Search service (services.msc).
  4. Monitor for 24 hours before declaring victory.

Fix 7: Reset the Search service and app package

When the service itself is wedged — index healthy, no churn, but CPU still wrong — reset the components rather than the data. This is deeper than a service restart and fixes state corruption the rebuild does not touch.

  1. In services.msc, stop the Windows Search service.
  2. Delete contents of C:\ProgramData\Microsoft\Search\Data\Applications\Windows (the index store).
  3. Restart the service; it rebuilds the store automatically.
  4. As a further step, re-register the Search app: run Get-AppxPackage Microsoft.Windows.Search | Reset-AppxPackage in elevated PowerShell (Windows 11).

Fix 8: Check Event Viewer for indexer errors

Windows logs indexer failures that never surface in Settings — corrupt catalog errors, permission failures on specific paths, crashes of the search service. These log entries often name the exact file or folder breaking the index, saving hours of guessing. This diagnostic complements the best-practice fix order ; use it when the standard fixes have not resolved your pattern.

  1. Open Event Viewer > Applications and Services Logs > Microsoft > Windows > Search.
  2. Look at the Operational log for Errors and Warnings during spike periods.
  3. Note any file paths or error codes mentioned repeatedly.
  4. Exclude the offending path from indexing (or fix its permissions), then rebuild.
  5. Cross-check with startup trimming if a startup app owns the offending files.

Closing

Search indexing troubleshooting is pattern work: constant CPU means corruption or scope, periodic spikes mean a churning app, post-update 100% means patience. Match your pattern, apply the corresponding fix — rebuild for corruption, exclusions for churn, time for rebuilds — and verify over a full day. The indexer is a good servant once its scope is sane and its database is healthy.

Frequently asked questions

How do I know if my search index is corrupted?
Tell-tale signs: indexing status perpetually shows ‘in progress’ without the file count stabilizing, searches return incomplete or no results for files that exist, SearchIndexer.exe uses constant CPU for days, and the indexed-item count swings wildly between checks. When two or more of these appear together, corruption is likely and a rebuild (Fix 4) is the answer.
Can Outlook really break Windows Search indexing?
Yes — it is one of the most common culprits. Large or damaged Outlook data files (PST/OST) can stall the indexer as it struggles to parse them, producing constant CPU with no progress. If you have Outlook with a multi-GB mail store and indexing never completes, check Indexing Options for Outlook errors and consider repairing or compacting the data file.
What's the difference between rebuilding and resetting the index?
Rebuilding (Fix 4) deletes the index database and re-crawls your currently configured locations — it fixes data corruption. Resetting the service components (Fix 7) goes deeper: it clears the service’s state store and re-registers the Search app package, fixing wedged-service problems that survive a rebuild. Try rebuild first; escalate to reset only if the rebuild did not help.
Is it safe to delete the index data folder manually?
Yes, if you stop the Windows Search service first — that is exactly what Fix 7 does. The folder (C:\ProgramData\Microsoft\Search\Data\Applications\Windows) contains only the generated index database, never your actual files. Windows recreates it automatically when the service restarts. Never delete it while the service is running, and never confuse it with your Documents or other data folders.