Why Search Indexer Re-Indexes Everything After a Cumulative Update

Quick fix: A cumulative update that touches the Search Indexer service version triggers a full schema upgrade, which forces a re-index. The first re-index after the update is unavoidable; subsequent ones aren’t. Set Find My Files: Classic instead of Enhanced in Search settings to reduce the indexed surface area and shorten future re-indexes.

You apply a Patch Tuesday cumulative update. The PC reboots, you sign in, and the disk starts thrashing. Task Manager shows SearchIndexer.exe at high I/O. The first time you open File Explorer search, results are slow or empty. The indexer is rebuilding its database from scratch — on a multi-TB drive with documents and code, this can take 12–48 hours.

What forces a full re-index

The Search Indexer stores its database under %ProgramData%\Microsoft\Search\Data\Applications\Windows. The database has a schema version embedded. When a cumulative update changes the indexer’s code — even a tiny change to how filenames are tokenized, or how a new file type is parsed — the schema version increments. On next boot, the service notices the schema mismatch and rebuilds. There’s no incremental upgrade path; the whole index has to come from scratch.

You can’t prevent this for the update itself. What you can do: narrow what gets indexed (less to rebuild), or move the index off the OS drive (faster rebuild on a dedicated SSD).

Method 1: Switch from Enhanced to Classic search

Enhanced indexing covers your entire drive. Classic indexes only specific folders (libraries, OneDrive, etc.) and is dramatically smaller.

1. Open Settings → Privacy & security → Searching Windows.
2. Under Find my files, select Classic.
3. Click Customize search locations here.
4. Add the folders you want indexed (Documents, Desktop, OneDrive); remove what you don’t.
5. Apply. The indexer trims its database, then future rebuilds touch only the smaller scope.

On a PC with mostly cloud-synced documents, Classic mode covers what you actually search and skips the multi-TB media drive that you rarely search through.

Method 2: Move the index to a faster drive

If you have a dedicated NVMe for development or downloads, point the index there — rebuilds run at NVMe speed.

1. Open Control Panel → Indexing Options.
2. Click Advanced.
3. Under Index location, click Select new and choose a folder on your fastest SSD (e.g., D:\SearchIndex).
4. Click OK. Windows confirms with “You need to restart the search service for this change to take effect.”
5. Reboot.
6. The indexer rebuilds at the new location. Subsequent rebuilds also run there.

Don’t move it to a slow HDD or an external drive — both make searches and rebuilds painful.

Method 3: Stop and rebuild the index manually after updates

If you want full control over when re-indexing happens (e.g., overnight, not during work hours):

1. Open Control Panel → Indexing Options → Advanced.
2. Click Rebuild under Troubleshooting. Confirm.
3. The indexer empties its database and starts over. Schedule this for a night you’re not using the PC.
4. Alternatively, stop the service temporarily during a work session:
   
   Stop-Service WSearch -Force (in elevated PowerShell)
   
   Re-enable when you have time:
   
   Start-Service WSearch

This isn’t a fix — it’s a workaround that lets you defer the rebuild cost. Useful for laptops on battery or systems with thermal limits.

How to verify the fix worked

• Open Control Panel → Indexing Options. The Items indexed count is lower (if Method 1) or rebuilding faster (if Method 2).
• SearchIndexer.exe CPU and disk activity drops to near-zero after the rebuild completes.
• File Explorer search returns instant results for indexed locations.
• Next cumulative update doesn’t produce a multi-day rebuild; the smaller scope finishes in hours.

If none of these work

If SearchIndexer keeps re-indexing even between updates, the database is corrupt — delete %ProgramData%\Microsoft\Search\Data\Applications\Windows (with the service stopped) and let it rebuild from scratch. For PCs where indexing chronically degrades performance, consider disabling the indexer entirely with sc config WSearch start=disabled — File Explorer search still works (it falls back to slow grep), but the background indexer no longer competes for I/O. This is fine for users who rarely search but want consistent responsiveness.

Bottom line: The first re-index after a cumulative update is unavoidable. Subsequent ones are smaller if you narrow the scope (Classic) or move the index to faster storage. Don’t panic when SearchIndexer goes crazy after an update — it’s expected, and shrinking the scope makes the next round faster.