Answer Engine Optimization for Developer Tools

Ask an assistant how to do something with your library and it will not summarise your homepage. It writes code. Somebody pastes that code into an editor and runs it, and either it works against the release you ship today or it throws a TypeError. No amount of brand mention decides which.

That makes this the one industry where the output of an answer engine can be tested. Take the snippet, run it, get a boolean back.

We run the answers instead of reading them

The panel here is a list of tasks, not a list of questions. Install the client and make an authenticated request. Page through a list. Stream a response. Retry a call that failed. Upload a file. For each task we capture what the assistant emits and run it in a clean environment against your current release. Three things get recorded. Did it import, did the method it called exist, did the call succeed.

That produces a number nobody can argue with. Fourteen of twenty tasks produced working code, and here are the six that did not with the line that broke. A folder of chat screenshots cannot do that, and a citation count says nothing about whether the citation helped anyone.

The API the assistants know is the one you deprecated

A model learns from what was published. What was published includes your v1 docs and four years of forum answers. A tutorial somebody wrote against a beta. The README of a fork nobody has touched since. Rename a method and none of that updates. The assistant keeps emitting the old call, in the old argument order, with complete confidence.

There is no switch for this and anyone selling you one is guessing. What you can do instead is make the current signature the easiest version of the truth to find in the sources these engines read. Keep a migration page that names the old call and the new call inside one paragraph, so a retrieval step can connect them. Mark deprecation clearly on the pages documenting the old API, and do not quietly delete them.

If the docs need JavaScript, several engines never see them

Vercel and MERJ measured OAI-SearchBot, ChatGPT-User, GPTBot, ClaudeBot and PerplexityBot, and none of them render JavaScript. Only Gemini and Applebot do. A documentation site that assembles its content in the browser is, to the others, a page with a loading state on it.

Some docs platforms ship real HTML. Some assemble it client-side, and those tend to be the ones with the nicest search box. We check per template what is actually in the initial response. The answer is usually partial. The prose is in the HTML and the language tabs are not. The tabs are the part that matters, because the snippet inside them is what the engine would have quoted.

Keeping v3 online and getting v5 cited

These two pull against each other. Customers on the previous major version need those pages up. A retriever reads them as well, and a page that is correct about v3 is a wrong answer handed to somebody on v5.

The work is labelling, and it is cheap. Every page under an old version path states which version it documents, in its title and in its first line. It links its current equivalent and carries the date it was frozen. That helps the human who landed there by accident, and it gives a retrieval step something unambiguous to match on. It also means that when an assistant does quote the old page, the quote arrives with the version attached to it.

On llms.txt, since you will be asked

John Mueller said in June 2025 that no AI system currently uses llms.txt. Nothing published since has changed that. We still ship one, for a reason that has nothing to do with answer engines. Chrome’s Lighthouse added an experimental Agentic Browsing category that audits for the file, and generating it costs an afternoon. That is a cheap bet on a format, and describing it as anything more would be selling you folklore. The effort that moves this number goes into the HTML the crawlers already fetch, and into the snippets inside it.