Search your content without running a search server
Every collection is searchable from a template with one call: AND, OR, quoted phrases and property-specific terms, ranked by the properties you say matter most.
{# Query syntax: a phrase, or, and a title-only term. Title hits rank first. #}
{% set query = '"cold brew" or title:espresso' %}
{% set results = cms.collection.search('blog', query, ['title', 'summary', 'tags']) %}
{# Relevance search: partial matches allowed, best coverage first #}
{% set results = cms.collection.searchScored('products', 'animated hamburger menu', {'name': 3, 'tags': 2}) %}
{% for item in results %}
<a href="{{ cms.collection.objectUrl('products', item) }}">{{ item.name }}</a>
{% endfor %}Search in Total CMS runs against a collection's index, so there is nothing to install and no search server to keep alive. Any property listed in the schema's index is searchable, including the attributes stored with it: index an image and its alt text and EXIF data are searched too. One call in a template, cms.collection.search(), returns the matching objects in the same shape as any other collection loop.
The query syntax is the part visitors notice. Searches are case-insensitive. Several words are an implicit AND, so brazil coffee finds objects containing both, even when the two words sit in different properties. Quotes make a phrase, or widens the match, and title:brazil restricts a term to one property. These combine, with one limit worth knowing: a query that mixes and with or is treated as all OR.
Ranking is yours to decide. Pass an ordered list of properties and a match in the first outranks a match in the second, so a hit in the title beats one in the summary. That ordering costs some processing, so keep the list short on a large collection.
Strict AND has a weakness: a long, descriptive query returns nothing if a single word is missing. cms.collection.searchScored() is the alternative. It keeps anything that matches at least one term and orders results by how many terms each matched, with optional per-property weights. The MCP search tools rank the same way, which is why an agent asking a wordy question gets the closest match instead of an empty list.
Where it stops. A front-end search covers one collection per call; there is no site-wide search page out of the box. The built-in search has no typo tolerance or synonyms, and it scans the index on every query, which is comfortable up to a few thousand objects per collection. Past that, or when relevance matters more than simplicity, the bundled Algolia Search extension (Pro) sends the MCP search tools through a hosted Algolia index and falls back to the built-in search if Algolia is unreachable.
At a glance
What you get
- A real query syntax
- Case-insensitive, with implicit AND, explicit or, quoted phrases and property-specific terms such as title:brazil. Visitors can combine them in one query.
- Searches what you index
- Any property in the schema's index is searchable, along with its attributes. Index an image and its alt text and EXIF data are searched too.
- You set the ranking
- Pass an ordered list of properties and a match in the first outranks a match in the second. A hit in the title beats a hit in the summary.
- Closest match, not no match
- searchScored() keeps partial matches and ranks them by how many query terms each matched, with optional per-property weights.
- Algolia when you outgrow it
- The bundled Algolia Search extension, a Pro feature, routes the MCP search tools through a hosted index and falls back to the built-in search if it is unavailable.
Search
Common questions
Does Total CMS have site-wide search?
Not as a single call on the front end. A template search covers one collection at a time, so a site-wide results page means running the search for each collection you want included and listing the groups. AI agents are the exception: the MCP server has a tool that searches across collections.
Which fields are searched?
Only properties listed in the schema's index. If a field is not in the index it is not searchable, so add the properties visitors will search on, such as title, summary and tags.
Does search handle typos?
The built-in search does not: it matches the words as typed, case-insensitively. For typo tolerance, prefix matching and synonyms, the bundled Algolia Search extension (Pro) can take over the MCP search tools.
How large a collection can it search?
The built-in search reads the collection's index on each query, which is fine up to a few thousand objects per collection. Beyond that, test your own data, keep the list of priority properties short, or move to Algolia.
Try it on a site of your own.
45 days, every Pro feature, no credit card. Build it, hand it to a client, and see what they can and can’t touch.