Console Errors Test
What is it?
Browser console messages are the running commentary your page emits as it loads: unhandled JavaScript exceptions, failed network requests, security warnings, deprecated API usage, and performance hints all show up there. A clean console is one of the simplest signs of a well-built page, and a noisy one usually points at something quietly broken. This test reviews the console output for the page you submit and reports the warnings and errors detected during load.
Why console messages matter
Many console messages do not visibly break the page, but every one of them indicates something that deserves attention. Failed network requests waste bandwidth and may indicate that a feature is silently broken. Mixed-content warnings mean an HTTPS page is loading insecure resources, which modern browsers may block. Deprecation notices warn that an API your code depends on is on its way out and will eventually stop working entirely.
Performance-related console hints are particularly worth heeding. Forced reflow warnings, large layout shift notifications, and long-task alerts often map directly to Core Web Vitals failures. Resolving them tends to improve both the user experience and the page's measured performance scores at the same time.
Common categories of console messages
- JavaScript runtime errors, the most disruptive category, see the JS Error Test for detailed coverage.
- Failed network requests (404s and 5xx responses) that point at broken assets or dead third-party endpoints.
- Mixed content warnings, where an HTTPS page loads HTTP sub-resources.
- CORS or Content Security Policy violations, which require updating server response headers.
- Deprecation notices, warning that an API in use will be removed in a future browser version.
- Cookie warnings about
SameSiteorSecureattributes that the browser expects to be set explicitly.
This test reports the warnings and errors detected on your page. The fix guide below walks through diagnosing each category in browser DevTools and resolving the most common underlying causes; production teams typically also pair these checks with a runtime error monitoring service so regressions surface from real users automatically.
Pass rate:
-
Top 100 websites: 27%This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
-
All websites: 50%This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.
| 2021 | 33% |
|---|---|
| 2022 | 32% |
| 2023 | 41% |
| 2024 | 27% |
100
75
50
25
0
How do I fix it?
Console errors include any unhandled JavaScript exceptions, network request failures, security warnings, or deprecation notices the browser emits while loading the page. Fixing this issue means resolving the underlying problem each error reports rather than suppressing the message. Even errors that do not visibly break the page can degrade performance, leak data, or trip Core Web Vitals.
Where to make the change
- Open DevTools, Console tab: expand each entry to see the file, line, and stack trace. Right-click an entry to filter, save, or jump to the source.
- Application code: patch the offending script (see js-errors). For network failures, fix the failing endpoint or remove the stale request.
- Third-party tags: if the error originates in an analytics, ad, or widget script, update the snippet, switch to the vendor's current loader, or remove unused tags.
Common causes and how to resolve them
- JavaScript runtime errors: see the JS Error Test fix; the same approach applies.
- Failed network requests (404 or 5xx): remove the dead request or fix the endpoint. Stale tracking pixels and removed assets are common culprits.
- Mixed content warnings: the page is HTTPS but loads an HTTP resource. Update the resource URL to
https://. - CORS or CSP violations: tighten or expand the policy as appropriate. CSP errors usually require allowlisting the offending origin in the response header.
- Deprecation warnings: update the call site to use the recommended API. These do not break the page today but will when the deprecation cycle completes.
Best practices
- Treat the console as a build artifact: a clean console is a sign of a healthy page. Aim for zero errors and zero warnings on production routes.
- Use error monitoring in production: real users hit edge cases your local environment will never reproduce. A monitoring service surfaces them with frequency data.
- Defer or remove unused third-party scripts: every removed script is one fewer source of console noise.
