toolkit

Scenario · The bigger jobs

Build a landing page for a campaign

“We're running ads for [procedure] — we need a page to send the traffic to.”

A landing page built for paid traffic isn't a normal page, and treating it like one is the mistake — its whole job is to convert, so the form and the tracking around it are the actual deliverable, not the page's place in the site's structure. This confirms the page's form can genuinely be submitted and that the conversion gets recorded once someone does, which matters more here than almost anywhere else on the site, because a landing page whose form silently fails is paid budget spent on nothing.

What to ask for

Content briefContent brief generator — turns a keyword into a brief a writer can execute without further research: search intent and audience, a recommended title / meta description / H1, an H2–H3 outline, entities and questions to cover, internal-link anchors, and a word-count target.Form submittabilityDrives a rendered page to prove its primary form can be submitted.Analytics & tagsAnalytics & tag presence audit — reads a page's delivered HTML and inventories the measurement, advertising and session-replay tags firing on it: Google Tag Manager, GA4, legacy Universal Analytics, Google Ads, Meta Pixel, LinkedIn, TikTok, Microsoft Ads, Pinterest, Clarity, Hotjar, Segment, Matomo.Performance (Core Web Vitals)Core Web Vitals and performance scan for a live page.Accessibility (a11y)Accessibility scan for a live page — runs axe-core (Deque) across device presets and scores the page against WCAG, returning an absolute PASS / REVIEW / FAIL verdict plus a self-contained HTML report grouped by impact.On-page SEOOn-page SEO scan — reads a page's delivered HTML and checks the head, meta and heading signals search engines use: title presence and length, meta description, rel=canonical, meta robots (noindex), Open Graph tags, viewport, html lang, and exactly one H1, plus a structured-data summary.ScreenshotsCapture multi-device screenshots of any URL from the command line — one PNG per device preset (iPhone → Desktop 4K), headless, on a Playwright core.

See it work

A real run of Form submittability:

Form submittability · form-submittability — https://toolkit-tests.pages.dev/forms/overlay-submit.html  (devices: desktop,iphone-17)

FAIL — https://toolkit-tests.pages.dev/forms/overlay-submit.html
  ✗ the submit button is covered by a fixed element (div.banner) — clicks land on the overlay, the form cannot be sent
  • field textarea [message] is covered by a fixed div.banner — a visitor may not be able to click it
  • field button is covered by a fixed div.banner — a visitor may not be able to click it

  report: ./out/form-submittability-form-submittability.html
  text:   ./out/form-submittability-form-submittability.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

A landing page is not a normal page and treating it as one is the mistake. It exists to convert paid traffic, so its form and its conversion tracking are the deliverable — not its place in the site structure, which it usually should not have.

  1. Brief it against the campaign’s keyword, not the site’s. The content brief gives the intent, the title, the outline and the questions to answer. A landing page briefed against a general service term when the ads target a specific procedure is a mismatch that costs the click.
  2. Decide the conversion, precisely, before it is built. Form submission, phone click, or booking completion — and where the visitor lands afterwards. The confirmation page is part of this build, not an afterthought, because it is where the conversion tag fires.
  3. [manual] Build the page and its confirmation state. Single focused call to action, the form above the fold, and deliberately no site navigation if the campaign wants no exits — which is the normal choice and the opposite of the new-page procedure. Publish.
  4. Submit the form for real. The submittability check end to end, then confirm the notification arrived in the destination inbox. A landing page whose form fails is paid traffic spent on nothing, and it is silent.
  5. Confirm the conversion fires. The tag audit on the confirmation page, not the landing page. This is the check that makes the campaign’s reporting mean anything, and step 2 is what made it checkable.
  6. Grade speed and reach. Performance, because paid traffic is mostly mobile and arrives impatient; and accessibility, because a form nobody can complete by keyboard excludes people who clicked the ad. Then capture it across devices.
  7. Decide its search posture deliberately. On-page grade for a clean title and description. If the page duplicates a service page, it should not compete with it in search — that is a canonical or a noindex decision, made once, on purpose, and recorded in the ticket.
  8. [manual] Confirm the ad’s destination URL matches the page, including any tracking parameters. The commonest launch failure is ads pointing at a URL that redirects, or at the pre-launch draft.

It is a conversion path, not a page

Every step that differs from building an ordinary page — no navigation, a confirmation state, the tag on the confirmation rather than the page, a deliberate search posture — follows from that. Build it as a page and the parts that make it a landing page are the parts that get left out.

What this does not cover

The campaign. Nothing here writes the ads, chooses the audience, or judges whether the offer converts — and a landing page that passes every check can still convert nobody. It also cannot tell you the page is consistent with what the ad promised, which is the single most common reason paid traffic bounces, because the ad copy lives in a platform this never sees.

← All scenarios