You press the Windows key, type two letters, and the fan spins up — SearchHost.exe leaps to 20–30% CPU and stays there long after you’ve found your app. Or worse, it’s burning CPU with the search box closed and you haven’t searched for anything all day. SearchHost is the search UI process in Windows 11, and when it misbehaves, the humble act of finding a file becomes a performance event.

The key distinction: this is the UI layer, not the index. SearchIndexer.exe crawling files is a different problem with different fixes. SearchHost spikes come from what the search window renders — highlights, web content, cloud results — or from a corrupted search app package. This guide targets exactly that layer.

Why this happens

  • Search highlights: The rotating illustrations and content in the search box keep the UI process active on schedules.
  • Cloud content in search: Web results and Microsoft account content fetched live, spiking CPU on slow or flaky connections.
  • Corrupted search app package: A damaged Windows Search app installation causing UI-layer retry loops.
  • Bing integration: Online search results rendering inside the local search flyout.
  • Large recent-search history: A bloated search history database slowing the UI render.
  • Conflicting shell customizations: Third-party Start-menu tools interfering with the search host process.
  • Stuck search UI state: The flyout’s cached state corrupting so it re-renders continuously.

How to fix it

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

Fix 1: Confirm it’s SearchHost, not the indexer

Open Task Manager and look carefully at the process name: SearchHost.exe (UI layer) versus SearchIndexer.exe (background crawler). Note the trigger — does CPU spike when you open search, or is it constant with search closed? Constant-with-closed points to highlights/cloud refresh (Fixes 2–3); spike-on-search points to the app package or history (Fixes 4–5). Getting this attribution right saves you from rebuilding the entire search index for what turns out to be a UI toggle. Write down which pattern you see.

  1. Identify the exact process: SearchHost.exe vs SearchIndexer.exe.
  2. Note whether spikes correlate with opening search.
  3. Check if usage is constant with search closed.
  4. Match your pattern to the fixes below.

Fix 2: Turn off search highlights

Open Settings → Privacy & security → Search permissions and toggle off “Show search highlights.” This kills the rotating content, illustrations, and tips in the search box — the single most common cause of SearchHost burning CPU while you’re not searching. The search box becomes plain and instant, which is what most people want anyway. Test for an hour: if constant background CPU vanishes, highlights were the entire problem. This one toggle resolves a remarkable number of SearchHost complaints.

  1. Open Settings → Privacy & security → Search permissions.
  2. Turn off “Show search highlights.”
  3. Monitor Task Manager for an hour with search closed.
  4. Keep highlights off permanently if CPU normalized.

Fix 3: Disable cloud content and Bing integration

In the same Search permissions page, turn off cloud search for your Microsoft account and work/school account — this stops SearchHost fetching web-backed content into local results. For Bing web results in the search flyout, set the registry value HKCU\Software\Policies\Microsoft\Windows\Explorer\DisableSearchBoxSuggestions (DWORD) = 1, which removes web suggestions from search. Local file and app search keep working perfectly; you just lose the web-results pane that was spiking CPU on every keystroke. Searches become faster as a bonus — no network round-trip per keystroke.

  1. Disable Microsoft account and work account cloud search.
  2. Set DisableSearchBoxSuggestions = 1 in the registry.
  3. Restart and test search responsiveness.
  4. Confirm SearchHost only spikes briefly during actual searches.

Fix 4: Clear search history and reset the Search app

A bloated or corrupted search history slows the UI render. In Settings → Privacy & security → Search permissions → History, click “Clear device search history.” Then reset the app package: Settings → Apps → Installed apps → Windows Search (or Search) → Advanced options → Repair, then Reset if needed. Resetting re-registers the SearchHost components without touching the index database — your indexed files stay indexed. After the reset, open search once and let it initialize, then verify CPU behavior across several searches. Microsoft documents search troubleshooting in the Windows support hub .

  1. Clear device search history in Search permissions.
  2. Repair the Windows Search app from Advanced options.
  3. Reset it if repair doesn’t resolve the spikes.
  4. Test multiple searches and watch CPU settle.

Fix 5: Re-register the search package via PowerShell

If the Settings-level reset didn’t stick, go deeper. In an admin PowerShell, re-register the search app package: Get-AppxPackage -Name Microsoft.Windows.Search | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}. Then restart the Windows Search service (services.msc → Windows Search → Restart). This rebuilds the package registration that the Settings reset sometimes misses — particularly effective after feature updates that half-migrated the search components. Reboot after running it and verify SearchHost behaves across a full day.

  1. Re-register Microsoft.Windows.Search via admin PowerShell.
  2. Restart the Windows Search service.
  3. Reboot the laptop.
  4. Verify behavior across a full day of use.

Fix 6: Check for indexer-side and system-wide contributors

If SearchHost is calm but overall search-adjacent CPU remains high, the indexer may be the real problem — apply the search indexer guide for trimming and rebuilds. Also remove third-party Start-menu replacements temporarily to rule out shell interference, and run sfc /scannow to repair any corrupted system files affecting the search stack. Finally, make sure Windows is fully updated: Microsoft has patched several SearchHost CPU bugs in cumulative updates. The combination of a calm UI layer (this guide) and a healthy index (the indexer guide) is the complete search-performance picture.

  1. Rule out indexer-side CPU with the dedicated indexer guide.
  2. Temporarily remove Start-menu replacement tools.
  3. Run sfc /scannow for system file integrity.
  4. Install all pending Windows updates.

Closing

SearchHost high CPU is a UI-layer problem with UI-layer fixes: highlights off, cloud content off, history cleared, app package reset. The search box gets faster as a side effect — no web round-trips, no rotating content, just instant local results. And if the indexer (not the host) turns out to be the hog, you now know exactly which guide to reach for. The post-update SearchHost variant covers cases triggered by Windows updates.

Frequently asked questions

What is SearchHost.exe?
SearchHost.exe is the Windows 11 process that powers the search user interface — the flyout you see when you press the Windows key and type. It’s distinct from SearchIndexer.exe, which builds the search database in the background. SearchHost renders results, search highlights, and web-integrated content. It should spike briefly when you search and then go quiet; sustained high CPU means the UI layer is stuck on something.
What's the difference between SearchHost and SearchIndexer high CPU?
SearchIndexer.exe builds and maintains the file index database — its CPU usage comes from crawling files. SearchHost.exe renders the search window you interact with — its CPU comes from the UI layer, often search highlights, web content, or a corrupted search cache. They need different fixes: indexer problems need index trimming or rebuilds, while SearchHost problems need UI-layer fixes like disabling search highlights or resetting the search app.
Can I disable SearchHost.exe?
You shouldn’t kill it permanently — it’s the process behind Start-menu search, and disabling it breaks searching from the taskbar. But you can calm it dramatically: disabling search highlights, turning off cloud content in search, and resetting the search app package all cut its workload without losing search functionality. The fixes below keep search working while removing the CPU spike.
Why does SearchHost use CPU when I'm not searching?
Usually search highlights: the rotating content, tips, and web-backed illustrations in the search box refresh on schedules and keep the UI process active. Cloud search integration also pings Microsoft services periodically. If SearchHost burns CPU with the search box closed, highlights and cloud content are the prime suspects — both addressed in Fixes 2 and 3.