Skill detail

landing-page-conversion-audit

Audits landing, sales, or checkout pages for conversion leaks and returns a fix list ranked by expected revenue impact. Relevant to the capture facet of lead generation.

MatchPossibleRecommended for Lead Generation
Sourceautonnel/​autonnel-skillsExternal source
Reported installs83,236Popularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: landing-page-conversion-audit
description: Audit a landing page, sales page or checkout page for conversion leaks and return a fix list ordered by expected revenue impact. Use when asked to review, critique or improve a landing page, sales page, opt-in page, product page or checkout flow, when conversion rate is low, when paid traffic is not converting, or when someone asks "why isn't this page converting" or wants a CRO / landing page review.
---

# Landing Page Conversion Audit

Audit a live page (or a mockup) for the things that actually move conversion rate on paid traffic, and return a ranked fix list. Do not return a generic "add more social proof" list - every finding must name the element, the failure mode, and what to change it to.

## When to use

- "Review my landing page" / "why is my conversion rate so low"
- Paid traffic is running and CPA is above target
- Before scaling ad spend on a page that has never been audited
- A checkout page with a high add-to-cart-to-purchase drop-off

## When not to use

- The page has no traffic yet - there is nothing to diagnose. Use `sales-funnel-blueprint` to design it instead.
- The problem is upstream (wrong audience, wrong offer). A page audit cannot fix a broken offer; say so and stop.

## Procedure

### 1. Gather what you are allowed to conclude from

Ask for, or fetch, in this order. Note explicitly which you did not get, because it caps what you can claim:

| Input | What it unlocks |
|---|---|
| Page URL | Everything below (fetch and read the rendered DOM, not just the HTML source) |
| Traffic source + a sample ad / keyword | Message-match check, the single highest-impact finding |
| Sessions and conversions over the last 14-30 days | Whether the problem is statistically real or noise |
| Funnel step drop-off numbers | Which step to audit at all |
| Device split | Whether to audit mobile-first (usually yes: paid social is 70-90% mobile) |

If you only have the URL, say so in the output and mark every quantitative claim as an estimate.

### 2. Run the checks

Work in this order. It is ordered by how much revenue each typically moves, not by how easy it is to check.

**A. Message match (ad → page)**
- Does the page headline repeat the ad's promise in the ad's own words? A mismatch here caps everything downstream and is the most common single leak on paid traffic.
- Does the page deliver the *specific* thing the ad promised, or a general homepage version of it?
- Is the offer visible without scrolling on a 390x844 viewport?

**B. Above the fold, mobile**
- One clear promise, one clear CTA. Count the competing CTAs - more than one primary action is a leak.
- Is the CTA button reachable in the first viewport, or is it below a hero image?
- Load: is anything meaningful painted before ~2.5s LCP? Slow hero video/images on paid social is a silent 10-30% loss.

**C. Offer clarity**
- Can a stranger answer, in 5 seconds: what is it, who is it for, what does it cost, what happens when I click?
- Price presented, or hidden? Hiding price is only correct for high-ticket / call-booking funnels.
- Risk reversal present (guarantee, trial, "cancel anytime", shipping/returns)?

**D. Friction in the form**
- Count the fields. Every field past the minimum costs conversions. Ask for each: is this needed *now*, or can it be collected after payment?
- Is the checkout on the same page as the offer, or is there an extra click/redirect?
- Are payment methods visible before the user commits? Mobile wallets (Apple Pay / PayPal) present?
- Does the form validate inline, or dump errors on submit?

**E. Trust at the moment of payment**
- Trust elements next to the button, not stranded in the footer: guarantee, secure-payment mark, real reviews with names, return policy.
- Are testimonials specific and attributable, or anonymous filler? Anonymous filler reads as fake and costs more than it earns.

**F. The path after the button**
- Is there a next step (upsell / order bump / thank-you with instr
Read the full source on GitHub (opens external page)
Context

Related work