How Broken Buttons Hurt Revenue

A button is a promise. The visitor clicks it expecting something to happen, and when nothing does, you don't just lose a click. You lose the one person who was ready to act.

That's what makes a broken button uniquely expensive. It doesn't fail the visitor who was browsing or undecided. It fails the visitor who read the page, made up their mind, and reached for the exact thing you built the whole page to make them reach for. "Get started," "Buy now," "Book a demo," "Upgrade." These are the pixels where intent becomes revenue, and a button that's dead at that moment forfeits everything you spent to get them there.

And like a broken form, a broken button is almost always silent. There's no error, no log, no support ticket. The person who'd have complained is the one whose click went nowhere, and they're already gone. You just see a conversion number that's a little lower than it should be and blame the funnel.

Let's look at what "broken" really means for a button, why it happens so often, where these dead clicks hide, what they cost, and how to catch them before your customers do.

What a "broken button" actually is

When people picture a broken button, they imagine one that's visibly missing or throws an error. Those are the easy cases. The expensive ones look completely normal and simply fail to do their job.

What is a broken button?

A broken button is any clickable element that fails to do what the visitor expects when they click it. That includes buttons that lead to a 404, that point to the wrong destination, that do nothing at all (a "dead click"), that work on desktop but fail on mobile or in another browser, that are visually present but not actually clickable, or that trigger an action which silently fails downstream. The failure is usually invisible to the site owner because no error is logged and the visitor simply leaves.

The defining trait is the same one that makes form bugs so costly: you can click it and it works, and the customer clicks it and nothing happens. Every example below is a version of that gap.

A button can be "broken" while looking perfectly fine:

• It leads to a 404 after a page was renamed or moved and the link wasn't updated.
• It points to the wrong place, sending a "Pricing" click to the old marketing page.
• It's a dead click: styled to look interactive but wired to nothing, so it just absorbs the tap.
• It works on desktop but fails on mobile, where a script error or overlay swallows the tap.
• It's covered by another element, a sticky banner or chat widget sitting invisibly on top of it.
• It fires an action that silently fails, like an "Add to cart" that animates but never updates the cart.

Why buttons break so often

Buttons feel trivial, which is exactly why they go unchecked. In reality they sit on top of a chain that can break at several points, and they're some of the most frequently touched elements on any site.

They depend on routing that changes constantly. A button is usually just a link to a destination. Rename a route, restructure a page, ship a redesign, and any button pointing at the old path is now dead. Routing is one of the most-edited parts of a codebase, and nobody re-clicks every button after each change.

They're wired by hand and easy to forget. A new CTA gets dropped onto a page during a sprint, styled to look right, and the actual click handler or href gets stubbed "for now" and never finished. It looks done. It does nothing.

Layout collisions hide them. A button can be perfectly functional and still unreachable because a sticky header, a cookie banner, a chat bubble, or a modal is sitting on top of it. This is invisible until you try to tap it on the device where the collision happens.

Mobile is a different machine. Touch targets too small to hit, buttons pushed off-screen, tap events swallowed by overlays, hover-dependent actions that don't exist on touch. The button that works on your laptop can be untappable on half your traffic.

It works on your machine. The most reliable reason any button bug survives: the person who built it tests it once, logged in, on desktop, in Chrome, and never clicks it again as a logged-out stranger on a phone. This is the same trap behind why founders skip testing altogether: the bug lives on the path you never take.

Why a broken button is so expensive

Not every bug costs the same. A broken button is among the worst, for the same compounding reasons a broken form is, because it's the same category of failure: a break at the point of action.

It fails at maximum intent. A visitor who clicks a CTA has already done the hard part. They scrolled, read, got convinced, and decided. A button that fails here doesn't lose a tire-kicker; it loses someone who was actively trying to convert. The Baymard Institute has documented how much abandonment comes down to fixable flow and interaction problems rather than price. These are buyers lost to friction at the final inch.

It's completely silent. A dead click produces no error you'll ever see. The visitor taps, nothing happens, they assume your product is flaky, and they leave. There's no log, no ticket, no bounce you can attribute to it, because the only person who experienced it is the one who left without a word.

The cost is confirmed, not hypothetical. When a button fails, you don't lose a maybe. You lose a high-intent lead or sale, after you've already paid to acquire that visitor and earned the trust it took to get them to click. As the Nielsen Norman Group notes, an interaction that fails with no feedback and no recovery path is one of the fastest ways to lose a user's confidence for good.

Maximum cost, minimum visibility. That's the signature of every break at the point of action, whether it's a broken form or a dead button, and it's why these can hold your conversion rate down for months while you optimize everything except the thing that's actually broken.

Where broken buttons hide

When live sites get crawled, dead and broken buttons cluster in the same predictable, high-value places:

• The primary homepage CTA on mobile. "Get started" works on desktop, swallowed by an overlay or pushed off-screen on a phone. Half your traffic, blocked at the front door.
• Pricing-page buttons after a plan change. Plans get renamed or restructured, the "Choose plan" buttons still point at the old, now-404 checkout URLs.
• The nav CTA after a route rename. A redesign moves /demo to /book, and the persistent header button still points at the dead path on every page.
• "Add to cart" / "Add to plan" that silently fails. The button animates, the cart never updates, and the visitor thinks they added something they didn't.
• Buttons under a sticky element. A cookie banner or chat widget covers the bottom CTA on smaller screens, so the most important button on the page can't be tapped.
• Social or app-store buttons pointing nowhere. Low stakes individually, but they signal a site nobody maintains, which erodes trust right where you're asking for it.

None of these are exotic. They're the default failure modes of any site that's shipped a few times and hasn't re-clicked its buttons end to end since. A dead button is a close cousin of the broken-link problem that quietly kills trust: same silent failure, applied to the elements you most need to work.

A broken-button checklist

Before any release that touches a page, a route, or a layout, and on a recurring basis after, verify each interactive element:

1. Every primary CTA resolves to a real, working destination, with no 404 between the click and the page.
2. Every CTA points to the right place, not an outdated or placeholder URL left over from a previous version.
3. No dead clicks: every element that looks clickable actually does something when clicked.
4. Buttons work on a real mobile device, tapped on an actual phone, not a resized desktop browser.
5. Buttons work across browsers, at minimum Chrome and Safari, plus Firefox if your audience uses it.
6. Nothing covers the button: no sticky banner, chat widget, or modal sitting invisibly on top of the tap target.
7. Touch targets are big enough to hit on a phone without zooming or mis-tapping a neighbor.
8. The action actually completes: "Add to cart" updates the cart, "Submit" sends, "Upgrade" reaches checkout.
9. There's visible feedback on click, so the user knows the tap registered and isn't left guessing.
10. Secondary links resolve too: footer, social, and app-store buttons go where they claim.

For the broader, release-by-release version of this, we keep a full pre-launch website testing checklist that covers buttons alongside links, forms, flows, and rendering.

How to catch broken buttons before customers do

The reason button bugs survive is that catching them by hand is relentless: click every CTA, on every page, on every browser and device, and confirm the action actually completed, after every single deploy, forever. Nobody sustains that. So the fix is to stop relying on willpower and automate the sweep.

Click everything, not just the obvious CTA. Real coverage means exercising every interactive element on every key page, including the secondary and footer ones, because the dead click you didn't think to test is the one a customer finds.

Test the destination, not just the click. A button that "works" can still point to a 404 or a silent failure. Confirm the click lands somewhere real and the intended action completed downstream, the same way you'd verify a form submission actually arrived.

Test as a real visitor would. Logged out, on mobile, across browsers. The happy path you click by hand on desktop is the one path that's already working; the breaks live everywhere else.

Make it part of every deploy. Buttons break on the deploy that renames a route, the redesign that shifts the layout, the banner that ships on top of a CTA. A check that runs automatically on every release is the only kind that survives a busy week; a once-at-launch audit goes stale the next time you ship.

Make the output a screenshot. "CTA: fail" in a report is easy to deprioritize. A screenshot of your actual "Get started" button leading to a 404, or buried under a chat widget on mobile, makes the lost revenue concrete and the fix urgent.

This is exactly what HowsMyApp is built to do: it crawls your live site the way a real visitor would, clicks your buttons and CTAs across devices and browsers, follows where they lead, and flags the ones that fail, with a screenshot of what your customer is actually hitting. Catching this is core to any serious website UX audit, where the buttons are where intent either converts or evaporates.

Common mistakes

The ways teams let broken buttons slip through are as predictable as the breaks themselves:

• Testing only on desktop Chrome. The least representative environment your buttons run in, and the one place every bug is already fixed.
• Assuming a button that renders is a button that works. Looking clickable and being wired correctly are different things.
• Only clicking the main CTA. Dead clicks love the buttons nobody thinks to test: secondary actions, footer links, app-store badges.
• Trusting the click animation. A button that animates on tap can still fail to complete its action. Verify the cart updated, the page loaded, the action landed.
• Treating it as a one-time check. Routes get renamed and layouts shift continuously. A button that worked at launch is not a button that works today.
• Reading silence as success. Almost nobody reports a button that did nothing; they just leave. "No complaints" usually means no feedback loop, not nothing broken.

Frequently asked questions

How do I know if a button on my site is broken? You often can't tell by looking, which is what makes it dangerous. The reliable check is to click it as a logged-out visitor, on a real phone and across browsers, then confirm it both landed somewhere real and completed the intended action. If it leads to a 404, does nothing, or animates without completing, it's broken.

What's a "dead click"? A dead click is a tap on something that looks interactive (a button, a card, an icon) but is wired to nothing, so the click is absorbed and no action happens. Users read it as the product being broken or unresponsive, and they leave without reporting it.

Why would a button work for me but not for my customers? Because you test it in the one environment where it works: your machine, your browser, logged in. The breaks live on the paths you don't take, mobile, Safari, a layout where a banner covers the button, a route you renamed. "Works for me" is the most common reason a button bug survives for months.

How much do broken buttons actually cost? More than most site bugs, because they fail at the point of maximum intent, after you've already paid to acquire the visitor and convinced them to act. Every dead CTA is a confirmed lead or sale lost at the final click, with no record that it happened.

How often should I test my buttons? After every deploy that touches a page, a route, or a layout, and on a recurring basis otherwise. Routing changes and layout shifts break buttons constantly, so a single audit goes stale fast.

The bottom line

A button is where your page finally asks the visitor to act, and a broken one fails at the exact moment someone decided to say yes. The cruelty is that it fails in silence, no error, no ticket, no trace, so it can quietly hold your conversion rate down for months while you tune headlines and pricing and wonder why nothing moves.

You don't need to click your buttons more by hand; that's why they go unchecked. You need every interactive element exercised automatically on every deploy, as a real visitor on a real device, with the destination and the downstream action both verified. Get that right and you stop losing the customers you already paid to bring to the click.

---

Want to know if your buttons actually work? Run a free scan with HowsMyApp. It clicks your CTAs the way a real visitor would, across devices and browsers, follows where they lead, and shows you each one that fails with a screenshot of exactly what your customers are hitting.