A landing page audit should start on a phone

A desktop screenshot can make a landing page look finished while its mobile version remains difficult to use. I begin a review at a narrow width because that quickly exposes cramped headings, hidden actions, oversized media, and navigation that interrupts the main task. The goal is to understand what a visitor experiences before recommending a visual treatment.

Start with one question

Can a new visitor understand the offer and find the next action without zooming or hunting through the page? Read the first screen as a visitor would. Identify the audience, the promised result, and the primary action. If any of those are unclear, record the exact wording or layout that caused the confusion. Do not assume the visitor already knows the product category or the vocabulary the team uses internally.

Next, try the primary action yourself. If it opens a form, can you complete it without a mouse? Are the fields labelled clearly? Is there enough context to know what will happen after submission? These checks often reveal friction that a screenshot misses.

Check the layout at several widths

A 375-pixel viewport is a useful starting point, but one screenshot is not enough. Widen and narrow the viewport and look for text that jumps, clipped buttons, cards that become too dense, and horizontal scrolling. Test the menu and forms with a keyboard as well as a pointer. Check the page at both the top and bottom: a footer can become an obstacle if the main action is buried above it.

Look at the visual hierarchy, not just whether elements fit. A mobile page can technically avoid overflow and still make the wrong thing dominant. The first heading, supporting sentence, and action should work as a coherent sequence. If a decorative image crowds out that sequence, moving or reducing the image may help more than shrinking every line of text.

Measure before you recommend a fix

Run Lighthouse to collect performance, accessibility, and SEO signals. Its automated checks are useful leads for investigation, not a complete verdict on design quality. Compare those results with an actual browser visit. A low score does not explain whether the offer is understandable, and a high score does not prove the page converts. Record whether the run used mobile emulation, when it happened, and which page was tested, because the numbers can vary.

When a loading metric looks weak, inspect the cause before proposing a redesign. A large image, blocked font, or third-party script may be responsible. A recommendation should say what is slow, why it matters to the visitor, and which change is likely to help. It should not promise an exact improvement before the new page exists.

Turn findings into a short action list

For each issue, save a screenshot, note the viewport, and explain the user impact. Prioritize changes that affect comprehension and the primary action. A useful audit might recommend rewriting a vague heading, making a form easier to reach, and reducing a heavy hero image. It should never claim a speed gain or conversion lift before that result has been measured.

I keep the list short. Three well-supported problems are more useful than a scorecard full of minor observations. Separate factual findings, such as horizontal overflow, from judgments, such as whether a headline is persuasive. This gives the founder something concrete to assess and gives the redesign a clear purpose.

This is the review method I use before proposing a landing-page redesign: observe the real page, document a small number of clear issues, and make each recommendation traceable to evidence.