What is a landing page, and how do you design one?

In short

Wikipedia defines a landing page as a single web page that appears in response to clicking a search result, a marketing email or an online ad. Its general aim is to turn the visitor into a sale or a lead.

The same source names two kinds: reference and transactional. A reference page presents information for the visitor with text, images or links. A transactional page tries to persuade the visitor to complete a transaction, and does it with a form.

The difference from the home page is the goal. The home page welcomes all kinds of visitors and sends them to different places. The landing page tells an audience from one particular campaign one thing.

The mistake I see most often in landing page audits: the page talks about the company and doesn't answer the visitor's question. The headline says “Who we are”, but the visitor is asking “Does this solve my problem?”.

When to use one

Use a landing page whenever you bring visitors in with a specific promise. According to Wikipedia, the sales copy on the page is usually a logical continuation of the ad, search result or link that was clicked.

• Ad campaigns. According to the Google Ads help page, landing page experience is one of the components of Quality Score. Google describes it as a measure of how relevant and useful the page is to someone who clicks the ad.
• Launching a single product or offer. A new package, sign-up for an event or a waitlist.
• Email and social media campaigns. Whoever taps the link should see on the first screen what they read in the message.

In these cases a landing page isn't the right tool:

• When visitors are looking for very different things. A home page or a category page welcomes them better.
• When the offer isn't clear yet. Draw a wireframe first and show it to a few people, then build the page.
• When the same offer goes to very different audiences. Then I consider one page per audience, because each audience has a different first question.

The anatomy, section by section

A good landing page answers the visitor's questions in order from top to bottom. What is this, does it suit me, is it real, what does it cost, what do I do now? The outline below spreads those questions across sections.

Clickable anatomy

1. 1Header bar
2. 2Hero: headline and button
3. 3Proof of trust
4. 4How it works
5. 5Concrete example
6. 6Price and terms
7. 7FAQ and final call

1. Header bar

Job: Says whose page this is. The visitor looks at the logo and knows they're in the right place.

Do

Put the logo top left. Next to it, at most one link or the same button as on the page.

Don’t

Don't bring the site's whole menu here. Every menu link is a way to leave the page without reading the offer.

2. Hero: headline and button

Job: Says on the first screen what you offer and for whom. This is usually where the visitor decides whether to stay.

Do

Write a short headline that explains to a new visitor what you do. Under it, one explaining sentence, and under that a single button that names the action.

Don’t

Don't write a headline that says nothing, such as “Welcome” or “Building the future together”. The button text isn't “Get started”.

3. Proof of trust

Job: Answers the question “Is this real?”. A visitor who doesn't know you will ask it for sure.

Do

Use real client logos and quotes with permission and names. If you write a number, give its source too.

Don’t

No made-up reviews and no “happy customers” from stock photos. No percentage without a source either.

4. How it works

Job: Explains what happens after the click. The less uncertainty, the easier the next step.

Do

Describe the work step by step from the user's point of view. After each step, say what the user has in hand.

Don’t

Don't list features by the team's internal names. “Smart sync module” means nothing to a visitor.

5. Concrete example

Job: Makes the abstract promise visible. The visitor sees with their own eyes what they get.

Do

Show the real product screen, a sample report or a sample result.

Don’t

Don't use a stock image that has nothing to do with the product and is only decoration.

6. Price and terms

Job: Gives the information for the decision: what it costs and what's included.

Do

Write the price and what's included clearly. If there's a delivery time or an important condition, it goes in the same place.

Don’t

Don't hide the price behind a form or in the small print at the bottom of the page.

7. FAQ and final call

Job: Answers the open questions and offers the same action once more. Whoever reads to the end decides here.

Do

Write the questions people really ask before buying. The last button has the same text as the one in the hero.

Don’t

Don't open a completely new offer at the bottom of the page. A second goal splits the strength of the first.

An outline of a landing page with seven sections. Press a section and its job and do's and don'ts appear under the outline. With JavaScript off, all notes are listed one after another.

The number of sections changes with the offer. For a cheap, familiar product, hero, price and button may be enough. For an expensive or new service, trust and example get longer, because the visitor has more questions.

The order hardly changes, though. A visitor doesn't look at proof of trust before understanding what it is, or at the price before seeing what they get.

Do's and don'ts

Most of the points below come from Nielsen Norman Group (NN/g) studies on home pages and button text. On a landing page these principles matter even more, because the page's only job is to lead the visitor to one action.

On the “Get Started” button there is a 2017 NN/g study. Aurora Harley and Kim Flaherty write that the button gets clicks but misleads. Users in the study wanted to find out what the company does. After the click they found themselves in a trial or a sign-up window.

Huei-Hsin Wang's 2024 NN/g article also gives a short warning about visual hierarchy: if everything is emphasised, nothing stands out. On a landing page that means one main button. How much a single button can change the result is told in the story of the $300 million button.

The difference between mobile and desktop

The outline is the same on both screens. What changes is whether sections sit side by side or stacked. On desktop the hero has two columns: headline and button on the left, the product image on the right. On a phone the image moves under the text.

On a phone the first screen is very short. Headline, explaining sentence and button have to fit into that short space. Put a big image above the headline and the button drops off the first screen.

Criterion 1.4.10 (AA) in the W3C's WCAG 2.2 helps here. Content has to be readable at 320 CSS pixels wide without scrolling in two directions. That means no horizontal scrolling on the phone.

Tap targets matter on mobile too. Criterion 2.5.8 (AA) in WCAG 2.2 requires pointer targets of at least 24 × 24 CSS pixels. If the target is smaller, enough spacing around it also meets the criterion. I keep the main button well above that, almost as wide as the screen.

The hero image is often the heaviest part of the page on a phone. One of the values looked at when measuring speed is LCP, the time until the largest content on the page is on screen.

In a lab test described on web.dev, a WordPress demo site was measured with mobile emulation. When lazy loading was turned off, the median LCP of the archive page dropped from 1,657 ms to 1,403 ms.

On desktop there's a different trap: information that opens on hover. A phone has no mouse pointer. A page where the price or terms are visible only with the pointer never shows that information to mobile visitors.

A note on accessibility

Landing pages most often fail on moving content and button labels. These four criteria I always check.

• Scrolling logo strip and sliders (2.2.2, level A). Motion that starts on its own, lasts more than five seconds and is shown next to other content must let the user pause, stop or hide it.
• Button name (2.5.3, level A). The name the screen reader gives the button must include the visible text. If someone using voice control says “See pricing”, the button has to work.
• Reflow (1.4.10, level AA). Vertically scrolling content doesn't require scrolling in two directions at 320 CSS pixels wide.
• Target size (2.5.8, level AA). Buttons and links are at least 24 × 24 CSS pixels, or separated by enough spacing.

The typical 2.5.3 mistake: design writes “Start” as the visible text, development sets “Open sign-up form” with aria-label. The W3C notes that the value of aria-label overrides the visible text in the accessible name. If there is a visible label, avoid aria-label or use it carefully. The cleanest fix is to write the visible text itself clearly.

Don't skip the keyboard round either. Put the mouse away: can you reach the main button with Tab, and can you see the focus? I make this check on every page in the UX Audit.

A note on implementation

Below is a plain HTML and CSS version of the hero section. One column on phones, two from 900 pixels.

<!-- Headline, explanation and one button. -->
<section class="hero">
  <div class="hero__text">
    <h1>See every rent payment on one screen</h1>
    <p>Monthly payment overview for landlords</p>
    <!-- The button says where it goes. -->
    <a class="btn" href="#pricing">See pricing</a>
  </div>
  <!-- The image on the first screen is not lazy-loaded. -->
  <img src="payments.webp" width="640" height="480"
       alt="List of monthly rent payments in the app"
       fetchpriority="high">
</section>

/* One column on phones. */
.hero { display: grid; gap: 24px; padding-inline: 16px; }
.hero img { width: 100%; height: auto; }
/* Two columns from 900 px. */
@media (min-width: 900px) {
  .hero { grid-template-columns: 1fr 1fr; align-items: center; }
}

The first decision is about the image. It has no loading="lazy", because lazy-loading the image on the first screen slows LCP, according to web.dev. Instead it has fetchpriority="high".

According to the web.dev article on Fetch Priority, images normally start with low priority. The attribute hints to the browser to load the image at high priority from the start. In the Google Flights test in the same article, LCP dropped from 2.6 to 1.9 seconds.

The image's width and height are set, so the browser reserves the space before the image arrives. The button text says where it goes too. When I turn the design into code, I do it in the Design & Ship Sprint.

Checklist

Before the page goes live I go through this list. If an item isn't ticked, the page doesn't go live.

• The page has a single purpose, and I can write it in one sentence.
• The headline explains what you do to someone who doesn't know you.
• The promise from the ad or email is also on the first screen.
• There is a single main button, and its text says where it goes.
• Price and important terms are easy to find.
• The images show the real product or a real result.
• The menu is cut down, and links that lead off the page are reduced.
• No unnecessary pop-ups and no videos that start on their own.
• The hero image isn't lazy-loaded, and its dimensions are set.
• At 320 pixels wide there's no horizontal scrolling.
• Moving content can be paused.
• The main button can be reached with the keyboard, and the focus is visible.