-
Step 1 · Say one thing clearly: who it's for, what they get, why believe you
Above the fold: audience, outcome, proof
A landing page is not a homepage. It does one thing: get a visitor to complete one action. So the first screen has to say three things:
- Who it's for: "for indie developers who don't want to maintain a backend" — not for everyone
- What they get: "a static site that can take money, up in two hours" — write the outcome, not the feature list
- Why believe you: "21 scenarios and 100+ steps already running", "real scripts included, not slides" — evidence, not slogans
First-screen structure (copy it):
one-line claim → subhead → primary CTA → proof strip (numbers / screenshot / one-line endorsement)The counter-example: "committed to becoming an industry-leading solutions provider". Anyone could write that, which is why it says nothing.
CTA copy is action plus benefit: "Get the scripts free →" outperforms "Submit" by a wide margin.
Checklist
- The first screen answers who / what / why believe you
- The CTA reads as action plus benefit, not "Submit"
- There's exactly one primary CTA above the fold, not two equally large buttons
-
Step 2 · Page structure: one line of argument, downwards
Pain → solution → proof → objections → CTA. No unrelated modules
Every screen answers the next question in the visitor's head:
- What is this? (first screen)
- What does it have to do with me? (the pain: where you're stuck now)
- How does it work? (the solution, in 3–5 steps, with screenshots)
- Has anyone used it? (proof: numbers, screenshots, a one-line quote)
- Is this going to screw me over? (objections: price, do I need paperwork, how long it takes, can I get out)
- So what do I do next? (CTA, repeated)
Ordering rule: the closer an objection sits to the decision, the later it goes — but it must be resolved before the final CTA.
What to cut: team bios, company history, news, a nav bar full of unrelated links. On a landing page the nav should be logo plus CTA, nothing else.
Mobile first: most traffic is on a phone. Get the claim and the CTA onto one phone screen before you touch the desktop layout.
Checklist
- The page follows one thread; any module can be removed without breaking comprehension
- Objections appear before the last CTA
- Claim and CTA are both visible on one phone screen
-
Step 3 · Instrument it: CTA clicks, scroll depth and source, recorded separately
Without tracking, A/B tests and "optimisation" are guesswork
The one thing you can't skip on a landing page is tracking. Three things must be recorded separately, or the data comes out as mush:
| Event | Trigger | props |
|---|---|---|
|lp_view| page visible |src(utm_source) /variant(A/B version) |
|lp_scroll| scrolled to 25 / 50 / 75 / 100% |depth|
|cta_click| any CTA clicked |pos(top / middle / bottom) /src|
|cta_submit| form submitted successfully |src|Why source has to be recorded: traffic from a chat app and traffic from search can convert three times differently. Mix them and you'll wrongly conclude "the page is fine". Put
?src=wx-style parameters in the URL and write them into props.Record the definitions in
data/conversion.json, so before-and-after changes are auditable.The smallest closed loop:
lp_view→cta_click→cta_submit. Connect those three and you have conversion observation at all.Checklist
- All 4 events are queryable in the tracking backend
- Every event carries src, so you can split by source
- This scenario's conversion definitions are in data/conversion.json
-
Step 4 · Run one A/B test: change one variable
Change only the headline, or only the CTA copy, and wait for enough samples
Don't change five things at once — if the number goes up, you won't know who to thank.
The least-work A/B, which a static site can do:
- Copy the page to
lp-b.htmland change exactly one variable — only the main headline, say - Split traffic by
?variant=bor by source: half the links point at A, half at B - Record
lp_view/cta_click/cta_submitseparately per version - Compare only after 100+ visits per version. Below that it's noise
Three things worth testing, in order of impact: the main headline, the CTA copy, the proof strip.
How to judge: look at two ratios — click rate =
cta_click / lp_view, and submit rate =cta_submit / lp_view. Not the absolute counts: when traffic rises, clicks rise too, and that was the traffic's doing, not the page's.Keep a record: write the conclusion into the notes in
data/conversion.json, so nobody re-tests the same variable next quarter.Checklist
- The two versions differ in exactly one variable
- Each version reached 100+ visits before you concluded
- The conclusion is recorded, so the test isn't repeated
- Copy the page to
-
Step 5 · Launch + speed + indexing and weekly review
Fast is part of conversion; and put the page on the indexing watchlist
Speed is conversion: past three seconds of mobile load time, bounce rate doubles. At minimum:
- Compress every image and use WebP or SVG; the first-screen image gets
loading="eager", the restlazy - Inline critical CSS; JS at the bottom or
defer - Put it behind a CDN (see the CDN + HTTPS Acceleration scenario) with gzip or br on
- Run PageSpeed Insights once and get LCP under 2.5 s first
Launch checklist:
- HTTPS with forced redirect
canonicalpointing at the main version — the B variant canonicals to A, so it isn't treated as a duplicate page- Submit the sitemap; add the landing page to
data/index-observation.json - Run
bash scripts/seo-check.sh
Weekly review (15 minutes):
Look atlp_view→cta_click→cta_submitand fix whichever stage drops hardest. Losing view→click means fix the first screen; losing click→submit means fix the form.Compliance, easy to forget: promises have to be keepable, state the conditions on any pricing or earnings claim, and put a disclaimer in the footer.
Checklist
- LCP under 2.5 s, measured in PageSpeed
- canonical points at the main version and the B variant isn't indexed separately
- It's on the indexing watchlist and checked weekly
- Compress every image and use WebP or SVG; the first-screen image gets