A new search

We've been working hard with our new partner Algolia to bring you a better, faster and more extensive search for the Kirby docs and blog.

This is a companion discussion topic for the original entry at https://getkirby.com/blog/a-new-search

Nice! Just a heads up: I spent around 2 minutes clicking around the Kirby website, looking for the search field, thinking that you must still be working on actually adding it to the site… before I finally noticed the word “Search” in the navbar.

When I’m looking for the search I normally scan the page for either a search icon, a box, or really anything visually resembling an input field. But the way you placed the search link and made it look like a menu item basically made it invisible to me.

Oh, thanks for pointing that out, I probably would have gone round searching for the search myself :wink:

Oh well, that’s not what I hoped for :slight_smile: I will add a search icon in the next days to make it cleaerer. Thanks for the feedback.

While the Algolia-powered search is probably much better than what existed previously, I have a few reservations about this change.

One is user context. I’m not sure someone discovering Kirby and wondering about, say, pricing or some other topic and not finding it in the top level navigation, would now click “search”, enter their query and get meaningful results. They would probably get a lot of very technical information as false positives for their search.

On the other hand, for users who actually want to get some docs/solutions/blog posts etc., because they’re actively developing something with Kirby, this search field is a) not prominent, b) tiny and hard to hit (update: looks like the empty space to the right of the text is clickable too, so the design only suggests that it’s tiny), c) shows results in a small space. Kinda feels like a loss of ease of access and reading compare to the previous version (not talking about the relevance of results here).

Having the search in the main nav also suggests it searches the whole site, whereas it only searches the docs and blog. Unless there are plans to expand to other content types?

I would keep the search bar in the docs, while making sure it appears in every page of the docs. E.g. with the big search box in the /docs page, and a smaller one at the top of the sidebar in internal pages. (This leaves a small problem with the Cheat Sheet and Toolkit pages, but frankly I would advocate harmonizing the layouts of those pages and their subpages with the rest of the docs.)

Another reservation of mine is that it does not work without JS enabled. That’s a pity, because there is a fallback PHP search page at https://getkirby.com/search?q=test, but the search box can’t get user focus or input without JS.


I also have some feedback. I agree much with the rest but here is my take on it.


I searched for this:

I was looking for this:


In Google it comes first but in this search it’s on 11 place. I don’t know if it’s possible to add keywords to Algolia to force some pages to have higher relevance to some keywords?

If so, with some tweaking I think we could have an awesome priority for some matches. :slight_smile:

Placement and look

I have no problem with it in the main nav or on all pages. I like the idea of a “quicksearch”.

An alternative to have it in the main menu could be to lift it out and place it in the top right corner. But as I said, I have no problem with the main nav. :slight_smile:

As others already said I also suggest to have a search icon, a magnifying glass?


The search is missing on mobile devices.



Other than this I think it’s a great step because I use the docs all the time. I have a goldfish memory.

Even if there are some things… Good work! :slight_smile:

1 Like

Ok, it’s becoming pretty clear that we have to do some more tweaking :slight_smile: I’m glad you are all happy with the search results, thought. That’s basically the most important part about it and I’m sure we made the right decision here. It’s definitely possible to improve them even more with custom prioritization, but that can only be achieve over time after analyzing the search results some more. To improve the UX is important as well, but not as challenging technically, as coming up with a good search in the first place. I think you already gave us some excellent feedback about that and we will try to improve it as soon as possible.


@bastianallgeier it is a very nice addition to Kirby’s ecosystem, congratulations! I have to admit I am quite shocked about the timing here. TLDR: https://github.com/mlbrgl/kirby-algolia

When I first considered Kirby for a site redesign where search is the main component, I was quite concerned about the end user experience, especially in the long run with the constant addition of articles to the “database”. Having some experience with Algolia already, I thought it could become the scalable backbone I was looking for.

When I talked to the guys over at Algolia, they pointed me to DocSearch, which slices up long articles into smaller blocks, for better relevance and end user experience (more on this here: https://blog.algolia.com/how-to-build-a-helpful-search-for-technical-documentation-the-laravel-example/).

I ran a quick search to see if such an effort was already underway but could not find anything substantial at the time. This led me to creating a plugin for Kirby, which implements what I called fragment indexing (cf. github link above).

Had I known you were already working on a Kirby / Algolia integration, I would have definitely held my horses and maybe joined efforts down the road. I guess I was knee-deep in moving the project forward and did not pay much attention to the outside world :).

I have not gone through your code yet and I do not yet know how much they overlap, but it might be interesting to consider merging the two projects (if only in concept) at some point, if it makes sense.

In the meantime, good luck with this new addition!



Yes, in the file /assets/css/site.css of https://getkirby.com/docs, starting at line 2169:

@media screen and (min-width: 52em) {
  .quicksearch {
    display: block; } }

the search is hidden for every browser with less width than 52em (= 832px, if the browser has “font-size: 16px;” as his default).

The default is set some lines before:

.quicksearch {
  position: relative;
  display: none; }
1 Like

Good research! It seems like it’s made by purpose then. :slight_smile:

After a few days of use, here’s more feedback.
First, I want to say I like the new search a lot, the results are already better most of the times. I don’t want to sound negative or critical, I just wanted to report things I experienced and suggest possible solutions.

  • I’ve found it difficult to reach “documentation” pages (as opposed to “spec” pages like the cheatsheet).
    For example I searched the word “cache” and expected to be able to reach this page easily but all the results linked to the cheatsheet. I clicked around a bit, couldn’t find the page in the left menu, then used Google.
    Is there a way to split the results in two parts, at least in the dropdown? The idea would be to display basic information to help newcomers first, then links to the cheatsheet.
    Or maybe refining the priority given to some pages is enough.
  • It’s not obvious you can get more results by hitting return. I actually discovered this by reading a post above. Adding a link at the bottom of the dropdown to “All results…” could help a lot.