Manual Website Conversion Audit: Find Where Leads Drop Off
A conversion rate tells you that a defined action happened. It does not tell you why a person stopped. This audit combines funnel evidence with direct page replays so the repair queue is based on observable friction, not a generic “best practices” list.
Audit one audience, one source, one landing page, one action and one device class at a time. If you mix paths, the denominator and evidence stop meaning the same thing.
Define the path before inspecting the page
Copy this header into a blank document and fill it before opening analytics or testing the page. Keeping one audience, action and device together makes every later observation comparable.
Audience and source:
Landing URL:
Primary action:
Start event:
Completion event:
Review window and timezone:
Included device/browser:
Known exclusions (staff, bots, tests, duplicates):
Evidence owner:
Google Analytics describes funnel exploration as analysis of user steps and where they succeed or fail. Use it to locate a step worth inspecting; do not treat abandonment alone as proof of a design defect. Review the documentation.
Capture the stage inventory
| Stage | Question | Evidence | Status |
|---|---|---|---|
| Arrival | Does the page match the promise, language and audience of its source? | Source message and first viewport | Pass/fail/unknown |
| Comprehension | Can a reader explain the offer, boundary and next step? | Page copy and observed replay | Pass/fail/unknown |
| Trust | Are material claims, price basis, privacy and contact routes inspectable? | Exact copy and linked policy/source | Pass/fail/unknown |
| Interaction | Does the page load, respond and remain visually stable on the included device? | Field test and page replay | Pass/fail/unknown |
| Form/chat | Are labels, required fields, errors and recovery clear? | Keyboard/mobile replay and error states | Pass/fail/unknown |
| Completion | Does one action create one visible confirmation and useful next step? | Event, confirmation and record ID | Pass/fail/unknown |
| Measurement | Do start and completion events share the intended population? | Event specification and exclusions | Pass/fail/unknown |
Google's Web Vitals provide user-centered loading, responsiveness and visual-stability measures; its form course covers labels, field purpose, validation and accessibility. These are diagnostic inputs, not conversion guarantees. See Web Vitals and Learn Forms.
Reproduce friction in five passes
- Message pass: compare the source promise with the title, opening, proof and action.
- First-use pass: load the declared device/network condition without an existing session.
- Form pass: use keyboard and mobile input; test empty, invalid and corrected values.
- Completion pass: submit one labeled test and trace confirmation plus downstream record.
- Recovery pass: test back, refresh, retry, duplicate submission and a temporary failure.
Record what happened, not what the reviewer expected. Delete test records under the team's data policy.
Prioritize without forecasting uplift
Score only reproduced findings:
Repair priority = User blockage (1–3) × Path exposure (1–3) × Evidence strength (1–3)
- User blockage:
1friction,2prevents some completions,3prevents completion or creates a material trust/data risk. - Path exposure:
1rare branch,2common segment,3default path. - Evidence strength:
1one observation,2repeated observation,3replay plus matching event/record evidence.
Scores range from 1 to 27. Before scoring, the team records its own action thresholds, required evidence and approver. The method provides no universal repair bands and does not estimate conversion points or revenue.
Completed fictional audit
Northstar predeclares fictional gates: 18–27 repair now, 8–17 next experiment, 1–7 evidence queue. These are not defaults.
Audience/source: Vietnam paid-search visitors
Landing URL: /pricing-guide
Primary action: Consultation form
Start/completion: Eligible landing view / visible confirmation plus one matching record
Window/timezone: 2026-08-09 to 2026-08-15 ICT
Device/browser: Mobile 390px, current Chrome and Safari
Exclusions: Staff, bots, labeled tests and duplicate records
Evidence owner: Web analytics owner
Arrival=fail (pricing-guide promise vs generic demo)
Comprehension=pass (offer and next step replayed)
Trust=pass (claims, privacy and contact inspected)
Interaction=pass (declared device metrics/replays)
Form/chat=fail (error summary focus)
Completion=fail (no response expectation/help route)
Measurement=pass (start/end population and exclusions match)
| Finding | B×E×S | Score | Northstar queue |
|---|---|---|---|
| Error summary is off-screen and focus does not move | 2×3×3 | 18 | Repair now |
| Source promises “pricing guide” but page opens with a generic demo | 2×2×2 | 8 | Next experiment |
| Confirmation has no response expectation or help route | 1×3×3 | 9 | Next experiment |
Evidence and completion checks: the error uses four keyboard/mobile replays and must move focus to an announced summary while preserving values; message match uses two campaigns and must align source/landing promise; confirmation uses three matching records and must state a verified next step plus monitored help route.
Recalculation: 2 × 3 × 3 = 18; 2 × 2 × 2 = 8; 1 × 3 × 3 = 9. Accessibility/error recovery is repaired first. The 9-point confirmation issue precedes the 8-point message experiment. No uplift value is attached.
Sensitivity and invalid states
If the error occurs only in a rare browser, exposure may fall from 3 to 1 and the score from 18 to 6; the team should still fix a known accessibility block but can plan it with the verified scope. Do not calculate when the start/completion events changed during the window, test traffic cannot be excluded, or the observation cannot be reproduced. Repair tracking first.
Repair record
Finding and evidence:
Affected path/segment:
Priority calculation:
Change hypothesis:
Owner and due date:
Primary success measure:
Guardrail (errors, quality, privacy, downstream acceptance):
Check that proves the repair is complete:
Rollback condition:
Decision after review window:
One page change can improve completion while reducing lead quality or breaking the downstream record. Always include a guardrail and verify the entire test record.
Completed record for the first finding:
Finding/evidence: Error summary focus; four mobile/keyboard replays
Affected path: Consultation form on mobile
Priority: 2 × 3 × 3 = 18; Northstar repair-now gate
Hypothesis: Move focus and announce summary while preserving values
Owner/due: Frontend accessibility owner / 2026-08-18
Success: The declared invalid-submit check passes
Guardrail: No increase in duplicate/error events; downstream record remains intact
Rollback: Focus loop or value loss appears
Decision: Pending retest; finding remains open
Frequently asked questions
These questions clarify what funnel data, page measurements and a successful repair can prove.
Is every funnel exit a defect? No. Some visitors are ineligible or choose not to continue. Investigate only against a declared audience and action.
Does a performance metric explain the cause? No. It locates an experience condition; replay and event evidence are still needed.
Does a passed repair prove higher conversion? No. It proves the completion check, not causal uplift.
Next steps, method, and limits
Continue beyond the page when needed. If the on-page action succeeds but qualification, routing or follow-up fails, continue with the full AI sales journey audit. Use the conversion-rate definition to keep numerator, denominator and window consistent.
Method and limits. This page stores no input and supplies no benchmark defaults. Findings require first-party evidence from the audited path. The score is a transparent triage aid, not causal proof, an A/B test result, an accessibility certification, a compliance review, or a forecast.