Suche

Clientseitige Suche, die ohne API-Schlüssel sofort funktioniert, plus gehostete und semantische Adapter, zu denen du wechseln kannst, wenn deine Doku wächst.

Blume liefert lokale Suche ohne gehostete Infrastruktur und ohne API-Schlüssel. Sie läuft im Browser, funktioniert sowohl in blume dev als auch in blume build und indexiert nur deine echten Inhalte — Navigationselemente und ausgeschlossene Seiten werden übersprungen. Wenn du sie irgendwann überwachsen hast, kannst du zu einem gehosteten oder semantischen Backend wechseln, ohne dass sich Aussehen oder Verhalten der Suche ändern — nur der Adapter, den du an search übergibst, ändert sich.

Jedes Backend ist ein Adapter, der aus blume/search importiert wird: Orama (der Standard), FlexSearch, Pagefind, Algolia, Orama Cloud, Typesense und Mixedbread. Jeder Adapter verwaltet seine eigenen Optionen, seine Laufzeitabhängigkeit und die Geheimnisse, die er braucht. Orama und Pagefind werden mit Blume ausgeliefert; das SDK jedes anderen Adapters ist eine optionale Peer-Dependency, die du selbst installierst, sodass die Wahl eines Backends nie die anderen mitzieht. Fehlt es, bricht blume build ab, bevor Vite läuft, und nennt das Paket sowie den Befehl, mit dem du es installierst; auch blume doctor meldet es.

import { defineConfig } from "blume";
import { algolia } from "blume/search";

export default defineConfig({
  search: algolia({
    appId: "YOUR_APP_ID",
    apiKey: "YOUR_SEARCH_ONLY_KEY",
    indexName: "docs",
  }),
});

Ein Adapter ist eine schlichte Beschreibung des Backends — kein aktiver Client —, sodass Blume ihn in die generierte Website und in ein per Eject erzeugtes Projekt einbetten kann. Übergib den Adapter direkt oder verwende die Objektform, wenn du daneben auch die Optionen für beliebte Links, die Indexierung oder Analytics setzen willst:

import { pagefind } from "blume/search";

search: {
  provider: pagefind(),
  popular: [{ href: "/guides/getting-started", icon: "rocket", label: "Getting started" }],
  indexing: { includeCodeBlocks: true },
},

Suche verwenden

Öffne die Suche über das Suchsymbol im Header, mit ⌘K (oder Ctrl K) oder indem du / drückst, wenn du gerade nicht in einem Feld tippst. Esc schließt sie, und ⌘J (oder Ctrl J) blendet die Ergebnisvorschau ein und aus.

Suchanfragen treffen auf Titel, Beschreibungen und Fließtext von Seiten, wobei Titeltreffer am höchsten und Beschreibungen über dem Fließtext bewertet werden.

Beliebte Seiten

Bevor ein Leser eine Suchanfrage tippt, zeigt der Suchdialog eine Beliebt-Liste. Standardmäßig sind das die ersten sechs Seiten der Seitenleiste — was auf Websites mit mehreren Tabs oft den falschen Bereich hervorhebt. Hefte stattdessen die gewünschten Links an:

search: {
  popular: [
    { href: "/guides/getting-started", icon: "rocket", label: "Getting started" },
    { href: "/guides/install", icon: "download", label: "Install" },
    { href: "/concepts/overview", label: "Overview" },
  ],
},

Jeder Eintrag benötigt ein href (interne Route oder externe URL) und ein label, dazu optional ein icon — der Name eines integrierten Icons, ein Bildpfad bzw. eine Bild-URL oder ein Inline-SVG (dieselben Eingaben wie bei Nav-Icons), standardmäßig ein Datei-Symbol. Lass popular weg oder leer, um den Fallback auf die Seitenleiste beizubehalten. Lässt du provider in der Objektform weg, bleibt es beim standardmäßigen Orama-Adapter.

Schreibe href so, als wäre die Website im Stammverzeichnis eingehängt — ein basePath wird für dich angewendet, genau wie bei navigation.featured. Externe URLs werden unverändert durchgereicht.

Was indexiert wird

Für Orama, FlexSearch, Algolia, Orama Cloud und Typesense — sowie für das search_docs-Tool des MCP-Servers — indexiert Blume den Titel, die Beschreibung und den auf reinen Text reduzierten Fließtext jeder Seite: Codeblöcke, Bilder und Markup werden entfernt, damit die Ergebnisse relevant bleiben. Diese Indizes werden aus deinen Quelldateien erstellt und sind daher in der Entwicklung und in der Produktion identisch. Pagefind indexiert stattdessen das gebaute HTML, und Mixedbread synchronisiert dein rohes Markdown, sodass beide immer auch Code durchsuchen.

Wenn deine Doku bei durchsuchbaren Begriffen wie Optionen, Methoden oder Fehlernamen auf Codebeispiele setzt, nimm eingefassten Code ausdrücklich in die quellbasierten Indizes auf:

search: {
  indexing: {
    includeCodeBlocks: true,
  },
},

Der Inhalt und der Titel jedes Code-Fences (blume.config.ts oben) werden durchsuchbar; die Sprache und die Fence-Marker nicht. Auf .mdx-Seiten liest der Index Komponenten als den Text, den sie anzeigen — den Titel einer Card, das Label eines Tab, die Beschreibungen einer TypeTable — und nutzt dabei dieselben Serializer wie die Agent-Oberflächen, sodass ein agents.markdownComponents-Eintrag auch deine eigenen Komponenten abdeckt. Auf Pagefind oder Mixedbread hat die Option keine Wirkung. Rechne damit, dass der Index mit deinen eingefassten Inhalten wächst — der Client-Index wird an jeden Leser ausgeliefert, gehostete Adapter speichern mehr (die Algolia-Synchronisierung teilt eine lange Seite auf mehrere Datensätze auf), und ein Treffer innerhalb eines Fences zeigt im Ergebnisauszug flach dargestellten Code.

Auf einer versionierten Website beziehen sich die Ergebnisse standardmäßig auf die gerade angesehene Version, mit einem „Alle Versionen“-Schalter in der Fußzeile des Dialogs (der pro Leser gemerkt wird). Treffer aus anderen Versionen nennen ihre Version in der Zeile. Orama, FlexSearch, Algolia und Typesense berücksichtigen diese Eingrenzung — gehostete Datensätze tragen eine version-Facette, wobei die aktuelle Doku als "current" hochgeladen wird. Pagefind, Orama Cloud und Mixedbread grenzen nicht nach Version ein: Ihre Ergebnisse umfassen alle Versionen, und der Dialog lässt den Schalter weg.

Auf einer Website mit i18n beziehen sich die Ergebnisse standardmäßig auf die Sprache der gerade angesehenen Seite, mit einem „Alle Sprachen“-Schalter daneben (ebenfalls pro Leser gemerkt). Orama und FlexSearch filtern ihren Index im Browser, und Algolia, Orama Cloud und Typesense filtern nach der locale, die jeder Datensatz trägt. Pagefind führt einen Index pro Sprache: Es durchsucht den der Seite, und mit „Alle Sprachen“ bindet es die übrigen ein, die es dann mit der Wortstammbildung der Seitensprache durchsucht. Mixedbread grenzt nicht nach Sprache ein: Seine Ergebnisse umfassen alle Sprachen, und der Dialog lässt den Schalter weg.

Ranking

Zwei Frontmatter-Felder bestimmen, wie eine Seite gerankt wird. search.keywords listet zusätzliche Begriffe auf, über die die Seite gefunden wird, selbst wenn ihr Text sie nicht verwendet. Das eignet sich für eine Seite, nach der Leser unter einem alten Namen, einem Akronym oder dem Begriff eines Mitbewerbers suchen. search.boost multipliziert die Relevanz der Seite: Werte über 1 schieben sie nach oben, Werte unter 1 nach unten.

search:
  keywords: [install, setup, getting started]
  boost: 3

Beschränke Boosts auf ein paar Seiten, die Leser am häufigsten brauchen, etwa einen Schnellstart oder eine Übersicht, mit Werten von 2 bis 5. Verwende einen Wert unter 1, z. B. 0.5, für eine Seite, die unter anderen, ebenso gut passenden Seiten landen soll, etwa eine veraltete Anleitung. Bleib mit Boosts unter 10: Darüber übertönt ein Boost, wie gut eine Seite passt, und die Seite landet bei Suchen ganz oben, zu denen sie kaum passt.

Wie stark ein Boost eine Seite verschiebt, hängt vom Adapter ab:

Orama (der Standard) und FlexSearch multiplizieren jeden Treffer vor dem Sortieren mit dem Boost seiner Seite, sodass ein Boost von 3 genau dreifach zählt. Der MCP-Server und die Suche des Assistenten ranken auf dieselbe Weise.
Pagefind gewichtet den Text einer geboosteten Seite stärker. Es dämpft wiederholte Treffer, daher fällt der Anstieg kleiner aus als der Multiplikator: Ein Boost von 5 rankt die Seite höher, allerdings eher nur etwa doppelt so hoch. Pagefind wertet einen Boost über 10 als 10.
Algolia sortiert unter Ergebnissen, die etwa gleich gut passen, nach Boost, sodass ein Boost knappe Entscheidungen klärt, ohne einen schwächeren Treffer über einen starken zu heben. Die Synchronisierung fügt desc(boost) zum Custom Ranking des Index hinzu, hinter jedem Ranking, das du selbst festgelegt hast.
Typesense sortiert nach Relevanz und dann unter Ergebnissen mit gleichem Relevanzwert nach Boost, sodass ein Boost Gleichstände auflöst, ohne einen schwächeren Treffer über einen starken zu heben.
Orama Cloud ruft eine größere Ergebnismenge ab und sortiert sie nach Relevanz mal Boost neu.
Mixedbread durchsucht deinen eigenen Store, in den Blume nichts hochlädt, daher kommen Boosts und Keywords dort nicht an.

Keywords sind bei jedem Adapter außer Mixedbread durchsuchbar.

Suchanalysen

Wenn ein Analytics-Adapter konfiguriert ist, meldet die Suche, wonach Leser suchen. Eine Suchanfrage wird erfasst, sobald sie sich gesetzt hat — nach einer Sekunde ohne Tippen oder wenn der Leser ein Ergebnis auswählt oder den Dialog schließt — und zwar als search-Event mit der query, der Anzahl der results und dem path, von dem aus gesucht wurde. Eine Suchanfrage ohne Ergebnisse erscheint mit results: 0, sodass ein Filter darauf zeigt, was deine Doku noch nicht abdeckt. Die Auswahl eines Ergebnisses sendet ein search_select-Event mit der query, der 1-basierten position des Ergebnisses, seiner url und dem path, von dem aus es ausgewählt wurde, damit du Click-throughs auswerten kannst.

Suchanfragen werden so gesendet, wie sie eingetippt wurden, mit bis zu 100 Zeichen. Dein Analytics-Tool sieht sie so, wie es die Suchbegriffe jeder anderen Seite sieht — behandle sie also als Leser-Eingaben: Ein Leser kann eine E-Mail-Adresse oder einen Schlüssel in das Feld einfügen, und Google Analytics und Plausible untersagen das Senden personenbezogener Daten. Um den Text von Suchanfragen von deinen Anbietern fernzuhalten, schalte ihn ab:

search: {
  analytics: { queries: false },
},

Die Events search und search_select tragen dann statt query das Feld queryChars, die Länge der Suchanfrage. Der Text wird nur über das DOM-Event blume:track weitergegeben, als query in detail.props, sodass ein selbst geschriebener Listener ihn dorthin weiterleiten kann, wo er deiner Meinung nach hingehört — so wie der Assistent mit Fragen umgeht. Bei aktivierter Cookie-Einwilligung werden nur Leser gezählt, die Analytics zugestimmt haben.

Adapter

Die clientseitigen Adapter kommen ohne Schlüssel aus und benötigen keine Optionen — ihre Clients werden aus i18n konfiguriert (bzw. bei Pagefind aus dem gebauten HTML), daher wird eine unbekannte Option von der Konfigurationsvalidierung abgelehnt statt ignoriert. Die gehosteten nehmen öffentliche Zugangsdaten entgegen (die gefahrlos an den Browser ausgeliefert werden können) und lesen ihren geheimen Admin-Schlüssel zur Buildzeit aus einer Umgebungsvariablen — das Geheimnis landet nie in der Konfiguration oder im Client-Bundle. Jede Option, die du einem gehosteten Adapter übergibst, bleibt unverändert erhalten und wird an dessen Suchclient im Browser weitergereicht (bzw. bei Mixedbread an den Such-Endpunkt), sodass auch eine Option, die Blume nicht ausdrücklich benennt, beim SDK ankommt — bei Algolias liteClient, dem Typesense-Client oder OramaClient. Diese Optionen müssen JSON-Werte sein — der Deskriptor wird als Literal in das generierte Projekt eingebettet, sodass eine Funktion, undefined oder ein BigInt mit einer Pfadangabe an der Konfigurationsvalidierung scheitert, statt unterwegs zu verschwinden.

Algolia, Orama Cloud und Typesense laden deine Seiten am Ende jedes blume build in ihren Index hoch. Ist der Admin-Schlüssel nicht gesetzt, warnt der Build und überspringt den Upload, sodass ein Build ohne Geheimnisse, etwa ein lokaler, trotzdem funktioniert. Ist der Schlüssel gesetzt und schlägt der Upload fehl (ein falscher Schlüssel, ein nicht erreichbarer Host, ein abgelehnter Datensatz), bricht der Build mit BLUME_SEARCH_SYNC_FAILED ab, statt gegen einen Index zu deployen, den er nicht aktualisiert hat.

Orama (Standard)

Blumes Standard-Engine. Sie erstellt einen JSON-Index, der unter /blume-search.json ausgeliefert wird, und fragt ihn im Browser ab — sofort, clientseitig und in blume dev live beim Bearbeiten. Keine Schlüssel, kein Dienst. Wenn du search ganz weglässt, wird sie ausgewählt; schreib sie nur aus, wenn du es explizit machen willst:

import { orama } from "blume/search";

search: orama(),

Nicht-lateinische Schriften

Der Standard-Tokenizer behält nur lateinische Buchstaben und Ziffern, sodass Text in jeder anderen Schrift — Japanisch, Chinesisch, Koreanisch und Thai, aber ebenso Russisch, Griechisch, Hebräisch und Hindi — sonst überhaupt keine Treffer liefern würde. Blume erledigt das für dich: Seiten in einer Sprache, die auf eine nicht-lateinische Schrift verweist, werden mit einem wortsegmentierenden Tokenizer indexiert (aufgebaut auf dem in Browser und Node nativ verfügbaren Intl.Segmenter). Die Sprachen deiner Website zu deklarieren, ist alles, was nötig ist:

i18n: {
  defaultLocale: "ja",
  locales: [{ code: "ja", label: "日本語" }],
}

Dieselben Tokenizer bedienen den Suchdialog, das search_docs-Tool des MCP-Servers und die Fundierung des Assistenten. Entscheidend ist die Schrift, nicht der Sprachname — az-Cyrl wird segmentiert, sr-Latn nicht. Bei einer nicht-lateinischen Standardsprache teilen sich alle Seiten den Tokenizer der Standardsprache: Lateinische Wörter überstehen die Segmentierung unverändert, sodass Seiten auf Englisch neben der Standardsprache durchsuchbar bleiben. Bei einer lateinischen Standardsprache behalten Seiten in lateinischer Schrift den Standard-Tokenizer, und jede Übersetzung in einer nicht-lateinischen Schrift erhält den ihrer eigenen Sprache, sodass die Seiten einer englischen Website auf Japanisch und Hindi sowohl aus ihrer eigenen Sprache heraus als auch bei einer Suche über alle Sprachen durchsuchbar sind. Der Standard-Tokenizer entfernt Akzente und schreibt Buchstaben ohne abtrennbaren Akzent aus (ø als o, ł als l, ß als ss), sodass cafe auch café findet und lodz auch Łódź, und auch der Suchdialog und die Auszüge des Assistenten finden das akzentuierte Wort auf der Seite. Wo Akzente Wörter unterscheiden (schwedisch ändra und andra, vietnamesische Töne), trifft eine Suchanfrage auch auf Wörter, die sich nur in diesen Akzenten von ihr unterscheiden.

Bei Japanisch und Chinesisch geht es noch einen Schritt weiter. Segmentierung allein indexiert einen zusammengesetzten Begriff als seine Bestandteile — 資金決済法 als 資金, 決済 und 法 — wodurch eine Seite, die jeden Bestandteil irgendwo erwähnt, die Seite überflügeln kann, um die es beim Begriff eigentlich geht. Han, Hiragana und Katakana werden deshalb als überlappende Zeichenpaare indexiert, und Abfragen auf diesen Indizes bevorzugen Seiten, die die Paare eines Begriffs gemeinsam tragen, und lockern auf Treffer mit beliebigen Paaren, wenn keine Seite alle trägt — so liefert auch das Tippen eines ganzen Satzes noch die passendsten Seiten. Koreanisch und Thai behalten ihre segmentierten Wörter.

FlexSearch

Eine zweite schlüssellose, clientseitige Option (installiere flexsearch). Sie verwendet denselben /blume-search.json-Index wieder, den Orama ausliefert, und baut im Browser einen FlexSearch-Dokumentindex auf. Funktioniert in blume dev und blume build.

FlexSearch hat keinen vergleichbaren Segmentierungs-Hook, daher solltest du für Websites in nicht-lateinischer Schrift Orama (den Standard) oder Pagefind bevorzugen, dessen pagefind_extended-Binary eine breite Palette von Sprachen indexiert und Chinesisch, Japanisch und Koreanisch nativ segmentiert.

import { flexsearch } from "blume/search";

search: flexsearch(),

Pagefind

Für sehr große Dokumentationen kannst du dich für Pagefind entscheiden. Es indexiert dein gebautes HTML und lädt den Index bei Bedarf in Shards, sodass die anfängliche Nutzlast winzig bleibt, egal wie groß die Website wird.

import { pagefind } from "blume/search";

search: pagefind(),

Pagefind läuft nur während blume build, daher ist die Suche mit diesem Adapter in blume dev nicht verfügbar. Es indexiert den Artikel jeder Doku-Seite — nicht den Header, die Seitenleiste oder die Fußzeile drumherum —, daher tauchen eigene Seiten auf Basis von PageLayout, die 404-Seite und die generierte Changelog-Übersicht nicht in seinen Ergebnissen auf.

Algolia

Installiere algoliasearch. Der Browser fragt Algolia direkt mit deinem reinen Suchschlüssel ab. Jedes blume build ersetzt den Index mithilfe des Admin-Schlüssels aus ALGOLIA_ADMIN_API_KEY (der Build warnt und überspringt den Upload, wenn er nicht gesetzt ist). Bei jeder Synchronisierung wird der gesamte Index ersetzt, sodass gelöschte oder umbenannte Seiten nicht als veraltete Ergebnisse zurückbleiben. Existiert noch kein Index mit dem Namen aus indexName, legt die Synchronisierung ihn an, sodass ein vertippter Name einen zweiten Index erzeugt, statt den Build scheitern zu lassen. Die Synchronisierung wartet bei jeder Indexierungsaufgabe, die Algolia in die Warteschlange stellt, bis zu etwa sieben Minuten; ist eine bis dahin nicht abgeschlossen, bricht der Build mit BLUME_SEARCH_SYNC_FAILED ab. Die Synchronisierung fügt außerdem filterOnly(locale) und filterOnly(version) zu den attributesForFaceting des Index hinzu und behält dabei alle Facetten bei, die du selbst deklariert hast, denn der Dialog grenzt Ergebnisse nach Sprache und Doku-Version ein, und in Algolia findet ein Filter auf ein Attribut, das nicht für Faceting deklariert ist, keine Treffer.

Algolia begrenzt einen Datensatz in den Tarifen Build und Grow auf 10 KB, daher teilt die Synchronisierung eine längere Seite auf mehrere Datensätze auf, von denen jeder den Titel, die Beschreibung und die URL der Seite zusammen mit einem Abschnitt ihres Texts trägt. Anschließend setzt sie das attributeForDistinct des Index auf url, sofern du kein eigenes festgelegt hast, sodass eine aufgeteilte Seite nur einmal in den Ergebnissen erscheint, und zwar bei ihrem am besten passenden Datensatz.

import { algolia } from "blume/search";

search: algolia({
  appId: "YOUR_APP_ID",
  apiKey: "YOUR_SEARCH_ONLY_KEY", // public
  indexName: "docs",
}),

Orama Cloud

Gehostetes Orama (installiere @oramacloud/client). Der Browser fragt deinen Index-Endpunkt mit dem öffentlichen API-Schlüssel ab; blume build schiebt Datensätze mit ORAMA_PRIVATE_API_KEY in den Index. Setze indexId, um die Synchronisierung zu aktivieren; ohne diese Angabe warnt der Build und überspringt die Synchronisierung, selbst wenn der Schlüssel gesetzt ist.

import { oramaCloud } from "blume/search";

search: oramaCloud({
  endpoint: "https://cloud.orama.run/v1/indexes/your-index",
  apiKey: "YOUR_PUBLIC_API_KEY",
  indexId: "your-index-id", // for the build-time sync
}),

Typesense

Selbst gehostetes oder Cloud-Typesense. Installiere typesense. Der Browser fragt die Collection mit dem reinen Suchschlüssel ab. Jedes blume build importiert deine Seiten mit TYPESENSE_ADMIN_API_KEY in eine neue Collection, richtet dann einen nach collection benannten Alias darauf aus und verwirft die ersetzte Collection. Suchen lesen weiterhin aus der vorherigen Collection, bis die neue vollständig ist, und gelöschte oder umbenannte Seiten bleiben nicht als veraltete Ergebnisse zurück. Schlägt die Synchronisierung fehl, schlägt auch der Build fehl, und der Alias liefert weiterhin die letzte vollständige Synchronisierung aus. Der Admin-Schlüssel muss Collections und Aliase verwalten dürfen. Bei der ersten Synchronisierung wird eine Collection, die bereits den collection-Namen trägt (aus einer früheren Blume-Version), durch den Alias ersetzt, und auf diesen Namen beschränkte Suchschlüssel funktionieren weiter. Einstellungen, die du an einer Collection von Hand feinabstimmst, werden nicht auf die nächste übertragen — wende sie daher nach einem Build erneut an.

import { typesense } from "blume/search";

search: typesense({
  host: "xyz.a1.typesense.net",
  collection: "docs",
  apiKey: "YOUR_SEARCH_ONLY_KEY", // public
  // port + protocol default to 443 / https
}),

Der Standard-Tokenizer von Typesense trennt Text an Leerzeichen, sodass eine Suchanfrage auf Chinesisch, Japanisch oder Thai nur vom Anfang eines zusammenhängenden Textabschnitts an trifft. Setze locale als zweibuchstabigen Code auf die Sprache deiner Seiten (locale: "ja", "zh", "th"), dann tokenisiert die Synchronisierung die durchsuchten Felder für diese Sprache; Wörter in lateinischer Schrift in diesen Feldern werden weiterhin gefunden. Eine einzige Collection enthält alle Sprachen, daher gilt die Einstellung für alle.

Mixedbread

Semantische Suche über Mixedbread (installiere @mixedbread/sdk). Anfragen werden über einen generierten /api/search-Endpunkt geleitet, der deinen Schlüssel hält, weshalb dieser Adapter Server-Output erfordert: einen Host-Adapter wie deployment: vercel() aus blume/deploy (siehe Server-Rendering). Der Endpunkt liest MIXEDBREAD_API_KEY. Blume lädt nichts in den Store hoch: Synchronisiere deinen Inhaltsordner im Rahmen deines Builds mit der Mixedbread-CLI, z. B. mxbai store sync <STORE_ID> ./docs --yes (die CLI liest ihren Schlüssel aus MXBAI_API_KEY).

Jedes Ergebnis verlinkt auf die Seite, die seine Datei rendert, ermittelt über den Pfad, den die CLI für die Datei erfasst — führe die Synchronisierung daher aus deinem Projektstamm oder einem darüberliegenden Ordner aus, etwa dem Stamm eines Monorepos. Eine Seite erscheint nur einmal, bei ihrer am besten passenden Passage, und Passagen aus Dateien, die keine Seiten sind, oder aus von der Suche ausgeschlossenen Seiten werden weggelassen.

import { mixedbread } from "blume/search";

search: mixedbread({
  storeId: "YOUR_STORE_ID",
}),

Der Suchdialog wartet, bis der Leser eine Tipppause macht, bevor er eine Suchanfrage sendet, und verwirft eine Suchanfrage, über die der Leser bereits hinausgetippt hat. Jede gesendete Suchanfrage zählt zum Rate-Limit des Endpunkts.

Suche deaktivieren

search: false,

Setze stattdessen provider: false in der Objektform, wenn indexing weiterhin für den Index des MCP-Servers gelten soll.

Seiten ausschließen

Es werden nur indexierbare Seiten durchsucht. Eine Seite bleibt aus dem Index heraus, wenn sie search.exclude im Frontmatter setzt:

search:
  exclude: true

Versteckte Seiten sind ebenfalls standardmäßig ausgeschlossen. Um sie trotzdem zu indexieren, aktiviere es ausdrücklich:

search: {
  indexing: { includeHiddenPages: true },
}