Site Search
Whether P1 gives you anything for a visitor-facing “search this site” box. Confirmed absent: not partially supported, not present under a different name.
This is a P1 platform gap, not a Brown-Forman-specific one. Filed here at the top level alongside Content Relationships and Managing the Header & Footer.
Confirmed: no search capability anywhere in the SDK
@pantheon-systems/css-client’s endpoint list (branches, checkpoints, documents,
merge, templates, versions, sites, presence, agent-edit, agent-registry,
migration-conflicts) has no search or query-by-text endpoint. documents.list()
returns documents on a branch; there’s no documents.search(query) or full-text
index to query against. Checked every installed @pantheon-systems/* package for
search-adjacent exports: nothing.
Not to be confused with this documentation site’s own search (the box in the top navbar here): that’s Pagefind, a static-site search tool we wired up ourselves for this Nextra docs site. It has nothing to do with, and doesn’t demonstrate anything about, search on a P1-built brand site.
What this means concretely
No native way for a visitor to type a query into a search box on a Herradura or Jack Daniel’s-style brand site and get matching pages/products/cocktails back. If a brand site needs search (likely, for any content-heavy site with a product catalog or a recipe collection), it’s entirely new infrastructure, the same shape as Form Builder or Email Delivery: nothing to configure, something to build.
Approach
Two realistic paths, depending on how much search actually needs to do:
Client-side static index (Pagefind or similar): works well for a smaller, mostly-static brand site. Same tool this docs site itself uses: crawl the built pages, generate a static search index at build/deploy time, ship a small client-side search widget. Cheapest to stand up, no backend to run, but the index is only as fresh as the last deploy/rebuild; the same staleness problem SEO’s sitemap plan already solved once for the sitemap. Whatever indexing step gets chosen would need the same “no rebuild required” treatment, or search results would silently drift stale every time a page is published without a redeploy.
Hosted search service (Algolia, Typesense, Meilisearch): a real backend search
service, indexed via a webhook or scheduled job pulling from documents.list().
More capable (faceting, typo tolerance, relevance tuning) and inherently solves the
freshness problem if the index gets updated on publish (the same
revalidatePath-on-publish hook pattern used elsewhere could trigger a re-index
call instead of/alongside cache invalidation). More infrastructure to provision and
pay for.
Whichever approach gets chosen, indexing needs to trigger on publish, not just on deploy; the same lesson already learned building the sitemap. A search index that only updates when someone redeploys the Next.js app will drift stale exactly like an un-revalidated sitemap would have.
Recommendation
Default to the static/Pagefind-style approach for a first brand site: cheapest,
fastest to ship, and this documentation site is a working reference for exactly that
setup (postbuild step + generated static index). Revisit a hosted service only if
a brand site’s catalog grows large enough, or needs faceted/relevance-tuned search,
that a static index stops being good enough.
Open questions for this page now live on Outstanding Questions, tracked centrally across all pages rather than repeated per page.