Technical content marketing when the reader is a machine

The technical content playbook was built around a person with a problem, a search box, and twenty minutes. That reader still exists. A second reader has arrived, and it wants completely different pages.

What the second reader searches for

These are real queries, issued by coding agents mid-task, 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

Read those carefully, because they contain the whole strategy.

They are long. They are scoped to a site. They ask for configuration options, pricing units, deployment specifics and current version tags. And they keep using one word: official.

The content that answers those queries

Ranked by how often agents in our sessions went looking for it.

1. A complete configuration reference. Every option, its default, its valid range, what breaks when it is wrong. One coherent place, not spread through tutorials.

2. Limits and quotas as numbers. Rate limits, payload sizes, retention, concurrency. In a table, on a page called limits.

3. Pricing in units. Not plan names. What a unit is, what counts as one, where the meter ticks. Several of the personas we tested carry cost constraints, and the agent goes looking.

4. Production setup. What to configure before going live. The word "production" appears constantly in agent queries.

5. Self-hosting and deployment specifics. Even when most customers use your cloud. A missing answer reads as a missing capability.

6. Error messages, verbatim. One page, every error string, with cause and fix. When an agent hits an error it searches the exact text. Owning that result recovers the session.

7. Symptom pages. Real requests describe symptoms, not categories. "People keep signing up with fake emails" rather than "bot protection". If your content only exists in category words, you are absent at the moment the symptom is described.

8. What breaks if you build it yourself. In five of the eighteen categories we measured, the most common outcome was that the agent wrote the code itself. Performance testing 52%, evals 29%, agent frameworks 25%, search 23%, product analytics 23%. In those categories your first competitor is a script, and the page that beats it lists the failure modes with numbers.

The content that answers none of them

Being direct, because this is where most budgets go.

• Vision and category-creation essays.
• Customer stories without technical detail.
• Comparison pages where you win every row. Both readers discount them.
• Anything gated. An agent cannot fill in a form.
• Anything rendered only by JavaScript. A plain fetch returns an empty shell.
• Listicles about your own category.

Some of that has other uses. None of it is read at the moment of choice.

Pricing gets its own page, because agents ask about it more than the category literature suggests: writing a pricing page an agent can use.

Shape beats volume

Forty posts that answer nothing specific lose to six pages that answer exactly what gets searched.

The shape that works, on every page:

• A heading that is the question a developer would type.
• A direct, self-contained answer in the first 40 to 60 words under it.
• A table for anything comparable.
• At least one real number with a date.
• Code that runs when pasted.
• The current version, stated in the text.

Then volume helps. Not before.

Where the pages belong

Mostly in the documentation, not the blog.

That is uncomfortable if content marketing sits in a different team from documentation, which it usually does. But the queries are documentation queries, scoped to documentation sites, asking for official answers. A brilliant blog post about your limits loses to a mediocre documentation page about your limits.

The practical fix is organisational, not editorial: give the content team write access to the docs, or give the docs team the content budget.

How much this is worth depends on the agent

Against Codex, published content is live in half of all decisions and pays back in weeks. Against Claude Code it reaches almost none of them in the moment, and your leverage is the repository and the training data.

So find out which agents your users run before you size the content budget. That single ratio should decide it.

The feedback loop that makes this work

Do not guess which page to write next. Read the sessions where an agent considered your product and chose something else.

A judge that records rejection reasons produces a list of missing pages, written by the buyer. In our data the reasons cluster into a short list, and four out of five of them are a missing or wrong page rather than a missing argument.

That list is a better content brief than anything a strategy workshop produces.