Great idea
I do not rush you, just assumed that it should be mentioned as all current screnshots are very readable for any interested in the topic but there are some who could get "lost" as pictures do not match the reality.
LLMS support is up:
basic info on the endpoints has also been added: Using this documentation | RouterOS Manual
Yeah, the LLM links are working now. But I've spotted a bunch of other discrepancies. I'll report them once the feedback links in the manual pages are working! 
I would move that content to the "Introduction" section.
yeah already done, didn't think of it at first. wait until next build 
Maybe it is an idea now that things are being reworked anyway to move the change notes of new versions into the documentation system, put a link to them in the release topics and online update checks, and abandon that cramped one-line-cryptic-message format (allow more text and documentation links)...
Is there a way for us to report errors found?
I happen to find one yesterday.
DHCP Client
use-broadcast
always ( should be never ) - broadcastbit is not set
thanks
The inconsistency is that the labs used to get those screenshots are obvious manually created.
A job that can not be humanly sustained.
OK, OK... Take the screenshots could be very hard to automatize.
But, if, at least, the labs could be created and provisioned automatically, with just the screenshot collected manually. This would be great!
Furthermore...
A public list of Container Lab recipes used by MikroTik for building documentation, and even for effective functionality testing, would be a very interesting addition to this documentation!
The machine-readable layer y'all added since this thread started — per-page .md, llms.txt/llms-full.txt, sitemap — is exactly right, and fast. So this post is about the next layer: search quality. I've spent a while running rosetta, which indexes RouterOS docs into SQLite FTS5, and a few of those lessons apply directly to the new site's search box.
S1. Full-text index stemmer improvements (product & commands)
The site's search is a lunr-based local plugin (it publishes search-doc.json), so Porter stemming is on by default. That's tuned for English prose — but a huge share of what people search for in RouterOS docs are identifiers, not words: CCR2216-1G-12XS-2XQ, RB4011iGS+RM, 88F3720, wifi-qcom, etc. Porter stemming on those is unpredictable, and worse, lunr does whole-token matching, so a search for RB1100 never finds the token RB1100AHx4.
In rosetta I ended up giving codes their own treatment: a unicode61-tokenized field with no stemming, plus a LIKE substring fallback, run as a cascade (exact → substring → prefix → stemmed). For a doc site the cheap version is: index product codes / command paths / argument-type names in a non-stemmed field and add a substring pass. It's the single biggest recall win for the "I typed half a model number" case.
S2. matrix.csv → generated "pivot" pages or inline content/"tooltips"
www.mikrotik.com/matrix has long had CSV will all products, and likely the www site is generated in part from it. But for manual.mikrotik.com I think there's real opportunity given MDX and static Docusaurus build. The product matrix is already structured data — 144 products × ~34 columns (CPU, architecture, RAM, PoE, SFP+ count, license level…). In rosetta, its extract it into SQLite (normalizing RAM/storage to integer MB) so AI can answer "which devices have 10G SFP+" or "ARM64 with PoE-out".
The best example where this be useful is for topics like L3HW offload, HW QoS, and other CPU/switch chip specific features as its takes quite a bit of effort to unwind those from CPU/swicth back into the product model. And same is true for other column in the matrix.csv, like IoT features or PoE or port speed.
None of those "pivots" exist as pages a human or AI can land on or search finds. But the beauty of the new doc system is "synthetic" docs can be generated at build time. Since the docs are MDX, a build step could emit content like:
- "Devices using CPU 88F3720"
- "Devices with 10G SFP+"
- "Devices using switch chip 98DX3236"
- "ARM64 devices"
…straight from the matrix you already publish. Either directly as new pages, or as inline content on existing pages like Bridging or Hardware Offloading.
The payoff is:
- linking products to CPU/switch chip features for search
- third-party tools get stable pivot URLs to deep-link. It's the same "generate, don't
hand-write" principle behind the CLI Reference — applied to hardware. - generated pages provide more surface for search engines and training to find/use, for a marginal one-off cost
Same spirit as the CLI-Reference-as-data ask in my earlier post — third parties could build these pivots independently too, but having them in the doc site is what makes them searchable.
And, MDX is well-suited to it: a small plugin reads the matrix CSV/JSON at build and renders one (or more) page per pivot value, fully indexed by the same search. You can get fancier too to handle generate inline "Applies To: " so docs don't have be updated if you add a new device that uses some CPU/switch/etc thing.
More food for thought.
Side note on www.mikrotik.com the "download" for matrix.csv is not downloadable by curl/fetch() since www page uses JS to generate the matrix.csv... so adding some direct URL to the matrix.csv would help, since it useful data. And the new llm.txt could reference the existence of the product matrix CSV (or ideally JSON) since its pretty "token efficient" for an LLM to know features for a model.
In this thread, indirect mentions were made about roadmaps, protocols, and features.
But until now, there wasn't a direct question expecting a direct answer.
In the new RouterOS documentation, will there be a specific section to discuss roadmaps for future releases?
Something that is continuously changed, updated, and adjusted.
Something that isn't equivalent to blog posts that happen once at the beginning and only reappear when something very serious happens...
The closest we had were the "Routing protocols status page" that got deleted in the move
For now we have no plans to pre-announce major new features, since sometimes the development time can be very long. We only do that here on the forum, once we know something can be tested.
And how about the idea to put release notes (of released versions) in the documentation system instead of in the very compact notes you get when checking for updates (replace that with a link to the document)?
yes it is planned
IMO, this is a missing piece:
Agree with @Larsa. In fact that thread prompt some quick work on eventual "useful user article" for prompting suggestion help AI agents by pointing them to the new doc site.
with the simplest form being:
Before answering, fetch https://manual.mikrotik.com/llms.txt, find the page that
matches my question, and read its ".md" version (append .md to the URL). For
exact command/property/enum syntax check https://manual.mikrotik.com/docs/cli-reference/
and don't invent properties. Assume RouterOS v7, cite the page you used, and if
you can't reach the docs say so instead of guessing — your RouterOS training data
is mostly old v6 wiki content.
My question: ...
And like MikroTik, I'm not considering V6... so for version 6.x, IDK what I'd recommend to tell an AI (well, perhaps less is more since Opus suggests: "mostly old v6 wiki content") .
Yeah, and regarding LLMs:
Improving the manual and user guide is exactly the kind of thing where an LLM can be really useful. I assume most MikroTik staff have access to tools like Claude or something similar.
I did a quick test myself, and even with the little time I had to look through the result, I’d say it already looked pretty good.
Of course, the output still needs to be checked by someone with real ROS knowledge. But using an LLM as a first pass to restructure, simplify, and clean up the documentation seems like a pretty low-effort way to make big improvements.
Another point worth considering is to focus on the newcomer-facing documentation first, instead of trying to improve everything at once. A few clear onboarding guides would probably have a bigger impact than polishing advanced reference pages that experienced users already know how to navigate.