Site Search

How Site Search Works

Search looks across the datastores you have indexed, rather than across everything.

Where to find it

Architect Panel → Searching:

• Site Searching — which datastores are indexed and their external visibility

Architect Panel → Data:

• Datastores — the datastores being indexed

Indexing is opt-in

A datastore is searchable because you added it, not by default. That is the right posture — search is a way to reach data, and everything reachable should be a decision.

Permissions still apply

Being indexed does not make something visible to everybody. A search returns what the person is allowed to see, so two people searching the same term legitimately get different results.

Search is not a way around access control, and worth saying plainly because people assume otherwise.

The external flag is the one to think about

Each indexed datastore carries a setting for whether it can be reached by external search — which decides what an anonymous or public visitor can find.

That is a materially different question from what a signed-in user sees, and it is the setting most worth reviewing deliberately. Something indexed for staff convenience and left externally visible is a disclosure that nobody configured on purpose.

Index what people look for

Not everything. A search returning results from twelve datastores is harder to use than one returning results from the three people actually search — relevance drops as breadth rises.

Start with the datastores people genuinely need to find things in, and add on evidence.

Search finds records; it does not report

The distinction people conflate. Search answers "where is the thing I am thinking of". Reporting answers "how many" and "which ones match these criteria".

Somebody using search to build a list is using the wrong tool, and will get an answer that looks complete and is not.

Check what an anonymous visitor gets

Before going live, search as somebody signed out. It is the only reliable way to confirm the external setting does what you intended, and it takes a minute.

Worked example

An organisation indexes three datastores for staff and marks only its published guidance externally searchable. Signing out and searching confirms guidance is findable and nothing else is — which caught one datastore that had been left external during testing.

Recommendations

• Index deliberately, starting with what people search for.
• Review the external flag on every indexed datastore.
• Search signed out before going live.
• Do not use search as reporting.

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.

Presenting Results

What a result shows decides whether somebody finds what they wanted or gives up.

Where to find it

Architect Panel → Searching:

• Site Searching — the indexed datastores and their output

Architect Panel → Layout & Pages:

• Browse Views — where a searcher often ends up next

A result must be distinguishable

The single most important thing. Five results all reading "J Smith" force the searcher to open each one — which is slower than not having searched.

Include whatever separates them: a town, a reference, a date, an organisation. One extra field usually turns an unusable result list into an obvious choice.

Say what kind of thing it is

Where several datastores are indexed, a result should make clear whether it is a case, a person or a document. Without that, a mixed list is confusing and people click the wrong things.

The first three results decide everything

People look at the top of the list and, if the answer is not there, conclude search does not work — rather than scrolling. So relevance at the top matters far more than completeness further down.

If the right answer is consistently fourth, that is a problem worth fixing even though the search is technically working.

Show enough, not everything

A result carrying six fields is as hard to scan as one carrying one. Two or three well-chosen pieces of information — the identifier, something distinguishing, and the type — is usually right.

Handle no results properly

An empty list is a dead end. Say plainly that nothing matched, and give a route onward — a suggestion to broaden the term, a link to browse, or a way to create the thing they were looking for.

Without that, somebody who searched for a customer who is not there will type the name into a free-text field and carry on, which is how unlinked data appears.

Take them somewhere useful

Clicking a result should open the thing, at the place they need. A search that lands somebody on a record and leaves them to navigate has done most of the work and stopped short.

Test as somebody who does not know the data

The person who built the index knows exactly what to type. Watch somebody else search for something — it is the fastest way to find that your results are indistinguishable or your vocabulary is wrong.

Worked example

A results list showed only names, so "Smith" returned nine indistinguishable rows. Adding the town and account number made the right one obvious, and the "no results" message now offers to create a customer — after several were found typed into notes fields instead.

Recommendations

• Include a distinguishing field in every result.
• Show the record type where several are indexed.
• Give no-result searches a route onward.
• Watch somebody else search before deciding it works.