Alternatives Page SEO with Codex: Build X vs Y Pages

Alternatives page SEO is the work of putting "X vs Y" and "alternatives to X" pages in front of buyers who are already comparing products, without turning those pages into one-sided sales copy. In Codex, RankCue's $seo competitor-pages command plans these pages for you: it picks the page type, maps the comparison keywords, builds a sourced feature matrix, writes a ready-to-build page outline and generates matching JSON-LD. This guide covers the four comparison formats, how the command runs inside Codex, the fairness rules it applies, and how to build the finished page in your own codebase.

Key takeaways

• $seo competitor-pages handles four formats: X vs Y pages, alternatives to X pages, best-of roundups, and multi-product comparison tables.
• Give it a URL to review a comparison page you already have, or use generate to get a page plan, schema, a keyword strategy and recommendations.
• Every competitor claim must be verifiable from public sources, prices carry an "as of [date]" note, and missing data is marked "Not publicly available" rather than guessed.
• The layout places calls to action above the fold, after the comparison table and at the end, and keeps hard selling out of the competitor sections.
• Codex can build the page from a data file in your repository, so the table, the dates and the schema stay in sync when a competitor changes its pricing.

The competitor pages command at a glance

What are comparison and alternatives pages?

Comparison pages serve people who have already narrowed their choice. Someone searching "[Product A] vs [Product B]" or "[Product] alternatives" knows the category and the names. They want help deciding. That intent makes these pages valuable to the business that publishes them, and it is also why readers approach them with suspicion: they expect the page to favor whoever wrote it.

Good alternatives page SEO works with that suspicion instead of against it. The page that wins the reader's trust is usually the one that admits where a competitor is stronger, shows its sources and dates its prices.

The four page types

Pick the type that matches the search. A query naming two products wants a head-to-head page. A query naming one product plus "alternatives" wants a list of options. A category query wants a roundup or a table.

Comparison keyword patterns

The skill keeps a list of eight comparison patterns, split into stronger and weaker volume signals:

Stronger: [A] vs [B] / [A] alternative / [A] alternatives [year] / best [category] tools
Weaker:   [A] vs [B] for [use case] / [A] review [year] / [A] vs [B] pricing / is [A] better than [B]

Those labels describe each pattern in general, not demand in your market. Check real numbers in your own keyword data before you commit to a page, and use the weaker patterns as sections inside a page when they don't justify one of their own.

Why fairness is also a search decision

Google's guidance on writing high-quality reviews asks for evidence, for benefits and drawbacks, and for what sets a product apart from its alternatives. That reads almost like the skill's fairness checklist. A page that only praises its own product and only criticizes the other one gives neither readers nor search engines much reason to trust it.

How $seo competitor-pages runs inside Codex

When you run the command, the skill works through page type, keywords, data, fairness, layout and schema before it writes anything. You see the progress in the task log, and the outputs land as files in your project.

1. Pick the page type. The keyword and the number of products decide between a head-to-head page, an alternatives list, a roundup or a grid.
2. Map the keywords. It sets the primary and secondary keywords, long-tail opportunities, a title from the skill's formulas and an H1 under 70 characters.
3. Gather public data. Codex reads the competitor pages you name. If a URL fails, the skill reports which one and carries on with the data it has, noting the gap.
4. Build the feature matrix. One row per feature or price point, one column per product, with a source for each competitor data point where possible.
5. Apply the fairness rules. Claims are checked for a public source, prices get a date, and competitor strengths are stated plainly.
6. Plan the layout. Summary and call to action above the fold, the table, competitor sections, pricing, methodology, verdict and related comparisons.
7. Generate schema. Product, SoftwareApplication or ItemList JSON-LD, depending on the page type.
8. Write the files. The page plan and the schema file, plus keyword strategy and recommendations.

If the products don't really overlap, the skill says so and suggests competitors with more feature overlap, or a category roundup instead.

What Codex checks: accuracy and fairness

The fairness rules are what separate a useful comparison page from an attack ad. The skill applies the same list to every page it plans or reviews.

Data accuracy

A reader should be able to check any statement about a rival against something public, so each competitor cell links to where the fact came from: that company's site, its docs, or a review site. Prices get a date stamp, because a price without one is already out of date. If a fact can't be found, the cell says "Not publicly available" rather than holding a guess. Testing the rival's feature yourself beats quoting its docs, when you can.

Trust signals and disclosure

Four signals tell a reader the page was made with care: a "last updated" date, a named author who knows the field, a short note on how you ran the comparison, and a plain statement of which product you make. The skill also asks for balance. Say what the competitor does well, and never state anything about it that is false or misleading.

Titles and headings

The skill has a title pattern for each page type:

X vs Y:        [A] vs [B]: [Key Differentiator] ([Year])
Alternatives:  [N] Best [A] Alternatives in [Year] (Free & Paid)
Roundup:       [N] Best [Category] Tools in [Year], Compared & Ranked

Keep the H1 aligned with the title, work the main keyword in naturally, and hold it under 70 characters. Only use "(Free & Paid)" when the list really includes both.

Schema for comparison pages

The skill generates Product JSON-LD with an AggregateRating block, SoftwareApplication with an Offer for software comparisons, and ItemList for roundups. Treat the rating block with care. Google's review snippet guidelines say marked-up ratings must be readily visible on the page, must describe a specific item rather than a list, and shouldn't be aggregated from other websites. So show third-party ratings as linked text if you like, but only mark up ratings your own users gave. The skill's template leaves the rating values as placeholders, which is the right default.

Run it in Codex, step by step

1. Install the kit using the install section, restart Codex, and open a new task in your website's project. Our Codex SEO setup guide walks through it.
2. Check your permission mode. The command reads live competitor pages, so depending on your mode, Codex may ask before it uses the internet. Approve it for the sites you're comparing.
3. To review a comparison page you already publish:

$seo competitor-pages https://example.com/compare/your-product-vs-competitor

1. To plan a new page, use generate and describe the page in the same message:

$seo competitor-pages generate
Page type: alternatives to [Competitor]. Our product: [Your Product] at https://example.com. Compare it with [Competitor A], [Competitor B] and [Competitor C] using their public pricing and documentation pages.

1. Or ask in plain language. Codex picks the skill when the request matches:

Plan a "[Competitor] vs [Your Product]" page. Use only facts from their public pricing and docs pages, mark anything you can't verify as not publicly available, and generate the schema.

Reading the page plan

The main output is COMPARISON-PAGE.md, a page structure you can build from directly. The sections depend on the page type, but an X vs Y plan follows this shape:

Title: [Your Product] vs [Competitor]: [Key Differentiator] ([Year])
H1: [Your Product] vs [Competitor] (under 70 characters)
Target length: 1,500+ words

## Summary and verdict (primary CTA)
## Feature comparison
| Feature | [Your Product] | [Competitor] |
|---|---|---|
| [Feature 1] | ✅ | ⚠️ Partial |
| Pricing (from), as of [date] | $X/mo | Not publicly available |
## Where [Competitor] is stronger
## Pricing, including setup fees and per-user costs
## How we compared (methodology, last updated [date])
## Verdict: who should choose which (final CTA)
## Related comparisons

Alongside it you get comparison-schema.json, a keyword strategy with primary, secondary and long-tail targets plus content gaps against competitors' own comparison pages, and recommendations covering content, new page ideas, schema and conversion.

Review it in this order:

1. Every competitor data point. Open each source link and confirm the claim yourself. This is the part you are accountable for.
2. The verdict. It should follow from the table. If the table is mostly ties, the verdict should say who each product suits, not declare a winner.
3. Pricing. Add the costs buyers find out about later, like onboarding fees, per-seat charges and usage overages, and argue on value rather than on the lowest sticker price.
4. Schema placeholders. Fill them with real values or remove the property.

Calls to action appear in three spots: the opening summary, just below the table, and the closing verdict. Pushing a signup button inside the section about a rival makes the whole page feel like an ad, so the skill leaves those sections clean.

Apply the fixes with Codex

Comparison pages go stale because their facts live in prose. Codex can fix that at the source by moving every competitor data point into a structured file, then rendering the table, the "as of" note and the schema from it. When a price changes, you edit one value.

A data file for one comparison might look like this:

{
  "competitor": "[Competitor]",
  "as_of": "2026-10-01",
  "rows": [
    { "feature": "[Feature 1]", "ours": "yes", "theirs": "partial", "source": "https://competitor.example/docs/feature-1" },
    { "feature": "Starting price", "ours": "$X/mo", "theirs": "Not publicly available", "source": null }
  ]
}

For a roundup, the ItemList the skill generates looks like this once the placeholders are filled:

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "Best [Category] Tools",
  "itemListOrder": "https://schema.org/ItemListOrderDescending",
  "numberOfItems": 2,
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "[Product 1]", "url": "https://example.com/tools/product-1" },
    { "@type": "ListItem", "position": 2, "name": "[Product 2]", "url": "https://example.com/tools/product-2" }
  ]
}

Then ask Codex to build it:

Build the page in COMPARISON-PAGE.md as a new route. Put every competitor data point in a JSON data file with a source URL and an as_of date, and render the feature table and the "as of" note from that file. Add the JSON-LD from comparison-schema.json, but leave out aggregateRating unless we show our own user ratings on the page. Add the breadcrumb Home > Comparisons > [this page] and link the page from the related comparisons section of our other vs pages. Show me the diff, then run the build.

Read the diff, check the rendered table against the sources one more time, and test the page in Google's Rich Results Test after deploy. Valid markup makes a page eligible for rich results; it doesn't promise them.

Make it repeatable

The skill's update rule is to review comparison pages every quarter, or sooner when a competitor ships a major change. That is a good job for codex exec, which runs Codex without the interactive interface and can save its final message to a file:

codex exec 'Run $seo competitor-pages https://example.com/compare/your-product-vs-competitor. Re-check every competitor price and feature claim against its source link, list anything that changed or lost its source, and flag pricing notes older than one quarter.' -o reports/compare-review.md

Schedule it once a quarter in cron or your CI system for each comparison page, and read the saved report before you edit anything. The run reads live competitor pages, so make sure your sandbox and permission setup allows the network access the task needs. Our guide to automating SEO checks with codex exec covers scheduling and CI in more depth.

Without the skill: a plain Codex prompt

Without the kit, a careful prompt still gets you a solid draft:

Plan an "alternatives to [Competitor]" page for [Your Product]. Read the public pricing and docs pages for [Competitor A], [Competitor B] and [Competitor C]. Build a feature table with a source link for every competitor cell and "Not publicly available" where you can't confirm a fact. Give each option a summary, pros, cons and a best-for line, state our affiliation, and suggest a title and an H1 under 70 characters.

What the skill adds is the full checklist on every run: the four page formats, title formulas, fairness and disclosure rules, placement rules for calls to action, schema templates, and a fixed set of output files you can hand straight back to Codex.

Pitfalls to avoid

• Publishing competitor prices without an "as of" date.
• Hiding where the competitor is better. Readers notice, and the verdict loses its weight.
• Marking up third-party ratings from review sites in your own JSON-LD.
• Placing hard-sell calls to action inside the competitor's section.
• Stating feature gaps you haven't checked against documentation or a real test.
• Publishing once and never updating after the competitor's next release.
• Leaving comparison pages isolated. Cross-link A vs B to A vs C, and link to the feature pages you discuss.

Keep going

• Schema markup with Codex goes deeper on validating Product, SoftwareApplication and ItemList markup.
• Search intent and SXO analysis with Codex helps confirm whether a query wants a vs page, a list or something else.
• Programmatic SEO with Codex explains the quality gates to respect if you plan many comparison pages from data.
• On-page SEO analysis with Codex checks the finished page, and the full skills list shows every command in both kits.

FAQ

What is an alternatives page?

An alternatives page lists other products a reader could use instead of a named one, usually targeting searches like "[Product] alternatives". Each option gets a short summary, pros and cons, and a note on who it suits. When the page is published by one of the alternatives, it should say so clearly.

Do comparison pages help SEO?

They target searches from people close to a decision, so they can bring visitors who are ready to act. They help most when they are accurate, balanced and kept current. A biased or outdated page loses the reader's trust quickly, even when it ranks well.

Can I mention competitor names on my website?

Naming rivals is normal on comparison pages, as long as each statement is true and a reader could check it against a public source. The skill's fairness rules forbid false or misleading statements, and they ask you to cite sources and disclose your affiliation. If you're unsure about trademark rules in your market, ask a lawyer.

How often should I update a comparison page?

The skill recommends a review every quarter, and sooner when a competitor ships a major change. Keep an "as of [date]" note on every price and a "last updated" date on the page, so readers can see how fresh the comparison is.

Can Codex write a comparison page for me?

Yes. $seo competitor-pages generate produces the page plan, feature matrix and schema, and Codex can then build the page in your codebase from those files. You should still confirm every competitor fact against its source before you publish.