AI visibility for
dev tools.

Developer questions draw on the most technical source mix of any vertical: official documentation, GitHub READMEs and issue threads, Stack Overflow, and Hacker News. In our citation-source data, GitHub discussions, Stack Overflow and Hacker News together account for a share comparable to Wikipedia's — a concentration in engineering forums that no other vertical shows.

Two query modes behave completely differently. Recommendation queries — 'best X for Y' — get answered from comparison content and forum consensus. Implementation queries — 'how do I do Z' — resolve almost deterministically to the documentation of whoever owns the underlying technology. Your documentation is therefore not marketing collateral; it is the corpus that decides one of the two modes outright.

The composition step assembles a working code path. A documentation page containing a complete, runnable example gets quoted whole. A page whose example depends on 'the configuration from the previous section' produces a chunk that is useless in isolation, and gets skipped in favour of a Stack Overflow answer that happens to be self-contained.

llms.txt, proposed by Jeremy Howard at Answer.AI in September 2024, is this vertical's one purpose-built lever: a root file declaring which URLs are worth ingesting and what the project is, with llms-full.txt inlining the corpus itself. Neither is a ranking factor. Both change what a crawler ingests in a single pass, which is worth three points in the technical pillar and considerably more in practice.

'Alternative to <incumbent>' and 'migrate from <incumbent>' are the highest-intent shapes in the category, and the incumbent will never write either one. A developer typing them has already made the decision and is now costing the switch.

Constraint queries are the second tier and they are pure spec facts: 'self-hostable', 'supports WebSockets', 'no Node dependency', 'works with Postgres 16'. Every constraint the developer applies has already disqualified the defaults, which is why a small tool can win these while losing every unconstrained comparison in the category.

'How do I <task> with <your product>' is not an acquisition query, but it is the expansion and retention query, and your documentation wins it by default. Track it in a separate bucket so it does not flatter your acquisition numbers.

'How do I <task> with <competitor>' is unwinnable. The model routes implementation questions to the owning vendor's documentation, so pages you write about someone else's API are accurate, expensive and never cited. Several dev-tool companies have built entire content programmes on this shape and got nothing back.

Language and framework queries — 'best backend framework for X' — are decided by a decade of accumulated community corpus and are not movable by a vendor. They carry the largest volume in the category and are the worst possible use of a dev-tool content budget.

Stripe's documentation is the reference implementation of the winning structure: one concept per URL, a complete example on every page, and URLs that have stayed stable for years. A chunk retrieved from any page stands alone. That property, not the writing quality, is what produces the citation rate.

Supabase's advantage is structural in a way that is easy to miss: because the project is open source, its code, issues and READMEs are themselves in the corpus, and the documentation restates the same claims — so the model sees two apparently independent sources agreeing. Vercel offers the whole documentation corpus pre-digested through llms.txt. Prisma wrote a comparison page per competing ORM before anyone asked for one. Clerk phrases feature claims as specific capabilities rather than benefits.

Every one of those except the open-source corroboration is a week of engineering work rather than a budget line. Split the docs, add a complete example per page, write the migration guides, generate llms.txt on release. The decade of Stack Overflow answers sitting behind the incumbents is not reproducible, but its shape is — engineers answering category questions under their own names accumulates the same kind of signal.

Marketing-site SEO. Dev-tool companies keep commissioning 'what is observability' explainers. Developers do not ask that question of a vendor site, and when they ask a model the answer comes from the weights with no citation attached to anyone. The same budget spent on one migration guide per competitor produces pages that match real query shapes.

Client-rendered documentation. A docs site that renders through hash routing, or that hides content behind a search-only interface, fails the crawl-blocking-JavaScript check worth three points — and the practical consequence is worse than the score, because the entire corpus that decides implementation queries becomes unreachable.

Unversioned canonicals. Serving /v1, /v2 and /latest without canonical tags triplicates every claim you make and hands the retrieval layer three candidates, one of which is deprecated. It is a purely mechanical own-goal and it is extremely common.

HowTo schema shipped as a Google play: Google deprecated HowTo rich results in 2023, so there is no search feature left to win. The markup still earns three points in the rubric because it segments steps for extraction, but if the rich result was your reason for shipping it, re-derive the reason before spending a sprint.

Google's Indexing API for documentation. It is documented only for JobPosting and BroadcastEvent, and using it for anything else does nothing. IndexNow — the open protocol operated by Bing and Yandex — is the one that matters here, because Bing's index feeds ChatGPT's browsing tool. And brand accounts on Hacker News or Reddit: the identity is the signal in those communities, so a company account announcing a launch produces a dead thread and a small reputational cost.

Dev-tool benchmarks are almost entirely about documentation architecture. The unusual thing about this vertical is that every row below is engineering work you can put on a sprint board, which is why the gap between an invisible dev tool and a cited one closes faster here than anywhere else.

Fix documentation granularity first, even though llms.txt is easier, because an llms.txt pointing at pages that are not self-contained just delivers unusable chunks faster. Granularity and example coverage are the two rows that change what a retrieved span actually contains.