What to write about when nobody searches your name
What we are solving
Section titled “What we are solving”Nobody types your product name yet. People search for their problem, in their own words, and they ask for the same answer in a dozen different phrasings.
So work with a cluster, not with a keyword and not with a topic: a cluster is the set of phrasings one page can answer in full, without splitting its answer in half.
Get the clusters wrong and you pay twice: first for writing the pages, then for merging the extra ones.
Where the phrasings come from
Section titled “Where the phrasings come from”Take them from support messages, reviews, forum threads and search autocomplete — anywhere people described the problem in their own words will do.
Write the words down exactly as they came, clumsy ones included, because the clumsy ones are what people actually type.
The one source I do not use is myself: I hear my own word for a feature all day, so it sounds natural to me, and nobody else types it.
The queries you already appear for and lose
Section titled “The queries you already appear for and lose”Search Console’s Performance report lists queries by impressions, not only by clicks, and that makes it the cheapest place to look. It opens from the property’s left-hand navigation, and the list you want is the Queries tab.
Find a query there with impressions and no clicks. You are already reaching that demand and losing it: you are on the results page, people read your line, and they go elsewhere. You do not have to invent that cluster — you already have it.
The capability nobody is searching for
Section titled “The capability nobody is searching for”Compare that list against what people actually do inside the product. On one project the most-used feature had 0 queries in the report, and the reason was simple: no page of mine named that feature.
So the report does not know about it, and that is a very different thing from nobody wanting it. The hole is in your map, not in the demand.
One page or two
Section titled “One page or two”Split by intent first, and by topic after that. Intent comes in three kinds: transactional, comparison, informational.
Same topic with different intent means different pages, so “X pricing” and “what is X” cannot share one page: one of them loses.
Then test the grouping against the results page, not against your own logic: search two candidate queries and compare the top URLs. Mostly the same URLs means one cluster. Different page types — a tool, a listicle, a product page — mean different clusters.
The results page shows what search thinks the query wants, and if comparisons hold the top, your essay will not take a slot there. Argue with search after you rank.
Who owns which query
Section titled “Who owns which query”Write it down as a table: one row is one cluster and one page, and you can commit that table next to the pages.
| Cluster | Primary query | URL | Status |
|---|---|---|---|
| transcription pricing | voice bot pricing | /pricing/ | published |
| free alternatives | free voice-to-text bot | — | to write |
The table stops next month’s article from quietly claiming somebody else’s query, because you can see that the query already has an owning page.
I kept the plan in my head for a while, and it ended with me publishing a page that competed with one of my own.
What to write first
Section titled “What to write first”Transactional first, then comparison, then informational. The order follows the money, not the volume.
A small query that ends in a signup beats a large one that ends in a bounce, and you will run out of energy long before you run out of clusters.
That order is easier to hold when the map is in front of you. Semrush groups the 76,416 keywords around ai voice agent into topics, and the column on the left is that grouping:
Semrush Keyword Magic Tool for ai voice agent, United States database, read on 13 August 2026. I would have written my first page for the head phrase, which carries 1,900 searches against 2,227,840 for the whole set. The clusters shaped like money sit lower and smaller: pricing 669, healthcare voice assistants 586, insurance 248, education appointment scheduling 145.
Each of those clusters is one page’s worth of demand, and staring at the head phrase alone would not have shown me a single one.
What did not work
Section titled “What did not work”- A page per keyword. Each one answered a variant of the same question, none had enough substance to rank, and read together they looked exactly like what a machine produces.
- Two pages chasing one intent. The same query returned different URLs on different days, and the average position sat still while search chose badly between them. The fix was a merge and a redirect, not a rewrite of each.
- Naming things in my own vocabulary. My word for the core feature was not the word people typed. The pages existed and the demand existed. They never met.
- Writing to the biggest volume number. The large informational cluster brought readers who had no reason to sign up. The small transactional cluster moved something.
- Reading low clicks as a content problem. Impressions with no clicks is a title and snippet problem. I rewrote the body twice before I read the report properly.
- Keeping the plan in my head. Months later I could not remember which page owned which query, so I published a new page that competed with one I already had.
Verify
Section titled “Verify”Run /atlas:content-plan from Tools. It takes the project description, the audience language and an optional query export, and returns clusters with one page each, in a markdown table you can commit next to the pages.
Then read the report two ways.
- Filter by page and count distinct queries. A cluster page collects many; a keyword page collects one.
- Filter by query and count your own URLs. More than one means the pages are competing, and the merge is already overdue.
- Compare impressions for the cluster before and after publishing, because impressions move first and clicks follow later. Do not read week one as a verdict.
- Check that every row in the table has exactly one owning URL, and that the URL exists.
The plan says which page to write. What goes inside it is the next problem: what a page that ranks and gets cited is made of.