Post Type Page Template
Use this comparison page template to structure buyer intent, evidence, alternatives, acceptance criteria, measurement, and production-ready examples now.
A comparison page exists because a reader is already doing difficult decision work. They are aligning capabilities, constraints, cost, implementation effort, and risk across alternatives that describe themselves in different language. The page earns attention by reducing that work without hiding inconvenient tradeoffs. This reference demonstrates the complete 15-block post-type template using the existing academy layout and reusable components.
Questions it answers
A comparison page answers: “Which of these options better fits my situation, and what evidence supports that choice?” The direct answer should identify the decisive variables before the page expands into detail. It should also make clear who the comparison is for, because the same alternatives can produce different recommendations for a five-person team, an enterprise procurement group, and an individual buyer.
This is not merely two product summaries placed side by side. A useful comparison establishes a common evaluation frame, applies it consistently, exposes unknowns, and ends with a conditional recommendation the reader can test against their own constraints.
When to use this post type
Choose a comparison page when the search itself names two or more credible alternatives, or when discovery evidence shows that buyers repeatedly ask how options differ. The format is valuable late in consideration because it converts scattered facts into a decision model. It also creates bounded, extractable statements that search and answer systems can quote without losing which option or condition they describe.
Do not choose it when the reader first needs to understand the category, when one option is imaginary, or when the evidence is too thin for symmetric treatment. A definition page should establish meaning. An alternatives page should widen a shortlist. A “best X” page should rank several options for a named use case. A direct A-versus-B comparison belongs where the shortlist already exists.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
Best for these business types
SaaS teams need comparison pages because buyers evaluate overlapping feature sets, integration effort, security requirements, and recurring cost before starting a trial. Ecommerce businesses use them when products solve the same job but differ by material, size, compatibility, durability, or lifetime cost. B2B services use them to explain delivery models, scope boundaries, client responsibilities, and time-to-value without pretending professional services are identical packages.
The business model changes the evidence. Software comparisons may require plan-level qualification and dated feature checks. Product comparisons need model identifiers and test conditions. Service comparisons need scope, assumptions, and responsibility boundaries. The format stays stable while the proof changes.
Search intent
The primary intent is decision support. The answer shape is a conditional recommendation followed by a common-frame comparison. Open by naming the better fit for two or three recognizable situations. Then define the criteria, show evidence, explain important differences, cover switching or implementation implications, and state what could change the recommendation.
Avoid a suspense structure. Readers should not have to reach the last paragraph to learn that one option lacks a required integration or exceeds their budget. Put decisive exclusions early, then give the detail needed to validate them.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Page structure
Comparison page anatomy
| Section | Word range | Purpose | Required? |
|---|---|---|---|
| Direct answer | 60–100 | Name the best fit by audience or constraint before expanding the evidence. | Yes |
| Decision context | 100–180 | Define the reader, alternatives, date, scope, and comparison basis. | Yes |
| At-a-glance table | 6–12 rows | Compare the decisive criteria using consistent units and qualification. | Yes |
| Criterion analysis | 500–900 | Explain why each difference matters and where the evidence is limited. | Yes |
| Implementation or switching | 180–300 | Expose migration effort, dependencies, training, and reversible versus irreversible costs. | Conditional |
| Recommendation by use case | 180–280 | Translate evidence into bounded choices for recognizable situations. | Yes |
| FAQ and next action | 150–300 | Resolve remaining objections and provide a relevant continuation. | Yes |
Word ranges are control limits, not padding targets. A page may be shorter when the alternatives are simple and evidence is decisive. It may be longer when implementation risk genuinely needs explanation. Repetition is never evidence of depth.
Required elements
The element order matters because each component prepares the next decision. The direct answer establishes the recommendation, the scope prevents overgeneralization, and the table compresses the common facts before prose handles nuance.
Element positions
| Element | Position | Status | Rule |
|---|---|---|---|
| Direct answer | Immediately after the hero | Required | Give a conditional recommendation in the first 100 words. |
| Scope note | Before the first comparison | Required | Name audience, market, versions, plans, date, and evidence method. |
| Comparison table | Before long criterion sections | Required | Use one dimension per row and qualify unknown or plan-specific values. |
| Evidence note | Beside the supported claim | Required when factual | Keep source, date, method, and limitation close enough to survive extraction. |
| Migration section | After capability comparison | Conditional | Include when changing options creates material work, risk, or lock-in. |
| FAQ | Before conversion | Required | Answer genuine residual questions rather than repeating headings. |
| CTA | Final | Required | Match the next action to the reader's decision readiness. |
The canonical definitions for these building blocks live in the content elements library. Authors should use those parameter and QA rules rather than redefining an element locally.
Frontmatter
Use TOML between +++ fences. Set playbookPillar = "post-type", a stable playbookFamily, an ordered elements array, ranked businessTypes, and journeyStage = "decision". The entity value should name the compared pair in canonical order, for example "product-a-vs-product-b". Use schemaType = "Article" unless the page contains a genuinely supported review and the site has an approved review-schema policy. Do not label ordinary editorial comparison as a product review merely to obtain richer search presentation.
Every internal link in the body needs a matching [[lnks]] entry whose text exactly matches the anchor. Every visible FAQ needs an identical [[faq]] record. Set screenshotsPending = true whenever a required capture is represented by a comment.
Full worked example skeleton
# Product A vs Product B: which fits [audience]?
[Direct answer: A fits condition one; B fits condition two; neither fits exclusion three.]
## Scope and evaluation method
[Audience, market, plan/version, checked date, sources, and limitations.]
## A vs B at a glance
[Rows for price basis, decisive capabilities, constraints, support, and implementation.]
## Capability one
[Like-for-like evidence, why it matters, and exception.]
## Capability two
[Like-for-like evidence, why it matters, and exception.]
## Migration and operating cost
[Setup, data movement, training, dependency, reversibility, and total-cost caveats.]
## Which should you choose?
[Recommendations by use case, with disqualifiers.]
## FAQ
[Residual questions only.]
## Next steps
[Action matched to decision readiness.]
The skeleton is deliberately sparse. It fixes information order while leaving the evidence and prose specific to the real decision.
Design examples
Each approved gallery capture must use the same pair of alternatives and the same facts so reviewers judge information hierarchy rather than copy differences. Capture desktop and narrow viewport behavior, but do not turn responsive states into separate editorial variants.
When those four files exist, replace the comments with features-with-4-images-grid using a specification label and description for each variant. Until then, comments are the only valid representation.
Quality bar and acceptance criteria
Acceptance is evidence-based. A reviewer should be able to point to the scope line, source record, table row, and recommendation clause that justify each decisive conclusion.
Common mistakes
Other failure modes include mixing monthly and annual prices, comparing an enterprise plan with a starter plan, treating “contact sales” as zero cost, listing features without explaining consequence, and using identical pros and cons that never affect the final choice.
Internal linking rules and sibling types
Link upward to SEO post types when readers need to choose another document shape. Link each named building block to its element definition once that page exists. Link to a sibling type only when the reader’s intent genuinely changes: an alternatives page for a wider shortlist, a best-for-use-case page for ranked discovery, or a product page for first-party capability detail.
Anchor text should name the destination concept. Avoid “learn more,” long strings of exact-match keywords, and link clusters that interrupt the comparison. A comparison is a decision document, not a directory.
How we measure it in AmICited
Measure the page against its intended chain: discovery for the compared query, citation or selection in relevant answers, engaged evaluation, and a downstream action appropriate to the business. Record a baseline and observation window before publication. Separate a visibility movement from a commercial outcome; neither proves the other by itself.
Use the SEO results framework to decide whether the page should be kept, refreshed, expanded, consolidated, or retired. In AmICited, track prompts that express the same decision conditions used in the page. Review the exact answer and cited source, not only an aggregate score, because a mention can still describe the wrong audience or cite a competitor’s comparison.
FAQ
Frequently asked questions
When should a team publish a comparison page?
Does a comparison page have to name a winner?
The academy layout supplies the closing conversion panel after this body. The reference deliberately does not insert a second CTA component, because two closing actions would weaken rather than clarify the next step.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card