Search and comments are the casualties of static-sites - unless you bow and crumble to the use of something 3rd party (Disqus or Google Site Search to name some poor examples)

Can't you point algolia at a static site and get decent search or have I misunderstood?

You can check out Lunr. The Jekyll theme Minimal Mistakes has that as a search option and builds a JSON index file.

The demo site uses Algolia though https://mmistakes.github.io/minimal-mistakes/

Hugo provides a Json output that can be used by a js script to provide simple search. I guess the same is possible for other systems.

Comments, contact forms and other features that "creates" content are more difficult.

staticman[0] for comments is a neat solution that avoids those surveillance companies. it can use heroku hobby tier for processing and github as the content backend for a free, hosted comments solution for static sites (fully acknowledging that heroku and github are both owned by other surveillers).

[0]: https://github.com/eduardoboucas/staticman

Comments are not as important as search, I guess. If the site has tons of pages, not having search might be annoying to the user

For a lot of situations something like jekyll search [0] works wonders. It basically generates a json file (you can customize it quite a bit). For even decently sized blogs it's quite quick and doesn't require a page refresh.

[0] https://github.com/christian-fei/Simple-Jekyll-Search

HTML form to jam the search string into a format like below (:

    https://duckduckgo.com/?q=site%3Ayour-site.tld+the+user+search+string

May I know how do you do that?

Here’s some docs from their site: https://www.gatsbyjs.com/docs/adding-search/#reach-skip-nav

But they assume some context, which I’ll give you: At compile time, Gatsby is capable of making a list of all the posts on your site that you can query with GraphQL (at compile time) or use in the JS of your pages. In fact, saying it makes a list of all “posts” is selling it short, because Gatsby can store and manipulate arbitrary data structures. So if you’ve got a Documentation site with a table of contents and three levels of content within it... that’s all queryable at compile time too. It’s extremely flexible.

Now, it’s not like your pages will actually be using GraphQL to query a DB when the user arrives on the page: all the data is basically “baked in” to the page when it is compiled. But for a static site where the “data” only changes when you add/change some content and recompile, this works really well.

That’s great thank you!