| name | landing-page-copy |
| description | Structure and write high-converting landing pages by matching page structure to the traffic's awareness stage and filling each section from the messaging — then hold the copy to a quality bar (components, adjective test, brevity, checklist). Use whenever the user wants to create, plan, write, edit, audit, or critique a landing page, homepage, or product page — its structure, sections, headlines, or copy. Terminal asset of the strategy stack: pulls from positioning-messaging, which pulls from stp-marketing-strategy. |
Landing Page Structure & Copy
A landing page renders the messaging for a specific traffic source. Two decisions come before writing any copy: what the visitor already knows (awareness), and therefore what structure the page needs. Content for every section comes from the messaging doc (or positioning) — never invented at the page level. Then every line is held to the quality bar in Section 4.
Inputs: this skill renders the output of positioning-messaging (which renders stp-marketing-strategy). If no messaging doc exists, reconstruct the minimum — target, alternatives, 2–3 value claims with proof — before writing.
1. Determine the traffic's awareness stage (Schwartz)
Where do visitors arrive from, and what do they already know?
| Stage | Visitor state | Typical source |
|---|
| Unaware | Doesn't know they have the problem | Cold social, broad display |
| Problem aware | Feels the problem, doesn't know solutions exist | Problem-language searches, content |
| Solution aware | Knows the solution category, not the product | Category searches ("[category] tool"), "near me" / local-pack searches |
| Product aware | Knows the product, unconvinced | Brand searches, "[product] vs [competitor]", retargeting, referrals |
| Most aware | Convinced, needs a reason to act now | Email list, pricing-page visitors, returning/walk-in customers |
Rule: the lower the awareness, the longer the page and the later the product appears. One offer needs structurally different pages per stage — there is no single correct structure.
Mixed traffic: if one page must serve several stages at once, build for the lowest awareness stage present — higher-awareness visitors can skip ahead, but a page built for the aware leaves the unaware behind. Better still, split into separate pages by source. Never average the stages into a vague middle. And once you pick a stage, the hero must match it: don't label the page solution-aware, then open with a mechanism only a product-aware visitor would grasp.
2. Select the structure
Low awareness (unaware / problem aware) — narrative long-form. Customer is the hero, product is the guide (StoryBrand logic); the argument flows Problem → Agitate → Solution (PAS):
Hero (problem or change in their words) → agitation/stakes → the shift or insight → solution introduced → how it works (plan in ~3 steps) → value themes → proof → objections/FAQ → CTA
Mid awareness (solution aware) — the canonical solution-aware structure (ubiquitous in SaaS; adapt the section names to your business):
Hero (value claim + category) → social proof strip → problem/before-after → how it works → benefits by value theme → use cases (by job, if the offer serves several) → testimonials → objections/FAQ → pricing (price list, a quote mechanism, or per-unit — whatever the buyer needs to see) → final CTA
High awareness (product / most aware) — short and direct: differentiation, proof, offer, CTA. Comparison pages: honest alternative pros/cons, win on the segment's criteria.
3. Fill each section from its source
| Section | Source | Rule |
|---|
| Hero headline | Primary value claim (or promised land for cold traffic) | Concrete and specific — a visitor understands what it is and for whom in 5 seconds. State value, not category ("Client reports that update themselves", or "Know the price before you're in the chair" — not "The #1 reporting platform") |
| Hero subheader | Category + differentiator | Explains how the headline is true |
| Social proof strip | Proof | Logos/numbers immediately after hero — borrowed credibility before claims |
| Problem section | Trigger + problem vocabulary | Mirror the trigger in their words; the reader should think "that's me" |
| How it works | Product | 3 steps max — reduces perceived effort |
| Benefits | Value themes | One block per theme: benefit headline + attribute as support + proof. Each block answers an implicit objection |
| Use cases | Jobs-to-be-done | One per job, in the language of each. A single target segment usually has several jobs — this section is jobs within the segment, not a licence to re-broaden the audience |
| Testimonials | Proof | Choose quotes that state a value theme or retire an objection — not generic praise |
| FAQ | Objections | Real objections as questions, verbatim; honest answers |
| CTA | Buying process | Commitment matched to awareness (cold → low-friction next step; hot → "Start free" / "Book a demo" / "Book a visit" / "Get a quote" / "Call now" — matched to how your business is actually bought). Outcome-phrased when possible. Repeat after every major section |
Proof-dependent sections (social proof strip, testimonials, quantified claims): these render real proof. If the proof asset doesn't exist yet, omit the section rather than fabricate it, and flag it as a launch gap to close — an empty or invented proof strip costs more trust than a missing one. Similarly, if a product mechanic you need (e.g. the exact "how it works" steps) isn't known, mark it as an input to confirm rather than inventing the flow.
4. Hold the copy to the quality bar
Structure gets the visitor to read; these rules decide whether the words convert. Apply them to every block.
4.1 Required components
Every text block must carry at least 3 of these. If you can't identify any, it's filler — delete it.
| Component | What it is |
|---|
| Problem | The specific pain you solve |
| User | Who benefits |
| Outcome | The concrete result |
| Benefit | Why that result matters |
| Feature | What makes it possible |
| Differentiator | What makes you unique |
| Evidence | A number, term, or fact that proves it |
4.2 Adjectives
- Empty → delete: any adjective a competitor could use with no evidence.
- Positioning → demonstrate: keep it, but prove it in the same or next sentence. No demonstration = empty.
- Test: could a competitor say the same? Yes → empty. No → positioning. (Same logic as the name-swap test in
positioning-messaging, applied to single words.)
4.3 Brevity
Every word is a tax on attention.
- Connectors: simplify compound connectors ("in order to" → "to").
- Redundancies: delete words that repeat information already stated.
- Filler: delete words that don't change meaning when removed.
- Em dashes: don't overuse them (—); overuse is a tell of AI-generated writing.
- Structure: fewest words possible. Subject + verb + object. One idea per sentence.
4.4 Copy rules
- One idea per section. A section arguing two things argues nothing.
- Specific beats clever. Numbers, timeframes, named outcomes. Delete every unprovable superlative.
- Headlines carry the argument. Reading only the headlines top to bottom should tell the full story — most visitors skim exactly that.
- Customer vocabulary over internal jargon, always.
- Proof travels with its claim, placed where the matching objection arises.
4.5 Numbers & CTAs
- Numbers: specific > range > estimate > nothing. Never use a vague adjective where a number could go.
- CTAs:
[Action: 2–4 words, imperative] + (Support: reduces friction or expands the benefit).
4.6 Write for the second reader: AI agents
A landing page increasingly has a second reader — an AI agent that parses it to answer, cite, or recommend. Humans skim and feel; agents read every word and reward concrete, unambiguous fact. Serving the agent sharpens the human page too: it forces out ambiguity and subjectivity and leaves specific, checkable claims.
- Make every factual claim quotable. Named capabilities, numbers, concrete outcomes an agent can lift verbatim — not "powerful", "seamless", "best-in-class".
- Kill ambiguity. One claim per sentence; name the entity instead of "it"/"they"; keep the claim next to its proof so the link survives extraction.
- Keep a machine-readable spine. Descriptive headings, the argument carried by the headlines (the skim test already forces this) — an agent reconstructs the page from them the same way a skimming human does.
This sits under the human story, not instead of it: lead with the emotional hook, but make every fact agent-quotable. (Empty adjectives fail both readers — §4.2.)
5. Pre-publish checklist
6. Critiquing an existing page
- Identify the real traffic source(s) → expected awareness stage.
- Check structure against stage (most common failure: high-awareness structure served to cold traffic).
- Per section, trace content to its source — flag orphan claims that exist in no messaging.
- Run the Section 4 rules as a checklist, quoting the page as evidence.
- Separate structure problems (wrong stage, missing sections) from copy problems (weak wording) — fix them in that order. Diagnose upward: if the messaging itself is thin, the fix is in
positioning-messaging, not the page.
Worked example: see ../example-acme.md for a landing page built from the messaging of a fictional company, carried down from stp-marketing-strategy.
