The content strategy that makes AI agents position you accurately

Cut through the noise and get more signups

Most dev-tools companies are described five different ways: by their homepage, their docs, their README, their founders, and whatever an AI agent pieced together from all four.

When nobody owns the description, everyone who writes explains the product their own way. The site, the docs, the README and the founders’ talks each describe a slightly different product, and buyers and AI agents both have to guess which one is real. In my experience, the first product marketer usually inherits exactly this.

The positioning itself is the company’s work, and it usually exists; it is just not written down in one place. Our work starts there: getting it onto one page, then into every page, post and launch the company ships, until AI agents describe the product the way the company does, including what makes it different from everything else in the category. That is what puts you on their shortlists, and it is where the signups come from.

The working examples are from our own client work: LlamaIndex, which moved its story from an open-source framework to a commercial document-parsing product; Microblink, which writes a different first sentence for each of its three audiences; and DeepInfra, where a new model ships every week.

TL;DR

• Find out how you are described before you change anything. Your own first sentences side by side, and what ChatGPT, Perplexity and Google say about you, including whether they say anything that sets you apart.
• Get the words from sales and engineers, not a workshop. The buyer’s words for the problem, the alternatives they name, one number, one limitation.
• Write down the positioning you already have, on one page, with what makes you different at the centre.
• Build a page for every question buyers ask. If a page does not exist, search and AI agents assume the capability does not.
• Put the same sentence on every surface, word for word, and check every new page against it.
• Make every release lead with the difference. The page and the brief both start from the positioning page.
• Turn every piece into many, each carrying the same line. An AI agent that sees the same difference in five places treats it as established.
• Score it before and after, and give it one owner.

Step 1: Find out how you are described today

Before we change a word, we find out how the company is described right now. Not what the team thinks it says: what a developer or an AI agent actually reads. It takes an afternoon, and it is the “before” column for everything after.

Your own first sentences, side by side

We copy the first sentence from each surface a developer or a crawler reads first into one sheet:

Surface	Where the sentence is
Homepage	The hero line and the line under it
Docs landing page	The first paragraph
GitHub README	The first line under the project name
Founders’ LinkedIn	Each founder’s headline
Review sites and directories	The short description on each listing

Then we read them in a row. Three things give it away. The category word changes from one surface to the next: a “platform” on the homepage, an “SDK” in the README, a “tool” on LinkedIn. The audience changes, or is never named. And no surface names the tools you are an alternative to. As far as a reader is concerned, each one is a different product.

What the AI agents say about you

Then we ask the agents. We run four prompts in ChatGPT, Perplexity and Google AI Overviews and keep the answers.

Prompt	What we check
“What is [product]?”	The category and the audience: are they yours?
“[product] alternatives”	Whether the tools named are the ones you actually compete with, and whether you are described in your terms or a competitor’s
“Best [category] for [audience]”	Whether you are on the shortlist at all
“Does [product] do [X]?”, for your three most important capabilities	Whether the answer is yes, no, or “it’s unclear”

We read the answers for one more thing: does anything in them set you apart? If the agent describes you in the same words it uses for three competitors, you are lost in the noise, even when every fact is right. That is the problem the rest of this guide fixes.

The “does it do X” row is usually the surprise. Countless times we’ve seen solutions pages miss obvious features or industries; if it’s not written on your website, LLMs will not pick up on it, and may even tell customers you do not have these features if they ask for them directly.

The output is one page: how you are described today, on your own surfaces and in the answers. We keep it. In Step 9 we run the same prompts again, and this page is what the new answers are measured against.

Run the GEO audit to see how AI agents understand your website It checks whether ChatGPT, Perplexity and Google AI Overviews can find and describe your product, and which of your pages they cite. Keep the result: it’s your “before”.

Run the free GEO audit

Step 2: Get the words from sales and engineers

The best material for positioning is already inside the building; it just is not in writing yet. Sales hears, every day, what real buyers struggle with, what they compare you to and the words they use for the problem. Engineers know what was built, what they considered instead and where it stops working. I’ve found a 25-minute interview with either produces better positioning than a week of workshops.

We start with what already exists: how the founders describe the product on sales calls, how the docs introduce it, and the pages and posts that brought in the most signups.

The questions

The PMM runs the interviews: 25 minutes each, recorded, transcript back the same day. Sales comes first, because the positioning has to be in the buyer’s words; engineers second, for the proof and the limits.

Ask sales	What it gives the positioning page
What question comes up in every call?	The problem, in the buyer’s words
What do prospects compare us to, and what do they say about those tools?	The alternatives: the “[A] and [B]” in your category statement
Which objection do we lose to, and what do we say back?	What you do that those tools don’t, and where you have to prove it
What did the last three deals we closed have in common?	Who it is for, and the moment they need it
What words do buyers use for the problem that we do not use on the site?	The words that go into the statement and the page titles

Ask an engineer	What it gives the positioning page
What did you build, and what did you consider instead?	The alternatives a developer also weighs, including building it themselves
What broke or surprised you along the way?	Where the product works differently than buyers expect: a limitation to state, or a claim to drop
What number would you put on a slide about this?	The proof behind each claim
What would you tell someone integrating this at 2am?	The first thing a developer needs to know, which is often the plainest description of what it does
What limitation do you wish was documented?	The one limitation you state plainly; it is what makes the rest credible

Other sources worth an hour

• Sales call recordings: the question asked in every call, and the comparison prospects raise, in their own words.
• Lost-deal notes: who you were not right for, and why. That becomes the honest “when not to use us” line, the most trusted thing you will publish.
• Onboarding and support calls: where new users get confused about what the product is for.

We walk out with four things or the interviews were not finished: the buyer’s words for the problem, the alternatives they named, one claim with a number attached, and one limitation stated plainly. Those four are the raw material for Step 3.

Nothing here requires anyone to write; it requires 25 minutes and a willingness to be quoted.

Step 3: Write down the positioning you already have

This is not a new positioning exercise. Your company already knows what it is; the problem is that it lives in the founders’ heads and in five different first sentences. The positioning page we write puts it in one place that every writer, page and launch can copy from.

It comes first because everything downstream repeats it: every page, post, Reddit comment and launch announcement, and the brief for every release in Step 7. Developers decide in seconds whether a tool is for them; LLMs decide from whatever sentence describes you most often across the web.

The page answers five questions, and each answer comes from what you collected in Step 2.

The question	Where the answer comes from
Who is it for? The type of team, and the moment they need it.	What the last three closed deals had in common; the question asked in every call
What would they use instead? A competitor, an open-source tool, or building it themselves. Name them.	What prospects compare you to; what the engineer considered instead
What does it do that those don’t?	The objection you lose to, and what you say back
What’s the proof? A benchmark, a code sample or a customer result for each claim. A claim without one comes off the page.	The number the engineer would put on a slide
What’s the one sentence that sums it up?	All of the above, in the buyer’s words for the problem

The third question is the one the rest of this guide depends on. The other four make it believable: who it is for sets the context, the alternatives give it something to differ from, the proof backs it, and the one sentence carries it onto every surface. Add one limitation, stated plainly: the answer to “what do you wish was documented?” It is what makes the rest credible.

Three things on the page

1. A one-sentence category statement in the form “X is a [category] for [who] that [does what], an alternative to [the two names they already know].” Convex’s reads: an open-source reactive backend for writing server functions in pure TypeScript, an alternative to Firebase and Supabase for TypeScript and React teams. The comparison anchors matter more than the adjectives.
2. A use-case list by audience, not by feature. DeepInfra’s buyers split into ML engineers, startup CTOs and indie developers; each searches for a different problem (GPU pricing, model benchmarks, OpenAI-compatible endpoints).
3. A competitor set you will name out loud. Build your competitor set based on your real competitors as well as your search-engine competitors — they may not compete for your customers, but they likely cover the same content topics and compete for the same SERP real estate.

This might already exist in your head, but in our experience writing it down is extremely helpful for writers, audiences and — most importantly — LLMs.

It is finished when someone outside the company can read the homepage and explain the product back in one sentence.

On a real account: LlamaIndex

The story had to move from the open-source framework everyone knew to the commercial document-parsing product. The positioning page we wrote set the KPI with it: non-branded organic traffic, “best OCR software” rather than “llamaindex OCR”. Every piece we’ve written since has been written to that sentence, and clicks on queries containing “ocr” went from 303 to 5,454 in a year.

Step 4: Build a page for every question buyers ask

If a page does not exist, Google and LLMs assume the capability does not exist. Most dev-tool sites are a homepage, docs and pricing, and the team believes the rest is obvious. It is obvious to you. ChatGPT has only indexed what you published, and it will recommend the competitor whose site spells it out.

We build each page type from one part of the positioning page. That is what keeps forty pages saying the same thing about you.

Page type	What it answers	Comes from the positioning page	Example from client work
Product page, one per product	“What is [product]?”	The category statement, as its first sentence	Microblink: separate pages for BlinkID, BlinkID Verify, BlinkCard
Feature page, one per capability	“Does [product] do X?”	Your capabilities, starting with the “does it do X” answers from Step 1	DeepInfra: OpenAI-compatible API, dedicated GPU capacity
Model or integration page, one per item	“Does [product] support [thing]?”	The models, languages or frameworks you support	DeepInfra: a page per model (Llama, DeepSeek, Mistral, Qwen) plus model-family pages
Solution page, one per use case	“[Product] for [job]”	The use-case list by audience	Microblink: age verification for gaming, KYC automation for fintech, document scanning for travel
Comparison page, one per competitor	“[Product] vs [competitor]”	The competitor set	Convex vs Firebase, Convex vs Supabase
Integration page, one per connected tool	“[Task] with [popular tool]”	The tools buyers mention on sales calls	A document-parsing API: “parse PDFs from SharePoint”, “index Google Drive files”, “load Notion pages”
Pricing page with real numbers	“What does it cost?”	The proof	“Contact us” pricing gets left out of AI recommendations

What every page carries

Element	The rule
The name	In the title, URL and first sentence, spelled the way people search for it
What it does	One sentence, from the positioning page
The specifics	Limits, pricing, supported languages or frameworks, in a table
A working snippet	Where there is code, tested by someone who did not build it
One limitation	Stated plainly; it is what makes the rest credible
The next step	Something a developer can do in five minutes

Integrations: ride the popularity of the tools you connect to

If your product connects to other software, every connection is a page. Developers do not search for your product; they search for the job plus the tool they already use: “parse PDFs from SharePoint”, “sync Postgres to a vector store”, “Slack alerts from Datadog”. Build one page per integration, titled with the task and the brand, with a code sample, the auth steps, the limits, and a link into the docs. Order the backlog by the partner tool’s popularity, not by how proud you are of the integration.

Two rules that save months later: give every page a stable URL now, because launches link into them and redirects leak authority; and design one template per page type so product managers can ship a new feature or integration page without a designer. Both matter again in Steps 6 to 8: every release adds a page to this map and links into it.

On a real account: Microblink

Three products, three audiences (developers, compliance officers, enterprise security buyers). Our keyword research split developer-intent from compliance-intent queries, and each intent got its own /services/ page in that audience’s vocabulary: KYC API for developers (SDK size, latency, response payload) next to automated KYC for compliance; liveness detection and selfie verification as one capability under two buyer searches; banking onboarding as the industry entry point. Same product, different first sentence per reader. Case study

On a real account: ReadMe

For ReadMe.com, we built explicit buying-intent pages for searches like “api documentation tool” and “api documentation generator” — the queries buyers type, kept separate from the developer-facing docs. 74 keywords improved on their old blog versions and total ranking keywords grew 11%, from 550 to 611. Case study

Step 5: Put the same sentence everywhere, and keep it there

We put the category statement on the homepage, the docs landing page, the GitHub README and the founder’s LinkedIn headline, word for word. Consistency across sources is what makes an LLM confident enough to repeat it.

The order we roll it out

The first five surfaces are the ones on your Step 1 sheet, so the sheet becomes the checklist.

Order	Surface	Who changes it
1	Homepage hero	The PMM
2	Docs landing page	DevRel
3	GitHub README	DevRel or the maintainer
4	Founders’ LinkedIn headlines	Each founder
5	Review sites and directories	The PMM
6	The first sentence of every page in the Step 4 map	Whoever owns that page

Keeping it consistent

We check that the name, the category and the audience read the same on every surface. AI agents gain confidence from agreement across sources and lose it from a stale description in one of them.

One rule keeps it that way: someone reads every new page, post and launch announcement against the positioning page before it goes live. It takes 30 minutes, and it is how a new hire’s first page ends up saying the same thing as the homepage.

Not sure which pages are still missing? Run the free GEO audit: it shows which questions about your product AI agents still can’t answer from your site, and what to build next.

Run the free GEO audit

Make everything you ship carry it

The positioning page is written once. Everything after it is repetition: every release, every post, every reply in a thread. That repetition is what AI agents learn from. An agent that sees the same difference described in five places, in the same words, treats it as established; an agent that sees it once, on your homepage, treats it as a claim. This part is how we make every piece you ship carry it.

Step 6: Make every release lead with the difference

If a feature does not have a page, search and AI agents assume you do not have it. Launch posts are time-stamped and sink; a feature page on a stable URL is what gets found and cited six months later. So we give every release a page first, and the announcement points at it.

The page’s first sentence says what the feature does in the positioning page’s words, and where it is different from the alternatives the positioning page names. The feature is new; the reason to pick you is not, and the page should say both.

Bigger releases get supporting pages too, each catching a question the feature page cannot:

Page	Build it when
Pricing or plan page	The feature changes what things cost
Comparison or “best of” page	Developers will shortlist you against alternatives for this; it names the competitor set from Step 3
Integration guide	There is code to copy
Benchmark or data piece	You have a number nobody else has
What changed, migration	Existing users have to migrate

Each one links back to the feature page, and the feature page links into the Step 4 map. The full launch page set, and which releases deserve it, is in the launch to pipeline playbook.

Step 7: Write the brief in the positioning language

Launch posts drift furthest from the positioning, because they get written last, by the person who built the feature, from the pull request description. Our fix is a six-field brief, filled from a 25-minute interview with that engineer, and everything for the release is written from the brief, in the positioning language. The engineer does not write; they answer questions and check the code.

Field	Where it comes from
What is new, in one sentence a developer would repeat	The engineer, then rewritten against the positioning page
Who it is for, and the moment they need it	The positioning page’s use-case list; the sales calls that asked for it
What they can do now that they could not yesterday	The engineer: “what does this let someone build?”
How to try it in five minutes	The snippet, the flag, the playground link; tested by someone who did not build it
One number	A benchmark, a limit, a latency, a price. The engineer: “what would you put on a slide?”
One limitation, stated plainly	The engineer: “what do you wish was documented?”

Then one check before anything is written: does the first field say what is new in a way that also says why you are different? If it could be pasted into a competitor’s changelog unchanged, rewrite it.

Step 8: Turn every piece into many, each carrying the same line

The team already produces more raw material than it publishes: a changelog entry, a conference talk, a long Discord answer, a YouTube walkthrough, a sales call. Each is one piece in one place. The habit we build in this step is to ask, of everything you ship, what else it is and where else it goes.

What you already have	What else it is
A conference or meetup talk	An article (the talk is its outline), a quickstart from the demo repo, a thread of the three best slides
A YouTube walkthrough	A written tutorial with the code pulled out, a docs example, a Reddit build guide
A changelog entry	A launch post in the positioning language, a short demo, a user email, a changelog thread on X
A long answer in Discord or a GitHub issue	A docs page, because the next person will ask the same thing; a glossary entry if it defines a term
A sales or onboarding call	A use-case piece in the buyer’s words; a “[product] vs [alternative]” page if the comparison came up
A benchmark an engineer ran internally	An original-data post with the method published; the most shareable thing on Reddit

Where each version goes, and what stays the same

The format changes with the channel. The sentence about what makes you different does not.

Channel	Form	Where the positioning shows
Your site	The article or feature page; the citable URL	The first sentence, from the positioning page
X	A short thread under the founder’s or the engineer’s name	The brief’s first field, as the opening line
LinkedIn	One takeaway in the author’s voice, the demo inline, link in the first comment	The difference, in the author’s words, not a tagline
Reddit	A complete answer, or a build guide where the product is one tool among several, under a real name	Shown in the build, not claimed; the alternatives named
dev.to or Medium	The guide or benchmark, republished with a canonical link back to your page	The same first paragraph as your site
Email to users	What changed, how to try it, two paragraphs	The same one sentence

Republishing is the point, not a shortcut. The same integration guide on your site, on dev.to with a canonical, and summarized in a Reddit answer is three mentions in three places the AI agents read, in one week, from one piece of writing. We set the canonical tag so the search credit stays with your page.

The rule I’ve found makes this work without a marketing team: the person who made the original does not make the derivatives. The engineer gave the talk; the DevRel writes it up; whoever handles the changelog sends the email. Nobody is asked to write more than they already do. The full channel list, and how to post on Reddit without getting banned, are in the launch to pipeline playbook.

On a real account: Convex

Convex had hours of YouTube content that developers were watching and nobody was reading, because none of it existed as text. We turned the videos into articles on their Stack blog: the transcript as the source, the code written out where the video only showed it, Convex’s voice, and internal links into the docs. The engineers who recorded the videos did nothing new. Case study

On a real account: DeepInfra

With the pages, the bundle and the mentions running on every release: blog clicks from Google went from 1,347 to 18,551 year over year, signups from organic sessions landing on the blog from 9 to 464, and organic sign-ups per session from 2.9% to 8.6%. In Gemini, deepinfra.com is now the most-cited domain for the inference prompts we track, with 563 citations in four weeks against 382 for artificialanalysis.ai and 353 for OpenRouter. Case study

Step 9: Score it before and after

This guide promises one outcome: AI agents describe you accurately, including what makes you different. So that is the first thing we score, against the page you kept from Step 1. Then whether it turned into signups.

Source	What we pull	When	What it tells you
The Step 1 prompts, rerun in ChatGPT, Perplexity and Google AI Overviews	The category, the audience, the competitors named, the features present, and whether the answer says what makes you different	Day 30, 60, 90	Whether AI agents position you accurately
PromptWatch	Presence on the shortlist prompts (“best [category] for [audience]”) and citations for your pages	Day 30, 60, 90	Whether you are recommended, and whether your page or someone’s roundup gets the credit
Google Search Console	Impressions and clicks for category terms and non-branded queries	Day 30, 90	Whether search sees you for what you are, not only for your name
GA4	Sessions and signups landing on the page map and the release pages, by source, per 100 sessions	Day 30, 90	Whether any of it turned into signups

We weight the shortlist prompts highest. A yes/no prompt gets you confirmed; a shortlist prompt gets you recommended, and that is where a description turns into a new customer. Keep it to five to ten prompts, weighted toward shortlists, starting from the questions sales hears in every call.

When an answer is still wrong at day 90, the Step 1 page tells you where to look: a surface that never changed, a page that does not exist yet, or a difference nobody repeated.

Step 10: Give the positioning one owner

Positioning drifts the moment nobody owns it: a new hire writes a page from memory, a founder updates their bio, a launch post borrows the pull request description. We give it one owner, and a small job to everyone around them.

Who	Owns	How often
The PMM	The positioning page, the rollout, the Step 9 scorecard	Rollout once; review every quarter
Sales	The buyer’s words: new questions, new comparisons, lost deals	One conversation a month
Engineers	The proof and the limits for each release	The 25-minute interview per release
DevRel	Docs, the README, Reddit and dev.to	As things ship
Founders	Their LinkedIn headlines and their talks	When the positioning page changes
The checker	Reads every new page, post and announcement against the positioning page	30 minutes per piece

We rewrite the positioning page when the product changes who it is for, when a new competitor shows up in the alternatives answers, or when the day-90 answers drift from it. Otherwise we leave it alone; a positioning page that changes every month is not one.

Once the positioning is on every surface, launches are where it gets repeated most often. The launch to pipeline playbook covers the rest: which releases deserve a full launch, the templates, launch week, every channel, Reddit, and the two weeks of mentions after.

The playbook on real accounts

The same process, as we ran it on four accounts.

LlamaIndex

Document parsing; the story moved from an open-source framework to a commercial product

18x OCR clicks (1,097 sign-ups from new content sections in Q3 · #1 cited domain in AI Overviews)

A positioning page with a non-branded KPI, the low-volume cluster built out around it, and listicles structured for citations.

Ask us about the LlamaIndex work

Microblink

Identity verification SDKs, three audiences

+173% traffic (+87% keywords · $33,000/month organic value)

Intent-split architecture: a page per audience in that audience’s vocabulary, three content formats, glossary and listicles for LLMs.

Read the Microblink case study

Convex

Open-source TypeScript backend, a Firebase and Supabase alternative

Help center from zero (intent-clustered keyword map · GA4 to signups and activations)

A TypeScript help center built from no content infrastructure, with the brand only where it is the honest answer.

Read the Convex case study

DeepInfra

Serverless AI inference; a new model most weeks

9 → 464 (signups from organic blog sessions · most-cited domain in Gemini for inference prompts)

Every release on a page the same day, written from one brief, and repeated across the channels developers read.

Read the DeepInfra case study

Run it yourselves, or have us run it

Everything above is doable by a PMM with help from sales, an engineer and DevRel. The hard part is not the positioning page; it is keeping every page, post and launch on it, week after week, while everyone has another job.

	In-house	With AUQ
The audit and the positioning page	Written by whoever has time, usually from the founders’ heads	Built from your sales and engineering interviews, in the buyer’s words, with the AI answers as the “before”
The page map	Built when someone notices a gap	Built in order of the questions buyers ask, one template per page type
Everything you ship	On-message when someone remembers	Every page, post and launch written from the positioning page by a subject-matter author, and checked before it goes live
The scorecard	A spreadsheet someone meant to keep	AI answers rerun at day 30, 60 and 90, with signups beside them

What stays yours either way: the product, the positioning, and the people who know why it matters. We never invent any of those.

Start with how you’re described today

We work with developer-tools companies where generalist content fails, and we hire a subject-matter author for every account rather than a generalist. Send us your homepage and your last three launches; we will come back with how AI agents describe you today, where your own surfaces disagree, and which pages are missing.

Book an audit with AUQ · More case studies

Related reading

• GEO for PLG SaaS: AI answers and self-serve signups