And some of us would probably say that one was just too good to leave unanswered 
And that's the thing: we want to you have to worry about "drop tables" because that means there is a more dynamic search engine behind the search. Not some JavaScript that runs in browser that's using a lousy index and the "stock" search plugin.
Y'all do make hardware (RDS, etc), and love DIY solutions, why don't write your own plugin to a better/custom search backend that's aware of your unique nomenclature?
I think there is no need to re-invent the wheel; there are already some very powerful search engines supported: https://docusaurus.io/docs/search
It is just not on MikroTik's top priority to have super accurate and tuned search results - right now. And this is completely understandable. The manual is more like a public PoC currently. Many things to change. Why start investing a lot of time fine-tuning search, when docs are still not fully migrated?
DROP .md 
Agree, that be my thought too. But this is MikroTik, so half-troll in my commentary - some backend is more the generic suggestion. IMO "search is lousy" today, and worse than confluence - so "feedback".
But I'm not sure it's hurt to start wiring up something since in theory a decent scheme should re-index upon changes, so no need to wait to add new class of documents which may "take some time" as those be picked up as added.
Another failed search: serialize
:serialize is mentioned in the Scripting doc pages, but was no found using the "search" tool. Also I could not find it in the CLI reference, now presumably since you're not cataloging scripting functions which IDK is the right call, since cross-references cannot hurt.
yes, confirmed serialize, so found another one. the indexer is not indexing some things, we adjusted the settings. it will be live in around 24h
While we wait for some per-page "feedback" button...
Minor point on REST API | RouterOS Manual
"The REST API does not support continuous commands such as
monitor"
This is not actually true. You do offer good advice "...Use the monitor once" next to it. However, the clunkers (even Opus and GPT 5.5) take you at your word. But the reality is you can use a "monitor" command without a "once" as long as your provided a duration of less the REST API 60s timeout. While the docs do literally show this in the bandwidth test example, which even shows the [{".section":0,...},...] return values, is not obvious enough.
And, despite, mentioning "monitor" specifically, there are plenty of other "continuous" command that use different names (monitor-interfaces, /system/license/renew, etc etc etc) and the above REST API comment applies equally.
I like complained commented that the various asynchronous/streamed/generators/"continuous" commands should be more clearly called out in the CLI reference. This specific instance is example of why, since it does effect what will be returned.
Is there any way to do a search via the URL or parameters? This is for browser quicksearches/'search engines'/keywords.
For example, for the old Jira documentation site I have it so:
mt<searchquery>opens
https://help.mikrotik.com/docs/dosearchsite.action?queryString=searchquery&where=ROS&additional=space+name&labels=&contentType=
I'll let MikroTik answer formally.
But AFAIK answer is curl cannot work with search, since it current client-side JS doing the search. See my/others comments on the need for a better search engine backend above.
Any chance it was restored any time soon?
You're talking about forum.mikrotik.com. That does not work on the manual.mikrotik.com that is the subject of this thread.
You'll note in web console for manual.mikrotik.com:
https://manual.mikrotik.com/search-doc-1783085448896.json
https://manual.mikrotik.com/lunr-index-1783085448896.json
and the lag from loading to when you can search.
The manual.mikrotik.com is build with https://docusaurus.io/docs/search, and you have to ask Mikrotik if they want to add some plugins to that to support url search.
The search is already a plugin (Lunr) and there is no way to do what you ask. I you can suggest a better search plugin, we will look into it. So far it seemed the best.
Currently when the search has more results than what is vertically visible, there is no possibility to scroll the result list. There is no scrollbar and scrolling with the mouse wheel affects the page content behind the result list instead.
"Security through obscurity" reasons.
Or...
"Reduction of genuine but inconvenient questions, based on obscurity".
On the existing plug-in, you might want to look at how handle the "products names with unicode", since those are seemingly ignored/not handled.
e.g. a search for "hAP ax3" should display first, and if I uses its unicode name like hAP ax³, the hAP ax² appears first... which suggests the full name is not indexed.
Further, the hAP ac² is unicode, while the hAP ac3 is not. The latter hAP ac3 page does have a stray hAP ax³ in page body.
Side note, there are actually two ways to express the ² things in unicode since you can say it 2 made a superscript, or use the unicode char for the square/cube since they have there own code. The product naming page does not specify unicode conventions ;).
It is a JS browser client search. It downloads the index as json. The more documents the more it takes to parse on client side. This is very limited and "ship fast" solution. Better evaluate alternative search plugins. Personally I don't have Docusaurus experience, but I am familiar with several popular search engines. And from the available plugins I would try GitHub - tauri-apps/meilisearch-docsearch: A quick search component for meilisearch, inspired by algolia/docsearch. · GitHub first. Meilisearch is lightweight and a breeze to set up.
True, more content, more time to load the index. But MikroTik can control what's indexed. IMO there is no needed to index the whole of the manual.mikrotik.com/hardware/* since all the regulatory/safety stuff is getting index. With >200 devices, with many longer than "normal" pages... it's having an impact o the first-time load of the page and Lunr search index.
Now, the product names should be index, so the hardware page comes up in a search. I dunno if there some "ignore from index" in the MDX backend. But perhaps each /hardware page is a landing page (that is index) with the short summary of the specs (ports/CPU/mem/switch-crip), link to it's default-configuration, and link to main www page for the product - all which are not in manual.mikrotik.com today, but more useful that FCC warnings. So the current /hardware page with its "Safety Warning" becomes a subpage under each /hardware landing that not index.
I won't discount that it's actually hard index RouterOS things. Now Lunr is not doing much, but MikroTik does use some custom logic on top already. Since folk may search for commands like /ip/address/print which becomes "ip address print" words against the index, MikroTik does have the ability to refine Lunr's logic to deal with RouterOS-isms by adding some JavaScript. And some for the /hardware pages since there often alias/alternative names and ways of expressing models were pre-processing the search string may be useful (e.g. you may say "hAP" but likely don't mean the decade old one, so "Did you mean?")
Now not saying some commercial service cannot work. But I doubt it be plug-and-play since the search query are often products or commands/attributes/paths, not some typical text-heavy documents.
This does not mean they should look for other solutions. As it stands Lunr takes a while to load for sure. Just MikroTik's problems are not typical is more my point.
And there might be some lighter option with Lunr/Docusaurus so the Search Box is ready before the index is loaded so that that you can start typing while the index loads in background. And not indexing the contents of the hardware pages may also have a significant impact on the load time, as noted at top.