Sitecore Solr Indexing Best Practices

Search downtime on Sitecore is rarely a Solr outage alone. It is a chain: publish events stall, the web index lags master, Coveo or headless serializers read stale fields, and marketing reports "search is broken" while Solr Admin still returns HTTP 200. Platform leaders need a shared vocabulary for Content Search vs xConnect Search, a documented index inventory, and rebuild windows measured on production volume before anyone promises a cutover date. This field note starts with basics for executives and architects, walks through cores, cadence, failure modes, and performance tuning, then points to official Sitecore documentation for deeper implementation work.

Executive summary

Sitecore XP and XM route almost every find-an-item workflow through Solr-backed indexes. Content Search indexes items in the content databases (master, web, core, marketing definitions). xConnect Search indexes experience data in separate xdb cores. Managed offerings (SearchStax on XM Cloud, SolrCloud on self-hosted XP) change hostnames and rebuild APIs, but the operational questions stay the same: which index is authoritative for delivery, how long a full rebuild takes, and who owns schema drift when an agency added custom computed fields three years ago.

• Blast radius: A stale sitecore_web_index affects live site search, personalization conditions that read index fields, and headless Layout Service payloads that embed search-driven lists.
• Cost driver: Full rebuilds during peak authoring hours compete with CM CPU, Solr heap, and network IO to the search cluster.
• Governance: Every custom IIndexable field and Solr dynamic field should live in source control with an owner and rollback plan.
• Cutover gate: Do not sign XP to XM migration until rebuild time, document counts, and spot checks on 50 high-traffic URLs pass on staging Solr.

Basics: two search frameworks, one operations team

Sitecore 10.4 documents two search frameworks. Treat them as separate on-call surfaces even when they share a Solr cluster.

Content Search

Indexes Sitecore items via the Content Search API. The index crawler runs inside the core Sitecore application on CM (and indexing strategy configuration on CD where applicable). Typical indexes include sitecore_master_index, sitecore_web_index, sitecore_core_index, plus marketing definition and FXM indexes on XP.

xConnect Search

Indexes contact and experience data. The xConnect Search Indexer runs as a Windows Service or Web Job, not inside the Sitecore content tree. Cores are commonly named xdb and xdb_rebuild. A broken xdb index does not always break content search, but it will break marketing automation lists, segmentation, and reporting that query xConnect.

Index vs core (vocabulary for ELT conversations)

In Sitecore UI and logs you see index names (sitecore_web_index). In Solr Admin you see core or collection names that may differ by prefix when using SolrCloud or SearchStax. Platform teams should maintain a one-page mapping table in the runbook wiki. Executives do not need Solr jargon in steering meetings, but they do need to know that "rebuild web" is not the same as "restart Solr."

Default Content Search index inventory

Use this as a starting checklist. Your environment may include additional marketing, testing, or custom indexes.

Sitecore index name	Primary database	Typical consumer	Rebuild impact
sitecore_master_index	master	Authoring search, Content Editor, some ops tools	Medium: slows authors, not live site
sitecore_web_index	web	Live site search, CD queries, many renderings	High: customer-facing findability
sitecore_core_index	core	Users, roles, system items	Medium: admin UX, security UI
sitecore_marketingdefinitions_*	master / web	Marketing Operations API	Medium: campaign tooling
sitecore_fxm_*	master / web	Forms Experience Manager	Medium: forms analytics
xdb / xdb_rebuild	xConnect	Segmentation, analytics search	High for marketing ops, not page HTML

Official index list and API differences: Search and indexing overview (Sitecore 10.4).

Topology: CM writes, CD reads, Solr scales in the middle

Classic XP places a Solr instance near CM for indexing and separate Solr nodes near CD for query load. SolrCloud (and SearchStax-managed Solr) consolidates shards and replicas behind a load balancer. Sitecore connects to the load balancer URL with solrCloud=true in connection strings; Solr.NET routing limitations mean you should not point CM at individual Solr nodes for production.

Decision questions for architects

• Do CM and CD share one Solr cluster or split Content Search vs xConnect Search hosts?
• Is Solr TLS terminated at the load balancer or on each node?
• What is the maximum acceptable lag between publish and searchable on web (minutes vs seconds)?
• On XM Cloud, which rebuild operations are self-service vs vendor ticket?

Document answers in the platform ADR folder before scaling CD horizontally. Adding CD servers without Solr query capacity shifts bottlenecks silently.

Indexing strategies and cadence

Sitecore indexing strategies control which items enter an index and when updates run. Strategies attach to indexes in configuration (App_Config/Include or environment-specific patches). The three operational modes you must distinguish in runbooks:

1. Incremental / event-driven: Item saves, publishes, and deletes enqueue updates. Normal steady state.
2. Full rebuild (Sync): Reprocesses all configured items. Required after schema changes, strategy changes, or corruption recovery.
3. Manual single-item refresh: Developer or support action from Indexing Manager or API for one-off fixes.

Schedule full rebuilds in maintenance windows. Measure duration on a staging clone with production item counts, not developer laptops. A rebuild that takes 45 minutes on staging with half the items is not a 45-minute production promise.

Indexing Manager (CM)

Control Panel → Indexing Manager lists indexes, document counts, and last update timestamps. Use it for operator visibility, not as the only monitoring source. Automate alerts on document count deltas and indexing lag.

PowerShell and C# rebuild entry points

Operators use PowerShell extensions or custom jobs; developers use Content Search API in tools and migration scripts.

# Sitecore PowerShell Extensions — rebuild one index (CM)
Get-SearchIndex -Name "sitecore_web_index" | Initialize-SearchIndex

# C# — same operation from a scheduled job or migration utility
using Sitecore.ContentSearch;
using Sitecore.ContentSearch.Maintenance;
var index = ContentSearchManager.GetIndex("sitecore_web_index");
IndexRebuildJob.Start(index);

Prefer index-scoped rebuilds over restarting Solr windows services unless JVM heap or corruption requires it.

Schema, computed fields, and managed schema population

Sitecore fields map to Solr field types through configuration and managed schema updates. When templates gain new field types, or custom AbstractIndexable providers emit new field names, Solr must accept those fields before indexing succeeds.

Populate Solr Managed Schema workflow

1. Deploy configuration and assembly changes to CM.
2. Open Control Panel → Populate Solr Managed Schema.
3. Select affected indexes and run Populate.
4. Run targeted or full rebuild per index risk assessment.

Skipping populate after adding computed index fields produces log errors like unknown field or class cast exceptions in custom providers. See Walkthrough: Setting up SolrCloud for SolrCloud-specific schema steps.

Common indexing failures (and how they present to the business)

Symptom	Likely technical cause	First response
Authoring search missing new pages	Master index lag or strategy excludes template	Check sitecore_master_index strategy roots and event queue
Live site search stale after publish	Web index not updating, CD reading wrong index	Compare master vs web document for item ID; rebuild web if needed
Indexing log timeout errors	Solr heap pressure, slow disk, oversized batches	Review Solr GC logs, reduce batch size, scale cluster
Field missing in JSON headless responses	Custom index field not in schema or not stored	Populate managed schema; verify return field list in computed provider
Marketing lists empty	xConnect indexer stopped	Restart xConnect Search Indexer service; check xdb core
Full rebuild never finishes	Single bad item crashes crawler loop	Binary search disable strategies; index single subtree to isolate item

Log locations worth tailing

• data/logs/Sitecore.ContentSearch*.log on CM
• Solr server log under server/logs for OOM and commit failures
• xConnect Search Indexer logs (service host) for experience data indexes

# Quick error scan on CM (adjust path to your instance)
Get-Content 'C:\inetpub\wwwroot\sitecore\data\logs\Sitecore.ContentSearch.Indexing.log' -Tail 500 |
  Select-String -Pattern 'ERROR|Exception|timeout' -CaseSensitive:$false

Performance optimization without guessing heap sizes

Solr tuning is iterative, but Sitecore-specific patterns repeat across clients.

CM-side levers

• Reduce indexing batch sizes when CM CPU spikes during publish storms.
• Separate heavy rebuild jobs from business hours authoring (scheduled tasks or ops windows).
• Disable unused indexes in non-production environments to shorten rebuild tests.
• Keep custom computed fields lean: storing large HTML blobs in Solr slows rebuild and query.

Solr-side levers

• Ensure SSD-backed storage for index directories; spinning disks fail first under merge pressure.
• Size heap based on index size guidance from Solr and your vendor (SearchStax publishes tier charts).
• Use Solr caching (filter cache, query cache) but measure hit rates; unbounded caches steal heap.
• For SolrCloud, confirm load balancer health checks match Sitecore connection timeout settings.

Query-side discipline

Developers often fix search slowness by adding Solr fields instead of fixing LINQ. Review Content Search queries in hot paths: prefer filters over heavy facets on CD, avoid unbounded Take() sizes, and cache stable queries at the rendering layer when business rules allow.

Rebuild runbook (staging first, production with a rollback timebox)

1. Announce window; freeze template and indexing config changes.
2. Snapshot Solr (or vendor backup) if policy requires fast rollback.
3. Rebuild lower-risk indexes first (sitecore_core_index, master) to validate schema.
4. Rebuild sitecore_web_index during agreed traffic trough.
5. Run automated diff: document count, sample 50 URLs, author search spot checks.
6. Record elapsed time and heap peak in the ops log for next capacity review.

If rebuild exceeds the rollback timebox, stop, restore snapshot, and open a Sev-2 with correlation IDs from ContentSearch logs. Partial success is worse than a clean rollback when marketing is mid-campaign.

XM Cloud and migration notes

Teams moving from XP to XM Cloud inherit different hostnames, managed Solr, and sometimes stricter self-service rebuild limits. Inventory Solr customizations early: dynamic fields, Coveo integrations, and custom crawlers do not migrate by default. Pair this post with the XP to XM migration question set on this site for cutover sequencing.

Further reading (official Sitecore documentation)

• Search and indexing overview (Sitecore 10.4) — framework comparison and index list.
• Scaling and configuring search — role scaling and provider options.
• Walkthrough: Setting up SolrCloud — connection strings, managed schema, SSL.
• Search and Indexing (developer configuration hub) — deep links to index configuration topics.
• Sitecore Solr Integration (2017 field archive) — step-by-step Solr 5.x install screenshots from an earlier integration project on this site.

Actionable checklist

• Publish index-to-core mapping wiki page with owners.
• Measure full rebuild duration on staging at production item counts.
• Export list of custom computed index fields to source control.
• Alert on ContentSearch error rate and web index document count deltas.
• Schedule full rebuilds outside peak authoring hours.
• Run Populate Solr Managed Schema after every indexing config release.
• Separate xConnect Search Indexer monitoring from Content Search alerts.
• Document publish-to-searchable SLA and test it weekly with a synthetic item.
• Keep Solr TLS and connection string changes in the same change ticket as Sitecore deploys.
• Before major releases, rebuild web on staging and run 50-URL parity script against production.