A use-case page deserves to exist when the audience it names asks materially different questions, needs different evidence, or has different requirements from the audience your existing page already serves. If the only thing that changes is the job title in the headline, you have a thin variant, and it adds maintenance without adding anything a buyer or an AI answer could use. The test is whether you can write down what the new page says that the old one cannot. This post gives you a six-test rubric to score that, a decision table, and a worked example.

In short

Decide on differences in questions, evidence and requirements, not on the number of audiences you can name.
Score each candidate with the six-test rubric below. Many candidates should end as a section on an existing page, not a new page.
Your tracked prompts and citation gaps are evidence of demand. A persona run is a way to form a hypothesis, not proof that an audience needs its own page.
A page you cannot keep accurate is a liability. Include the upkeep cost in the decision.
Write the decision down so the next request for "a page for X" has something to be tested against.

What is a use-case page, and what makes one thin?

A use-case page is a page written for one audience or one job to be done, such as "document review for compliance teams", that explains how your product fits that situation. A thin variant is a use-case page whose body is the general product page with the audience name swapped in.

The difference shows up when you try to complete this sentence: "This page answers questions that the [nearest existing page] does not, namely...". If you can only finish it with "it says compliance instead of legal", the page is thin. If you can finish it with a specific list of questions, requirements or proof points, you have a candidate.

Thin variants are a problem for readers first. A buyer who lands on one learns nothing they would not have learned elsewhere on your site. They are also a problem for maintenance: every fact on the general page must now be kept true on each copy.

Why does this decision matter for AI answers?

AI answers are built from questions, and different audiences ask different ones. A use-case page is one way to give an answer engine a page that responds directly to a question it might be asked on that audience's behalf.

That is a hypothesis, not a promise. Adding a page does not guarantee a mention or a citation, and nothing in the DiscoveredBy docs says that audience pages outperform a well-built general page. What you can do is use evidence you already collect to decide whether a page has a real question to answer. That evidence comes from three places: the prompts you track, the sources engines cite for them, and the citation gaps between your pages and the pages that win.

A decision path with three outcomes: create a new page, add a section to an existing page, or do not create anything. — A simplified path; the full rubric also scores observed demand.

What are the six tests for a use-case page?

Score each test 0, 1 or 2, where 0 means no real difference, 1 means a partial difference, and 2 means a clear difference you can name. Each test asks a question you can answer with evidence, not opinion.

Different questions. Does this audience ask questions the existing page never answers? Look at the prompts you would track for them. If the wording differs only by the audience name, score 0.
Different evidence. Does this audience need proof the existing page lacks, such as a specific integration, a certification, a kind of customer, or a process detail? Proof you already have and merely have not placed on the page still counts, because you can supply it truthfully.
Different requirements. Are there constraints that change the buying decision, such as regulatory context, team size, data handling or approval steps? A requirement that changes the answer to "is this right for me?" scores 2.
No good home. Is there really no page that could carry this? If the nearest existing page could take a well-labelled section and stay coherent, score 0. If adding it would make that page confusing, score 2.
Observed demand. Is there evidence in your monitoring that engines answer this audience's questions without you, or with someone else's page? Score 2 when you track prompts for this audience and the same rival pages keep being cited. Score 0 if the only source is a colleague's hunch.
Upkeep. Can you keep the page true? Score 2 when a named owner exists and the facts on it come from the same source as the rest of your site. Score 1 when an owner exists but some facts would be copied by hand from another page. Score 0 when there is no owner, or the page would repeat facts that live in several places.

How do you read the total?

Total (of 12)	Decision	What to do
0 to 4	Do not create	Note the request, add the audience's wording to an existing page if it helps, revisit if demand evidence appears
5 to 8	Add a section	Add a labelled section to the nearest page, using the differing questions and evidence
9 to 12	Create the page	Brief a new page around the differing questions, evidence and requirements

Two rules override the total. Never create a page when test 6 scores 0, because a page you cannot keep accurate is worse than no page. And never create one when tests 1, 2 and 3 all score 0, whatever the rest says, because nothing distinguishes it. The thresholds are a starting convention for your team to adjust, not an industry standard.

How do you gather the evidence for each test?

Gather it before scoring, so the scores reflect what you found rather than what you expected. Most of it comes from things you can do in a monitoring tool and from your own site.

Tests 1 to 3: compare what the audience asks

Write the ten questions you think this audience would ask at the moment they are choosing a product. Then put them next to the questions the existing page already answers. Every question the existing page does not answer is a difference; every question that is the general one with a job title added is not.

If your monitoring tool supports audience personas, a persona is a useful way to draft candidate questions. In DiscoveredBy (personas depend on your plan; see plans and limits), a persona is a named buyer profile (a name and a short description) that a tracked prompt can run as, alongside the plain unbranded "General" audience. Each active persona can also propose up to 10 buyer-intent questions it would plausibly ask, saved as pending suggestions you review; nothing is tracked automatically.

Be careful what you conclude from persona runs. The persona is added to the message as an audience block of text. It is not a signed-in session, a saved profile or a separate account. And persona variants are not sent to Google AI Overviews, Google AI Mode, ChatGPT (app) or Gemini (app), so those engines tell you nothing about the persona. If a persona changes an answer, treat it as a reason to look harder, not as proof the audience's real needs differ.

Test 5: look for citation gaps

A citation gap is the difference between what the pages engines cite for a prompt contain and what your own page offers. In DiscoveredBy, the citation gaps queue (available depending on your plan) considers a prompt only when, over its trailing window, you appear in under 30% of that prompt's runs and at least one citation points at a domain that is not yours. It compares the five most-cited competing pages for the prompt against your best matching page.

The citation gaps list, ranked by impact score, with the evidence and the accept, dismiss and open actions for each opportunity. — Demo data. The citation gaps queue is one input to the "observed demand" test.

Two things in that workflow bear on this decision. When no page of yours is a close enough match, the opportunity is to create one instead of fixing an existing page. And accepting an opportunity creates a candidate topic on the Articles screen, where the brief decides which asset to build: updating a page you own, publishing something new, or holding off. Only a new article or a comparison page gets drafted; for other outcomes the brief is the deliverable. The brief can therefore tell you to hold off, which is a valid result of this rubric too.

For a walk-through of ranking those gaps, see find the citation gaps that deserve your next content update.

Test 6: settle upkeep with a fact list

Before approving a page, list every fact it will state (for example integrations, regions, limits and certifications) and where each is maintained. If most facts already have one owner and one source, the page is cheap to keep true. If they are scattered, the page will drift.

A copyable use-case page decision record

Fill in one record per request. It becomes the reference for the next request.

USE-CASE PAGE DECISION RECORD

Requested by / date:
Audience or use case:
Nearest existing page (URL):

Evidence gathered
- Questions this audience asks that the nearest page does not answer (list):
- Proof or evidence this audience needs that the nearest page lacks (list):
- Requirements that change the buying decision (list):
- Tracked prompts for this audience, and which pages are cited for them:
- Citation gap or opportunity link, if any:
- Facts the page would state, and the single source for each:
- Named owner for upkeep:

Scores (0 = no difference, 1 = partial, 2 = clear)
1 Different questions:     _
2 Different evidence:      _
3 Different requirements:  _
4 No good home:            _
5 Observed demand:         _
6 Upkeep:                  _
Total (of 12):             _

Overrides checked
- Upkeep scored 0?                       yes / no  (yes = do not create)
- Tests 1, 2 and 3 all scored 0?         yes / no  (yes = do not create)

Decision: do not create / add a section to ___ / create a page
One-sentence reason:
What would change this decision (e.g. tracked prompts, a new requirement):
Review date:

Worked example: Quillstone and two audience requests

Quillstone sells document-review software to mid-sized legal and compliance teams. It has one product page and gets two requests: a page for "compliance teams at fintech companies", and a page for "paralegals". A competitor, Brieflane, has a page for each.

Request 1: compliance teams at fintech companies. The nearest page is the general product page.

Test	Evidence	Score
1 Different questions	Seven of ten drafted questions are new, such as how regulator audit requests are handled and how retention rules apply	2
2 Different evidence	Quillstone has an audit-trail export and a data-retention setting the general page never mentions	2
3 Different requirements	Approval steps and retention rules change whether the product fits	2
4 No good home	Adding this to the general page would bury the legal-team story	1
5 Observed demand	Three tracked prompts for this audience; Quillstone appears in fewer than 30% of runs and the same Brieflane page is cited each time	2
6 Upkeep	The facts come from the product's existing settings documentation; a named owner exists	2
Total		11 of 12

The arithmetic: 2 + 2 + 2 + 1 + 2 + 2 = 11. Neither override applies. Decision: create the page, and brief it around the seven new questions and the two pieces of proof.

Request 2: paralegals. The same nearest page.

Test	Evidence	Score
1 Different questions	Nine of ten drafted questions are the general ones with "paralegal" added; one is new (batch upload)	1
2 Different evidence	No proof the general page lacks	0
3 Different requirements	Same requirements as the legal team	0
4 No good home	The general page can carry a short section on batch upload	0
5 Observed demand	No tracked prompts; the request came from a sales call	0
6 Upkeep	Facts would be copied from the general page	1
Total		2 of 12

The arithmetic: 1 + 0 + 0 + 0 + 0 + 1 = 2. Decision: do not create a page. Add the batch-upload answer to the general page, record the request, and revisit if paralegal prompts show a rival winning. Brieflane having a paralegal page is not evidence that paralegals need one.

What can this rubric not tell you?

It does not predict citations. A high score means the page has something distinct to say. It does not mean any engine will cite it, and a 12 out of 12 page may still earn nothing.
Scores are judgments. Two people can score the same request differently. The value is that the reasons are written down and can be challenged.
Persona runs are indirect. They show how an engine answers when told who is asking, in text. They do not show what a real person from that group would see.
Demand evidence is only as good as your prompt set. If you never tracked prompts for an audience, test 5 scores 0 by omission. Adding the prompts first is often the right next step.
A rival's page is not a mandate. What another company publishes tells you what an engine may pull from, not that you need the same page.

Common mistakes

Creating a page per job title. Ten near-identical pages are ten things to maintain and ten places for a fact to go stale.
Scoring the audience's importance instead of its difference. A valuable audience with the same needs as everyone else still does not need its own page.
Skipping the home test. Sometimes the fix is a better-labelled section, an FAQ answer, or a table on an existing page.
Never revisiting a "no". Record what would change the decision, and check it when your monitoring changes.
Letting the page drift. Give it an owner and a review date when it is approved.

For choosing between a page update, a new article and an earned mention once you know the gap, see update a page, write a new article, or earn a mention. For rewriting an existing page around a decision, see rewrite a feature page around the decision it helps buyers make.

Frequently asked questions

How many use-case pages should a company have?

There is no right number. Have as many as pass the rubric, and no more. A company with three audiences that truly differ should have three; a company with ten labels and one real audience should have one page with a few sections.

Should every persona I track get its own page?

No. A persona is a way to run a prompt from a described buyer's point of view and to draft questions. It is a measurement tool, not a page plan. Create a page only when the questions, evidence or requirements differ, as the rubric tests. See measure AI visibility for different buyer personas without mixing the results for the measurement side.

Is a competitor's use-case page a reason to make one?

Only if the same test passes for you. Check whether engines cite their page for prompts you track and whether your own audience really has different needs. A rival's page shows what exists, not what buyers need.

What if the audience is real but the score is low?

Add a section or an FAQ answer to the nearest page instead, and note what would raise the score. Often the difference is one requirement or one piece of proof, and a section carries that without a new page.

Can a citation gap tell me to create a page?

It can point that way. When no page of yours matches closely enough, the tool treats creating a page as the opportunity, and the Articles brief then decides between updating, publishing something new, or holding off. Treat that as one input and still run the rubric.

Next step: check demand before you write

The most useful evidence for a use-case page is knowing which prompts an audience's buyers ask and which pages engines cite for them. In DiscoveredBy you can track those prompts, review the citation gaps queue, and read the brief on the Articles screen before anyone writes a word. Start with the prompts for the audience you are unsure about, then score the request with the record above. See how the optimize features work together for the wider workflow, and Prompts for how audiences attach to tracked prompts.

When to create a use-case page: a rubric that stops thin audience variants