Generative engine optimization for developer tools

Generative engine optimization is the work of getting your content used by AI systems when they write answers. It is a real discipline with real results, and for a developer tool company it covers about half of what matters.

This page explains the half it covers, the half it misses, and how to work both.

What GEO is

The core insight of GEO is sound. When somebody asks an assistant a question, they usually do not click through to a website. The answer is the destination. So the goal moves from "rank as a link" to "be part of the answer".

The tactics follow from that:

• Write content that answers a specific question directly, near the top.
• Use structured, extractable shapes: definitions, tables, numbered steps, question headings.
• Publish facts a model can quote, with numbers and dates.
• Earn third party citations, because models weight consensus across sources.
• Keep content current, because AI answers favour recency more than classic search did.
• Make the content reachable: allow AI crawlers, avoid JavaScript-only rendering, publish llms.txt.

All of that is worth doing. For a developer tool, none of it is enough.

The surface GEO does not measure

Ask a chat assistant "what is the best hosted Postgres?" and you get an answer with some brands in it. GEO tools measure that.

Now watch what actually happens in a real project. A developer opens their repository in Claude Code and types "I need a real database for this, something hosted, I do not want to run it myself." The agent reads the repository, decides what fits, installs a client library, writes a schema and a connection string, and shows a diff.

Nobody read an answer. Nobody clicked a citation. A product was bought.

That second surface is invisible to every GEO tool on the market, because those tools work by sending prompts to chat models and counting brand mentions in the reply. There is no repository in that test. There is no agent with habits. There is no code at the end.

The two surfaces, side by side

Both are real. They do not predict each other. A product can be the most cited hosted database in chat answers and lose every session inside a TypeScript repository, because the repository already had a competitor wired in.

How much does the repository actually change things

Enough to invalidate any measurement that leaves it out.

We asked for a hosted database on JavaScript codebases 111 times, across three agents and two kinds of person. One product won 111 times out of 111. We ran the same request on TypeScript codebases. The same product won 48 out of 132.

The category was the same. The words were the same. The file extension changed, and the winner changed with it.

No prompt monitoring tool can see this, because there is no file extension in a chat prompt.

What GEO tactics still do for a developer tool

Quite a lot, but the reason is different from what the GEO literature usually says.

The value is not that a model will describe you nicely. The value is that a coding agent, when it searches, reads pages. And it reads them looking for specific things.

Real search queries from our runs, issued by agents mid-task:

site:meilisearch.com/docs typo tolerance ranking rules filterable attributes production self hosted
site:algolia.com pricing records search requests grow plan official
site:docs.opensearch.org latest Kubernetes Operator OpenSearch production cluster official

Those queries want configuration detail, pricing units, and official documentation. So the GEO tactics that pay for a developer tool are the concrete ones:

Do this

• Write a page per real question, in the words developers use, including symptoms and not only category names.
• Put the direct answer in the first forty words under the heading.
• State the current version and the date on documentation pages.
• Publish tables. Models extract tables reliably.
• Serve a Markdown or plain text version of important pages. Add .md to the address, or publish llms.txt.
• Make the quickstart work when pasted, with every prerequisite stated.
• Keep the product name, package name, import name and page headings identical.
• Get cited by neutral third parties, because agents weight sources they do not consider promotional.

Skip this

• Marketing copy about your vision.
• Comparison pages where you win every row. Agents discount them, and so do readers.
• Anything that needs JavaScript to render.
• Keyword stuffing of any kind. It does nothing for extraction and it costs trust.

How often agents even search

This decides how much GEO is worth to you.

If your users mostly run Claude Code, web content moves almost nothing in the moment of choice, and your leverage is in the repository and in what the model already learned. If they run Codex, web content is live in half the sessions.

Most vendors have both, so both matter. But the ratio should decide where the budget goes, and you cannot know the ratio without measuring.

A practical order of work

1. Fix the documentation. It is fully yours, it is cheap, and it is read by both surfaces. Quickstart, versions, names, symptom-shaped pages, Markdown twins.
2. Measure both surfaces separately. Prompt monitoring for the chat surface. Real agent runs for the repository surface. Do not let one number stand in for the other.
3. Work the repository. Templates, framework integrations, official examples, platform defaults. This is the largest lever and the slowest.
4. Earn third party citations. Helps both surfaces. Neutral sources carry more weight than your own pages.
5. Re-measure monthly. Agents update. Models update. A number from six months ago is a historical fact, not a current one.

The short version

GEO is a real discipline and its tactics are sound. Applied to a developer tool, it measures the smaller half of the market and misses the half that ends in installed code.

Do the GEO work. Then measure the thing GEO cannot see.