Website error check: links, 404s, 5xx, JS errors and forms

A practical website error check: how to find broken links, real and soft 404s, 5xx responses, JavaScript errors, dead forms, mixed content and broken images.

Links · Published: 12 October 2026 · 6 min read · Марк Лебедев

Visitors rarely report errors. They hit a dead link, a form that silently does nothing or a page that renders half a layout — and leave. Search engines are less polite: they record the error and crawl you less. A regular website error check is how you find these before either group does. This article is a field guide to the seven kinds of errors that show up most often, where each hides and how to confirm it.

1. Broken links

A link that leads to a 404 or 410 is the most common error on any site older than a year. Pages get renamed, products get removed, a menu item keeps pointing to last season's sale. Internal broken links are fully under your control and hurt twice: a dead end for the visitor and a wasted fetch for the crawler. External ones rot on their own schedule.

The fix is to change the link, not to redirect forever: point the anchor at the final address. Our broken links guide covers the edge cases, and this reference page explains how the scanner follows internal links to see where they land.

2. 404 pages and soft 404s

A real 404 is fine — it is the honest answer for a missing page. The error is when a missing page answers 200 OK with "Not found" in the text. That is a soft 404: monitors think the page is healthy, search engines index garbage. Test it in one line:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/no-such-page-7c1/

Anything except 404 or 410 needs fixing. The scan runs exactly this test — see how 404 handling is checked.

3. Server errors (5xx)

A 500, 502 or 503 means the server failed, not the visitor. Sporadic 5xx are the hardest to catch: the page works when you open it and fails under load, on a cold cache or for a particular query string. Look for them in server logs and in any crawl that fetches many pages in a row. A page answering with an error is one of the few findings that is always critical: it is broken for everyone right now.

4. JavaScript console errors

A thrown exception can stop the rest of a script from running: the menu does not open, the cart does not update, the analytics tag never fires. Visually the page may look perfect. Open DevTools → Console and reload; red lines are errors, uncaught exceptions are the worst. Common culprits are a third-party script that failed to load, a missing element the code expects and a 404 on a JS chunk after a deploy. The console errors article explains how to triage them.

5. Forms that do not work

A contact or checkout form is where errors cost money directly. Typical failures: the form has no action or posts to a removed endpoint, validation rejects valid input (a phone number with a plus sign, a Polish letter in a name), the submit button does nothing because of a JS error, or the "thank you" page is a 404. Submit every form yourself after each release; the form testing guide lists what to try.

6. Mixed content and broken images

On an HTTPS page, any resource loaded over http:// is mixed content. Browsers block active mixed content (scripts, iframes) outright and flag passive content, so a single old image URL can cost you the padlock. Details are in the mixed content article. Broken images are the visual twin of broken links: an image URL that answers 404 shows an empty frame and a missing alt shows nothing at all.

Checking a site for errors with SiteScan

1. Enter the address on the home page. A free scan opens up to ten pages in a real browser, so it sees what a visitor sees, including JavaScript.
2. In the report, look at the HTTP status of each page in the Pages table and at Site checks → Internal links: every internal link found on the crawled pages is fetched, and the dead ones are listed with the page they were found on.
3. Check 404 handling for soft 404s, the Browser console block for errors and exceptions logged on each page, and the images check for files that do not load.
4. Fix, then press Rescan. Signed in, the Watch this site button puts the domain on a schedule, and the next report shows what is new, what is fixed and what is still there.

For problems that start with a symptom rather than an error code — "the site got slow", "emails go to spam" — continue with website diagnostics.