Including page title in search results

[osresearch]

The search results include the section header where a keyword is found, but not the page that it was found on, which sometimes makes it difficult to tell which one is the most relevant. Is it possible to include the page title in the search results like Page title - Section?

Test case is using mkdocs 1.1 and has three files:

% cat docs/notitle1.md
This is page 1 with no title.

## Other stuff

Keyword

% cat docs/notitle2.md
This is page 2 with no title.

## Other stuff

Keyword

% cat docs/withtitle.md
# Titled Page

This page has a title element `#`.

## Other stuff

Keyword

[waylan]

The search index is created by breaking up a page into its individual sections (divided by headers). Each section is then indexed as if it was its own separate document. However, the entire page is also indexed as a single document. Therefore, the same result should appear twice: once as its own section (without the page title) and once as part of the entire page (with the page title).

I suppose we could store the page title as another attribute in the index for the page sections. A PR is welcome.

[osresearch]

Does this sort of patch look like a reasonable way to do it? One additional feature is to add the url to the search text so that searching by file name will bring up a link to the specific file.

diff --git a/mkdocs/contrib/search/search_index.py b/mkdocs/contrib/search/search_index.py
index 1aa9fa7..787380a 100644
--- a/mkdocs/contrib/search/search_index.py
+++ b/mkdocs/contrib/search/search_index.py
@@ -65,28 +65,28 @@ class SearchIndex:
         # prepended to the urls of the sections
         url = page.url
 
-        # Create an entry for the full page.
+        print("search page='", page, "'")
+        # Create an entry for the full page, including the URL.
         self._add_entry(
-            title=page.title,
-            text=self.strip_tags(page.content).rstrip('\n'),
+            title=str(page.title),
+            text=self.strip_tags(page.content).rstrip('\n') + " " + url,
             loc=url
         )
 
         for section in parser.data:
-            self.create_entry_for_section(section, page.toc, url)
+            self.create_entry_for_section(section, page, url)
 
-    def create_entry_for_section(self, section, toc, abs_url):
+    def create_entry_for_section(self, section, page, abs_url):
         """
         Given a section on the page, the table of contents and
         the absolute url for the page create an entry in the
-        index
+        index.  H1 will not appear here since no sections were added.
         """
-
-        toc_item = self._find_toc_by_id(toc, section.id)
+        toc_item = self._find_toc_by_id(page.toc, section.id)
 
         if toc_item is not None:
             self._add_entry(
-                title=toc_item.title,
+                title=str(page.title) + " - " + toc_item.title,
                 text=" ".join(section.text),
                 loc=abs_url + toc_item.url
             )
@@ -194,7 +194,8 @@ class ContentParser(HTMLParser):
         """Called at the start of every HTML tag."""
 
         # We only care about the opening tag for headings.
-        if tag not in (["h%d" % x for x in range(1, 7)]):
+        # skip the H1 section since it will be created for the page title
+        if tag not in (["h%d" % x for x in range(2, 7)]):
             return
 
         # We are dealing with a new header, create a new section

[amartin3225]

I would also find this very helpful to identify the correct page in search results

[paulmelis]

I would also find this very helpful to identify the correct page in search results

Seconded

[scott-bro]

I would also find this very helpful to identify the correct page in search results

Seconded

Me as well.

[tadashi-aikawa]

Me, too 👍

[pawamoy]

To show titles in a meaningful and non-confusing way, sections would need to be sorted under pages, or navigation breadcrumbs should be shown.

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. @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.