---
name: rankizz-write-alternatives-page
description: Research and write a fair, evidence-backed alternatives page for readers considering replacements for a named product. Use when a user asks for "X alternatives," "alternatives to X," "best X competitors," a replacement guide, or a migration-focused commercial page. The skill verifies switching reasons, product fit, current pricing, limitations, and publisher relationships instead of producing a generic affiliate list. Rankizz keyword and SERP data is optional; current product research is required.
---

# Write an alternatives page

Help a specific reader decide whether to leave the named product and, if so, which qualified alternative fits the reason for switching. Do not turn ordinary competitors into alternatives without proving the fit.

Read [references/alternatives-evidence.md](references/alternatives-evidence.md) before researching or drafting.

## Establish the decision

Resolve:

- the product being replaced and the exact audience
- jobs the reader must preserve after switching
- genuine switching reasons, such as price, limits, workflow, privacy, deployment, or integrations
- non-negotiable capabilities and disqualifiers
- region, currency, team size, and expected usage
- migration constraints, data export, contracts, and retraining costs
- whether the publisher owns, sells, or earns commission from any candidate
- research and pricing cutoff date

Do not assume every searcher should switch. The finished page must explain who should remain with the current product.

## Research the incumbent first

Use current official pricing, documentation, limits, security material, terms, help content, and changelog. Separate verified reasons to switch from complaints that cannot be substantiated. Independent reporting and user evidence can identify issues, but one anecdote does not establish a general product flaw.

Create an incumbent brief:

| Reader need | Incumbent behavior | Evidence | Reason to switch, stay, or verify |
| --- | --- | --- | --- |

Never invent a weakness to make an alternative look stronger. Mark inaccessible enterprise terms, negotiated prices, and unverified behavior clearly.

## Qualify the alternatives

Choose candidates only after setting the criteria. Each included product must:

1. complete the reader's essential job
2. remove at least one verified switching problem or serve a distinct segment better
3. have enough current evidence for a useful assessment
4. expose an honest tradeoff compared with the incumbent

Evaluate every candidate on the same core dimensions:

| Alternative | Best fit | Switching advantage | Lost capability | Price basis/date | Migration concern | Sources |
| --- | --- | --- | --- | --- | --- | --- |

Normalize currency, tax treatment, billing period, seats, usage allowances, overages, add-ons, and contract terms. Do not present annual per-user pricing beside monthly team pricing without explaining the difference.

Rankizz is optional. If connected data will change the page, use search intent, keywords, or live SERPs to understand the audience and expected decision questions. Metrics do not prove product quality. If a Rankizz call is unavailable because of entitlement or credit balance, tell the user: "This feature is unavailable because the connected account does not have the required entitlement or credit balance."

## Order by fit, not fame

Use labels with explicit boundaries, such as:

- best for agencies leaving because of client-seat costs
- best self-hosted alternative
- best for teams that need a specific integration
- best low-complexity replacement

Every label needs evidence and a defined audience. If the publisher owns one option, disclose that relationship near its first recommendation and in the methodology. Apply the same criteria, include competitors that win important categories, and do not automatically place the publisher's product first.

## Write the page

### Opening and quick answer

State the audience, verified reason for considering a switch, strongest options by use case, and the research date. Avoid claiming the incumbent is bad for everyone.

### Why people look for alternatives

Describe only supported switching triggers. Connect each trigger to the affected user and the criterion used later.

### Methodology and disclosure

Explain what was tested, what was verified from official sources, how products qualified, how pricing was normalized, and any commercial relationship.

### Comparison table

Use decision fields, not a wall of generic checkmarks. Include best fit, decisive advantage, lost capability, normalized price basis, and migration concern.

### Alternative sections

For every option, include:

1. a one-sentence fit verdict
2. why someone would switch from the incumbent
3. what the alternative does better
4. what the reader gives up or must verify
5. current pricing and relevant limits
6. migration, integration, and data-portability implications
7. who should choose it and who should skip it

### Stay or switch

Name the users who are still better served by the incumbent. End with a constraint-based chooser, not a universal winner.

## Do and do not

| Do | Do not |
| --- | --- |
| Start with verified switching reasons | Invent weaknesses from competitor positioning copy |
| Keep the incumbent in the comparison | Compare alternatives only with one another |
| Use the same criteria for every product | Apply stricter standards to competitors than the publisher's tool |
| Explain lost features and migration costs | Treat switching as free and immediate |
| Normalize plans and prices | Compare incompatible tiers or billing periods |
| Tell some readers to stay when evidence supports it | Force every reader toward an alternative |
| State what was directly tested | Convert documentation research into "hands-on testing" |
| Disclose ownership and affiliate relationships early | Hide a commercial motive in the footer |
| Combine pages with the same audience and decision | Scale near-duplicate pages for every keyword variation |
| Use trademarks to identify products accurately | Imply sponsorship, affiliation, or endorsement |

## Examples

### Weak switching claim

> Teams are leaving Acme because it is expensive and difficult to use.

This is broad, unattributed, and may not be true for the target reader.

### Better switching claim

> Acme's published Business plan requires five paid seats. A two-person agency therefore pays for three unused seats. Solo consultants should compare alternatives with per-seat billing; teams already using five seats do not face that mismatch. Pricing checked 16 August 2026.

This identifies the source, affected segment, consequence, boundary, and date.

### Honest owned-product recommendation

Good:

> Rankizz publishes this guide and is one of the products compared. It is the better fit when remote MCP access is required, but Acme remains the stronger choice for teams that need its native reporting integration.

Bad:

> Rankizz is the obvious number-one alternative for everyone.

### Useful tradeoff

Good:

> Beta removes the five-seat minimum, but its CSV import does not preserve custom statuses. Plan a manual remapping step before switching.

Bad:

> Beta has fewer features but is still a great option.

## Add the publication package

Provide one descriptive H1, a restrained title and page-specific description, stable slug, descriptive internal links, current source links, image briefs, and truthful structured data based on visible content. Do not add review scores or review markup without a genuine, documented evaluation.

## Limitations

- Public evidence may not expose negotiated pricing, private roadmaps, service quality, or enterprise terms.
- Documentation can confirm capability but not always reliability or usability.
- Migration effort depends on the reader's data, integrations, contract, and internal process.
- Product names, plans, limits, and prices change. Date the research and identify refresh points.
- Do not fabricate customer sentiment, hands-on use, benchmark results, or reasons for switching.
- The page cannot guarantee rankings, conversions, or that one choice fits every organization.

## Output template

```markdown
# [Number] best [Incumbent] alternatives for [specific audience or reason]

[Direct answer: the switching reason, best fits, and who should not switch.]

Disclosure: [ownership, affiliate, sponsorship, or free-access relationship]

## Why consider an [Incumbent] alternative?
- [Verified trigger]: [affected user and evidence]

## How we evaluated the alternatives
- Audience and essential job:
- Qualification criteria:
- Disqualifiers:
- Hands-on work:
- Source and pricing cutoff:

## Quick comparison
| Product | Best for | Advantage over [Incumbent] | What you give up | Price basis | Migration concern |
| --- | --- | --- | --- | --- | --- |

## 1. [Alternative]: best for [specific fit]
[One-sentence verdict]

### Why switch from [Incumbent]
[Specific evidence]

### What improves
- [Evidence-backed advantage]

### What you give up
- [Concrete tradeoff]

### Pricing and migration
[Normalized current price, limits, export/import, integrations, and date]

### Choose it if
[Fit]

### Skip it if
[Non-fit]

[Repeat for each qualified alternative]

## Who should stay with [Incumbent]?
[Audience and evidence]

## Which alternative should you choose?
- If [constraint], choose [product] because [evidence].

## Research notes
- Last checked:
- Unverified facts:
- Refresh triggers:

## Editorial QA
- [ ] Every switching reason is evidenced and audience-specific
- [ ] Every alternative solves a verified problem
- [ ] Prices and plans use comparable units
- [ ] Lost capabilities and migration costs are visible
- [ ] Owned products and affiliate relationships are disclosed
- [ ] Some readers are told to stay when appropriate
- [ ] No invented testing, sentiment, or product claims
```