Landing Page Audits: Find the Friction Between an Ad Promise and an Enquiry

A landing page audit checklist should help you decide what to fix, what to investigate and what to leave alone. Start with the promise that brought someone to the page, follow the route to an enquiry, and record evidence at each point. A useful finding names the condition observed, the consequence, an owner and a test that can establish whether the problem has been resolved.

The output is an accountable work list, not a percentage score for how persuasive a page looks. A broken enquiry route, an unsupported claim and a suspected wording problem need different responses. None automatically establishes how many customers a business has lost, or how much a proposed change will improve conversion.

This guide is for marketing leads, business owners and website teams reviewing a specific campaign destination. It includes a fictional audit and reusable CSV and JSON worksheets. The examples are invented teaching scenarios. They are not Canada Create client results, live user observations or measurements from a functioning website.

Define the decision before reviewing the design

Begin with one sentence: “We are reviewing this page for this visitor, arriving through this promise, trying to take this next step.” That sentence prevents the audit from becoming a general website redesign. A visitor comparing office cleaning providers needs different information from an existing customer trying to reschedule a visit, even if both people land on the same URL.

Write down the exact destination, the language, the campaign or referring page, the intended service area and the action that counts as an enquiry. Include the version of the page and the date examined. If multiple advertisements send people to one destination, identify the offer variants that matter. You do not need a separate audit for every punctuation change; you do need to notice different prices, eligibility conditions or promised outcomes.

Agree where the review ends. For a request form, the useful boundary usually includes the confirmation and evidence that the request reached the intended intake destination. For a booking link, distinguish a request for availability from a reserved appointment. For a telephone link, distinguish opening a dialler from a connected call. These boundaries determine what evidence is needed later.

The broader discipline is explained in Canada Create’s introduction to conversion rate optimisation. Here, the narrower job is to diagnose one journey and prepare decisions. Campaign economics belong in the PPC ROI guide; they should not be inferred from how a landing page looks.

Before anyone submits a test, identify a safe test destination and tell the intake owner how test records will be labelled. Use invented details. Establish whether a submission sends emails, creates appointments or triggers follow-up. A review can inspect a public page without permission to manufacture operational records in somebody else’s system.

Separate observations, hypotheses and unanswered questions

An observation describes something another reviewer could inspect or reproduce. “The confirmation says the appointment is booked” is an observation when the wording has been captured. “Visitors are disappointed because they expected a booking” is a hypothesis until suitable evidence supports that interpretation. Keep those statements in separate worksheet fields.

A strong evidence reference includes the location, capture date, page version, device or viewport, interaction steps and result. A screenshot can establish what was visible at one moment. It cannot establish whether a request was delivered or what a visitor believed. A server record can establish that a request was accepted at a particular stage. It cannot, by itself, establish that sales followed up.

Use four review states: finding, pass, not tested and not applicable. A pass belongs to a defined check under recorded conditions. “Telephone link opens the expected number in the tested mobile dialler” is bounded. “Phone conversion works” is too broad. If you cannot examine the destination or lack the evidence to decide, use not tested and describe what would complete the check.

Keep source credibility beside each evidence reference. Ask who produced it, whether it directly supports the observation, whether it is current and whether another source confirms it. A marketing manager’s recollection of the offer is useful context; the approved current offer record is stronger evidence of what the business actually sells. A browser console warning is a clue, not proof that visitors cannot enquire.

Contradictory evidence is valuable. If a page capture shows one fee and the approved offer shows another, retain both references and ask the offer owner to resolve the discrepancy. Do not quietly choose the document that makes the proposed redesign easier to justify. If evidence has expired or refers to an older version, keep the historical record but label its limits.

Use short, neutral findings. “At the recorded viewport, the fixed banner covers the submit control” is actionable. “Terrible mobile UX” mixes judgement with an unspecified problem. Neutral language also helps teams disagree productively: they can dispute the reproduction steps, the consequence or the proposed solution without arguing over taste.

Use the checklist to gather evidence

Work through the journey in the order a prospective customer encounters it. The checklist below is a collection plan. It does not imply that every page needs a testimonial carousel, a shorter form, a larger headline or any other predetermined design treatment.

Record good outcomes as well as problems. A correctly labelled request confirmation provides a baseline that should survive later edits. Marking a check as not applicable also needs a reason: “No appointment booking is offered on this page” is useful; an empty cell is ambiguous.

Keep the first review narrow enough to finish. If one page contains several routes, complete a primary route and list the remaining coverage explicitly. A short audit with visible limitations is more useful than a long checklist whose green cells hide assumptions.

Check the offer from arrival to confirmation

Compare the source promise with the first meaningful page content, the action label, the form introduction and the confirmation. Focus on material commitments: what is available, for whom, where, at what cost and subject to which conditions. Matching a headline word for word does not resolve a contradictory offer.

For example, an advertisement might offer a free site assessment while the page asks visitors to purchase a maintenance plan. The audit should capture the contradiction and identify who owns the offer. It should not start rewriting all campaign messages before anyone confirms whether the assessment is still available.

Google’s landing-page guidance recommends alignment between advertisements and destinations, accessible next steps, mobile usability and useful original content. Use that guidance as context for the review. It is not evidence that a particular change will produce a specified conversion lift.

Check the details a real enquiry depends on. Are prices clearly identified as Canadian dollars where a visitor could reasonably be unsure? Are recurring charges distinguished from one-time charges? Does “Toronto” describe the actual service area, an office location or an illustrative example? If appointments depend on availability, does the page say so before someone acts?

Where the page has several versions, compare the relevant variation rather than assuming the desktop English capture represents every visitor. A translated offer, a campaign-specific parameter or a returning-visitor state can change what appears. Record the actual version examined; leave the others as coverage gaps until reviewed.

A practical audit recommendation may be as small as “Resolve the conflicting assessment terms and carry the approved wording into the confirmation.” A full message-trace exercise across queries, advertisements and page variants is a separate copy and campaign task. This audit establishes why that work is necessary and what evidence its owner needs.

Check whether the page earns the trust it asks for

List claims that could materially affect the decision to enquire. Examples include professional qualifications, service coverage, response times, named partnerships, customer counts, guarantees and claimed outcomes. For each, record a supporting source and the limits of what it establishes. A badge image without a verifiable basis remains an unanswered question.

Assess relevance as well as authenticity. A genuine review of a different service may be weak evidence for the offer on this page. A case example from several years ago may need context if the product or delivery process has changed. A customer quote can describe that customer’s experience without promising that every future customer will receive the same result.

Do not convert “support was not supplied to the reviewer” into “the claim is false.” The finding is an evidence gap. Give the owner a specific action: supply the supporting record, qualify the wording to the supported scope, or remove the claim pending verification. If the owner confirms the statement is wrong, record that separately as a confirmed issue.

Review the business identity and next-step explanation together. A visitor should be able to understand who will receive the request and what happens afterwards. A page can look polished while leaving those practical questions unanswered. Conversely, a modest design can explain the offer and process clearly.

For public audit reports, use sanitised descriptions and references that the audience is allowed to see. Customer messages, raw form submissions and internal approval documents can contain information that does not belong in an exported worksheet. Keep sensitive evidence in its approved location and describe only the part needed to make the decision.

Inspect mobile and accessibility conditions that change the journey

Start with actual tasks: read the offer, find the conditions, reach the action, correct a mistake and understand the outcome. Inspect them on a relevant phone and with a keyboard on desktop. Record the device and browser details. A resized desktop window is useful for layout checks, but it does not reproduce every mobile keyboard, browser or assistive-technology interaction.

Include the page states that alter the layout: consent notices, chat panels, sticky calls to action, validation messages and an open on-screen keyboard. A control visible on initial load may become unreachable later. Do not stop at a screenshot of the top of the page.

For vertically scrolling content, WCAG 2.2’s Reflow criterion addresses presentation at a width equivalent to 320 CSS pixels without lost information or functionality and without two-dimensional scrolling, with exceptions for content that requires a two-dimensional layout. Record the viewport and affected component rather than writing only “fails mobile.”

Follow the keyboard focus through the journey. Check that you can locate it and reach the controls without becoming trapped. Under Focus Not Obscured (Minimum), a focused component must not be entirely hidden by author-created content. A fixed promotional banner covering the focused submit control is a specific issue to document. Check the criterion’s notes for user-movable content and user-opened overlays, including whether the component can be revealed without advancing focus, before assigning a conformance failure.

Inspect small adjacent controls as well. The WCAG 2.2 Target Size (Minimum) criterion uses 24 by 24 CSS pixels, subject to exceptions including spacing, equivalent controls, inline links, user-agent controls and essential presentation. Do not declare every small link a failure without considering the criterion and its exceptions.

Review labels, heading order, text alternatives and contrast as part of the scoped check, using suitable tools and qualified judgement. Keep the standard reference separate from the observed behaviour. An automated warning requires examination; a clean automated report does not establish that every person can complete the task.

W3C’s Easy Checks explicitly describes preliminary checks as limited. This landing-page audit is likewise not a complete accessibility conformance assessment or a determination of legal compliance. Assign unresolved accessibility questions to a suitably qualified reviewer and retain the exact affected paths.

Prioritise the consequence for the person using the page, even when the affected group is not large in a marketing report. A journey that excludes someone should not receive a low severity merely because their interaction is difficult to count. Record the barrier and the scope of what has actually been established.

Follow both the successful and unsuccessful enquiry routes

Run a controlled successful enquiry only when the relevant people and systems are ready for the test. Trace the visible confirmation, the receiving system and the assigned destination. Give the test a recognisable identifier so the team can distinguish it from a genuine opportunity and remove or exclude it through its normal process.

Then inspect a small set of meaningful failure states: a required field omitted, an invalid format, a declined or unavailable booking, and a simulated service failure in a safe environment. Check what remains on the page, whether useful entries survive and whether the visitor can recover without guessing.

WCAG’s Error Identification criterion requires automatically detected input errors to identify the affected item and describe the error in text. A coloured outline by itself is not sufficient evidence of a useful explanation. Capture the actual message and its relation to the affected control.

Distinguish an input problem from a delivery problem. If the browser rejects an incomplete field, that is different from the server accepting the request and an integration failing afterwards. These states may need different owners. “The form is broken” makes it difficult to decide whether the work belongs to content, development, the integration provider or intake operations.

Also check repeated actions. What happens when someone presses the button twice, refreshes a confirmation or returns with the back button? The audit question is whether the interface and recorded outcome remain truthful. Any implementation for preventing duplicate submissions needs to be assessed against the actual system; do not assume an analytics setting fixes duplicate business records.

This is a diagnostic pass, not a complete form redesign. Record field-purpose concerns and recovery failures, then hand detailed field choices and implementation to the form owner. For wording examples, Canada Create’s CTA guide covers action language. The audit should identify the misleading or inaccessible action and its acceptance condition before selecting replacement copy.

Interpret performance evidence in context

If the page appears slow or unstable, record the symptom before prescribing a fix. Does the main offer arrive late? Does a moving element displace the action? Does a control appear ready but respond slowly? Separate the observed experience from a presumed cause such as an image, third-party script or server response.

Google’s current Core Web Vitals documentation identifies Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Its good thresholds are 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 and segmented by mobile and desktop. These are performance thresholds, not conversion targets.

Keep laboratory tests separate from field observations. Record the test configuration, the URL and the time of collection. When a report provides field data, note whether it describes the exact page or a broader origin and what reporting period it covers. If the exact page has insufficient field data, retain that limitation. An origin-level result is not a measured result for every campaign page.

Use repeated controlled checks to investigate a reproducible symptom, not to select the most favourable score. A developer can then identify the cause and define a suitable technical retest. Whether the improvement changes qualified enquiry outcomes is a separate measurement question. A faster page may still offer the wrong service or send requests to the wrong destination.

Establish what the reported conversion actually means

Write a plain-language definition for each event used to judge the page. Is it an action click, an attempted submission, an accepted request, a received enquiry or a qualified opportunity? Keep those states separate. Otherwise a page change can appear successful because it generates more easy-to-trigger events while the team receives no additional usable enquiries.

Google Analytics documents form_start and form_submit within enhanced measurement. Those descriptions do not establish that a particular website’s form reached its CRM. The audit must verify the meaning of the implementation in use rather than infer delivery from an event’s name.

Google also lists generate_lead and later lead-stage events in its recommended events. Recommended events need implementation; their names do not make them automatic business records. Document when the chosen event should occur and which receiving-system evidence should agree with it.

In an authorised environment, trace a labelled test through the stages the business claims to measure. Compare one accepted request with its event and receiving record. Check a rejected attempt and a repeated action too. If the necessary access is unavailable, mark measurement validity as not tested and assign the reconciliation. Do not write “tracking verified” because a tag was visible.

Before calculating a rate, define the numerator, denominator, period and exclusions. “Unique accepted enquiries divided by eligible landing-page sessions in the same reporting window” is one possible operational definition, provided the business can measure both consistently. It is not automatically the same as a platform’s session key-event rate or a campaign’s conversion rate.

Record how test submissions, spam, duplicates, consent choices and delayed outcomes affect interpretation. Do not bypass consent controls to improve apparent coverage. If an enquiry becomes qualified days later, a current-period visitor count and a mixture of older qualification decisions are not necessarily a coherent cohort. Note the lag and report provisional outcomes as provisional.

Google Ads Quality Score guidance describes that score as a diagnostic rather than a KPI or an auction input. Do not import it into this audit as a composite page grade. Your decision record should identify the visitor problem and the evidence, not disguise several uncertain judgements as a precise number.

Use a consequence-based severity rubric

Severity describes the consequence supported by evidence. Effort describes the work needed to address it. Evidence strength describes what you know. Keep all three separate. Multiplying arbitrary numbers together makes a spreadsheet easy to sort, but it can hide an important barrier behind a speculative estimate.

These definitions are a proposed working rubric for this worksheet. They are not a recognised certification scheme or a prediction of revenue. Adapt the response timing to the business’s actual consequences and authority. A person responsible for campaigns should decide whether affected traffic needs changing; the worksheet itself cannot make that operational decision.

Use equally plain effort labels: small for a bounded change within an existing component; coordinated for work involving several owners or systems; investigation for an unresolved cause; unknown when the implementer has not assessed it. Avoid assigning hours on somebody else’s behalf. A short text edit can require substantial approval if it changes a commercial commitment.

Prioritise confirmed inability to complete a journey and false success messages before discretionary polish. Next, resolve measurement defects that would undermine decisions, and material offer or credibility problems. Dependencies can change the order: a wording experiment should wait if nobody agrees what a successful enquiry means.

Record why a decision was made. “Repair the false confirmation first because it reports a booking that has not happened” is clearer than “priority 9.” If a finding is deferred, retain an owner, reason and review date. Deferred should never become an invisible synonym for resolved.

One accountable owner should accept each finding, even where several specialists contribute. Pair that owner with a concrete acceptance criterion. “Improve mobile experience” cannot be closed reliably. “The submit control remains visible and operable in the recorded keyboard and overlay states” can be retested.

Worked example: a fictional office-cleaning assessment page

Consider Maple Lantern Office Care, an invented Canadian business used only for this exercise. Its fictional advertisement offers a free office-cleaning assessment in Toronto. The intended action is an assessment request, not a confirmed visit. The companion specification supplies imaginary page states and evidence notes so you can practise using the worksheet.

No site was built or user study conducted for this example. Every observation below is stipulated by the fictional specification. The worksheet’s validation steps are proposed future tests; they are not completed repairs. This distinction matters because a realistic-looking audit table can otherwise be mistaken for actual client evidence.

The distinction between F01 and F03 is useful. F01 contains a visible contradiction between two supplied statements. F03 establishes that supporting evidence is absent from the review materials; it does not establish that the badge is fraudulent. Both deserve action, but their owners need different evidence to close them.

F02 is rated for a defined visibility barrier; the scenario does not establish that every input method fails. The example does not estimate how many visitors encounter that state. F05 has a known mismatch between the proposed business definition and the fictional trigger rule, but no invented report of lost revenue. Its immediate purpose is to make future measurements interpretable.

The full worksheet also includes an unrated comprehension hypothesis, a not-tested integration, a bounded pass for a service-area statement and a not-applicable booking check. The headline question stays unrated because neither user difficulty nor a working end-to-end path has been established. It is a reason to collect evidence, not a demonstrated usability defect. Including these records prevents the audit from becoming a collection of accusations. Some things work within the scenario; others remain unknown.

A sensible fictional handoff would first assign the obscured control and false confirmation, resolve the offer and evidence questions, and establish valid measurement before evaluating a new headline. This is a reasoning exercise. It is not a promise that this sequence is optimal for every business or that all listed changes increase enquiry volume.

Put the reusable worksheets to work

Download the landing-page audit worksheets (ZIP)

The companion files contain a blank findings CSV, a blank JSON audit, a populated fictional version in both formats, an evidence register, a field dictionary, instructions and a validation plan. The JSON version keeps context, evidence and findings together; the CSV version is convenient for a team that works in spreadsheets.

Begin with the blank files. Give the audit a stable identifier and fill in the scope before adding rows. Keep one finding per independently assignable problem. If an offer contradiction and a broken submit route have different owners and tests, they should not share a row simply because both appear near the form.

Use evidence IDs to connect rows to the register. Store a location and a concise description of the evidence, including its credibility and limits. The public fictional register points to the supplied scenario, not to fabricated screenshots or analytics reports. In a real audit, point to actual authorised evidence and protect information that should not appear in a shared export.

Complete the observation before the hypothesis. Then write the consequence, severity, effort and proposed action. Name the owner and add the acceptance criterion before work begins. If the owner cannot say what would count as resolution, the recommendation is not ready for implementation.

Keep validation status separate from business outcome. A repaired interaction can pass its technical retest while its commercial effect remains unmeasured. Similarly, a result can be inconclusive because too few suitable observations have accumulated. The files make those distinctions explicit instead of forcing every row into “successful” or “unsuccessful.”

The supplied validator checks the template structure and fictional records, including duplicate IDs, missing evidence references, invalid categories and missing closure references. It checks recorded structure, not whether a source is truthful, an owner has accepted the work, or a retest proves the acceptance criterion. Those decisions still require review. It also exercises CSV quoting and newline handling. Those are synthetic file checks. They do not test a browser, contact a CRM, send an analytics event or establish accessibility conformance.

When importing the CSV, preserve the headers and treat free-text columns as text. The files contain no spreadsheet formulas. Review later additions before importing them into software that may interpret leading formula characters. Save a clean blank master so example rows never become confused with evidence from a real review.

Validate the repair and then evaluate the outcome

There are two separate questions after a change: did the intended repair work, and did the business outcome change? Design evidence for each. A screenshot can support a layout correction. A controlled request can support delivery to a test destination. Neither demonstrates a population-wide increase in qualified enquiries.

Retest the original failing condition and relevant adjacent states. If a fixed banner was moved, check that the movement did not cover another control or hide necessary information. If confirmation wording changed, verify both the normal success response and a failure response. Preserve the original finding so the team can see what the new evidence resolves.

For a hypothesis about comprehension, observe suitable participants attempting a realistic task with neutral instructions. Document what they do and say separately from your interpretation. If research has not happened, write a research plan and keep the status unmeasured. A colleague reading the copy is useful editorial review, but it is not automatically representative user research.

For a measurable commercial hypothesis, define the outcome, eligible traffic, guardrails and analysis plan before launching a comparison. Qualified enquiries, duplicates and wrong-service requests may matter alongside total submissions. Avoid a universal target such as “every service page should convert at five per cent.” Different offers, audiences and measurement definitions make such targets misleading.

Where traffic and operational conditions support a controlled experiment, have the responsible analyst set the design and stopping rule. Where they do not, a before-and-after comparison may still help monitor the change, but record differences in traffic sources, seasonality, offer, staffing and tracking. Do not attribute the full difference to the page simply because the change happened first.

Use honest closing language: “The specified error path now shows a descriptive message; commercial effect remains unmeasured.” Or: “The observation period cannot distinguish an improvement from ordinary variation.” A finding can be closed as a verified repair while the outcome review remains open. That is a stronger record than labelling every implemented recommendation a conversion win.

Finish with a small, usable decision record

Bring the owners together around the evidence, not a slide full of red circles. Confirm which issues are supported, which need investigation and which proposed changes depend on other work. Let implementers challenge effort assumptions and let offer owners resolve commercial ambiguity before copy is revised.

The handoff should identify the first actions, the people accountable, the dependencies, the acceptance tests and the next review date. Keep a visible list of untested routes. When a booking provider, offer, form component or confirmation process changes, revisit the affected checks instead of assuming the old pass still applies.

A landing page audit is complete when another person can understand each decision and reproduce the relevant check. Its value comes from reducing uncertainty and making repairs accountable. Enquiry volume may rise, stay unchanged or fall as unsuitable requests are filtered out. Evaluate that outcome against the purpose agreed at the beginning.

Discuss a conversion review with Canada Create.

Methodology: the checklist and rubric are original working tools. Platform and accessibility references were checked on 8 October 2026. All Maple Lantern examples are fictional; no live user testing or conversion results are represented.