Button not working on website: find the cause

The button draws on screen, but the tap goes somewhere else. A cookie banner or a chat launcher can sit over its lower edge and take the press without showing anything. Or a script failed on page load, so no handler was ever attached and the press does nothing at all. A button inside a form submits that form by default, which reloads the page and looks like nothing happened. None of these show up on the owner's laptop, where the banner sits in a corner and the owner is already logged in.

• Press the button in a private window, so your saved login and cookies do not change the result.
• At phone width, check whether a banner, chat launcher or sticky bar covers any part of the button.
• Read the Console on page load and right after the press for a red error line.
• Look in the Network tab for a document request that starts when you press it.
• Check the Elements panel for a disabled attribute, or pointer-events set to none, on the button or a parent.

A visitor scrolls down to the button, reads the label and taps it. Nothing opens. They tap again, a little harder, then look for another way in: the menu, the phone number in the footer, the back arrow. A few seconds later they leave. Your analytics shows a page view and no booking. Nothing in that record says whether a banner covered the button, a script failed, or the visitor simply changed their mind, so the stopped visit looks the same as a choice not to buy.

The first cause is a layer on top. Open the developer tools and run document.elementFromPoint with the center of the button's position. If it returns a banner, a chat launcher or an empty box rather than the button, that layer takes the tap. The second cause is a script that failed before the button was wired up. One uncaught error can stop the rest of that file from running, and the Console shows it with a file name, while the page looks normal.

The third cause is a button with no type inside a form. A plain button submits the form by default. If a required field is empty, the browser shows its own message on that field, often off screen, and the page stays put, so the press looks dead. If the form posts, the page reloads and the visitor sees a brief flash. The fourth cause is a disabled state left behind. A button stuck in a loading state keeps its disabled attribute, or a parent sets pointer-events to none, and the browser ignores the tap without any error.

Open a private window, clear the Console and Network tabs, then press the button once and read the result in this order. A red error at the press points to a script. A document request points to a form submit. A request that returns an error status points to the server. No request and no error points to a layer on top or to a disabled button, and the elementFromPoint check settles which one. Keep a phone-width window open as well, because the layer on top often exists only at that width.

On a laptop a cookie banner often sits in a corner, away from the button, so the press works. At phone width the same banner can slide onto the button's lower edge, and a desktop check misses it. A simulated visitor arrives at phone width as a stranger, taps the button, waits and looks. The report gives the step where the tap did nothing, any JavaScript errors and failed requests recorded on that step, and a screenshot of that screen. It does not open your developer tools, so the Console and the layer check are still how you name the element that took the tap.

The same overlay can come back after the next release, when a new chat widget, banner or sticky bar lands on the same corner. Rerun the same phone visitor after each change to the layout, and confirm the button still takes the tap. With paid credits, a site password or a preview bypass lets the visitor reach a staging copy, so the same check can run on each preview deploy before release.