Rewrite a feature page around the decision it helps buyers make

The best way to rewrite a feature page is to pick the one decision a buyer is making when they reach it, then organise the page to answer that decision: what the feature is used for, who it suits, what it cannot do, what you must have in place first, and what proof exists. A page that only describes the feature gives a skimming reader, and an AI answer drawing on the page, little specific to repeat. A page built around a decision gives both clearer statements that can be checked. Whether the rewrite changes what AI engines say or cite is something you test afterwards; it is a hypothesis, not a promise.

In short

• A feature page should answer a decision ("should we switch from spreadsheets to this?"), not only name a capability.
• Every feature page needs four things beyond description: use, limits, prerequisites and proof. Limits and prerequisites are the parts most pages skip.
• Choose the decision from evidence: what AI answers say about you, what they say about rivals, and what buyers ask you directly.
• Treat each change as a hypothesis. No layout guarantees a citation, and you can check the result with fixed prompts afterwards.
• The template and the annotated before-and-after below are meant to be copied.

What is a decision-first feature page?

A decision-first feature page is a page organised around one buying question and the facts needed to answer it. It still describes the feature, but the description serves the decision.

Definitions used in this post. A feature page is a public page describing one product capability. A buying decision is the specific choice a reader is trying to make when they open it, such as "can this handle our approval process?" or "is this worth adding to our plan?". A stated reason is a reason an AI answer itself gives for favouring or cautioning against a brand, saved with a label such as pricing or integrations and a direction (strength or weakness). A citation is a source linked in an AI answer; the key terms page explains how it differs from a mention (your brand named in the answer).

The contrast is between "Feature: clause comparison. Compare clauses across contracts quickly" and a page that says who compares clauses, across how many documents, what it cannot compare, what you need to have set up, and what evidence you can show.

Which decision should the page answer?

Pick the decision from what buyers and AI answers actually raise, not from your internal name for the feature. Three sources are worth checking, and they measure different things.

1. What AI answers say about your brand and rivals. The Brand reasons screen in DiscoveredBy (availability depends on your plan; see plans and limits) shows, for your brand and each active tracked competitor, how many analysed answers gave each reason as a strength or a weakness, with the quote behind every count. If answers repeatedly give "integrations" as a weakness for you and a strength for a rival, that is a decision worth a page. The limit matters: the label and direction are an extraction model's reading of the answer, and the quote lets you check that reading. It is not a verified fact about your product, and it does not show what caused an engine to favour a brand.

2. Which pages win the prompt. Citation gaps compares the pages engines cite for a prompt with your best matching page and records what your page lacks, such as a table, an FAQ, a statistic or a schema type. This shows what DiscoveredBy found in the cited pages that yours lacks. It only covers prompts where you appear in a minority of answers and a page from another domain is cited, so it will not exist for every feature. It is a comparison of pages, not a ranking rule.

3. Direct objections. The Objections study asks the chat engines on your plan, directly, why a buyer might not choose a brand. Because the question is designed to produce objections, almost every brand will have some, so read it as a list of concerns to answer, not a verdict.

Then add your own sources: sales calls, support tickets, and the questions your prospects ask. Those are not in any tool report, but they are often the most direct evidence of what a buyer needs to know.

Enlarge image

What does a feature page need beyond a description?

It needs four parts that connect the feature to the decision: use, limits, prerequisites and proof. Each one answers a question that a description alone leaves open.

• Use: who does what with this feature, in what situation, and what they get out. Name the job, not the button.
• Limits: what the feature does not do, or does only under conditions. Honest limits make the rest of the page more believable and stop a reader from inferring a capability you do not have.
• Prerequisites: what must already be true: a plan or entitlement, a connected system, a file format, a role, a setup step. Prerequisites are where buyers stall, and they are easy to check.
• Proof: something a reader or a reviewer can verify: a documented behaviour, a screenshot of the real product, a dated public fact, a link to a help page. Proof means evidence you can point to, not an adjective.

A useful test: cover the feature name and read the page. Could a reader tell which decision it helps with and what they must do first?

The deliverable: a decision-first feature page template

Copy this into your content brief. Fill each field from a source you can name; leave a field marked "unknown" rather than guessing.

FEATURE PAGE BRIEF
Feature (internal name):
Page URL (or "new"):

1. THE DECISION
   Buyer role:
   The question they are trying to answer (one sentence, in their words):
   Evidence this is the question (AI stated reasons, citation gap, objection, sales/support):
   What they are likely comparing against (category, not a named vendor):

2. THE ANSWER IN ONE PARAGRAPH (first 80 to 120 words of the page)
   Who it suits + what it does + the main condition or limit:

3. USE
   Job the feature does, in one sentence:
   Two concrete scenarios (who, what they start with, what they end with):

4. LIMITS
   What it does not do:
   Conditions where it works less well:
   Anything a reader might wrongly assume:

5. PREREQUISITES
   Plan / access needed (say "depending on plan"; do not state prices here):
   Setup or data needed before first use:
   Roles or permissions:

6. PROOF
   Documented behaviour (link to help page):
   Real screenshot (which screen, what must be visible):
   Dated public fact (with the date and where it lives):
   Anything you cannot prove yet (do NOT claim it):

7. NEXT STEP
   One action for a reader who has decided (trial, demo, docs):

8. CHECKS BEFORE PUBLISH
   Every claim matches the current product and the pricing page:
   Limits section reviewed by someone who supports the product:
   Wording of the feature name is the same in title, headings and body:
   Date shown for last review:

Worked example: Quillstone's clause comparison page

Quillstone sells document-review software to mid-sized legal and compliance teams. Its rival Brieflane is tracked as a competitor. The team wants to rewrite the "Clause comparison" feature page.

Step 1: choose the decision. In the Brand reasons screen for a 28-day window, the made-up counts look like this.

The rates follow the screen's formula, answers with that reason and direction divided by answers analysed. Both brands have at least 30 analysed answers, so neither is marked provisional. Reading the quotes behind Quillstone's 14 weakness answers, the team finds most say Quillstone "only works with files you upload" and asks whether it fits an existing document system. The team also notes the sales team hears the same question. So the decision on this page is: "Can we compare clauses across contracts we already keep in our document system, or do we have to upload everything?"

The team does not conclude that the answers rank Quillstone lower because of integrations. They conclude that answers state this concern and that the page does not address it.

Step 2: the before. The current page, condensed.

Clause comparison
Compare clauses across contracts quickly and accurately. Our powerful
comparison engine highlights differences so your team can work faster.
Trusted by legal teams everywhere.

[Book a demo]

Step 3: the after. The annotated rewrite.

Clause comparison: compare a clause across many contracts, from uploads
or your connected document system                          <- [1]

Clause comparison shows how one clause, such as termination or
liability cap, differs across a set of contracts your team selects.
It suits reviewers who must check a portfolio against a standard
position. It works on documents you upload or that arrive through a
connected document system; it does not rewrite clauses or judge
legal risk. Connected-system access depends on your plan.  <- [2]

Use
- A compliance analyst selects 30 supplier contracts and one clause
  type, and gets a side-by-side list showing which contracts differ
  from the standard wording.                                 <- [3]

What it does not do
- It does not give legal advice or decide which wording is acceptable.
- Scanned pages with no readable text must be processed before
  comparison.                                                <- [4]

Before you start
- A folder of contracts, or a connected document system (see the
  integrations help page, updated 12 March).
- An admin role to connect a system; any reviewer can compare uploads. <- [5]

Evidence
- Screenshot: the comparison view showing three contracts and one
  flagged difference.
- How comparison works: link to the help article.             <- [6]

Next step: start with an upload, or read the connection guide.

Annotations.

1. The heading names the job and the two input routes, so the decision (uploads versus existing system) is visible before the reader scrolls.
2. The opening paragraph states who it suits, what it does, the main limit and the plan condition in one quotable block. It stays factual and avoids adjectives.
3. The scenario is specific: who, what they start with, what they get. The made-up "30 contracts" is an example, not a benchmark.
4. Limits are stated plainly. The reader learns what not to assume, and an AI answer that quotes this page will not have to guess.
5. Prerequisites include the role and the date the linked help page was last reviewed, so a stale claim is easier to spot.
6. Proof is something a reader can open: a real screenshot and a help article, not "trusted by legal teams everywhere".

What was removed: "powerful", "quickly and accurately", and "trusted by legal teams everywhere". None of those could be checked, and none helped the decision.

Enlarge image

How do you check that the rewrite worked?

Compare fixed prompts before and after, and describe any change as an association. A rewrite does not guarantee that engines will cite or recommend you, and other things change at the same time.

A workable approach, using the product's own mechanisms:

• Before editing, note the prompts tied to the decision and their current results, including which pages are cited and what reasons are stated.
• Publish the rewrite. If your plan includes the Optimizations screen and the page is one it has a fix for, you can mark a fix applied yourself; it records the trailing month of visibility for its prompts and later compares against a baseline measured from answers in the 30 days before you marked it. Its outcome stays "pending more data" while too little time has passed or there are no completed answers.
• Note anything else that changed in the same period: a new backlink, a product launch, a competitor's update.
• Read the result as "visibility for these prompts moved, or did not, during a period when we changed this page". For a deeper method, see Did your content update help?.

On plans that include it, Optimizations can also draft page-level changes for a page of yours, each backed by at least one verified quote from a page engines cite. The documentation is clear that the check covers the evidence quote, not the draft body, so read any draft as a starting point to verify. Nothing reaches your site unless you put it there.

Common mistakes and what this approach cannot tell you

• Rewriting without a decision. If you cannot state the question in a sentence, you are polishing copy, not answering a buyer.
• Treating stated reasons as ranking causes. A stated reason is what an answer said. It shows a concern that appears in answers. It does not explain why a model produced that answer.
• Hiding limits. Omitting a limitation does not make it disappear; buyers find it later, and an AI answer may fill the gap with a guess.
• Claiming proof you do not have. If you cannot show it, do not say it. List it as "unknown" in the brief and fix the gap in the product or documentation first.
• One page for every audience. If different buyers need materially different answers, that may deserve a separate page; see When a use-case page deserves to exist.
• Expecting a fixed outcome. Structure, tables and FAQs may help a reader and may make a page easier to quote, but no format is a proven citation factor. Test it.

Frequently asked questions

How long should a feature page be?

Long enough to cover use, limits, prerequisites and proof for one decision, and no longer. A short page that answers the decision beats a long one that repeats benefits. Split a page when it tries to serve two decisions.

Should I add an FAQ to every feature page?

Add questions buyers actually ask, each answered from a source you can point to. An FAQ pasted for its own sake adds length without help. See Build an FAQ from observed buyer questions for a method.

Do I need a comparison with named competitors?

No. State what your feature does and does not do, and let the reader compare. Claims about a rival are risky to keep accurate, and this template does not need them.

Where should limits go on the page?

Near the top, after the opening summary, in their own short section. Readers who scan the page are less likely to miss a limit there than at the bottom, and it is the sort of statement an extracted summary can pick up.

Can a rewrite alone fix an integrations concern?

Only if the concern comes from unclear information. If the product genuinely lacks a capability, the page can state that honestly, but it cannot change what the product does.

How do I know which feature pages to rewrite first?

Start where evidence agrees: a stated weakness in answers, a citation gap on the same prompts, and a question from sales. As a rule of thumb, a page with one signal is a candidate and a page with three is a priority.

Next step

Open your Brand reasons and Citation gaps views (depending on your plan) for the prompts around one feature, read the quotes, and write down the single decision before you touch the page. If you are not yet tracking those prompts, start a project; the Optimize feature page describes the page-fix workflow. The citation gap glossary entry defines the terms used above, and Turn an AI citation gap into a content brief shows how to hand the result to a writer.