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 gives this engagement a direct test. Run the snippet against the documented version and record the result.

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.

We report how many tasks passed, which release we tested and the errors from failed tasks. That gives your team something it can reproduce. A citation count alone does not tell you whether the suggested code worked.

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’s December 2024 measurements found no JavaScript rendering from the OpenAI, Anthropic and Perplexity crawlers they observed. That finding has a date and a defined sample. We check whether your current documentation reaches the crawlers you want to support.

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

Google Search says it ignores llms.txt. That does not tell us what every other system does. Publish one when it helps a documented consumer find the right material. We do not count the file itself as evidence of better rankings or more citations.

Correction, 23 September 2026: the earlier version said no AI system used llms.txt. The claim now applies to Google Search. The crawler rendering observation now names its date and sample.