A browsable, searchable docs site
Turn a folder of notes into a real website — a left-hand menu of pages, a search box that finds any word, a clean reading layout — that anyone opens by clicking a link. Your agent builds it from your markdown and puts it online; the recipient just reads it, no account, nothing to install.
Reach for it when there's enough to navigate — many pages a reader moves through by topic, not one thing they scroll. Skip it when it's one or two pages (a Google Doc is lighter) or people need the underlying files to build on (a GitHub repo).
Last verified: 2026-06-07 · checked against mkdocs.org and squidfunk.github.io/mkdocs-material · Confidence: high on the build-from-markdown flow, the built-in menu + search, and the static-files-deploy-anywhere model.
It allows you to
- Give a reader a website, not a file. They open a link and browse a polished site — never seeing the markdown underneath, the way they would in a repo.
[confirmed] - Let them find any word. A search box comes built in — type a term, jump to the page — which one long Google Doc can't do across a whole reference.
[confirmed] - Navigate by topic. A left-hand menu lists every page in sections; on a phone it collapses to a hamburger button.
[confirmed] - Update it in one place. Change a markdown file, tell your agent to rebuild and re-publish — everyone gets the latest at the same link.
[confirmed] - Decide who gets in by where you host it. It's an ordinary website: public by default, or gated to named people. → Who can get in.
Ideal for
- A multi-page onboarding handbook — "how we work here" for new hires or fellows: a setup page, a tools page, a who-does-what page in one menu a newcomer reads on day one and searches for "expenses" three weeks later.
- An internal "how we use AI" guide — a living playbook of prompts, skills, and workflows your team navigates by section, far easier to find your way around than the same content in one endless doc.
- Public docs for a tool you've built — like Microsoft Presidio's documentation, a data-de-identification toolkit: the standard shape for "here's how to use the thing I made."
Who can get in
- Whoever your host lets in. A docs site is just a website — public by default (anyone with the link reads it), or behind a login.
[confirmed] - Lock it to named people. Put the site behind a Google sign-in so only the emails on your list get through → A website only named people can open.
[confirmed] - Cut someone off. On a gated site, remove their email and the next load is blocked. (A page they already saved stays theirs — true everywhere.)
[estimate]
Which rungs it can hold. Anyone-with-the-link / public on a plain deploy; named-people or org-only once you gate it — every rung except just-you. → Who can see it? [confirmed]
Handing data to the host. Nothing new here — the trust question is your deploy host's, not a separate docs vendor's (MkDocs and the Material theme are open-source tools that run on your machine). → Can you trust the company? [confirmed]
What you do to set it up
- Ask: in the folder that holds your notes, tell Claude Code "build a MkDocs Material site from these notes and deploy it, and give me the live URL." It writes the config, builds the site, fixes broken menu entries, and deploys it. Every later change: edit a file, say "rebuild and redeploy."
[confirmed] - The only un-delegable step is creating one free account on whatever host you deploy to (~3 min once) — the account-and-CAPTCHA wall an agent can't click through.
- One-time prerequisites: Set up Claude Code (~10 min once), a folder of markdown notes (one file per page; sub-folders become menu groups), and a place to put a website (no-account route, a live link in ~30 sec).
[confirmed]
Full walkthrough, the config it writes, and an "if it doesn't work" FAQ: Publish a docs site from your notes. Rather do it by hand? That tutorial's last section is a no-agent terminal path. [confirmed]
What the other person does
- Just read it: click the link. ~5 sec, no account, nothing to install — an ordinary public website with the menu and search box from It allows you to above. The floor-0 case.
[confirmed] - Pay: nothing — free to host and free to read.
[confirmed]
Other ways to share
- It's one finished thing they click and use, not a set of pages to read? → a docs site is itself a deployed website; reach there directly for a page, dashboard, or app rather than a topic menu.
- Want it editable by the reader, and don't need the polish? → a Notion page is a browsable multi-page space anyone can edit in place, where a docs site is read-only and you own every change.
- They'll build on the underlying files, not just read? → a GitHub repo hands over the whole folder with full history.
Sources
- MkDocs — Getting started — Markdown + one YAML config build to a static
site/folder you host anywhere; built-in search — checked 2026-06-07 - Material for MkDocs — home — "create a professional static site"; search runs "entirely in the user's browser" — checked 2026-06-07
- Microsoft Presidio docs — a live MkDocs Material site (in-the-wild example)
- The high-staleness details — cost, static-only limits, the MkDocs 2.0 rewrite: Docs site — the fine print
- Build, config, FAQ, and the by-hand path: Publish a docs site from your notes
- Where it gets hosted: Deploy a website
Good to know
- It's free, end to end — open-source tools, static output, free hosting; the recipient just opens a link.
[confirmed] - Static files only — no forms, no logins inside the page. Need those? That's a deployed app, with the login itself a gated website.
[confirmed] - A breaking rewrite (MkDocs 2.0) is announced but pre-release — it doesn't affect today's build, which still runs on MkDocs 1.6.x.
[confirmed]
Sources, the site_url gotcha that can break links on a hasty deploy, and the rest of the fine print: Docs site — the fine print.