How the search index works — and how to rebuild it
One index per catalog, kept current by the Catalog Service — what's in it, the four failure patterns and which one actually calls for a rebuild, and the Catalog Manager rebuild that runs in the background while search stays up.
By the end of this page you'll know what the index holds and who keeps it current — and, before you reach for the rebuild, which of the four index failure patterns you're actually looking at, because a rebuild fixes exactly one of them.
The shape of it
- One index per catalog, stored under the index root (Configuration Manager > System Folders > Index root folder:). A catalog's searchability is its index's health — one catalog searching badly while others are fine points at its index.
- What's indexed: each document's full text and its field values, names, and dates — which is why both content search and field search answer from the same machinery.
- Who keeps it current: the Ademero Content Central Catalog Service on the server. New and changed documents queue for indexing and the service works the queue continuously — plus each catalog's own update schedule if one is set. No service, no fresh index.
Four failure patterns, one of which wants a rebuild
| Pattern | What's really wrong | The fix |
|---|---|---|
| Recent documents missing from results, older ones fine | The Catalog Service is stopped or backlogged — documents are waiting, not lost | Start the service; the backlog drains. A rebuild does nothing while the service is down |
| A document's text you can see isn't searchable | The document has no text layer — an OCR gap, not an index gap | The searchability article, and the Make Searchable backfill at scale |
| A whole catalog returns nothing, silently | The index path is unreachable — moved disk, permissions | Fix the path/permissions (System Health flags this) |
| Search-engine errors in the event log, documents erratically findable | The index itself has bad entries — and failed documents are not retried automatically | This is the rebuild. |
Rebuilding
In Catalog Manager (on the server), select the catalog, choose Rebuild selected catalog's index in the action drop-down at the bottom, and click Go (Rebuild all catalogs' indexes for the sweep).
Read the confirmation as a schedule note, not a threat: "During an index rebuild, documents will become available as they are reindexed. Also, an index rebuild may take a long time if there are many documents in the catalog." Search stays up throughout — results are simply incomplete until the rebuild finishes.
The dialog then says the part people miss: "The catalog should update shortly. Check the Windows Event Log for completion status." The rebuild is queued for the Catalog Service and runs in the background — the dialog closing means started, and the Event Log is where finished shows.
A rebuild re-flags every document and reindexes from stored text — it doesn't re-OCR anything, which is why it can't fix the missing-text pattern above.
Catalog Manager's Details... for a catalog shows the index's vitals — Updated, Documents, Words, Size, Fragmentation — worth a glance before and after: "Updated: Never" or a document count far below reality tells its own story.
Success check: after the Event Log reports the update complete, search for a phrase from a recently added document and from an old one — both hitting means the index covers its whole span again.