Conversion Rate Optimization Checklist: 34 Checks, Each Tied to a Metric

Most conversion rate optimization checklists are redesign briefs in disguise. “Add social proof. Shorten the form. Make the button bigger.” Nothing in them tells you whether the button is the problem on your site, or which number would move if you fixed it. I’ve watched teams ship 30 such changes in a quarter and end up with a conversion rate that looks exactly like last year’s.

This conversion rate optimization checklist is built the other way round. Every item names what to check, which metric or report answers it, what number should worry you, and what to test if it does. Thirty-four checks in seven groups, and none of them says “consider adding” without telling you how you’d know it worked.

It’s written for whoever owns the analytics as much as whoever owns the page — often the same founder or marketer who inherited the Google Analytics property. You’ll spend the first group on your data, and that’s deliberate.

What should a CRO checklist include?

A useful CRO checklist covers the layers where potential customers are won or lost — measurement, landing pages, the conversion funnel, checkout or lead capture, trust, and testing — and attaches a metric to every item. Without the metric, a checklist is a list of opinions. With it, the same list becomes an audit you can repeat each quarter and compare with the last run.

The layers matter because problems don’t spread evenly. Most sites I’ve audited have one or two layers doing real damage and four that are fine; working layer by layer with the data open finds the damaged one in an afternoon.

Each item follows the same pattern: Check (what you’re looking at), Metric (the report or number that answers it), Red flag (where I’d stop and investigate), Test (the experiment worth running). Where a threshold is my rule of thumb rather than a published figure, I say so. Your own baseline beats anyone’s benchmark.

Measurement checks: make the numbers trustworthy first

Every CRO decision downstream inherits whatever is wrong here. I’ve seen a “12% lift” evaporate because half the variant’s traffic was a monitoring bot, and a checkout “problem” vanish once someone noticed the conversion event fired twice on the thank-you page. Nothing below is worth your time until these six pass.

• ☐ One primary conversion is defined and everyone agrees on it. Check: the event you call “the conversion” is a business outcome, not a proxy like a pricing page view. Metric: key events (or goals) marked primary in the last 90 days. Red flag: more than one primary per funnel, or a primary a bot could fire. Test: none yet. Fix the definition with the two-tier model in primary vs secondary conversions, then rerun the baseline.
• ☐ Bot and internal traffic are filtered before you compute any rate. Check: sessions with zero engagement time, data-center networks, your own office IPs. Metric: sessions by hostname and channel, with engagement rate beside them. Red flag: any single source above 5% of sessions at near-zero engagement (my threshold). Test: none — clean it, following bot traffic filtering for clean analytics data, and rerun every rate afterwards.
• ☐ The conversion event fires once, and only on the real outcome. Check: open the confirmation page with DebugView or your tool’s live view; reload; hit back and forward. Metric: conversions per converting session — it should be 1.0. Red flag: 1.2 or higher (my trigger for opening DebugView, not a published standard) means double-firing; below 1 means sessions convert without the event. Test: none; fix the tag.
• ☐ Conversion rate is segmented by device and source before you read it. Check: the blended rate hides a 1.1% mobile rate behind a 3.8% desktop one. Metric: conversion rate by device category, then by default channel group. Red flag: a 2× gap between device rates (mine again; industries vary). Test: treat mobile as its own funnel and run the landing page checks on a phone.
• ☐ You know which attribution model your per-channel rate is built on. Check: channel conversion rates shift between last-click and data-driven models. Metric: the conversion paths report under two models. Red flag: a channel that looks dead in last-click but appears in most assisted paths. Test: none directly, but read why last-click attribution is misleading before you cut a channel on its page conversion rate.
• ☐ A written baseline exists for every KPI you plan to move. Check: date range, segment, definition, and the number, somewhere anyone can find. Metric: the rate itself over at least four full weeks. Red flag: the only baseline lives in someone’s memory or a Slack screenshot. Test: none. This is the prerequisite for the whole testing group.

Landing page CRO checklist

The landing page is where most checklists start, and where most of the advice is generic. These five checks use data you already have — bounce rate by source, scroll depth, field speed data, click maps — so “the headline isn’t working” becomes something you can show before you rewrite it.

• ☐ The headline matches the ad, email, or search result that brought the visitor. Check: your top five landing pages beside the ads and queries sending traffic to them. Metric: bounce rate by source/medium per landing page. Red flag: one source bouncing 20 points worse than the page average — 20 points is my own line, not an industry figure — which usually means message mismatch, not a page problem. Test: a headline that repeats the ad promise word for word. Landing page drop-off covers the other four reasons visitors leave and how to tell them apart.
• ☐ The value proposition is visible without scrolling on a phone. Check: load the page at 390px wide; can you tell what it is and who it’s for in five seconds? Metric: scroll-depth events at 25% and the click map for the first viewport. Red flag: fewer than half of mobile sessions reaching 25% scroll — my cut-off again, so compare it with your own site’s median before you act on it. Test: move the proof point (price, guarantee, key number) into the first screen; compare scroll and click-through.
• ☐ Page speed passes Core Web Vitals at the 75th percentile on mobile. Check: field data, not a lab run. Metric: Google’s thresholds are LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less, at the 75th percentile of page loads. Red flag: any of the three failing on mobile. Test: speed work is rarely A/B-testable; compare conversion rate before and after the fix, same segment.
• ☐ There is one primary call to action per page, and it’s the most-clicked element. Check: count what a visitor is asked to do above the fold. Metric: click-event counts per CTA. Red flag: a nav item, “learn more” link, or social icon out-clicking the primary button. Test: demote the competing element; compare completed conversions, not clicks alone.
• ☐ Click and scroll heatmaps are read with their sample size, not as pictures. Check: how many sessions the map is built from, on which device. Metric: sessions behind the map, split mobile/desktop. Red flag: a “cold” section that simply sits below average scroll depth, or a map built on a few hundred mixed-device sessions. Test: none off a heatmap alone; confirm with event counts. Heatmaps beyond the pretty picture lists the three patterns most teams misread.

Funnel checks between the landing page and the money step

This is the layer teams skip because there’s no obvious page to redesign. It’s also where the largest leaks in the customer journey usually sit. Three checks, all readable from a funnel report and a replay tool.

• ☐ A funnel exists in your analytics tool, with steps that match what users really do. Check: does it cover landing → product or pricing → cart or form → confirmation? Metric: step-to-step completion rate. Red flag: no funnel, or steps defined by URL on a site that runs on modals. Test: none. Build it, then use finding funnel leaks to rank drop-offs by users lost — volume × drop-off rate — rather than by percentage alone.
• ☐ You’ve read the funnel as both open and closed, with elapsed time on. Check: in GA4 funnel exploration, the “make open funnel” toggle lets users enter at any step; a closed funnel requires entry at step one; “show elapsed time” adds the time between steps. Metric: abandonment per step in both modes, plus elapsed time. Red flag: a step that looks healthy open and terrible closed (people arrive mid-funnel from somewhere you aren’t sending them), or a step where time doubles for no good reason. Test: usually a navigation fix rather than a split test.
• ☐ Rage clicks, U-turns, and error loops are watched on the leakiest step only. Check: replays filtered to sessions that reached the worst step and didn’t complete it. Metric: rage-click and dead-click counts on that step; a handful of replays, not a hundred. Red flag: the same element in three of five replays. Test: fix the element. If you’re tempted to keep watching, session replay decoded explains why that’s usually a way of postponing the decision.

E-commerce conversion rate optimization checklist for checkout

Checkout optimization gets its own section because the reasons people abandon a checkout process are unusually well documented. Baymard Institute keeps a running list of 50 cart abandonment studies and puts the average documented abandonment rate at 70.22%; once “just browsing” is removed, the top stated reasons in their US survey are extra costs (40%), slow delivery (20%), not trusting the site with card details (19%), and forced account creation (18%); a checkout that was too long or complicated comes next on 17%, tied with websites that threw errors or crashed. The same page reports an average of 23.48 form elements in US checkouts, against an ideal flow of 12–14. Each check below maps to one of those reasons and to a step in your funnel.

• ☐ Cart abandonment and checkout abandonment are measured separately. Check: people who never start checkout differ from people who start and quit. Metric: begin_checkout ÷ add_to_cart, and purchase ÷ begin_checkout, as two numbers. Red flag: one blended “abandonment rate”. Test: depends on which is worse; checkout abandonment: what your data can tell you walks through the four steps and what each drop-off pattern means.
• ☐ The full cost, including shipping and tax, is visible before the payment step. Check: where shipping cost first appears. Metric: drop-off at the step where it’s revealed. Red flag: the shipping step losing more sessions than the payment step. Test: an estimated shipping line in the cart or a free-shipping threshold bar; read checkout completion and average order value together.
• ☐ Guest checkout is available and visible on the first checkout screen. Check: can a new visitor pay without an account, and is that option as prominent as sign-in? Metric: drop-off at the account step for new users. Red flag: new-user drop-off there far exceeding returning-user drop-off. Test: guest as the default path, with account creation offered on the confirmation page.
• ☐ The visible form elements in checkout have been counted. Check: every field, checkbox, and dropdown shown by default across all steps. Metric: the count, against Baymard’s 12–14 ideal. Red flag: more than 20 without a regulatory reason — Baymard’s 12–14 is the researched ideal, the 20 is where I personally stop counting and start cutting. Test: collapse optional fields (company, address line 2, phone where not needed) behind a link; compare completion.
• ☐ Payment errors are tracked as events, with the decline reason. Check: a failed payment fires an event with a sanitized reason (declined, 3-D Secure failed, invalid card). Metric: error rate per attempt and recovery rate after an error. Red flag: more than 2–3% of attempts erroring (my own bar; decline rates vary a lot by market and product), or no data at all. Test: clearer inline error copy and an alternative payment method surfaced on failure.
• ☐ Mobile checkout has been completed by a human on a real phone this month. Check: keyboard types (numeric for card and ZIP), autofill, error messages visible above the keyboard. Metric: mobile vs desktop completion for sessions that reached payment. Red flag: mobile under two-thirds of desktop at that step — a personal cut-off, not a benchmark. Test: input type and autocomplete fixes first; they’re cheap and usually measurable within two weeks.

Forms and lead capture checklist

If you sell services, software, or anything with a sales call in the middle, the form is your checkout, and form optimization starts with seeing inside it. Standard analytics gives you one number: submissions. These four checks need field-level data, which most tools can collect with a little setup.

• ☐ Form start rate and field-level drop-off are both tracked. Check: focus, blur, error, and submit events per field. Metric: start rate (first-field focus ÷ page views) and drop-off per field. Red flag: a start rate under 40% (a rule of thumb of mine) points at the page, not the form; one field losing a disproportionate share points at that field. Form analytics and what drop-off rates reveal covers the five metrics and the setup. Test: remove or defer the worst field.
• ☐ Validation errors are measured by field, not only counted. Check: which fields throw errors and what the message says. Metric: error events per field divided by field interactions. Red flag: one field producing most of the errors (phone formats and ZIP codes, usually). Test: inline validation on blur with a specific message, instead of a red banner after submit.
• ☐ Every required field has a reason the sales team can state. Check: walk the form with whoever uses the submissions and ask what each field changes. Metric: completion rate by form length across your own forms. Red flag: fields that exist because the CRM template had them. Test: a shorter form; measure qualified leads, not raw submissions, or you’ll optimize for junk.
• ☐ The thank-you state is the conversion event, and only submitting reaches it. Check: can someone land on the thank-you URL from a bookmark or a refresh? Metric: analytics conversions vs CRM records for the same period. Red flag: analytics counting more leads than the CRM received. Test: none — fire the event on successful submission and put the page behind a token or redirect.

Trust and social proof checklist

Trust is the layer everyone agrees matters and nobody measures. You can, though: a trust element either changes behavior at the step where doubt shows up, or it doesn’t. These four checks put each signal next to the drop-off it’s supposed to address.

• ☐ Customer reviews and ratings sit where the buying decision is made, not only on a testimonials page. Check: product and pricing pages, and the cart. Metric: conversion rate of sessions that viewed the reviews block (scroll or click event) vs those that didn’t. Red flag: a busy testimonials page and a product page with no proof on it. Test: the review summary (average, count) next to the price; measure add-to-cart or form start.
• ☐ Security and payment reassurance appear at the payment step itself. Check: accepted card logos and a plain sentence about what happens to card data. Metric: payment-step drop-off for first-time buyers. Red flag: that drop-off exceeding the shipping step’s. Test: reassurance copy directly under the card fields — one of the few places where a small text change tends to be measurable.
• ☐ A real human is findable: address, phone or chat, and who runs the company. Check: footer, about page, and the checkout itself. Metric: traffic to about and contact pages from within the funnel. Red flag: funnel sessions detouring to “about” before they convert — they’re checking you exist. Test: company details and a support line inside the checkout or form page.
• ☐ Urgency and scarcity claims are true and don’t fire on every visit. Check: countdown timers that reset, “only 3 left” on every product. Metric: returning vs new visitor conversion rate on those pages. Red flag: returning visitors converting worse than new ones — they’ve seen the timer reset. Test: remove the manufactured urgency and watch returning-visitor behavior; honest stock counts tend to survive.

A/B testing checklist: hypothesis, sample size, and the decision

Everything above produces candidates. This group decides which ones get tested, how, and when you’re allowed to call a result. It’s the shortest section and the one I’d least like you to skip. The last item covers what to do when you don’t have the traffic for any of it.

• ☐ Every test has a written hypothesis that names the metric and the segment. Check: “Because mobile shipping-step drop-off is 38%, showing shipping cost in the cart will raise mobile checkout completion by at least 10% relative.” Metric: the one named in the hypothesis, nothing else. Red flag: “let’s see what happens” tests, or a success metric chosen after the results came in. Test: that one.
• ☐ Sample size and duration are calculated before launch. Check: baseline conversion rate and minimum detectable effect go into a calculator such as Evan Miller’s, at the conventional 80% power and 5% significance level. Metric: visitors per variation required, divided by daily eligible traffic, rounded up to full weeks. Red flag: the answer is longer than you’re willing to run — then the test is the wrong size, not the calculator. Conversion rate confidence shows why the same 14% lift means nothing at 500 visitors per variation, is still borderline at 10,000, and only becomes statistically significant at around 20,000.
• ☐ Tests run for whole weeks and nobody calls a winner early. Check: the test calendar and who has dashboard access. Metric: days run vs days planned. Red flag: a test stopped on day four because the green bar was up. Test: the discipline, not the page.
• ☐ Guardrail metrics are defined and reported next to the result. Check: revenue per visitor, average order value, refund rate, lead quality — whatever could get worse while the primary metric gets better. Metric: the guardrails themselves. Red flag: conversion rate up, revenue per visitor flat or down. Test: ship only if the guardrails hold.
• ☐ Results are logged, including the flat and negative ones. Check: a test log with hypothesis, dates, sample, result, decision. Metric: the share of tests that moved the primary metric at all. Red flag: a log that only contains wins. Test: none; this is how next quarter’s checklist gets better than this one.
• ☐ Low-traffic pages get before/after measurement and fixes, not split tests. Check: daily conversions on the page. Metric: if the sample-size calculation says months, stop calculating. Red flag: “A/B tests” run on 30 conversions a month with a declared winner. Test: fix what’s broken, slow, or confusing; compare four weeks before and after on the same segment; accept the evidence is weaker than a controlled test.

Where do you start with CRO on a low-traffic site?

Start with the measurement group and the funnel report, then fix what is clearly broken rather than merely suboptimal. With a few hundred conversions a month you can’t resolve a 10% difference between two designs, but you can find the step where 60% of mobile users leave and watch what they do there.

The order I use with smaller clients: clean the data (items 1–6), build the funnel (item 12), pick the worst step by lost conversions, and run the checks for that layer only. Lean on qualitative data here — replays, field-level form events, a five-second test with real people — because it gives signal from tens of sessions where quantitative data needs thousands. Make the fix, compare four weeks before and after on the same segment, and write it down as an observation, not a test. What I wouldn’t do is run the trust and copy items first; on low traffic they produce the most opinions per unit of evidence.

How do you know whether a change worked?

A change worked if the metric you named in advance moved by at least the amount you said mattered, in the segment you specified, over a sample large enough that chance is an unlikely explanation — and the guardrails didn’t move the other way. If you can’t fill in every clause of that sentence before a test starts, you won’t be able to answer the question after it ends.

Two failure modes account for most false wins I’ve been asked to review: peeking (looking daily and stopping on the first good day) and the silent segment switch (the hypothesis was about mobile, the win was reported on all traffic). The testing group above prevents both; a better tool fixes neither.

Which metrics matter most for CRO?

One primary conversion rate per funnel, segmented by device and source, plus the step-to-step rates inside the funnel. Everything else on this list is a diagnostic: it tells you why a step is losing people, not whether. Here are the key metrics by layer — what I’d pull first with ten minutes.

Notice what isn’t in the table: bounce rate on its own, session duration, pages per session. They’re fine as context; as CRO metrics they mostly generate meetings.

How often should you run the checklist?

Run the full list quarterly, the measurement group monthly, and the layer you’re testing whenever a test concludes. Tracking breaks quietly — a theme update, a new consent banner, a tag change nobody mentioned — so the six measurement checks are cheap insurance. The rest only needs to move when the site, the user experience, or the traffic mix has changed.

A quarterly pass with the previous run’s numbers beside it is worth more than a one-off CRO audit checklist from an agency. The audit gives you recommendations; the repeated checklist gives you a trend, and the trend tells you which recommendations worked.

Frequently asked questions

What’s the difference between a CRO audit checklist and a CRO checklist?

Mostly timing. A CRO audit is the first pass, often by someone outside the team, and produces a long list of findings. The checklist above is the same set of checks made repeatable, with the metric for each item written down so later passes can be compared with the first. If you commission an audit, ask for the metric behind each finding; if there isn’t one, it’s an opinion.

Does this conversion optimization checklist work for SaaS and lead gen?

Yes. Swap the checkout group for the forms group, treat “trial started” or “demo booked” as the primary conversion, and use activation or qualified-lead rate as the guardrail. The other groups apply unchanged.

Which tools do I need to run it?

An analytics tool with events and a funnel report (Google Analytics 4, Matomo, PostHog, Plausible with goals, Umami — any of them), a way to see field-level form events, and something for click maps or replays if you want the diagnostic items. A test log can be a spreadsheet. You don’t need a dedicated CRO platform; you need a conversion event that fires once and a funnel you believe.

How many items should I fix at once?

One per funnel step if you’re testing, because simultaneous changes on the same step make the result unreadable. Several at once is fine for clearly broken things — double-firing events, payment errors, a form that fails on iOS — since those aren’t experiments. Fix the broken in a batch, then test the debatable one at a time.

If you’re about to run this for the first time, print the measurement group, open your analytics tool, and don’t read past item six until all six pass. The rest of the checklist will still be here, and it’ll be telling you the truth by the time you reach it.