GEO for Developer Tools Companies

TL;DR

Devtools companies live or die in two AI surfaces: conversational engines (ChatGPT, Perplexity, Claude, Google AI Overviews) recommending tools, and coding assistants (Cursor, GitHub Copilot, Claude Code) wiring code against documentation. Winning both requires the same primitives—entity clarity, agent-readable references, an llms.txt index, MCP exposure for action-capable products, and durable community signals—executed with more rigor than a typical content marketing program.

Why devtools GEO is different

Most GEO advice optimizes for an end-user reader. Devtools have two parallel readers and they need different things:

1. The buying engineer asks an answer engine for recommendations: "best auth library for Next.js," "how do I parse PDFs in Python." The engine returns one to three named tools with a brief comparison. Ranking on page 8 of Google does not appear here. You are recommended or you are invisible.
2. The agent assistant is integrating against your API right now. It needs reference content it can ingest in a single fetch, type definitions, runnable examples, and error semantics. If the assistant cannot pull a clean reference, it falls back to a competitor whose docs it can.

These two readers share a small set of source patterns—the API reference, the README, the changelog—so a single, well-engineered documentation surface serves both. Most devtools companies under-invest by treating docs as a hand-off to a content team rather than the core GEO surface.

Layer 1: Anchor the product entity

Publish Organization schema on the company root and SoftwareApplication (or WebApplication/SoftwareSourceCode) schema on the product page, with name, description, applicationCategory, programmingLanguage, operatingSystem, softwareVersion, offers, and a complete sameAs array linking to: GitHub organization, npm/PyPI/crates.io package, Wikipedia (if applicable), LinkedIn, X, Stack Overflow tag, Hacker News user, and any conference speaker pages.

The goal is that an LLM resolving "What is X?" lands on a single canonical entity rather than five fragmented profile pages. Stable identity is doubly load-bearing for devtools because product names often collide with common English words ("Linear", "Box", "Vercel", "Resend").

Layer 2: Build agent-readable documentation

API reference as the entity anchor

An auto-generated, OpenAPI-driven reference is the single highest-value GEO asset a devtools company has. It must be:

• Crawlable as static HTML. Not a SPA that requires JavaScript to render endpoints. Most LLM crawlers do not execute JS reliably.
• One canonical URL per resource and per endpoint. Stable for years.
• Inline code examples in the languages your customers use, with full request/response payloads and error codes.
• Type definitions visible in the page, not behind a tab toggle. Tabs that hide content from the static HTML are invisible to agents.

Keep specification, SDKs, and rendered docs aligned. Documentation drift between OpenAPI spec, generated SDKs, and human-facing reference creates exactly the broken examples that make AI assistants stop recommending you.

Markdown twins and llms.txt

Follow the pattern that platforms like Expo, OpenAI, and LangChain have adopted: every documentation page has a Markdown twin at a predictable URL (commonly /path/to/page/index.md or /path/to/page.md). Then publish two index files at the root:

• /llms.txt — a curated table of contents pointing to the highest-value pages.
• /llms-full.txt — the entire documentation set concatenated as Markdown, suitable for one-shot ingestion into an agent's context window.

This pattern is cheap to automate from any modern docs framework (Mintlify, Fern, Docusaurus, GitBook all support it natively or with a single plugin) and removes ambiguity about which URLs you want LLMs to consume.

GitHub README as canonical short-form

For open-source SDKs and tools, the GitHub README is heavily ingested by training corpora and live retrieval. Treat it as a first-class GEO surface: lead with a one-paragraph plain-language description, an installation snippet, a 30-second example, a link to the canonical docs site, and an explicit "What this is / what this is not" section to assist disambiguation.

Layer 3: Publish a Model Context Protocol server

The Model Context Protocol, introduced by Anthropic in November 2024 and adopted across major AI providers, is the standard interface that lets Claude, ChatGPT, Cursor, and other clients call tools and pull data from external systems. For action-capable devtools (anything with an API your customers script against), publishing an MCP server creates two GEO benefits:

1. Agent-driven activation. Customers can use your product directly inside their AI coding assistant, dramatically lowering trial friction.
2. Discoverability inside agent surfaces. As MCP registries and agent cards mature, the surface you publish becomes a citation channel of its own.

Autonomous agent-side discovery is still maturing—community discussion (for example on r/ClaudeCode) suggests most MCP installs today are still human-configured. Treat MCP publishing as a low-cost, forward-leaning bet rather than a guaranteed inbound channel.

Minimum viable MCP publishing checklist: list the server in the official MCP server registry, expose tools with clear input schemas and descriptions, implement OAuth or token auth without requiring sideloaded scripts, and document the server on a stable URL with installation snippets for the common clients.

Layer 4: Build the community citation surface

The single biggest predictor of being recommended in conversational AI is being talked about on the surfaces those models trust. For devtools that means:

• GitHub: maintained README, populated examples/, used-by badges, pinned star repositories, useful issues with on-topic answers.
• Stack Overflow: a tag for your product (or contributions to existing canonical tags), staff answers on the canonical questions, and links from those answers to your docs.
• Reddit and Hacker News: durable, on-topic threads where your tool is named and linked to the canonical docs URL. Avoid astroturfing—these communities flag it and the resulting penalties bleed into LLM trust signals.
• DEV.to, Lobste.rs, and language-specific blogs: durable how-to posts that solve a real problem and reference your tool by name.
• Conference talks and OSS sponsorships: generate the third-party write-ups that LLMs treat as authoritative.

Keep changelogs fresh. Stale latest version: 0.4.2 text rendered into a static page tells both engineers and LLMs the project is dead.

Common mistakes

• Hiding the API reference behind a JavaScript-rendered SPA.
• Letting OpenAPI, SDK, and docs drift apart.
• Using a clever product name that collides with a common word, with no schema disambiguation.
• Treating the GitHub README as marketing copy rather than canonical documentation short-form.
• Skipping llms.txt because "the standard is debated." It is cheap and removes ambiguity even before it carries traffic.
• Investing only in conversational-AI ranking and ignoring AI coding assistants, where the integration decision is actually made.

FAQ

Q: Do I need both llms.txt and per-page Markdown twins?

Yes if you want full coverage. llms.txt is the curated index; the per-page Markdown twins are what an agent fetches when a user asks about a specific feature. Together they support both "give me the whole library" and "give me this one page" patterns.

Q: Should we publish an MCP server even if usage is low today?

For any product whose value is action-oriented (databases, deployment tools, scripts, automations), yes. The cost is small and the discovery surface inside coding assistants is growing fast. For pure read-only documentation products, the priority is lower.

Q: How important is GitHub stars vs. Stack Overflow tag activity?

Both matter, but for different reasons. GitHub stars and READMEs feed into training corpora and conversational AI recommendations. Stack Overflow tag activity and high-quality answers feed into the assistant surfaces where engineers are wiring code against your API.

Q: Is OpenAPI enough on its own for AI agents?

Not quite. OpenAPI gives agents a machine-readable contract; an llms.txt-pointed Markdown reference gives them a usable narrative. Most production agents work better with both: spec for tool calls, narrative for reasoning about which call to make.

Q: Should we hide our docs behind a login wall?

No. Anything behind an auth wall is invisible to LLM crawlers and to most coding assistants at retrieval time. If you must restrict, gate enterprise-only operational guides; never gate the API reference, getting-started, or core SDK docs.