[reakaleek]

API search finds parameter and schema field names and links directly to the matching row on an operation page.

Closes https://github.com/elastic/docs-eng-team/issues/967

Affects: Search, API reference, Site UI

Prompt summary: Make API fields discoverable through search while keeping operation and endpoint matches prominent. Show compact property rows with their JSON paths, clear page grouping, and yellow highlights that match the destination property.

Why

Readers who know a field name must find its operation and then locate the field manually. Operation text does not reliably identify nested schema fields or provide a link to their rendered anchors.

What

Searchable property metadata

Index rendered parameter, request, and response fields with their names, paths, types, descriptions, locations, and anchors. Indexing shares the page's property-tree construction so search links match rendered rows, including dictionaries and union variants, and two listings that differ only in their descriptions stay separate as they do on the page. Existing parameter text stays in the searchable operation body.

Operation and property matching

Match a field's own name or prefix in the API-filtered lookup, with qualified paths available for narrower searches. The docs-wide search tries only a word that looks like an identifier, containing _ or ., and matches a field by its exact name, so plain words such as index keep the pages about them on top. Ancestor paths and descriptions provide context without admitting unrelated child rows. Direct operation and endpoint matches retain priority, and combined searches such as /_search knn, knn /_search or knn search show the matching fields beneath their operations: a word with a slash, or an HTTP method word right before one, is the endpoint, and two plain words are tried in both orders with the endpoint required, so the index keeps the reading that holds. The endpoint half matches the path as typed or its underscore alias, and each reading is a named query, so a result carries only the field rows of the reading it matched.

Routes for a path hit

When a query word names a path, such as _search or /_search, the result shows one route in place of the description: the method the page leads with and the path with the match highlighted. The route whose whole path is the query word wins, so /_search shows /_search; otherwise the operation's primary route shows when it contains the word, and an alternate route only when the primary does not. A placeholder such as {index} never matches a query word. The index stores each operation's routes with their methods, taken from the same endpoint rows the operation page renders.

Compact results and direct navigation

Use a consistent bordered box for each result, with compact property rows beneath its operation header. Arrow keys traverse operations and properties together, and Enter opens the selected destination. The Enter badge on a row names where it leads: "Go to operation", "Go to property", or "Go to page" for a docs page, and the dropdown footer keeps a static "Go to page" hint. Field navigation reveals collapsed content and flashes the destination name using the same yellow tint as search matches. A click reports the result's rank as its telemetry position, with the property anchor as a separate attribute.

Verify

./build.sh unit-test
cd src/Elastic.Documentation.Site
npm run test
npm run compile:check
npm run lint

The full C# unit suite, 779 frontend tests, type checking, and lint pass. Local browser checks verify 32px property rows, 12px text, yellow matches, consistent boxes, and destination flashes.

Known limitation: A combined query of three or more plain words, with no slash and no HTTP method word, takes its last word as the field. Two plain words are tried in both orders with the endpoint required, so knn search and search knn read the same.

Risk: Indexing adds the nested api.properties mapping to existing semantic indices. A code revert leaves this additive mapping in place. Existing documents receive property metadata during the next indexing run.

Check on the preview

• Elasticsearch search — search for search, _search, and /_search knn. Check operation priority, compact grouped fields, yellow matches, and keyboard navigation to a field. For _search, each result should show one route line, POST /_search on the search operation, in place of the description; search shows the primary POST /{index}/_search instead.
• Nested property destination — check that navigation reveals the nested field and flashes its name.
• Elasticsearch bulk — control page for existing operation rendering and the bulk operation lookup.

Property search checks require a search API and indexed metadata with this branch's property support.

[github-actions]

Docs preview (local build)

Handbook preview: https://docs-v3-preview.elastic.dev/elastic/docs-builder/pull/4574/

Sample changed pages:

• docs/data/openapi/api-explorer.md

[infra-vault-gh-plugin-prod]

Severity: P3 (Low)

Pass the operation's supplemental documentation into property indexing instead of always supplying null. Rendering applies parameter and request-body description overrides, but these new search rows always retain the original spec descriptions, or remain blank when only the supplemental file documents the field. Editing an override also leaves the indexed property metadata unchanged, so search continues showing text that no longer matches the destination row.

_{Generated by Libra. React with 👍 or 👎 to give feedback on this comment.}

[reakaleek]

This is substantial enough to track separately. Created #4662 as a follow-up. Not blocking this PR.

[infra-vault-gh-plugin-prod]

Severity: P2 (Medium)

Populate Routes from the merged page endpoint rather than the individual spec operation. This endpoint is built with an empty sibling list, but navigation can collapse interchangeable operations onto one page. For a GET/POST /_search and /{index}/_search family without a description-level route listing, each indexed hit therefore carries only its own route and method, while the destination page leads with POST /{index}/_search and lists both routes. Search can consequently show a different primary route or omit a matching alternate route entirely.

_{Generated by Libra. React with 👍 or 👎 to give feedback on this comment.}

[reakaleek]

This is substantial enough to track separately. Created #4663 as a follow-up. Not blocking this PR.