Landing page audit: a founder's checklist

Audit one page for one audience and one intended action. Record where visitors come from, what that source promises, and what a qualified visitor should do next. A page built for a demo request needs a different next step from a page offering a downloadable checklist. Do not judge both by the same conversion event.

Treat unclear messaging as the first failure to rule out. If visitors cannot identify what you sell, who it is for, and why it matters, faster delivery or a brighter button will not explain the offer. This guide prioritizes that diagnosis; it does not claim a measured ranking of failures across all startup landing pages.

Gather evidence before making changes. Open the page on a real phone, follow the call to action, record relevant speed measurements, and ask people who fit the audience to explain the offer without coaching. Keep a distinction between your own reading, a buyer's response, and measured behavior. A checklist can organize judgment, but it cannot manufacture customer evidence.

Read the headline without the navigation or supporting paragraph. Can a relevant buyer identify the offer or useful outcome? Does it connect to the promise in the ad, email, or search result that brought them here? Replace unexplained abstractions with customer language. Avoid adding a longer list of features.

Ask a target reader what the company does and who it serves. Record their answer before revealing yours. A short line is not automatically clear, and a clever phrase can depend on context the visitor does not have. Keep the headline specific enough to orient the reader and use supporting copy to explain mechanism and boundaries.

Follow the headline with a recognizable problem, the change your approach enables, and the reason it works for this audience. Connect a product capability to a changed workflow. Do not assume that AI, automation, or a dashboard is itself a customer benefit.

Compare the page with the buyer's current alternative, including a spreadsheet, a manual process, or doing nothing. Explain the relevant difference accurately. Mark planned capabilities and untested outcomes as such, and remove claims the product cannot support today. If the team cannot agree on audience or alternative, resolve positioning before polishing the page.

List every claim that asks the visitor to believe something important. Look for evidence near it: a product demonstration, an approved quote with context, or a measured result with a defined baseline and time period. Explain what the evidence shows and avoid implying a wider result than it supports.

A decorative logo row is not a substitute for explaining the relationship or outcome. Only publish names, quotes, or marks you have permission to use. Before you have customer results, demonstrate actual product behavior and be explicit about what remains unproven. Do not invent testimonials, numerical improvements, or recognizable customers to make the page look established.

Name the action and set an accurate expectation. Request a demo, start a free review, and download a template are different commitments. Use a label that matches the destination, and explain what follows where uncertainty could stop a qualified visitor. Avoid competing primary actions with equal visual emphasis.

Complete the entire user flow. Do not inspect the button alone. Check the destination, required fields, validation errors, confirmation, and keyboard access. Ask only for information necessary at this stage. Verify any promised follow-up before describing it on the page; a confirmation screen is not evidence that an email was delivered.

Measure the page rather than judging it from a fast laptop. Use a mobile lab test to diagnose resource costs and field data where available to understand actual visits. Check Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Lab scores and field behavior answer different questions; one good local run is not a production performance guarantee.

Aim for the Core Web Vitals good thresholds in field data: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile. If there is not enough field data, say so. Inspect large images, blocking scripts, fonts, layout shifts, and third-party embeds before choosing a fix.

Use appropriately sized compressed images, explicit dimensions, and deferred below-fold media. Keep the first meaningful content visible without waiting for entrance effects. Do not lazy-load the main above-the-fold image merely to reduce a test's request count. Recheck the real page after each change, including the CTA, forms, and consent controls.

Inspect narrow phone widths and a real device. The headline should wrap naturally, proof should remain readable, and the primary action should appear early enough to be found. Look for horizontal page overflow, overlapping text, tiny controls, and sticky banners that hide the offer or form.

Test the form with the on-screen keyboard open. Check field labels, input types, errors, and the final confirmation. Use generous touch targets, visible focus, sufficient contrast, and a logical reading order. Confirm that keyboard navigation works and that reduced-motion preferences are respected. A desktop layout shrunk to fit is not evidence of a usable mobile experience.