JavaScript console errors: what breaks

A JavaScript console error means a script on the page stopped partway through. What it breaks depends on what that script was doing: if it opened the menu or checked a form, that feature stops responding; if it counted visits, visitors notice nothing.

The rest of the page keeps working, which is why these errors so often go unnoticed. Errors on page load are part of what our audit checks on user experience and reliability.

What happens when a script fails

When a script hits an error nothing was written to handle, it stops. MDN's JavaScript reference puts it plainly: if no catch block handles the error, "the program will terminate." The instructions that came after it never run.

Other scripts on the page carry on. The browser shows the visitor nothing: it writes the error to the console, a developer panel nobody opens while browsing. All the visitor sees is a button that does nothing.

What an error can break, and what it leaves alone

How serious an error is depends on the job of the script that stopped, not on the message. The same words in the console can mean a broken quote form or an analytics counter that stopped counting.

Navigation: on mobile, the menu often opens through a script. If it fails, your pages are still online, but visitors can no longer reach them.
Forms: a script that checks fields or sends the request can leave the submit button doing nothing, with no message at all.
Cart and checkout: adding to cart, picking a size, calculating shipping. The visitor can see the product and still cannot buy it.
Analytics and marketing tools: visitors see no difference, but your traffic numbers are wrong and nothing tells you so.
Display features such as a carousel or a gallery: the content is there, but part of it can stay hidden.

What we find on the sites we audit

55%show at least one JavaScript runtime error while their pages load

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

That figure does not mean these sites are down. It means at least one script failed, and the impact depends on what that script was doing. That is why the report quotes each message and the page it appears on, rather than a single total.

Not every console "error" is an error

Google's Lighthouse flags every error logged to the console. But the console mixes messages of very different kinds, and a raw count includes failures that are not failures. Before counting, the audit sorts each message.

Runtime errors: a script that fails while the page loads. These are the only ones counted here.
Browser messages about how the site is configured, such as a badly written security policy. No script failed, so these belong to the security pillar.
Messages about a file that failed to load. The defect is the missing file, and it is counted once, with broken images and missing files.
Messages a site's own script writes to the console on purpose. The page works, so they are noted for the record and not counted as errors.

An error on page load does not always show what it blocks. When it can be done without changing anything on your site, the audit also clicks the controls on the page, because a button that triggers nothing is a failure no screenshot will show. The report separates what was actually clicked from what was only observed.

Third-party scripts count too

Most pages load scripts written by other companies: chat widgets, analytics, ads, embedded video, consent management. They run inside your page, and their errors land in the same console as your own code.

Visitors can't tell the difference: to them, your site is the one not responding. So the audit counts these errors along with the rest. The message quoted in the report often names the file at fault, which tells you who to contact.

What is quick to fix, and what takes a project

An error that shows up on every page usually comes from something shared: a page template, a plugin, a script added to the header. One fix removes it everywhere. A failing third-party script can be updated, reconfigured or removed, often without touching the rest of the site.

Errors in the site's own code take more work, especially when they come from an old library or an outdated version of the framework. Fixing an error that breaks nothing is still worth it: a console full of known messages hides the ones that appear tomorrow.

What this check doesn't tell you

We record errors that occur while the sample pages load and while they are scrolled. Errors on logged-in pages, in a customer account or after a form is submitted are out of reach: the audit never submits a form or creates an account.

Pages are loaded in a single browser. An error specific to another browser, an older device or an extension a visitor has installed can escape us.

By Quentin Mathis, Z29K · updated September 28, 2026