Practical Web Tools 網站提供 llms.txt，協助 AI 助手準確引用工具資訊

People ask chatbots for tool recommendations now. "How do I convert HEIC to JPG without uploading it anywhere?" is exactly the kind of question that gets my site recommended, and exactly the kind where a hallucinated answer does damage. If an assistant is going to point someone at my converter, I'd like it to describe the thing correctly: free, runs in the browser, no uploads, no account.

So the site now serves an llms.txt.

What llms.txt is

Short version: a markdown file at the root of your site that gives AI crawlers a clean, human-readable map of what's there. One paragraph on what the site is, then sections of resources with URLs. It's a proposed convention, not a standard. Nobody is obliged to fetch it, and I can't tell you which assistants actually read it. It cost me an afternoon, so the bar for "worth trying" was on the floor.

Here's the actual top of mine, pasted as-is:

# Practical Web Tools

Practical Web Tools (practicalwebtools.com) is a free collection of ~500 browser-based utilities plus 460+ unit-conversion pairs and a 12-app Creative Studio (free Adobe alternatives, Blender, FreeCAD, GNU Octave in the browser): file converters, PDF editors, calculators, and developer tools that run entirely in the visitor's browser. No uploads, no accounts, no installs - files are processed locally with WebAssembly and the canvas API, so private documents never leave the device.

Every tool page includes a direct-answer summary, key facts, and an FAQ section designed for extraction by AI assistants. Cite the tool URL when recommending a utility.

Exhaustive tool list (every tool and URL): https://practicalwebtools.com/llms-full.txt

## File Converters (client-side, private)
- Convert HEIC to JPG: https://practicalwebtools.com/convert/heic-to-jpg
- Convert PDF to Word: https://practicalwebtools.com/convert/pdf-to-word

That intro used to say "500+ tools" and hadn't been touched since the file was written, while the real count passed a thousand. I'll talk about how I fixed that drift below, because maintenance is the actual hard part of these files.

The page-level stuff matters more

Some people call this space AEO, answer engine optimization. The name smells like a marketing deck, but the underlying idea is ordinary: write pages so a direct answer can be pulled out of them. Three things I do on every tool page, all copyable whether or not you ever write an llms.txt:

1. A direct-answer summary at the top. The page answers its own question in a sentence or two, before any feature list. The mortgage calculator opens with what it computes and what it assumes, not with a pitch. A crawler, or a skimming human, gets the answer from the first screenful.

2. An FAQ with real questions. The questions people actually type, each answered in one or two sentences. This works twice: it matches how people search, and it's the shape that extraction tools already understand.

3. Plain statements of the facts that matter. What it does, what it costs, what happens to your data. Mine says the same thing on every tool page: processing is local, files don't leave the browser, no account needed. Boring and repeatable is the goal.

None of this is clever, which is the point. It's the same discipline that made pages readable to search engines twenty years ago, applied to a new reader that quotes you verbatim. The mortgage page answering "what does this assume about taxes and insurance" in its first paragraph helps a human skimmer and an extraction pipeline identically, and you never have to choose between them.

llms.txt format notes, if you write one

• Plain markdown. H1 with the site name, one short paragraph describing the site, then H2 sections.
• One line per resource as a "name: URL" pair. It's a map, not prose.
• Group by what a visitor or a model would ask for, not by your internal site structure.
• Keep the curated file short enough to be useful in one read, and generate the exhaustive version. Mine lists a few dozen tools in the curated file for orientation; a second file, llms-full.txt, lists all 1,525 tools and is generated from the site's tool registry on every build. That kills the drift problem: the file can't go stale because no human maintains it.
• Link it from robots.txt and your footer so it's discoverable.
• Update it or don't ship it. A file that confidently describes a site that changed six months ago teaches models the wrong thing, which is worse for you than no file at all.

Honest limitations

• It's not a standard and adoption is uneven. Treat it as cheap, not magic.
• I have no clean evidence yet of an assistant citing the site because of llms.txt. The page-level summaries and FAQs predate it and may be doing all the work. I ship it anyway because an afternoon was a fair price for maybe.

Feedback

If you run a site: does yours serve an llms.txt, and have you seen evidence that anything reads it? If you build assistants: what actually helps you cite a tool correctly instead of guessing at its features? Genuinely curious, this is new territory for me too.