What should I check when reviewing a landing page?

Start with the headline: can a cold visitor name the offer in five seconds? Then check CTA copy (does it match the intent of each page section?), mobile render at 390px (hero text wrapping, button tap targets, logo overflow), and social proof placement (above the fold for high-intent visitors, or positioned after the pitch for colder traffic). These four areas catch most of what clients flag and most of what hurts conversions.

How do you know if a landing page is good?

A landing page is working when it passes three tests: a cold stranger can name the offer in under five seconds (headline test), every CTA copy is specific enough to belong to this product only, and the mobile render doesn't force scrolling past the hero before the visitor knows what to do. Social proof helps conversion but isn't a substitute for a clear headline and a specific CTA.

How do I review a landing page with a client?

Share an annotated review link rather than the raw staging URL. The client clicks the element they want to flag and pins a note there. This gives you specific, actionable feedback anchored to the page — not 'the blue section' in an email thread. Send two focused questions with the link ('Does the headline make the offer clear?' / 'Would you click the CTA?') to get useful answers instead of 'looks great!'

What is the most common landing page mistake designers miss?

The most common missed issue is a headline that the designer can read clearly but a cold visitor can't place in the right context. After weeks of building the page, you already know what the product does — so the ambiguous headline reads as clear. The five-second test with someone who hasn't seen the page before is the only reliable check. The second most common miss is duplicate CTA copy across the three or four CTAs on the page.

How many rounds of client feedback should a landing page take?

One or two rounds is typical when the client can annotate directly on the page — because element-pinned feedback removes the back-and-forth needed to locate what they meant. Email-based feedback runs longer: each vague comment ('the top section feels off') requires at least one exchange before you know what to fix. Doing a self-review pass before the client sees the page reduces the total rounds.

Can I review a landing page on mobile before launch?

Yes — open DevTools in Chrome and set the viewport to 390px (iPhone 16 width). Look for hero text that wraps too many lines, buttons smaller than 44px, and logo rows that overflow horizontally. For iOS Safari specifically, check that scroll animations don't lock the page. The mobile render is worth checking before every client review, not after, because clients almost always check the page on their phone.

drafty

How to review a landing page before the client sees it

Quick answer

To review a landing page, work through four areas in order: headline and value prop (can a stranger understand the offer in five seconds?), CTA placement and copy, mobile render at 390px width, and social proof. Flag each issue with a pinned note on the live page rather than a screenshot — so you and the client are always looking at the same version.

Step 1

The five-second test on your headline

Paste the URL into a fresh Incognito window and set a timer. If you can't read the headline and name the offer before the timer runs, the copy needs work — not the design. This is the most common thing designers miss when reviewing their own page: they see what they meant, not what a stranger reads. Ask a colleague to do the same test cold. The question is: 'Who is this for and what do they get?' If the answer takes more than one sentence, the headline is doing too much. Rewrite the headline before the client ever sees it — vague headline feedback from a client is harder to action than a page that already passes the test.

Step 2

Check CTA copy and placement

Scroll through the page and mark every CTA. Most designers put one in the hero, one mid-page, and one at the bottom — but the copy often reads identically on all three ('Get started', 'Get started', 'Get started'). Each CTA should match the intent of the section it's in: the hero CTA for someone who arrived already sold; the mid-page CTA for someone who just read your benefits; the bottom CTA for someone who scrolled all the way down still uncertain. A concrete check: cover the logo and ask whether the CTA copy gives away what the product is. If 'Get started' could belong to any SaaS, the copy is too generic. Also check button contrast — landing page CTAs fail accessibility contrast thresholds more often than any other element.

Step 3

Mobile render at 390px (iPhone 16 width)

Open DevTools, set device to 390px width, and scroll the whole page. Look for three specific failure modes: hero text that wraps to five lines (the mobile user sees no offer, just paragraphs), CTA buttons narrower than 44px tap target, and social proof logos that overflow the viewport horizontally. These three issues account for the majority of mobile landing page problems and all three are invisible in a desktop preview. For a Webflow or Framer build, also check that any scroll animations don't freeze the page on iOS Safari — trigger-based animations sometimes lock the scroll position on that browser specifically. Mobile review takes four minutes; it catches things a client will notice on their phone before sign-off.

Step 4

Share a review link for annotated feedback before the call

Once you've done the self-review, don't send the client the staging URL and ask 'what do you think?' Share a link they can annotate directly — they click the headline, the hero image, the CTA button, and pin a note to the exact element. You see each note in a thread anchored to the spot they meant. This changes the client call: instead of 'the bit near the top', you're resolving 'headline comment #2: too long for mobile'. Send the link with two specific prompts: 'Does the headline make the offer clear?' and 'Would you click the CTA — and does the copy match what you'd expect next?' Specific questions get specific answers. One round of annotated feedback typically replaces two rounds of email.

The faster way

If you're reviewing a page you built in Webflow, Framer, or as a Vercel preview — paste the URL into Drafty and share the link with your client before the call. They click the element they mean and pin a note. Every comment lands in one thread, anchored to the exact spot. No account on their end, no re-emailing screenshots. When you push a revised version, the same link shows the update — you don't send a new URL.

Open a live demo

Questions

What should I check when reviewing a landing page?: Start with the headline: can a cold visitor name the offer in five seconds? Then check CTA copy (does it match the intent of each page section?), mobile render at 390px (hero text wrapping, button tap targets, logo overflow), and social proof placement (above the fold for high-intent visitors, or positioned after the pitch for colder traffic). These four areas catch most of what clients flag and most of what hurts conversions.
How do you know if a landing page is good?: A landing page is working when it passes three tests: a cold stranger can name the offer in under five seconds (headline test), every CTA copy is specific enough to belong to this product only, and the mobile render doesn't force scrolling past the hero before the visitor knows what to do. Social proof helps conversion but isn't a substitute for a clear headline and a specific CTA.
How do I review a landing page with a client?: Share an annotated review link rather than the raw staging URL. The client clicks the element they want to flag and pins a note there. This gives you specific, actionable feedback anchored to the page — not 'the blue section' in an email thread. Send two focused questions with the link ('Does the headline make the offer clear?' / 'Would you click the CTA?') to get useful answers instead of 'looks great!'
What is the most common landing page mistake designers miss?: The most common missed issue is a headline that the designer can read clearly but a cold visitor can't place in the right context. After weeks of building the page, you already know what the product does — so the ambiguous headline reads as clear. The five-second test with someone who hasn't seen the page before is the only reliable check. The second most common miss is duplicate CTA copy across the three or four CTAs on the page.
How many rounds of client feedback should a landing page take?: One or two rounds is typical when the client can annotate directly on the page — because element-pinned feedback removes the back-and-forth needed to locate what they meant. Email-based feedback runs longer: each vague comment ('the top section feels off') requires at least one exchange before you know what to fix. Doing a self-review pass before the client sees the page reduces the total rounds.
Can I review a landing page on mobile before launch?: Yes — open DevTools in Chrome and set the viewport to 390px (iPhone 16 width). Look for hero text that wraps too many lines, buttons smaller than 44px, and logo rows that overflow horizontally. For iOS Safari specifically, check that scroll animations don't lock the page. The mobile render is worth checking before every client review, not after, because clients almost always check the page on their phone.

Keep exploring

How to get feedback on a landing page How to annotate a landing page Review a website Design feedback tool

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.

Open a live demo