Search Several Content Types in One Index

A site search usually spans different kinds of content — books, articles, events, authors, pages, series — and users expect one search box, one ranked list, and counts per type.

Indx handles this with one dataset and a type field. Documents in a dataset do not need the same shape; fields that only some documents have are simply absent on the others.

Load everything into one dataset

json

[
  { "id": "book-4711",   "contentType": "book",   "title": "Sult",        "author": "Knut Hamsun", "isbn": "978…" },
  { "id": "article-88",  "contentType": "article","title": "Hamsun i dag", "body": "…",             "publishedAt": "2026-03-01" },
  { "id": "event-17",    "contentType": "event",  "title": "Forfattermøte", "startsAt": "2026-10-02", "venue": "Litteraturhuset" },
  { "id": "author-9",    "contentType": "author", "name": "Knut Hamsun",  "bio": "…" }
]

Configure the fields once:

contentType — Filterable + Facetable. This gives per-type counts in every search response and lets a tab or chip narrow to one type.
title, name, body, bio — Searchable, with weights that express priority (title 2.0, author/name 1.5, body 1.0).
Type-specific fields (isbn, startsAt, venue) — Filterable/Sortable as needed. A filter on startsAt simply never matches books.

One request, ranked across types, with counts

json

POST …/search
{ "text": "hamsun", "maxNumberOfRecordsToReturn": 20, "enableFacets": true }

The response is one ranked list mixing books, articles, events and the author, and facets.contentType carries the count per type for the same query — the numbers you show on "Books (12) · Articles (4) · Events (1) · Authors (1)". Add a value filter on contentType to switch to a single-type view; the facet counts still reflect the full query so the tabs keep their numbers.

Key field

Give every document a key that is unique across types ("book-4711", "event-17"), or declare an auto-generated key. Numeric ids that collide across source systems must be prefixed.

When to use separate datasets instead

Only when the types have separate access rules, wildly different update cadences, or must be searched independently by different clients. Each dataset is its own index and its own search call; there is no cross-dataset search, so "one box, one list" needs one dataset.