Alternative Landing

Alternative Landing Pages

Build or refresh landing pages at src/pages/alternative/[slug].js.

The goal is not generic comparison copy. The goal is a repo-native page that:

• matches the existing alternative landing architecture for its category
• uses benchmark data only from src/pages/benchmarks/screenshot-api.js (screenshot pages only)
• researches the competitor honestly from real sources
• avoids SEO cannibalization with existing alternative pages
• improves the page when a competitor-specific angle is stronger than a boilerplate comparison

Category Selection — Ask First

Before any research or editing, ask the user which Microlink product the competitor competes with:

• Screenshot API — competitor offers headless-browser screenshots / PDFs as their primary product. Examples already in the repo: ScreenshotOne, ApiFlash, Urlbox, Url2Png, Thum.io, ScreenshotAPI, ScreenshotLayer, ScreenshotMachine, Cloudflare (Browser Rendering).
• Embed API — competitor offers URL → card / oEmbed / link preview as their primary product. Example already in the repo: Iframely.
• AI data / scraping — competitor converts URLs into LLM-ready markdown or structured/brand data (Firecrawl, Context.dev). No benchmark exists: use the no-benchmark screenshot structure (cloudflare.js shape — curl-vs-curl hero, no SpeedSection), CTA URLs target /markdown or /metadata, and the TryIt uses MultiCodeEditorInteractive with a markdown or meta mqlCode.

If you can identify the category confidently from the competitor's homepage, confirm with the user before proceeding instead of asking blindly. Phrasing example: "I see [Competitor] leads with [rich-media embeds / headless screenshots / LLM-ready markdown]. I'll use the [embed / screenshot / AI data] template — confirm?"

If a competitor straddles more than one category, pick the dominant product. Lead with embeds → embed template. Lead with screenshots → screenshot template. Lead with LLM-ready markdown or structured data → AI data / scraping structure. Never mix templates.

The category choice changes:

• which reference doc you follow (template-structure.md for screenshot and AI data; embed-template.md for embed)
• which existing page you use as a primary example (screenshotone.js, iframely.js, or cloudflare.js for the no-benchmark shape)
• whether you include SpeedSection — only when the competitor has real benchmark data in src/pages/benchmarks/screenshot-api.js. Embed and AI data / scraping competitors never do, and an unbenchmarked screenshot competitor does not either (cloudflare.js is the reference for that case). Without benchmark data there is no SpeedSection and no RaceContainer.
• which hero visual you use (RaceContainer when benchmarked, a side-by-side curl comparison when not, <InteractiveExample flat hideFooter /> for embed)
• which TryIt visual you use (MultiCodeEditorInteractive for screenshot and AI data, <PreviewVariantsShowcase /> for embed)
• which CTA URLs you target (/screenshot, /embed, or /markdown / /metadata for AI data)

Read First

Before planning or editing, read these in order:

1. If present, .claude/product-marketing-context.md
2. .cursor/skills/alternative-landing/references/microlink-features.md
3. AGENTS.md

Then, depending on the category:

Screenshot category

4. src/pages/alternative/screenshotone.js — primary structural reference
5. src/pages/alternative/screenshotapi.js — secondary reference for a different angle
6. All other src/pages/alternative/*.js files — required for anti-cannibalization
7. src/pages/benchmarks/screenshot-api.js — only source of truth for benchmark numbers
8. .cursor/skills/alternative-landing/references/template-structure.md

Embed category

4. src/pages/alternative/iframely.js — canonical structural reference (the only embed alternative page so far)
5. src/pages/embed.js — source of the InteractiveExample and PreviewVariantsShowcase exports you'll import
6. All other src/pages/alternative/*.js files — required for anti-cannibalization (even though they're screenshot pages, FAQ wording and SEO titles can still clash)
7. src/pages/features/proxy.js — source of truth for proxy / antibot / CAPTCHA claims
8. .cursor/skills/alternative-landing/references/embed-template.md

Core Rules

These are non-negotiable:

• Never guess the competitor URL. Ask if it is missing.
• Never invent competitor features, pricing, SLA, rate limits, integrations, or infrastructure claims.
• Never invent benchmark numbers or extrapolate them to unbenchmarked competitors.
• Never round speed claims up. Use conservative wording and round down.
• Never claim a competitor feature unless it is verified on the competitor website or docs.
• Never claim a Microlink feature unless it exists in references/microlink-features.md.
• Never ship a placeholder comparison page full of assumptions.
• Never repeat the same hero angle, title angle, or FAQ phrasing used by another alternative page if it risks cannibalization.
• Never run Prettier or any formatter as part of this skill. This includes prettier, prettier-standard, repo-wide format commands, or any command that may rewrite unrelated files.

Source Hierarchy

Use sources in this order:

1. Competitor website and official docs
2. src/pages/benchmarks/screenshot-api.js
3. .cursor/skills/alternative-landing/references/microlink-features.md
4. Third-party sources and review sites

Use third-party sources only for:

• understanding market positioning
• identifying likely objections or limitations to verify
• finding missing official pages

Do not use third-party sources as proof for hard claims if the competitor site does not confirm them.

Workflow

1. Gather Inputs

Before editing:

1. Confirm the category — screenshot, embed, or AI data / scraping (see "Category Selection — Ask First" above). Every subsequent step depends on this choice.
2. Confirm the competitor name.
3. Confirm the competitor URL.
4. Confirm the target slug if the user gave one.

Screenshot-only step: map the competitor to a benchmark key in BENCHMARK_DATA.results.

If the competitor is screenshot-category but not benchmarked in src/pages/benchmarks/screenshot-api.js, stop and ask how to proceed. Do not fabricate a speed section.

Recommended options:

• wait until benchmark data exists
• create only an improvement report
• create a non-speed draft only if the user explicitly accepts a deviation from the existing structure

If the competitor is embed-category, skip the benchmark mapping — there is no embed benchmark. Follow embed-template.md which deliberately omits SpeedSection.

If the competitor is AI data / scraping, skip the benchmark mapping too — there is no markdown or structured-data benchmark. Follow the cloudflare.js no-benchmark shape, which omits SpeedSection and RaceContainer.

2. Research the Competitor

This phase is mandatory.

Use WebFetch to fetch and inspect, at minimum:

• homepage
• features or product page
• pricing page
• API docs or docs home
• any page covering integrations, storage, or automation if relevant

Use WebSearch to discover missing official pages and to understand positioning:

• "[Competitor] pricing [year]"
• "[Competitor] [category] api features" — swap [category] for screenshot or embed
• "[Competitor] docs"
• "[Competitor] alternatives"
• "[Competitor] review limitations"

For embed-category competitors, also confirm:

• their pricing unit (per-request, per-hit, per-domain, etc.) and any documented rate limits
• whether they ship a proxy / antibot / CAPTCHA layer (most embed APIs do not — that is the Microlink Pro differentiator)
• their publisher catalog size if they publish one
• their CMS / framework integrations (WordPress plugin, AMP, React component, etc.)

From research, build a working ledger of:

• verified features
• verified missing features
• pricing tiers, quotas, rate limits, and overages
• integrations and workflow tooling
• notable strengths where the competitor is genuinely better
• limitations or tradeoffs worth mentioning
• open questions that remain unverified

If the site is too JS-heavy to verify a claim via fetchable content, treat that claim as unverified and ask the user before using it.

3. Anti-Cannibalization Pass

Every alternative page needs a distinct search and messaging angle.

Read every existing file in src/pages/alternative/*.js and compare:

• <Meta title>
• <Meta description>
• hero heading
• speed-section subhead
• CTA heading
• FAQ questions

Current angle map:

Screenshot category:

• screenshotone.js: speed-first angle ("The fastest ScreenshotOne alternative")
• screenshotapi.js: breadth / "does more" angle ("broader browser workflows")
• urlbox.js: cost per render angle ("better cost per render")
• screenshotmachine.js: upgrade path angle ("richer browser workflows")
• apiflash.js: production workloads angle ("for production workloads")
• url2png.js: modernization angle ("a more modern screenshot API")
• screenshotlayer.js: throughput / overage angle
• thumio.js: final-screenshot vs streamed-thumbnail angle
• cloudflare.js: batteries-included angle ("managed screenshot API vs DIY browser infrastructure") — no benchmark data, so no SpeedSection/RaceContainer; hero uses a side-by-side curl comparison instead

AI data / scraping category:

• firecrawl.js: flat-pricing angle ("without the credit math" — 5× stealth multiplier, one-time free credits, no rollover)
• context-dev.js: one-request bundle angle ("answers in one request" — credit menu vs metadata+logo+markdown+screenshot in a single flat request)

Embed category:

• iframely.js: developer-first angle ("The developer-first Iframely alternative") — emphasizes per-request pricing vs hit-based pricing, no rate-limit ceiling, and the Pro proxy bundle

Pick a primary angle and a secondary angle for the new page. Examples:

• fastest
• more complete platform
• cheaper at scale
• open-source / auditable
• better for AI agents
• better for metadata + screenshot in one API
• better migration path

Avoid collisions such as:

• two pages both leading with "fastest [Competitor] alternative"
• reusing near-identical FAQ wording
• repeating the same title pattern across pages

If the best angle clearly collides with an existing page, change the angle or ask the user which angle to prioritize.

4. Build the Page Data

BENCHMARK_DATA (screenshot category only)

Skip this whole subsection on embed pages. Embed alternatives have no benchmark and no SpeedSection.

For screenshot pages, copy only:

• microlink
• the target competitor

Keep the same testUrls array from src/pages/benchmarks/screenshot-api.js. Inline the values exactly. Do not reference helper constants from the benchmark page.

SERVICE_COLORS (screenshot category only)

Embed pages do not render a benchmark race and do not need a SERVICE_COLORS map. Skip.

For screenshot pages, use:

• microlink: colors.red6
• competitor: a color not already used by another alternative page

Currently used:

• screenshotone: colors.pink6
• screenshotapi: colors.grape7
• urlbox: colors.teal6
• screenshotmachine: colors.blue6
• apiflash: colors.orange6

Speed claim math (screenshot category only)

Embed pages do not have speed claims. Skip this subsection.

For screenshot pages, compute conservatively:

• average speed advantage: ((competitorAvg - microlinkAvg) / microlinkAvg) * 100
• per-URL multiplier: competitorUrl / microlinkUrl

For marketing copy:

• floor percentages instead of rounding up
• floor multipliers instead of rounding up
• prefer "up to 2× faster" over "up to 2.4× faster" unless the decimal precision is important and still conservative

If the benchmark result is directionally mixed or too small to support a strong claim, soften the copy.