How to write a product landing page: seven sections, one proof line

How to write a product landing page: build seven sections in a fixed order — hero, problem, mechanism, proof, objections, alternative, next step — and write one proof line for every claim before you write a headline. The order is the argument. A reader decides in that sequence, and a page that skips a step asks them to believe something they have not been given yet.

Why most product landing pages fail before the copy

Most pages open with the product because the founder is proud of it. The reader arrives with a different question: is this for someone like me, and what happens if I try it? Copy that answers the founder's question reads like a brochure. Copy that answers the reader's question reads like a demonstration.

There is a second failure that is easier to miss. Teams collect proof after drafting, so the page ends up with claims looking for evidence. Reverse that. Decide what you can prove, then write sentences that the proof can carry. This is the same discipline behind a product positioning statement: one sentence first, evidence second, decoration last.

A landing page is not a shorter homepage. It is one decision, argued in order.

The order also protects you from a common editing loop. When a page feels weak, the temptation is to rewrite the headline again and again. Usually the headline is fine and the proof is missing. Working in sequence tells you which section is actually empty, because each section depends on the one before it.

One more constraint before you start: a landing page argues one decision. If you catch yourself adding a second audience, a second use case, or a second product, stop and split the page. Two arguments on one page produce a page that wins neither.

How to write a product landing page in seven sections

The seven sections are hero, problem, mechanism, proof, objections, alternative, and next step. Each one answers a single reader question. If a section cannot answer its question in the first two lines, it is not ready — no amount of design will fix a missing answer.

How do you write the proof line first?

A proof line is one sentence that makes a claim checkable. It has three parts: a specific action, a visible result, and a boundary. Write it before the paragraph it supports. If you cannot fill all three parts, the claim is not ready for the page.

The boundary is the part most pages omit. "Works for sites with fewer than 10,000 pages" is stronger than "scales with you", because it tells the reader whether the next sentence applies to them. A boundary is not a weakness in the offer. It is the reason the rest of the page can be believed.

How do you write a hero without a category cliché?

Name the reader, the job, and the change in that order, then delete every word that does not carry one of the three. A useful test is to read the sentence to someone outside your market. If they can repeat the job back to you, the hero works. If they repeat the category, it does not.

Avoid opening with a category label that nobody searches for. "The collaborative workspace for modern teams" describes a shelf, not a job. A stronger version says who the reader is and what becomes possible: "Turn one recorded call into a client-ready summary before the call ends." The second sentence is longer, but it gives the reader something to recognise.

Keep the hero to one sentence and one action. The action can be a signup, a demo, or a waitlist, but it should be the same action the final section asks for. Two different primary actions on one page usually mean the page is still deciding what it sells.

What do you do when you have no testimonials or logos?

You replace social proof with mechanical proof. A reproducible demo, a dated self-measurement, a public changelog, and a named limitation all tell the reader more than a row of grey logos. None of them require a customer to say yes.

Do not invent a customer count, a rating, or a "trusted by" strip. Readers cannot verify those numbers, and neither can you six months later. If the only proof you have is a demo, make the demo the centre of the page.

What does a copyable product landing page skeleton look like?

Use this skeleton as the first draft, then delete any section you cannot support. A short page with five honest sections beats a long page with seven and a gap where the proof should be.

<h1>[Product] helps [audience] [outcome]</h1>
<p>[One sentence: the job, and what changes after it.]</p>
<a href="[signup]">[Start the action]</a>

<h2>The problem</h2>
<p>[One scene from the reader's week, in their words.]</p>

<h2>How it works</h2>
<ol>
  <li>[Input] → [step] → [output]</li>
  <li>[Input] → [step] → [output]</li>
  <li>[Input] → [step] → [output]</li>
</ol>

<h2>Proof</h2>
<p>[Dated result, reproducible demo, or public number.]</p>

<h2>What it does not do</h2>
<p>[Boundary, price, setup time, and who should not buy.]</p>

<h2>Why not [current alternative]</h2>
<p>[Honest trade-off, including where the alternative wins.]</p>

<h2>Start here</h2>
<p>[One action, how long it takes, and what happens next.]</p>

What should you check before you publish?

Read the page against five questions. Any no means go back to the section that caused it, not to the whole page.

1. Can a stranger repeat the hero sentence to a colleague without adding context?
2. Does every claim have a proof line with an action, a result, and a boundary?
3. Does the page say who it is not for, in plain words?
4. Is there exactly one primary action, and does the reader know what happens after it?
5. Would the page still be true if a competitor read it out loud?

Three ways this goes wrong

The first is the most common, and it is a writing problem rather than a design problem.

1. Writing the page as a feature list. A list of capabilities forces the reader to assemble the argument. Do that work for them: three steps, one outcome, one boundary.
2. Saving proof for the bottom. Readers leave before they reach it. Put the strongest piece of evidence in section four, directly after the mechanism it supports.
3. Treating the page as permanent. A landing page is a hypothesis. Change one section at a time and keep the before, the same way you would when you rewrite an about page.

What we do not know

We do not have conversion data for your traffic, your price, or your audience. The seven sections are a writing order, not a promise that the page will convert. What we can say is narrower: a page that answers these questions in this order gives a reader fewer reasons to leave before the action.

If you are running the whole promotion workflow, the landing page is one asset inside the content creation workflow. It should reuse the same positioning sentence and the same proof inventory as your directory listings and launch posts. When those disagree, the reader is the one who notices.

Common questions

How long should a product landing page be?

Long enough to answer the seven questions, and no longer. For a simple tool that is often 500 to 700 words; for a product with a real objection list it can be twice that. Length is not the lever. Order is.

Do I need a testimonial to publish?

No. A reproducible demo or a dated self-test can carry the proof section. A testimonial is useful when it names the same job the hero promises. A generic quote does less work than a screenshot of the product doing the job.

Should the landing page match the homepage?

They should share the positioning sentence and differ in scope. The homepage explains the whole product; the landing page argues one decision. If they use different names for the same feature, fix the names before you fix the layout.

How do I know whether it worked?

Pick one action and one outcome before launch, then record the date you changed the page. Without a before and a date, you cannot separate the copy from the traffic, the season, or the ad. We cannot tell you which section caused a change from a single snapshot.