Landing Page Copy

Write copy for pages with a single conversion goal: signup, purchase, demo request, download, lead capture. Stack-agnostic.

This skill is narrower than content-and-copy. Landing pages exist to drive a specific action, not to inform broadly.

When to use

• Writing a hero section for a homepage or product page
• Writing a sales page or long-form sales letter
• Drafting opt-in or lead-capture page copy
• Campaign-specific landing pages
• Pricing page copy
• Demo or signup CTAs

When NOT to use

• Long-form blog content (use content-and-copy)
• Email sequences (use email-sequences)
• Brand voice definition (use brand-voice)
• Page design and layout decisions (use design-standards)

Required inputs

• The product, service, or offer
• The target audience and the specific objection they bring
• The conversion goal (one specific action)
• Brand voice
• Existing customer language (testimonials, support tickets, sales calls)
• Any constraints (length, format, regulatory)

If audience is unclear or objections are unknown, run brand-discovery or pull from sales call recordings before writing.

The framework: 7 sections

A landing page does seven things in sequence. The structure can flex (combine, reorder, expand), but the elements stay constant.

1. Hero

The first 3 to 5 seconds. Decides whether the visitor stays.

Three components:

• Headline. The promise. Specific, outcome-focused, free of cliche.
• Subheadline. The mechanism. How you deliver the promise.
• Primary CTA. The action. One button, descriptive label.

Strong hero patterns:

• Outcome + audience + mechanism. "Ship features 3x faster, for engineering teams who hate meetings, with our async-first project tool."
• Pain reversal. "Stop losing customers to slow page loads."
• Surprising claim. "The note-taking app that gets used. We have data."
• Direct address. "You have 47 unread Slack messages. Here's what to do about it."

Weak hero patterns:

• Generic adjective stacking ("Powerful, intuitive, scalable")
• "Welcome to our platform"
• Brand-name-only headlines ("Acme: The Future of X")
• Vague benefits ("Streamline your workflow")

2. Social proof (early)

Within the first scroll, prove someone else trusts you.

Forms:

• Customer logos (recognizable beats unknown)
• Quantitative trust signal ("Over 10,000 teams")
• One strong testimonial with name and role
• Press mentions (logos of where you've been featured)

Placement: Right below the hero, before the visitor invests in reading more.

3. Problem / promise

Establish that you understand the visitor's situation.

Pattern:

• 1 to 3 paragraphs naming the specific problem
• Use the visitor's language (mined from research, not your marketing language)
• Stop before you sell. Resonate first.

Test: Read the problem section aloud. Does the target audience nod? If they don't, you don't understand them yet.

4. Solution / mechanism

How you solve the problem. The "what we actually do" section.

Effective structure:

• One headline summarizing the solution
• 3 to 5 specific features or capabilities, each with a 1-2 sentence explanation
• Each feature framed as the benefit it produces, not the technical detail
• Visual support (screenshots, illustrations, video clips)

Failure mode: Listing features without translating to outcomes. "Real-time collaboration" is a feature. "Edit together without copying-pasting from email" is the outcome.

5. Proof and detail

The expanded social proof and case studies section.

Components:

• 1 to 3 detailed case studies (specific customer, specific outcome, specific numbers)
• Multiple testimonials with attribution
• Specific data points (usage stats, success metrics, growth)
• Awards, certifications, or third-party validation

The deeper proof section is where committed visitors convert. Skim-readers won't make it here, but the ones who do are ready to buy.

6. Objection handling

Anticipate the reasons people say no. Address them directly.

Common objection types:

• Price. "Is this worth it?"
• Time. "Will this take forever to set up?"
• Trust. "Will this actually work for my situation?"
• Risk. "What if I commit and it's wrong?"
• Comparison. "How is this different from [competitor]?"
• Implementation. "Can my team handle the change?"

Handling formats:

• FAQ section. Structured, scannable.
• Comparison table. Vs. competitors or vs. alternatives.
• Risk reversal. Money-back guarantee, free trial, no-contract terms.
• Proof of effort needed. "Setup takes 5 minutes, not 5 weeks."

7. Final CTA

The closer. Re-state the offer. Re-state the action.

Strong final CTAs:

• Repeat the primary CTA from the hero (consistency)
• Frame in terms of the visitor's situation ("Get your team set up in 5 minutes")
• Remove friction ("No credit card required")
• One action only (avoid offering 5 alternatives that paralyze decision)

Avoid:

• Multiple CTAs competing for attention at the bottom
• New offers introduced only at the bottom (visitor is now confused)
• Long forms that ask for more information than needed for the action

The CTA itself

Buttons matter. Treat the button copy as a whole-page-worth of attention.

Strong CTA patterns:

• Action + outcome. "Start your free trial," "Get my pricing," "Send me the guide"
• First-person. "Show me how" outperforms "Show you how"
• Specific. "Book a 15-minute demo" beats "Contact us"
• Low-friction. "Free trial, no credit card" reduces commitment cost

Weak CTAs:

• "Submit" (functional but lifeless)
• "Click here" (no value statement)
• "Learn more" (vague; about what?)
• "Get started" (started doing what?)

Workflow

1. Confirm the offer. What exactly is being offered? At what price (if any)? What does the visitor get?
2. Confirm the audience and objection. Specific segment. The specific worry they bring.
3. Mine the language. Customer testimonials, support tickets, sales calls. Use real customer phrases.
4. Draft the hero. Headline, subheadline, CTA. Test 5 to 10 variations.
5. Build the structure. All 7 sections in order. Sections can combine for shorter pages.
6. Draft sections. Section by section. Don't polish until the structure is sound.
7. Edit for friction. Remove every word that doesn't earn its place. Landing pages do not have words to spare.
8. Test the CTA. Read the page aloud. By the end, is the visitor's next action obvious?
9. Hand off with a post-import checklist. The deliverable is a markdown document, not a built page, so step 9 is not something you perform: it is a list you attach for whoever builds the page. Spell-check the copy yourself, then hand over the rest. Every destination URL resolves. Mobile preview of the built page. SEO basics if SEO is a goal. If the page is already built and you are revising it in place, run the checklist yourself instead of handing it over.

Failure patterns

• Hero that explains instead of sells. "We're an X for Y" is description. "Get X without Y" is sell.
• Feature lists with no outcomes. Features without benefits read as a spec sheet.
• Generic testimonials. "Great product!" is worth less than nothing. "We cut onboarding time from 2 weeks to 4 days" is gold.
• Multiple competing CTAs. Pick one primary action. Everything else is noise.
• Walls of text. Visitors scan. Use short paragraphs, bullet lists, and visual breakpoints.
• No social proof. Trust is the first hurdle. Without proof, the rest of the page does not earn the chance to be read.
• Mismatched headline and CTA. Hero promises X, CTA asks for Y. Visitor confused.
• Writing for everyone. "Our solution works for any business" appeals to no one. Specificity converts.
• Ignoring mobile. Most visitors are on mobile. Test the page at 375px first.

Output format

Default output is a structured markdown document for the page, with each section labeled. The markdown is ready to import into the CMS or hand to design.

Structure:

# [Page Title]

## SECTION: Hero
- Headline: [text]
- Subheadline: [text]
- Primary CTA: [button text]
- Supporting cue: [optional, e.g., "No credit card required"]
- Hero visual notes: [if any]

## SECTION: Social proof (early)
- Logo bar: [list customer/press logos]
- Trust statistic: [if any]

## SECTION: Problem / promise
[2 to 3 paragraphs]

## SECTION: Solution
- Headline: [text]
- Feature 1: [headline + description]
- Feature 2: [headline + description]
- Feature 3: [headline + description]

## SECTION: Proof
- Case study 1: [customer, outcome, numbers, or state the gap per the data-availability rule]
- Testimonials: [list]
- Data points: [list]

## SECTION: Objection handling
- FAQ: [questions and answers]
- OR Comparison table: [vs alternatives]
- OR Risk reversal: [guarantee, terms]

## SECTION: Final CTA
- Headline: [text]
- Final CTA button: [text]
- Supporting cue: [optional]

## Variants for testing
- [Alternate headlines]
- [Alternate CTAs]
- [Alternate proof framings]

If required data is unavailable

This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.

Reference files

• references/hero-formulas.md - Patterns and formulas for hero headlines.
• references/objection-library.md - Common objections by category, with handling strategies.