On July 25 I shipped /discover, one search page for the public work on my site. It opened with 95 results across Apps, Tools, Writing, Vault, Newsletter, and Books.
I already had six registries feeding those sections. I used them as the index instead of creating a second content store that could drift. The page takes the public title, description, tags, and destination from each owner source. Vault entries contribute listing metadata only, so locked body content never enters search.
The browser does the filtering. React state holds the current query and category while the page is open. The query does not go into the URL, browser history, localStorage, sessionStorage, analytics, server logs, a backend, or another network request. The site's normal page measurement stays separate and never receives the words somebody typed.
Local search still needs rules or the results turn into mush. I normalize case, extra spaces, and diacritics. Every term has to match somewhere in the entry. Exact titles rank first, then title prefixes and title phrases, while equal scores keep the original registry order.
I tested the privacy boundary as behavior, not copy. The browser checks covered desktop and mobile, keyboard recovery, reduced motion, no localStorage writes, and no request carrying the query. The production page returned the same 95-entry catalog with no console errors.
For 95 public entries, a separate search service would add another store and another failure path. It could also create a query trail without solving a problem the browser cannot handle. The current page filters the complete public index without another request. If the catalog eventually outgrows that approach, I can move the boundary then.