Landing pages

Articles are written once and age. A landing page is different: it's a permanent answer to a question buyers keep asking — is this for someone like me?, how does it compare to X?, does it work with the tool I already use? — and it should change whenever your positioning does.

Ballad writes those pages, keeps them in step with what you now say, and proposes a rewrite as a diff when something moves.

The four types

The type lives on the collection, and the collection's slug is the route prefix, so pages land at readable URLs on your own domain:

Type	Where it lives	What the page covers
Segment	/for/technical-founders	The situation in the reader's words, what Ballad does for it by job, proof, one ask
Use case	/use/launch-week	The moment, the loop for it step by step, what it produces, proof, one ask
Comparison	/vs/acme	Who each is for, what each does well, where they differ as a table, when to pick which
Alternative	/vs/agency	The tradeoff in time and money, what changes, what doesn't
Integration	/integrations/slack	What connects, what flows each way, setup in three steps

The shape of each is fixed in code rather than left to a prompt, so a comparison page always has the comparison table and never wanders.

Where a page comes from

Four doors, and every one produces a proposal rather than a published page:

• The site audit. A coverage finding — "the positioning promises a page for agencies and the site doesn't have one" — turns into a page of the right type when you press Write it.
• The plan. Adding a segment or a competitor can carry a follow-on proposal for the matching page; removing one proposes unpublishing it.
• You. Start one from the collection in Content.
• An agent. propose_page with a type and a subject.

How a page is written

A page is written only from what Ballad already holds about you: your positioning, your product and its real feature names, battlecards for a comparison, customer proof that carries consent, and your site map for what to link to. There's no research pass and no invented specifics.

The drift check runs at write time, as a gate: a page that contradicts your current positioning is never offered for review in the first place.

Pages speak in the brand voice by default, with your own voice appearing only inside quoted proof — a segment page that reads better in the first person can be switched.

They stay current

This is the part that makes a page different from a post. When a segment is added or dropped, an offer changes, the one-liner is reworded, or a competitor's weekly drift check finds they've moved, the affected pages are proposed for a rewrite as a diff: what would change, and why.

A page never auto-applies, whatever your trust setting. There will be dozens of posts and a handful of pages, and a handful earns a look.

Rendering them on your site

Pages need one catch-all route added once — after that, a new page collection Ballad creates later needs nothing from you:

// lib/ballad.ts
import { createSitePages } from '@balladlabs/next/pages';
export const pages = createSitePages(ballad, { publisher });

// app/[...slug]/page.tsx
export const generateStaticParams = pages.generateStaticParams;
export const generateMetadata = pages.generateMetadata;
export default pages.Page;

The full wiring — including the combined revalidate route and the capability check Ballad uses to know your site can render pages — is in Set up your Next.js blog. Until it's there, Ballad shows the install step instead of proposing pages.

Pages have no index and no feed, carry WebPage structured data (FAQPage where a section is questions), and a page built as an ad destination is marked noindex and kept out of your sitemap.

How they're judged

Two numbers, not traffic:

• Conversion from the page itself, per page, through the beacon.
• Whether AI answers cite it. A comparison page is working when the weekly check sees you named for a question where a competitor used to be.

Next

• Set up your Next.js blog — the catch-all route.
• Sitemap and site audit — where coverage gaps come from.
• Content — where page collections live.