You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a request to enable a document/page or field to be buried in a search result, as in the opposite to boost.
Use case
A bury function is useful in cases where a document, or field (section), is superseded with either new functions, a new versions, or is deprecated and still should be searchable, but not shown high up in a search result. An example for this is when page or section titles are identical but older versions are deprecated and the newer version should be presented:
When a visitor searches for autocomplete we would like to present the latest version first, bury the v2 page a bit and bury the v1 page even more.
Why not just boost the new page?
As pages can share titles and be present in different sections, such as /guides/integration/autocomplete, or /features#autocomplete, we shouldn't have to boost these other pages and sections to the same level of the latest API page for them to rise above the older API pages. From a long term perspective it is also more likely that a document or section that has been buried should remain buried. Continuously managing positive boost levels in large products to mitigate what a bury would solve permanently is also quite cumbersome.
The text was updated successfully, but these errors were encountered:
Description
This is a request to enable a document/page or field to be buried in a search result, as in the opposite to boost.
Use case
A
bury
function is useful in cases where a document, or field (section), is superseded with either new functions, a new versions, or is deprecated and still should be searchable, but not shown high up in a search result. An example for this is when page or section titles are identical but older versions are deprecated and the newer version should be presented:Page 1:
/api/v3/queries/autocomplete/
Page 2:
/api/v2/queries/autocomplete/
Page 3:
/api/v1/queries/autocomplete/
When a visitor searches for
autocomplete
we would like to present the latest version first, bury the v2 page a bit and bury the v1 page even more.Why not just boost the new page?
As pages can share titles and be present in different sections, such as
/guides/integration/autocomplete
, or/features#autocomplete
, we shouldn't have to boost these other pages and sections to the same level of the latest API page for them to rise above the older API pages. From a long term perspective it is also more likely that a document or section that has been buried should remain buried. Continuously managing positive boost levels in large products to mitigate what a bury would solve permanently is also quite cumbersome.The text was updated successfully, but these errors were encountered: