How to Brief a Comparison Page (X vs Y and Alternatives Posts)

Comparison pages are the closest thing a content team has to a sales call. Someone searching "Asana vs Trello" or "Clearscope alternatives" has a shortlist and wants a reason to pick one. They will read carefully. They will also leave the moment the page feels rigged.

That is why these pages fail so often.

The usual brief for a comparison page is a keyword, a list of tools, and a note that says "make us look good." The writer, who has never logged into half the products, assembles a feature table from vendor marketing pages, adds a paragraph of pros and cons per tool, and ends with a conclusion that recommends your product for everyone. Readers have seen that page a hundred times, and so has Google, which has spent the last few years rewarding first-hand product reviews over rewritten spec sheets.

A good comparison brief does most of the deciding before the writer starts. This guide covers what that brief needs, field by field, and where it differs from the standard content brief template.

Decide which kind of comparison page you are briefing

There are two common shapes, and they need different briefs.

Head-to-head pages ("Notion vs Confluence") compare two products for a reader who has already narrowed the field. The reader wants a verdict and the reasoning behind it, usually organized around the four or five differences that actually change the decision. Depth beats breadth here. A head-to-head page that lists forty features with checkmarks next to both columns has told the reader nothing.

Alternatives pages ("Surfer SEO alternatives") serve someone who is unhappy with a tool, or priced out of it, and wants options. The brief has to name why people leave the original product, because that reason is the organizing principle of the whole page. If people leave because of price, every alternative gets evaluated on price first. If they leave because the tool is too complex for a two-person team, simplicity is the lens.

Run SERP analysis before choosing. Some "X vs Y" queries are dominated by Reddit threads and YouTube reviews, which tells you searchers distrust vendor content for that pair and your page will need unusually strong evidence to compete. Others return a featured snippet with a comparison table, which tells you the format Google wants to lift.

Write the verdict into the brief

This is the field most comparison briefs leave out, and it is the one that matters most. Before the writer drafts a word, the brief should state who should pick each option.

Something like: "Pick Tool A if you run a team of more than ten writers and need approval workflows. Pick Tool B if you are a solo consultant who mostly needs keyword data and hates paying per seat." The verdict can be conditional (most honest ones are), but it has to exist, and it has to be specific enough that a reader could disagree with it.

A writer who is handed a verdict can spend their time building the case for it. A writer who is not handed one either hedges every paragraph into mush or invents a verdict of their own, often based on whichever vendor site had the clearest copy. Both outcomes cost you a revision round, and if your editor is giving feedback against the brief, there is nothing to give feedback against.

Pick the comparison criteria, and cap them

List the criteria the page will compare on, in order of how much they influence the decision. Five is usually plenty. Seven is a ceiling.

The criteria should come from buyers rather than feature pages. Read the G2 and Capterra reviews for each tool, especially the two- and three-star ones, which are where people explain what actually bothered them. Ask your sales team which objections come up on calls. Search the product names on Reddit with words like "switched" and "regret." If the same complaint about onboarding time shows up in thirty reviews, onboarding time is a criterion, even though no vendor lists it on their pricing page.

For each criterion, tell the writer what "good" looks like. "Pricing" is a heading. "Pricing for a team of five on annual billing, including any per-seat or per-credit charges that show up after the trial" is an instruction.

Set evidence rules the writer cannot skip

Comparison pages live or die on whether the reader believes the author used the products. The brief should spell out what proof is required, and it should be honest about what the team can and cannot supply.

• Hands-on access. Name who has accounts for each tool. If nobody does, budget for trial signups and say which plan tier to test, because a free tier often hides the features the comparison is about.
• Original screenshots. Taken by the writer or your team, dated, and showing the specific workflow the criterion is about. Vendor press images are a tell.
• Pricing with a date. Every price on the page gets a "checked on" date, and the brief should say who rechecks it and how often.
• A real task. One concrete job run through each tool, such as building the same brief or importing the same 200-row spreadsheet, gives the reader a fair basis for comparison and gives the writer something to say that no competing page has.
• Sourced claims. Anything about a competitor that the writer did not personally verify needs a link to where it came from.

If you have an internal expert who has used a competitor at a previous job, that is gold. A short SME interview will produce better material for the page than a week of reading feature lists.

Tell the writer exactly how to treat your own product

Most teams publishing comparison pages sell one of the products being compared. Readers know this. Pretending otherwise is the fastest way to lose them.

The brief should require a disclosure near the top, in plain words: "We make Tool A. We have tried to be fair, and here is where Tool B is the better pick." Then it should list, explicitly, the situations where a competitor wins. If the honest answer is that a competitor is better for enterprise teams with SSO requirements, the page says so, and the brief tells the writer to say so.

Writers will not volunteer this on their own. They are working for you, and admitting your product loses somewhere feels like a mistake to anyone who has not been told otherwise. Put it in writing, and mark it as required.

There is a commercial reason for this beyond trust. The reader who picks a competitor after reading your fair comparison was never going to be a happy customer. The reader who sees you admit a weakness and still decides your product fits is far more likely to stay.

Plan the table, then plan what goes around it

Almost every comparison page needs a summary table. The brief should define the rows, which are the criteria in ranked order, and spell out what each cell contains. Short text beats checkmarks. "Yes, on the $99 plan and up" carries information that a green tick hides.

The table goes high on the page for readers who want the answer fast, and the prose underneath explains it. Give the writer a section per criterion rather than a section per product. Product-by-product layouts force the reader to hold five tools in their head and do the comparison themselves, which is the job the page was supposed to do for them.

Close the page with the verdict from the brief, restated as a short decision guide. "If you need X, pick A. If budget is the main constraint, pick B." Readers screenshot these.

Questions worth answering on the page

Comparison queries generate their own family of follow-up questions, and most of them show up in People Also Ask. A few appear for almost every software pair:

• Can I migrate my data from one to the other, and how long does it take?
• Is there a free plan, and what does it actually limit?
• Which one integrates with the tool I already use (usually the CMS, or wherever drafts live now)?
• Is the cheaper option missing something I will regret later?

Migration is the one teams forget. A reader who already uses Tool B and is considering a switch to yours cares more about the move than about any feature, and a page that answers it honestly converts better than one that does not mention it.

Keeping comparison pages accurate after publishing

Comparison pages go stale faster than almost anything else you publish.

Competitors change pricing, ship features, rename plans, and get acquired. A page that called a competitor's editor "limited" eight months ago may now be wrong, and a reader who notices will discount everything else on the page. The brief should name an owner and a review cadence (quarterly is the minimum for software comparisons) and list the specific facts most likely to change, so the next person updating the page knows where to look. When that review turns up enough changes, write a refresh brief rather than patching sentences one at a time.

Comparison pages also belong in a cluster. A single "alternatives" page can link out to several head-to-head pages, and each head-to-head page links back. If you are planning more than two or three, map them first using a content cluster plan so they do not end up competing for the same queries.

The comparison brief, field by field

Here is what to add to your normal brief when the page is a comparison:

• Page type: head-to-head or alternatives, with the products named.
• Why readers are searching: for alternatives pages, the main reason people leave the original tool.
• Verdict: who should pick each option, stated conditionally and specifically.
• Criteria: five to seven, ranked, each with a definition of what is being measured.
• Evidence requirements: account access, screenshots, the real task to run, dated pricing.
• Disclosure and concessions: the disclosure line plus the specific cases where a competitor wins.
• Table spec: the rows and what each cell should say.
• Migration notes: what moving between the tools involves, if anyone on your team knows.
• Maintenance: who owns the page and how often they recheck it, plus a short list of facts most likely to go stale.

Everything else (search intent, target keyword, internal links, word count range) comes from your normal process. If you generate the research half of the brief with ContentBrief.io, you get the ranking pages, their headings, and the PAA questions pulled in automatically, which leaves the strategist free to work on the verdict and the concessions. Those two fields take judgment. No tool can tell you where your own product loses.

Someone on your team already knows. Ask them.