Choosing What to Index
Each indexed datastore is a row: what it is, and whether external visitors may reach it.
Where to find it
Architect Panel → Searching:
- Site Searching — the indexed datastores
Architect Panel → Data:
- Datastores — the datastores themselves
Architect Panel → Security:
- Permissions — what each searcher may see
Add one at a time
And look at the results afterwards. Each addition changes relevance for every search, and adding several at once makes it impossible to tell which one made results worse.
The external decision, per datastore
Ask directly: should somebody who is not signed in be able to find this?
- Published guidance, a public register, a product catalogue — yes, that is the point.
- Anything about people, anything internal, anything commercially sensitive — no.
Where you hesitate, the answer is no. It is trivially reversible in that direction and not in the other.
Do not index working data
Datastores full of drafts, internal notes or intermediate records make search worse for everybody — the useful result is buried among things nobody was looking for.
Index what people search for, not everything that exists.
More indexed is not better
The instinct is to index everything so nothing is missed. The effect is that everything is found and nothing is prominent, and people stop using search because it never gives them the answer first.
Review after a schema change
Renaming or removing fields changes what is searchable. A datastore reworked significantly is worth re-checking, because search will quietly stop finding what it used to.
Watch what people search for
Repeated searches returning nothing are the most useful signal available — either something should be indexed and is not, or people are using vocabulary your data does not contain.
Both are fixable, and neither is visible unless somebody looks.
Test with real terms
The words people actually type — a surname, a reference, a part of an address — rather than a term you know will match. Test terms chosen by the person who built the index prove very little.
Worked example
A team indexes its cases datastore, checks results, then adds organisations a week later. When a third addition made surname searches noticeably worse, it was obvious which change had caused it, and its scope was narrowed rather than removed.
Recommendations
- Add one datastore at a time.
- Default the external flag to no when unsure.
- Do not index working data.
- Test with terms real users type.