Studio search configuration

Global search for Sanity Studio allows content search, can hide specific documents, and allows custom field weighting.

The global search for Sanity Studio lets you search your Content Lake dataset for any document that matches your term, or narrow down by filtering your query by schema types. You can activate the global search from the 🔍 icon in the top toolbar, or with the ctrl/cmd + k hotkey.

There may be instances where you want to keep specific documents from appearing in the search results. To hide search results for a particular document type and remove it as a selectable filter, set the __experimental_omnisearch_visibility property to false on the document type:

{
  type: 'document',
  name: 'author',
  fields: [
    {name: 'name', type: 'string'},
    // ...
  ],
	// Hide all results for authors (and the author document type filter) in omnisearch
	__experimental_omnisearch_visibility: false,
  // ...
}

• You have workflow-related documents that you don’t wish to expose editors to.
• You want to hide documents that are less frequently used by editors.
• You’re an author of a Sanity plugin that registers its own document schema and would prefer it doesn't appear in user's studios.

You can define specific weights on searchable fields for document types.

Search weights are configurable via options.search.weight. Here's an example:

{
  type: 'document',
  name: 'author',
  fields: [
    {
      name: 'name',
      type: 'string',
      options: {
        search: { weight: 10 },
        // ...
      }
    },
    {
      name: 'description',
      type: 'array',
      of: [{type: 'block'}],
      options: {
        search: { weight: 10 },
        // ...
      }
    }
    // ...
  ],
  // ...
}

Define your desired search strategy in the sanity.config.js|ts file. Accepted values are groqLegacy, groq2024, and textSearch.

You must be on Studio version v3.70.0 or greater to define strategy and opt-in to groq2024.

import { defineConfig } from 'sanity`

export default defineConfig({
 search: {
   strategy: 'groq2024'
 },
})

Default search strategy in current studio versions.

Considered experimental and opt-in only until the underlying API is moved to a versioned endpoint.

Updates compared to groqLegacy search:

• Improved performance for large datasets.
• The ability to search deeply nested content beyond the default five levels that groqLegacy is restricted to today.
• The ability to search all Portable Text content.
• Support for “Google-style” query string parsing. In the below query string, wine, good vintage, and fruit* must all be present in order for the query to match. In other words, there is an implicit “and” between the words. Results with beer in will be omitted.

wine -beer "good vintage" fruit*

• Text search operates on all tokens that are 1 character or longer, up to 255 character maximum.
• _ is not a word-breaking character.
• Punctuation is ignored.
• Apostrophes are not word-breaking: bob does not match bob's or vice versa.
• All words and phrases (with/without wildcards) must appear in at least one attribute value.
• Negations do not match any attribute values.
• Phrases must not match across attribute values (i.e. half matching one value and another half matching another value).

Search strategy some customers may use for historic purposes but not a recommended strategy. This will likely be deprecated in the future.

• Global weight multiplier: Search weights act as global multipliers across all document types. For instance, if the name field in the customer type has a weight of 2, and the author type has a weight of 4, then author documents will rank higher than customer documents for identical name matches in search results.
• Default search configuration:
  • The field designated as the title in the preview config automatically receives a search weight of 10, while the subtitle field gets a weight of 5.
  • Any user-specified weight overrides default settings, ensuring custom search relevance can be achieved as needed.
  • If you have customized the preview options using a prepare function search weights cannot be inferred from the preview configuration so explicit custom field weights must be used if you want to boost specific fields.
  • If you have a reusable custom type you need to define search weighting on the type definition itself.
  • Fields marked as hidden: true in the preview config are scored lower to push them lower in the result set.