After a Windows 11 update, SearchHost.exe — the process behind the search box and its flyout — starts burning CPU like it’s rendering a movie. You didn’t change anything; the update changed search itself: new highlights content, altered online integration, a migrated cache that didn’t survive the trip intact. The result is a UI process stuck fetching, rendering, or retrying.

The good news: SearchHost is just an interface process. It’s safe to restart, its cache is safe to clear, and its most expensive features can be switched off without losing the ability to search. Here’s the fix sequence.

Why this happens

  • Search highlights feed loops: The rotating content in the search box fetches images and stories continuously; a stuck feed retries aggressively.
  • Corrupted search UI cache: The update migrates the SearchHost cache, and a damaged migration leaves it re-fetching forever.
  • Online search integration churn: Web results integration in the search box generates constant network-and-render cycles, worse on flaky connections.
  • Personalization re-sync: The update resets or re-syncs search personalization, triggering repeated cloud sync attempts.
  • Conflicting shell extensions: Third-party shell customizations interacting with the new search UI can cause render loops.
  • Corrupted user profile search data: Per-user search settings damaged by the update keep the host re-initializing.
  • Index/UI mismatch: The indexer rebuilding post-update while the UI hammers it for results creates a feedback loop between the two processes.

How to fix it

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

Fix 1: Confirm SearchHost is the process

Task Manager → Details, sort by CPU: verify it’s SearchHost.exe, not SearchIndexer.exe (the cataloger) or Widgets.exe (the widgets board). Note the usage pattern — constant high CPU versus spikes when you open search. Constant usage at idle is the stuck-loop pattern this guide fixes.

  1. Task Manager → Details → sort by CPU.
  2. Confirm SearchHost.exe (not SearchIndexer.exe).
  3. Observe for 3–5 minutes at idle; record the pattern.
  4. Constant idle CPU → continue to Fix 2.

Fix 2: Restart the SearchHost process

The simplest diagnostic: end the process and let Windows respawn it fresh. If CPU stays calm afterward, it was a wedged process — possibly a one-time post-update glitch. If it climbs again within minutes, the trigger is persistent (cache, highlights, or sync) and you’ll fix it below.

  1. In Task Manager → Details, right-click SearchHost.exe → End task.
  2. Wait 2 minutes; the process restarts automatically.
  3. Observe for 10 minutes.
  4. Calm = one-time wedge; recurring = continue.

Fix 3: Turn off search highlights

Search highlights are the number-one SearchHost CPU trigger. Settings → Privacy & security → Search permissions → scroll to More settings → turn off Show search highlights. This kills the rotating content fetch-and-render cycle entirely. Retest for 30 minutes — this single toggle resolves a large share of cases.

  1. Settings → Privacy & security → Search permissions.
  2. Under More settings, turn Show search highlights Off.
  3. Close Settings; observe SearchHost for 30 minutes.
  4. If resolved, you’ve found your trigger — leave highlights off.

Fix 4: Disable online search integration (test)

The Bing/web integration in the search box adds fetch-render cycles on every keystroke and periodically at idle. As a diagnostic, turn it off: Settings → Privacy & security → Search permissions → turn off Cloud content search options (Microsoft account and Work/School account). If CPU normalizes, you’ve isolated the trigger; you can leave it off or re-enable after the next cumulative update.

  1. Settings → Privacy & security → Search permissions.
  2. Turn off Cloud content search for both account types.
  3. Test search and observe CPU for 30 minutes.
  4. Re-enable later if a future update fixes the underlying issue.

Fix 5: Clear the search cache and reset the experience

Corrupted migrated cache keeps the host re-fetching. Reset the Windows Web Experience Pack (Settings → Apps → Installed apps → Windows Web Experience Pack → ⋯ → Advanced options → Repair, then Reset if needed) — this also backs the widgets board, so it addresses both. Then run the Search and Indexing troubleshooter (Settings → System → Troubleshoot → Other troubleshooters) to catch permission and configuration issues.

  1. Reset the Windows Web Experience Pack (Repair, then Reset).
  2. Run the Search and Indexing troubleshooter; apply recommendations.
  3. Restart the laptop.
  4. Observe for an hour. The indexer-side companion guide is post-update indexer CPU .

Fix 6: Check for profile-level corruption

If SearchHost misbehaves for your user account but the machine is otherwise fine, the per-user search data may be damaged. Create a new local user account (Settings → Accounts → Other users → Add account) and check SearchHost CPU there. Calm in the new profile confirms profile corruption; the fix is migrating to the fresh profile (or resetting the damaged one’s search data stores).

  1. Create a new local administrator account.
  2. Log into it; observe SearchHost CPU for 30 minutes.
  3. Calm = your profile’s search data is corrupt.
  4. Migrate files to the new profile; delete the old one after verifying.

Fix 7: Repair system files and wait for the cumulative update

Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth elevated to fix update-damaged system components. Then check Settings → Windows Update — Microsoft frequently ships SearchHost fixes in cumulative updates, and a post-update SearchHost loop is exactly the kind of regression the next cumulative addresses. If onset matches a specific KB, noting it helps you verify the fix in the update notes. Reference: Windows support . For the step-by-step indexer angle, see search indexing step by step .

  1. Elevated: sfc /scannow, then DISM restore-health.
  2. Install all pending cumulative updates; restart.
  3. Note the KB number matching onset; check its successor’s notes.
  4. Persistent across two cumulative updates → consider in-place repair install.

Closing

SearchHost.exe high CPU after a Windows 11 update is the search interface choking on the update’s changes — usually highlights feeds, migrated cache, or re-synced personalization. Restart it, kill the highlights, clear the cache, and repair what’s damaged. It’s a UI process, not a system crisis, and it surrenders quickly to the right sequence.

Frequently asked questions

What is SearchHost.exe and how is it different from SearchIndexer.exe?
SearchHost.exe is the search user-interface process — it powers the search box, the search flyout, and search highlights. SearchIndexer.exe is the background cataloger that builds the search database. High CPU in SearchHost means the interface layer is stuck, usually on rendering or fetching content, while indexer CPU means cataloging work. They have different fixes, so identifying the right executable in Task Manager matters.
Is SearchHost.exe safe to end in Task Manager?
Yes, temporarily. Ending SearchHost.exe just closes the search interface process; Windows restarts it automatically the next time you use search. It’s a safe diagnostic step — if CPU was stuck and stays calm after the restart, you had a wedged process. Unlike the kernel or Defender, there’s no protection loss from restarting it.
Why did SearchHost CPU start right after the Windows update?
Updates frequently change the search experience: new search highlights content, altered online-search integration, and reset personalization settings. The updated SearchHost can get stuck fetching the new highlights feed or rendering changed UI components, especially if its cache carried over in a corrupted state. Clearing that cache and reconfiguring the new options usually resolves it.
Will disabling search highlights stop the high CPU?
Often, yes — search highlights (the rotating images and stories in the search box) are the most common trigger for SearchHost loops, because the process fetches and renders that content continuously. Turning highlights off removes the entire fetch-and-render cycle. Many users see SearchHost drop to near-zero immediately after disabling highlights.