SaaS Landing Page Design: The Anatomy of a Page That Converts
A landing page is not a smaller homepage. What belongs in each of its seven sections, the hero patterns that work and the ones that fail, and how to choose between them.
A landing page is not a smaller homepage. It is a different kind of object, and most of them underperform because they were built as the homepage with sections deleted.
A homepage serves several audiences at once and can afford breadth. A landing page serves one promise — usually one made in an ad, an email or a search result — and every element that does not support that promise is competing with it.
This is a section-by-section account of what belongs on one, in what order, and the decisions inside each block.
The short answer
A SaaS landing page needs seven parts, in this order:
- Hero — the promise, the audience, and the action.
- Proof strip — enough credibility to buy attention for the rest.
- The product, shown — what it actually looks like doing the thing.
- Mechanism — how it works, in enough depth to be believed.
- Objection handling — the specific reasons this reader would say no.
- Pricing or terms — what it costs, or what the next step costs.
- Final action — the same action as the hero, unchanged.
Everything below is the reasoning, and the decisions inside each part.
If you are designing a whole site rather than one page, the architecture question comes first — that is covered in our guide to SaaS website design.
One page, one promise
The single most useful constraint: write the promise down in one sentence before designing anything, and delete any section that does not serve it.
This sounds obvious and is almost never done. The usual failure is a page that promises "cut your onboarding time in half" and then spends four sections on unrelated features, because those features exist and somebody wanted them mentioned. Each one dilutes the promise it took the ad budget to make.
A landing page can afford to be narrow. It is allowed to ignore most of what your product does.
Part one: the hero
The hero has about ten seconds to do three jobs. Nielsen Norman Group, reporting Microsoft Research's analysis of over two billion page visits, found that dwell time follows a Weibull distribution with negative aging — most departures happen almost immediately, and the curve only flattens after roughly thirty seconds. Read the study summary.
Three jobs, in this order:
The headline names the category or the outcome. Not the aspiration. "Cut invoice approval from days to hours" or "Fraud detection for online stores." A visitor who cannot categorise what they are looking at cannot evaluate anything else on the page.
The subheading names the reader or the situation. "For finance teams closing the books monthly." "If your onboarding is three spreadsheets and a Notion page." This is where differentiation belongs — after comprehension, not instead of it.
The action states its terms. "Start free — no card required." Not "Get started."
Choosing the hero visual
This is the decision teams spend longest on and reason about least. Here is how the options actually behave:
| Pattern | Works when | Fails when |
|---|---|---|
| Product screenshot | The interface is legible at a glance and shows the outcome | The UI is dense, or the value is not visible in one frame |
| Cropped detail of the UI | One screen element carries the whole story | It needs surrounding context to make sense |
| Short looping video | The value is in a sequence or a transformation | It needs sound, or takes longer than a few seconds to pay off |
| Interactive demo | The product is simple enough to try in under a minute | Setup, data or accounts are required first |
| Abstract illustration | The product has no visual surface at all | It is chosen because the real UI looks unfinished |
| Founder or customer photo | Trust is the primary barrier | The reader does not yet know what the product is |
The honest note on the last two: an abstract illustration is very often chosen because the product is not pretty yet. That is a real reason, but it costs you the strongest thing a hero can do, which is prove the product exists by showing it. If the interface is the problem, fixing the interface will do more for the page than any illustration.
For products with genuinely no visible surface — an API, a model, an infrastructure layer — the visual problem is real and needs a different approach, which we cover in designing AI startup websites.
What does not belong in the hero
- Full site navigation. A landing page with a nav bar gives the visitor eight ways to leave before they have read anything. Keep the logo, drop the menu.
- Two competing actions. One primary. A quiet secondary link is fine; two buttons of equal weight is not.
- A cookie banner covering the CTA. Obvious, routinely shipped, and worth checking on a real phone rather than a simulator.
Part two: the proof strip
Immediately under the hero, a thin band of credibility. Logos, a count, a rating, a certification — whatever is true.
The job here is narrow: buy permission for the next scroll. It does not need to close a specific objection; that comes later. It needs to answer "is this a real company?"
Two rules. Use real logos only — placeholder or "as seen in" logos that link nowhere are actively corrosive if anyone checks. And keep it thin. A full section of logos this early spends attention you have not yet earned.
Part three: show the product
The single most under-used section on SaaS landing pages: a large, clear, honest picture of the product doing the thing the headline promised.
Not a carousel of six screenshots. One image, big, annotated if the interface needs it.
This section does double duty — it explains and it proves simultaneously. A screenshot showing the specific claimed outcome is close to unfakeable, which is why it outperforms almost any written proof.
Annotation matters more than most teams think. A bare screenshot asks the visitor to find the important part; two or three short labels pointing at what to look at does the work for them. That is a design job, not a marketing one.
Part four: mechanism
Now explain how it works — because a sceptical buyer needs a plausible mechanism before they believe an outcome.
The most reliable structure is three steps. Not five, not seven. Three, each with a heading that is a verb, and each with a picture of the thing actually happening.
Connect your billing data → We flag anomalies against your own history → You approve or dismiss in one click
The failure mode here is the feature grid: nine icons with three-word labels. It looks organised and communicates almost nothing, because a feature name is not a mechanism. "Smart alerts" tells a reader nothing. "Flags charges that break your own historical pattern" tells them how it works and what it would catch.
If you have nine features, the page needs the three that matter for this promise. The other six belong on a page for a different promise.
Part five: handle the objection
Every audience has one dominant reason to say no, and it is usually not the one the team assumes.
For SaaS it is typically one of:
| Objection | What answers it |
|---|---|
| "Switching costs too much" | Migration support, import tooling, a named customer who switched |
| "My data isn't safe with you" | Certifications, where data lives, who can see it — specifics, not "enterprise-grade" |
| "My team won't adopt it" | Time to first value, a customer with a comparable team, what onboarding involves |
| "It won't handle our edge case" | The edge case, named, addressed directly |
| "You might not exist next year" | Funding, customer count, how long you have operated |
Find yours by asking people who did not buy. Not people who did — they are the ones for whom the objection was already answered.
Then answer it in its own section, in plain words, with proof beside it. A named customer with a specific number does more here than any amount of reassuring copy.
Part six: pricing or terms
Show pricing if you have it.
Hidden pricing is a defensible choice for genuinely enterprise products with negotiated contracts. For everything else it costs more than it protects. A visitor who cannot tell whether you are in their range assumes you are not, and leaves — and the ones who do book a call include a large share who were never going to afford it, which is a cost paid by your sales team rather than your marketing budget.
If pricing genuinely cannot be shown, show the shape of it: a starting point, what drives the number, or what the demo will cover. "Plans start at $X for teams up to Y" removes most of the uncertainty without publishing a rate card.
Part seven: the final action
Repeat the hero's action, unchanged, with the same wording.
Changing it — "Start free trial" at the top, "Talk to sales" at the bottom — reads as uncertainty about what you want, and it makes a visitor who had decided at the top hesitate at the bottom.
A short FAQ directly above the final CTA is worth its space. It is the last chance to close objections, it costs nothing in attention because people self-select into it, and the questions are already written: they are the ones your sales team answers every week.
The page, assembled
| Section | Job | Fails when |
|---|---|---|
| Hero | Category, audience, action | It leads with aspiration |
| Proof strip | Buy the next scroll | It is a full section this early |
| Product shown | Explain and prove at once | It is a carousel nobody advances |
| Mechanism | Make the outcome plausible | It is a grid of feature names |
| Objection | Close the real reason for no | It answers an objection nobody had |
| Pricing | Remove the last unknown | It is hidden for no good reason |
| Final action | Convert the decided | It differs from the hero's |
Things worth measuring, in order
- Scroll depth by section. Where people stop is where the page stops being worth reading.
- Time to first interaction. Long means the hero is not landing.
- CTA click rate versus form completion. Separates page problems from form problems.
- Conversion split by traffic source. If one source converts and another does not, the page may be fine and the traffic wrong — see why SaaS sites get traffic but no signups.
Frequently asked questions
How long should a SaaS landing page be?
Long enough to close the objections that stop this specific audience, and no longer. Seven sections is typical. Length is not the variable; unanswered questions are. A short page that leaves the main objection open converts worse than a long one that closes it.
Should a landing page have navigation?
No full navigation. Keep the logo linking home, and drop the menu. A landing page exists to serve one promise, and navigation is a set of invitations to abandon it. This differs from a homepage, where navigation is the point.
One long page or several short ones?
One page per promise. If you are running three campaigns with three different promises, that is three pages, each narrow. Splitting one promise across several pages adds a step without adding clarity.
Do videos convert better than screenshots?
Not reliably, and they cost more to produce and to load. A short silent loop showing a single interaction is usually the best of both. A video that requires sound, or that takes thirty seconds to reach the point, performs worse than a well-annotated still — and it puts pressure on your Largest Contentful Paint, which Google measures against a 2.5 second threshold at the 75th percentile.
Where should the pricing section go?
After the mechanism and the objection handling, before the final CTA. Early enough that nobody reaches the bottom still wondering, late enough that the number lands on someone who already understands what they would be buying.