Sitecore

Solr Search Notes from a Bad Rebuild Night

If the index is stale, don't add another computed field first. Rebuild the right core.

We added a field because search 'felt off.' The core was just old. I still add fields when I'm impatient.

We added a field because search 'felt off'

The core was just old. I still add fields when I'm impatient. Impatience looks like engineering. It isn't. Check core, crawler, and the query. In that order. I skipped step one. Spent two hours in a schema I wasn't using. The site wasn't even pointed there. That's a special kind of tired.

If the index is stale, don't add another computed field first. Rebuild the right core. Tell marketing the window. They'll search during it anyway. Warn them twice. Twice is the minimum. Once is a rumor.

Order of operations

Confirm which core the site hits. Confirm the crawler last run. Then look at the query. Write the core name on a sticky. I know. Stickies again. They work on search too. If the sticky and the config disagree, the config is lying or you are. Find out which.

Last crawl time is a number you should be able to say in standup. If you can't, you don't have search ops. You have hope. Hope doesn't index.

Computed fields

They're fine. They're also a way to hide a bad source field. If the raw field is empty, a computed one won't save you. I learned that on a product title. Empty in, poetry out, still empty for the user. Poetry doesn't rank.

If you must compute, log the source field in a debug view you can hit without a deploy. If you can't see source, you'll argue about Solr when XM is blank. I've argued. Solr won the argument and still wasn't the problem.

  • Core name on a sticky.
  • Last crawl time.
  • One test query you always run.
  • Rebuild off peak.

Rebuilds

Off peak. Watch memory. Don't start a rebuild because a meeting is awkward and you want to look busy. I've seen that rebuild. It finished in the morning rush. Search went weird in the rush. Of course it did.

Have one test query you always run. If that query fails, you don't ship content tricks. You fix search. Content tricks on a dead core are interior design on a house fire.

Queries

Copy the live query, not the one from a blog. Blogs assume your schema. Your schema is yours. I wasted time on a blog query that searched a field we didn't index. It returned nothing with great confidence.

When results are 'a bit off,' dump the first three IDs and open the items. Look with your eyes. Eyes beat relevance debates at 4 p.m.

Further reading

Sitecore Solr docs for your version. Your own last rebuild notes. If you don't have notes, that's the first doc you write. Date. Core. Duration. Memory. Who approved the window. Future you will want that. Future you is ungrateful but right.

Checklist

Core. Crawler. Query. Then fields. Then rebuild. If you reverse that, you'll add fields to the wrong core and call it a week. I've called it a week. It wasn't a week. It was a wrong core.

Monday

Say the core name out loud with a teammate watching the config. If you disagree, you don't rebuild anything. You fix the disagreement. Then you pick a window. Then you warn marketing twice. Then you rebuild. Then you run the test query. Then you go home.

The Miss

Rebuild All on a Friday because a dashboard was yellow. Saturday search died. I still don't rebuild on Fridays. Yellow can wait. Saturday cannot.

The Hold

No Rebuild All as a habit. Delta. Explain. Off-peak. Ticket. If you can't explain, you don't rebuild. Yellow is not an explanation.

How We Roll It

One core. One query. One owner. We watch that query after a publish. If it's slow, we talk about that core. We don't talk about 'search' as a blob. Blob talk is how Rebuild All gets typed.

What Broke Anyway

Someone wanted a nightly rebuild 'to be safe.' Safe is the word that burns weekends. I said no. I said it twice. The second time I put it in the runbook in bold. Bold is not a personality. It's a scar.

Checklist

Delta. Explain. Off-peak. Ticket. If Rebuild All appears in a chat, the chat is already wrong.

If You Only Do One Thing

Pick the query that makes money or makes authors swear. Put it on a sticky. That's your search program. The rest can be ugly a while.

I wrote the query on a card because Confluence was a maze. The card is in my bag. The maze can keep the rest.

What I Won't Do

I won't treat Solr like a mystery box you kick. Kicking is Rebuild All. I already did that. I'm not doing it again for a color.

Saturday Search

Authors couldn't find a press release. The release was there. Solr wasn't. Rebuild All on Friday had been 'just in case.' Just in case ate Saturday. I drove in. I don't like driving in. I like delta indexes more now.

The dashboard was still yellow after the rebuild. Yellow was a replica lag, not a corrupt core. We kicked the wrong thing. I wrote 'yellow is not explain' on the runbook. It's still there. The ink is ugly.

The Query On A Card

It's the query that fills the mega menu. If that query is slow, money is slow. Other queries can be ugly. This one gets a name and an owner. Owner is a person who hates phone calls on Saturday. That's a good owner.

Confluence has a longer version. Nobody opens it. The card is in my bag. I photocopied it for the drawer. Two copies. Solr can have a drawer too.

Nightly Rebuild, The Sequel

They asked again. I said no again. Bold in the runbook. If someone runs it anyway, that's an incident, not a preference. I want it to feel that heavy. It is that heavy.

Further reading

Actionable checklist

  • Check your current Solr index settings and performance stats.
  • Make sure your indexing strategies match how often you update content.
  • Double-check schema definitions for correctness and relevance.
  • Set up a failure matrix to track common problems and solutions.
  • Plan regular index rebuilds to keep content current.
  • Adjust Solr performance settings based on traffic patterns.
  • Review logs for indexing errors and deal with them quickly.
  • Document the rebuild runbook and share it with the team.
  • Backup Solr data often to avoid losses during failures.
  • Stay updated with Sitecore documentation for best practices.