Guide

How to find broken website CTAs

Buttons and anchors on a website hide a surprising number of failure modes. A CTA can be visible, styled correctly, and still lead nowhere useful. This guide describes the failure patterns, the manual checks that expose them and where continuous pathway monitoring saves work.

By LeadGuard Product Team · Published 15 July 2026 · Editorial policy

A CTA is a promise that clicking will do something useful. When that promise silently breaks the visitor either bounces or blames the business. Most CTA breakages are not full outages. They are small, specific and easy to overlook: a stale href, a scripted handler stripped by a theme update, a modal that no longer opens, a button hidden behind a cookie banner on one viewport width.

Types of CTA and how they break

  • Ordinary anchor CTAs: the href points at a URL that no longer exists or has moved.
  • In-page anchor CTAs: the anchor id has been renamed and the button now scrolls to the wrong section or nothing.
  • Scripted CTAs: the click handler was stripped or the script that attached it no longer loads.
  • Modal CTAs: the modal library was updated and the CTA no longer opens the modal.
  • Buttons that are technically clickable but visually hidden or covered.
  • Buttons that lead to a page which no longer contains the destination they promise (a booking page without a booking widget, a form page without a form).

Common symptoms

  • Bounce rates on landing pages rise while traffic stays flat.
  • The CTA is visible in reports but downstream conversions no longer occur.
  • Console errors appear on the page when the CTA is inspected.
  • The CTA works on desktop but does nothing on mobile, or vice versa.
  • The next step page loads with an error instead of the intended experience.

Manual diagnosis process

  1. Open the page with developer tools and inspect the CTA element.
  2. Confirm the href, data attributes or onClick handler point at a current, expected destination.
  3. Click the CTA as a visitor would; watch the network and console for errors.
  4. Verify the destination page or modal actually contains what the CTA promises.
  5. Repeat on mobile at real viewport widths, including any sticky variants.
  6. Check for covering elements: consent tools, chat widgets, promo bars, sticky headers.

Two realistic scenarios

What can be checked manually

  • Every primary CTA on landing pages, service pages and campaign pages.
  • In-page anchor CTAs and their target sections.
  • Modal CTAs and their modal contents.
  • Sticky CTAs and any element that could cover them.
  • Destination pages actually contain the next step the CTA promises.
  • Behaviour on both desktop and real mobile devices.

What ongoing monitoring adds

Manual checks scale badly across a site with many pages and many CTAs. Pathway monitoring treats each protected CTA as its own object, records history, and catches regressions when a shared component is edited. It also spots the subtle case where the CTA still exists but its destination is no longer the right page for the promise it makes.

What LeadGuard can verify

  • The CTA element is present on the source page and matches its canonical identity.
  • The CTA is visible and interactive at real viewport widths.
  • The click destination is a reachable URL, or the modal target is present in the DOM.
  • The destination page still contains the pathway or content it is supposed to lead to (when that pathway is also protected).
  • Real visitors continue to interact with the CTA and reach its outcome source.

What LeadGuard cannot verify

  • Whether the CTA copy is compelling to visitors.
  • Whether the destination content converts once reached.
  • Every possible browser and device combination in the wild.
  • Handlers whose behaviour depends on account state after a login the monitor does not perform.

How to set it up well

  1. Identify the CTAs that carry commercial risk (the ones that lead to enquiry pathways).
  2. Protect each such CTA rather than assuming a general page check will notice its failure.
  3. Verify that repeated CTAs on shared components are protected on every page they appear on.
  4. Route alerts to a person who can push a fix, not just to a group inbox.
  5. After a redesign or a shared-component refactor, review the discovered CTAs and confirm the important ones are still on the list.

A traditional link checker crawls a site and reports 404s. That is useful for content pages, but it misses most CTA failures because the href technically resolves. Pathway monitoring adds visibility of scripted handlers, modal behaviour, viewport-specific visibility and the destination's contents, none of which a link checker was designed to reason about.

FAQs

Does a link checker catch broken CTAs?
Only the subset that are anchors with dead hrefs. Most CTA failures involve scripted handlers, modal behaviour, visibility or the destination page no longer containing the promised content.
Can LeadGuard tell me my hero button is dull?
No. Copy and design questions are outside pathway monitoring. LeadGuard confirms the CTA works and points at the right destination; behaviour analytics tools help judge whether the CTA earns clicks.
How do I know if a modal CTA is broken?
The click handler and the modal target are the key signals. Pathway monitoring inspects both, and can record when the click handler is missing or the modal target is no longer in the DOM.
What about sticky CTAs?
They deserve explicit protection because they can be covered by other overlays on some viewports. Visibility checks at real widths catch this failure mode.
Does LeadGuard click every CTA on my site?
It performs safe active checks on the pathways an account chooses to protect. It does not attempt to simulate every possible user action across the entire site.
Should I keep testing CTAs manually?
After large redesigns or refactors of shared components, yes. Between those events, continuous monitoring covers the routine work.

Related content