Field boost and document boost for search

[waylan]

Previously MkDocs used field boost to boost the title field (by 10) for search results. However, when lunr.js removed support for field boost in 2.0 it was removed from MkDocs when we refactored search into a plugin. As documented in olivernn/lunr.js#312 the feature was restored to lunr.js in version 2.3.0. Therefore, we should restore the boost to the title field. We should also update lunr.js to the most recent version.

That's an easy fix. However, at the same time that lunr.js restored field boost, they also added support for boosting a document. In other words, if boost is applied to a document, that document would get returned higher in the list of search results. It occurs to me that we could implement this with a meta-data value by adding support for a boost (or search priority or other, better name) as a meta-data key. The key would then be added to each entry in the JSON data used to build the search index. When building the index, the value of that key could be applied as document boost. That would allow site authors to better control search results to ensure that certain pages always appear higher up in the results.

However, I'm not sure if there is any demand for such a feature. Field boost will definately be restored. but we may only add document boost if we get demand for it here. Please reply below.

[waylan]

👍 this comment to vote for document boost or 👎 this comment to vote against document boost.

[rusefillc]

Yes, there is demand for for title to be boosted in search, as is search is weird.

[pawamoy]

Nowadays (2024) lunr.js is unmaintained (last commit 2020). While we welcome enhancements to existing themes, we're also discussing creating a new, better default theme, which would probably use something else than lunr.js.

Field boost is by the way already supported in Material for MkDocs' own search plugin. @squidfunk also stated that he and his team are working on a standalone search plugin that is theme-agnostic and will bring such functionality, see the discussion starting here #3560 (comment).

For these reasons, we'll close this as not planned! If someone wants to work on this anyway, we can re-open the issue.