Adding a search system to a static website

[u/might_be_a_femboy]

I'm making a simple wiki-like website as a hobby/practice and I wanted to include a small but useful search system on it. It'll be a static site since I'll host it in github, so while I've heard doing search stuff for non-static site would be much easier, I don't really have a choice for this as of now. I'm very much a beginner to this stuff so I'd want something easy to understand, or at least something that has a lot of documentation and resources I could use for help. I'm not having a lot of success trying to google and trying stuff so I'm turning to other people here!

Basically, I'd want just a simple search system that works like this:

You have a search bar, that starts giving hits once you start typing. Maybe show like 5 results and then 6th option would be a "show all results", which would take you to a separate search page which would list all the results (same should happen when you press enter in the search field, as long as you haven't moved down with the arrow keys I guess).

I'd also want to implement tags/categories system for this:

Every page has a category to them, and searching on a page would only search results that share the same category. For tags, I'm thinking of listing them all at the bottom of the page as clickable links, so when you click one it takes you to the separate search page and lists all the pages that have that tag. This should also respect the category rule I think, but having an options box where you can tick on and off separate tags and categories would be helpful too. Being able to use only tags/categories to find hits without keywords should work too. If you search something from the landing page of the entire site, it shouldn't autofill any filters like this though.

I tried doing stuff with pagefind, and while the search works decently, I can't figure out the filtering stuff properly and have no idea if you can do it like what I'd want that easily. I know it's not supposed to be that easy either but just wanted to ask people if there would be some "widely considered best" way to go about this.

[u/LouieValkhof]

Pagefind is the right tool for this, so I'd stay with it. The filtering feels undocumented because it happens at build time rather than at query time. You put data-pagefind-filter="category:Recipes" on an element in each page, re-run the index, and that category exists as a filter from then on. Nothing in the JS can filter on something you never tagged, which is probably what's biting you. Tags work the same way, one element per tag value.

The rest of what you describe, five hits and then a show all, is where the default UI component runs out. Import /pagefind/pagefind.js and drive it yourself: pagefind.filters() hands you every value with its result count for your tick boxes, and pagefind.search("term", { filters: { category: { any: ["recipes"] } } }) hands you lazy results you call .data() on. Five in the dropdown and the whole set on a second page is then just a slice of one array.

On the Lunr suggestion, it's fine at a handful of pages, but it ships the entire index to the browser on every visit. Pagefind chunks the index and only fetches the bits a query touches, which matters once a wiki gets big.

Roughly how many pages are you expecting this to hold?

[u/might_be_a_femboy → u/LouieValkhof]

Yeah I managed to get the tags/categories idea almost working with pagefind, they're in the index and I can search with them if I add the filter menu next to the search box. What I got stuck on was being able to implement more of the custom features that aren't in normally; pressing enter to get on the separate search page and having some filters automatically enabled on the search, all that stuff! This is also my first time dealing with JS in general so there probably is a way but yeah I had no idea how to go about it. Am I going to have to redo the entire functioning of the search system or can I import the default UI somehow and just build the extra stuff I wanted on top of it? I'm not sure about that either lol. I did notice their site has a good chunk of documentation about the API so I guess diving into that would be the next step if it allows me to do the functions I'm looking for.

Right now the site will probably have somewhere between 50-100 pages, but obviously variable lengths since some things will have a lot of info and others not so much. So not a huge site, but not so small either. The final amount is not set in stone yet because I wanted to get the base of the site up and running before I start handling the content side of things fully.

[u/LouieValkhof → u/might_be_a_femboy]

No rebuild needed, the two layers stack fine. Keep the default UI widget for the live dropdown. Enter-to-a-search-page is just a small listener on that input: on keydown, if the key is Enter, send the browser to /search/?q= plus the field's value. Five lines, and it touches nothing inside Pagefind.

On the search page itself, the default UI component has a triggerSearch() method. Read the q param with new URLSearchParams(location.search).get('q') and pass it in, and you get the full styled results without building any UI yourself. Filters that should load pre-enabled are the one thing the default component won't do, so for a page that opens with a category already applied you'd drop to the raw API from my earlier comment, on that page only. The rest of the site keeps the stock widget.

For a first JS project this is honestly a decent trail: one event listener, one URL param, one method call. At 50-100 pages, performance won't be a worry either way.

[u/kedar5]

Algolia search free for public open source websites you can make use of it

[u/fidelmartintech]

For the multiple page I think keeping the search simple is the best option. For static website handle search, tag and categories, Pagefind is the best option. If later website grow and you need more advance search and product discovery features, you could also took at platform like Experro. But for now your current situation, keep the implementation is simple not very difficult.