In short. "Website errors" can mean different things — here we mean technical defects, not text spelling. They're best checked by category: broken links (404s within the site), server errors (5xx), mixed content (http on an https page), browser console errors (broken JavaScript), security-header issues, and invalid markup. Each category has its own tool that checks it in a couple of minutes, and the browser console (F12) shows most client-side errors at once. Start with what the user and the search engine see: broken links and server errors. Below is what to check, with what, and in what order.
What counts as a "website error"
The query "check a website for errors" combines two different requests. Some want spell-checking of the text — that's for proofreading services. Here it's about technical errors: the things that break how the site works, scare off users, and hamper indexing. These are what both the search engine and the visitor see.
"Check a site for errors" is too broad a task. Break it into categories: what the user sees (broken links, 5xx), what the browser sees (console, mixed content), what the search engine sees (markup, redirects). That makes the check concrete.
By category — what to check and with what
1. Broken links (404s within the site)
Links to non-existent pages annoy users and waste the search engine's crawl budget. Finding them by hand on a large site is impossible — you need a crawl. Run the site through a broken-links check: it crawls the pages and shows which links return 404 and where they lead from. How to fix the code itself is in the 404 breakdown.
2. Server errors (5xx)
Responses of 500, 502, 503, 504 mean the server couldn't deliver the page — the most critical errors, the page simply doesn't work. You can check the response code with an HTTP header check; common causes and fixes are in the articles on the 500 error and 502.
3. Mixed content
If an https page loads images, scripts, or styles over http, the browser complains about "mixed content": some resources get blocked and the padlock in the address bar becomes incomplete. The error is visible in the console (F12) and in the security scanner. How to fix it is in the mixed-content breakdown.
4. Browser console errors
Open DevTools (F12) → the Console tab: there the browser collects client-side errors — broken JavaScript, files that failed to load (404 on a script/style), CSP blocks. Red lines are what's breaking right in front of the user. The Network tab next to it shows every request with its status code.
5. Security headers and configuration
Missing protective headers, insecure cookies, disclosed versions — not a "breakage," but defects the security scanner finds. For a site handling user data, that's part of an error check.
| Category | Check with | Who sees it |
|---|---|---|
| Broken links (404) | Broken-links check | User, search engine |
| Server (5xx) | Header check / response code | Everyone — the page fails |
| Mixed content | Console (F12), security scanner | Browser (blocks resources) |
| Console / JS | DevTools → Console | User (broken functionality) |
| Headers, cookies | Security scanner | Hidden risks |
In what order to check
Fix by degree of harm: first what fully breaks the page (5xx), then what tears navigation and indexing (broken links), then client-side errors, and last — configuration. Otherwise it's easy to spend time on trifles while the user's homepage won't open.
- First — server 5xx: if the page isn't delivered, the rest doesn't matter.
- Then — broken links and redirects: they tear navigation and crawling.
- Then — console and mixed content: they break functionality and trust.
- Last — headers and configuration: hidden security risks.
Frequently asked questions
Is there one service that finds all errors at once?
There's no universal one: broken links are found by a crawler, server errors by a response check, client-side ones by the browser console, configuration by a security scanner. These are different checks because the errors live at different levels. But each takes a couple of minutes, and the console (F12) shows most client-side problems for free right away.
How often should I check a site for errors?
Once — after every major change or migration. Continuously — via uptime monitoring: it catches 5xx and outages automatically, without waiting for a manual check. A one-off run is a snapshot; monitoring is watching over time.
Are console errors always a problem?
Not always. Some warnings (yellow) are non-critical notes from third-party scripts and analytics. Red errors matter more: those are what actually broke. Start with the red ones and those that reference your own files, not someone else's widgets.
Checklist to remember
- "Website errors" are categories: broken links, 5xx, mixed content, console, headers. Check them one at a time.
- The browser console (F12) shows most client-side errors for free.
- Fix order by harm: first 5xx, then broken links, then console and configuration.
- There's no universal "check everything" service — each category has its own tool.
- After major changes — a one-off check; continuously — uptime monitoring.