How to get your product recommended by Codex

Codex is the agent where publishing works best. It goes and looks in almost every decision it makes, which means the page you write this month can change an outcome next month.

That is not true of every agent to the same degree, and it should change where you spend.

The number

If a meaningful share of your users run Codex, content is your highest leverage work and it pays back quickly.

What Codex actually searches for

This is the part that changes what you write. Agent queries are nothing like the queries a person types. They are long, specific, and usually scoped to a site.

Real queries from our sessions:

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
site:docs.opensearch.org latest index state management snapshots security plugin official documentation
site:postgresql.org/docs/current pg_trgm GIN index similarity ILIKE official documentation
site:hub.docker.com/r/getmeili/meilisearch tags v1.37

Look at what those want:

• Configuration options and what they do
• Limits and quotas as numbers
• Pricing units, not plan names
• Self-hosting and deployment specifics
• Current version tags
• The word "official", repeatedly

Now look at what most vendor content is: positioning, vision, customer stories, comparison pages. None of that answers any of those queries.

The pages that win Codex sessions

Write these, in this order.

1. A complete configuration reference. Every option, its default, its valid range, and what happens if you get it wrong. One page or a clean set of pages, not scattered across a tutorial.

2. Limits and quotas as numbers. Rate limits, size limits, retention, concurrency. Numbers, in a table, on a page that says "limits".

3. Pricing in units. Not "Pro plan $99". What a unit is, what counts as one, and where the meter ticks. Agents ask about pricing more than you would expect, because the personas we tested include people with cost constraints.

4. A production checklist. What to set before going live. Agents searching "production" and "official" are looking for exactly this.

5. Self-hosting and deployment. Even if most users are on your cloud, the agent asks, and a missing answer reads as a missing capability.

6. Your error messages, verbatim. One page listing every error string with its cause and its fix. When an agent hits an error it searches for the exact text. If you own that result you recover the session.

7. Current version, stated on the page. In the text, near the top:

Current version: 4.2.1 (September 2026)

Models carry old interfaces. This one line prevents a whole class of failure.

Make the pages reachable

None of it counts if the fetch returns nothing.

• Do not require JavaScript. If your documentation is a client-rendered application, a plain fetch gets an empty shell. Server render it, or serve a static copy.
• Allow the crawlers by name in robots.txt: GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended and the rest.
• Publish a Markdown twin. Same content, same address plus .md. Agents read Markdown better than a rendered documentation site, and almost nobody does this.
• Publish llms.txt at the root, listing what matters and where it is.
• Use one heading per question. The query is a question. Your heading should be that question.

The thing that still beats content

Being honest about the ceiling: even for Codex, the repository outweighs everything you publish.

The same email request went to Resend in 38 of 51 sessions on TypeScript codebases and to SendGrid in 16 of 17 on a Python codebase. A sentence in a repository file naming a preferred product was followed 16 of 18 times, and lost 2 of 3 once a rival library was installed.

So content is the fastest lever with Codex, and templates and framework integrations are still the largest. Do both, in that order, because content pays back in weeks and integrations pay back in years.

What Codex picked differently

In 16 of 31 categories, Codex and Claude Code named different leaders.

There is a pattern worth noticing. Codex leans towards the larger, more established option in several of these rows: AWS Lambda, Auth0, Google Maps, DocuSign. That is consistent with an agent that searches, finds a lot of written material, and weighs what it finds. Established products have more written about them.

For a challenger, that means the written record is the thing to fix, and Codex is the agent most likely to notice when you fix it.

Building rather than buying

Codex wrote its own implementation in 6% of runs, against 12% for Claude Code. It is the easier of the two to sell to.

That said, in categories where in-house is common at all, it is still your competitor: performance testing, agent frameworks, evals and search, where Codex wrote its own in between a fifth and a third of sessions. The counter is the same, and for Codex it can live on the open web rather than only in the training data: a specific page about what breaks, with numbers.

How to check whether it worked

Run Codex on three repositories that look like your users' projects, with ten requests written the way your users describe the problem. Five runs each. Record what got installed. Then read the sessions you lost, and look at what the agent searched for before it decided.

That last part is the useful bit. With Codex you can see the queries it ran, which tells you exactly which page to write next. In our sessions it did not show the result lists, so you see what it asked, not everything it read.