Your data
Plan your records
What a record should be, which fields to give it, and what to leave out, for products, docs, articles, listings, and places.
Search works best when each record is one thing a person is looking for, with the fields they search, narrow by, and see in results. This page covers what applies to any data, and the pages after it have a recipe for each kind:
| Your data | One record per | Recipe |
|---|---|---|
| A store's catalog | Product, or product color | Products |
| Documentation or a help center | Section of a page | Docs and help centers |
| Blog posts, news, papers, or a knowledge base | Article | Articles and research |
| Homes, rentals, jobs, a directory, or store sites | Listing or place | Listings and places |
Each kind also has a use case page with a live demo.
Choose what a record is
A record is what a search result links to, so ask what people click:
- Too big, such as a whole manual as one record: it matches nearly every search, and opens at the top of a long page.
- Too small, such as one record per shoe size: the same product shows once per size.
Findlane doesn't group results, so choose the level you want each result to be.
Give each field a job
| Job | Fields such as | Setting |
|---|---|---|
| Searched | title, brand, description | searchableAttributes, up to five |
| Narrowed by | category, brand, price, year | facetFields and filterFields |
| Sorted by | price, published, popularity | sorts |
| Shown in results | url, image, summary | Returned with each hit |
| Placed on a map | _geoloc | locationField |
- Search the short, precise fields first. A title says more about a record than its description, so give it more weight. The first two searchable fields hold 1 KB of text each and the other three 16 KB each, so list titles, names, and brands first and long text last. A record with more text than its field holds is rejected: cut the text, or split the record.
- Use the right types. Prices and counts are numbers, yes-or-no values are
trueorfalse, and dates are numbers, such as Unix seconds, so they can be filtered by range and sorted. Once a field is a filter, facet, or sort, its type is fixed. - Use lists for several values, such as
"tags": ["waterproof", "vegan"]. A list matches a filter when any of its values does, and each value counts in facets. You can't sort by a list. - Include what results show, such as
urlandimage, so a page can show a hit without asking your server for more. - Keep IDs stable. Use your database's ID as the
objectID, so an update replaces the right record.
Leave out what isn't public
Browser search can read every field you upload, unless the index's public policy limits it. Leave out cost prices, supplier details, internal notes, customer data, and anything else you wouldn't publish, or limit browser search to the fields it needs.
Records that only signed-in people may see belong in their own index, searched from your server with a search key, never from the browser.
One index per kind and language
- Kinds of data. A store's products and its help center need different fields and settings, so give each its own index, and send a search to each to show both.
- Languages. Keep each language's records in their own index, with its
languagesset, so common words and plurals match that language. - Stores and sites. One index each, so each has its own records, settings, and allowed origins.
Plans set how many indexes and records a workspace has; see Limits.
Keep records current
Write changes as they happen, and replace everything now and then so deleted records leave search too. See Keep records in sync.
Let an agent do it
An AI agent connected to Findlane's MCP server reads these pages. Ask it to add search to your app, and it decides what a record is, loads your data, and chooses the settings.