Broken links and console errors check

Broken links and JavaScript errors are cheap to fix and expensive to leave: they break flows, hurt trust and waste crawl budget. This page shows what to collect, how to group it, and a task your AI beta tester can run across your site.

Who it’s for

  • Site owners after a redesign, migration or URL change
  • Developers who want a list of every front-end error users hit
  • Content teams with large blogs or documentation
  • Anyone whose site has grown for years without a cleanup

Updated 2026-10-19.

Why check in a real browser

Link crawlers find dead URLs, but many problems only appear when the page actually runs: a script that throws an error, an API call that fails, an image path built in JavaScript, a button that does nothing. A real-browser check opens each page as a visitor would and records what the browser reports.

This makes a broken links checker plus console review one of the most useful quick beta tests you can run. It needs no test plan, it covers the whole site, and it often surfaces the bugs behind vague user reports like "the page is weird" or "the button doesn't work".

What to collect on every page

  • Broken links: internal links returning 404 or 5xx, links to removed pages, anchors pointing to sections that no longer exist.
  • Redirect chains: links that bounce through several redirects before landing.
  • Missing images and assets: images, fonts, scripts or stylesheets that fail to load.
  • Console errors: uncaught exceptions, failed script loads, framework warnings that indicate real bugs.
  • Failed requests: API calls returning 4xx or 5xx, CORS errors, timeouts.
  • Mixed content: HTTP resources on HTTPS pages.
  • Dead buttons: links with an empty href or buttons that do nothing when clicked.
  • External links: links to other sites that return errors (check politely, without hammering them).

How to run a broken links and console errors check

  1. Start from the navigation and footer. These links appear on every page, so one bug there is a site-wide bug.
  2. Add your most important flows: signup, login, pricing, checkout and contact.
  3. Sample each template on big sites: one blog post, one product page, one docs page, instead of every URL.
  4. Open each page with the console and network list visible, and let it finish loading.
  5. Click the interactive elements: menus, tabs, buttons and forms, since many errors only fire on interaction.
  6. Log each problem with the page, the element or URL, the error text and the status code.
  7. Group duplicates so each distinct error appears once, with the list of pages where it occurs.
  8. Stay on your own domain and keep the pace gentle: a few pages per minute is plenty.

Checklist by type

Links

  • Every link in the header, footer and main menu returns a working page.
  • In-page anchors land on an existing section.
  • Old URLs redirect once to the right new page, not to the home page.
  • Links in emails, docs and help articles still point to live pages.

Assets and requests

  • No 404s for images, fonts, scripts or stylesheets.
  • API requests return success on page load and on key actions.
  • No CORS errors or timeouts in the network list.
  • No HTTP resources on HTTPS pages.

Console

  • No uncaught exceptions on load or after clicking main buttons.
  • No repeated errors that fire in a loop.
  • Framework warnings that point to real bugs, such as hydration mismatches or missing keys, are noted.

Example bug report

Title: "Pricing" link in footer returns 404 on every page
Environment: Chrome 129, macOS 14, 1440px wide; same on mobile viewport
Pages affected: all pages (shared footer component)
Steps to reproduce:
1. Open any page, for example /features
2. Scroll to the footer and click "Pricing"
Expected: opens /pricing
Actual: opens /plans, which returns 404 "Page not found".
        Console on /plans: "Failed to load resource: 404".
Severity: High (site-wide, on a link close to revenue)
Suggested fix: update the footer link to /pricing and add a redirect
               from /plans to /pricing

Common mistakes

  • Running only a crawler and missing errors that appear when JavaScript runs.
  • Loading pages without clicking anything, so interaction errors never fire.
  • Filing the same error once per page, burying the real count under hundreds of duplicates.
  • Crawling aggressively, slowing your own site or tripping rate limits on external sites.
  • Ignoring console errors because "the page still looks fine".

Grouping and prioritizing

A single broken component can generate the same error on hundreds of pages. Good reports group duplicates: one finding per distinct error, with the list of pages where it appears. Then prioritize:

  • High: errors that break a flow (signup, checkout, login) or appear on every page.
  • Medium: broken links in content, missing images on important pages.
  • Low: warnings with no visible effect, broken links on old pages with little traffic.

After the fix

Re-run the same check and compare. Scheduling it weekly or after each deploy turns it into a lightweight regression test: new errors show up the day they ship, not months later.

Doing it manually vs with an AI beta tester

Clicking through a site with the console open is easy for a few pages, but nobody does it across every template after every deploy.

An AI beta tester like betatest.ing opens your pages in a real browser, clicks the navigation and key buttons, collects broken links, failed requests and console errors, groups duplicates and files each finding with steps, severity and screenshots. It keeps a gentle pace on your own domain, never attacks or stress-tests a site, and can run on a schedule after each release. With a test login, encrypted and never shown to the AI, it can also check pages behind login.

What it does not replace: deciding which warnings matter for your codebase, and real users telling you about problems that only appear with their data or setup. Use it to keep the obvious breakage out, and keep listening to user reports.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Check [SITE URL] for broken links and errors. Visit every page a visitor can reach from the main navigation and footer, plus these flows: [EXTRA PAGES OR FLOWS]. Stay on this domain, at most 30 pages, and keep a gentle pace (a few pages per minute). On each page call logs and collect console errors, uncaught exceptions, failed requests and HTTP 4xx/5xx responses, CORS and mixed-content warnings; note broken internal links, links to missing anchors, redirect chains, missing images, fonts or scripts, and buttons or links that do nothing. Check external links only once each. Group duplicates so each distinct problem is one finding with the list of pages it appears on, include the URL and the exact error text, rate its impact, and attach an annotated screenshot when the problem is visible. End with a table of pages and their status, and the fixes ordered by impact.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] Your site, e.g. https://example.com
  • [EXTRA PAGES OR FLOWS] e.g. "signup, pricing and the blog index", or "none"

What the AI beta tester checks

  • Internal links returning 404 or 5xx
  • Missing anchors and redirect chains
  • Images, fonts, scripts and stylesheets that fail to load
  • Console errors and uncaught exceptions
  • Failed API requests, CORS and mixed-content warnings
  • Buttons and links that do nothing
  • External links that return errors

What you get

  • One finding per distinct error, with every page it appears on
  • The exact URL and error text for each problem
  • A table of pages and their status
  • Fixes ordered by impact

How to run it with betatest.ing

  1. Add your site as a project
  2. Paste the task and add any flows beyond the navigation
  3. Send it; the tester visits each page and reads the browser logs
  4. Fix the grouped errors, then schedule the check weekly or after deploys

Tips

  • Fix errors in the header and footer first: they affect every page
  • Set up redirects for old URLs after a migration instead of leaving 404s
  • Sample one page per template on large sites
  • Keep the error list from each run to see whether things improve

Broken links checker: FAQ

How is this different from a link checker?

A link checker requests URLs. This check opens pages in a real browser, so it also catches JavaScript errors, failed API calls, missing assets and buttons that do nothing.

Will it slow down my site?

No. It visits a limited number of pages at a gentle pace, like a single visitor.

Can it check pages behind login?

Yes. Save a test login in the project and list the logged-in pages to include.

Should I fix every console warning?

Not necessarily. Prioritize errors that break something visible or appear on many pages. Harmless warnings can wait.

How often should I check for broken links?

After every deploy that changes navigation, URLs or shared components, and on a regular schedule such as weekly. Links also break from the outside when pages you link to move, so a recurring check catches problems nobody on the team caused.

What do console errors mean for users?

A console error means some code failed while the page was running. Sometimes it has no visible effect, but often it means a button, form, widget or tracking script quietly stopped working. Check whether each error lines up with something a visitor can't do.

Which broken links should I fix first?

Fix links in the header, footer and main menu first, because they appear on every page, then links in signup, pricing and checkout flows. Broken links in old, low-traffic content can wait. For removed pages, a single redirect to the closest relevant page usually beats deleting the link.

Related beta testing guides

  • Website performance check — A slow page loses visitors before they see anything. This page explains the Core Web Vitals thresholds, what a browser-based performance check can tell you, and a test task your AI beta tester can run on your key pages.
  • Smoke testing — A smoke test is a short, shallow test that answers one question: is this build working well enough to use and test further? It takes minutes, and it is the first thing to run after any deploy.
  • Regression testing after deploys — Regression testing checks that what worked yesterday still works after today’s change. For small teams shipping often, a short regression suite run after every deploy prevents most "it used to work" bugs from reaching users.
  • WordPress site testing — WordPress sites break in predictable places: plugin conflicts, forms that stop sending, caching, and theme updates that shift layouts. This checklist covers what to test before launch and after every update, and gives you a task your AI beta tester can run on the site.
  • Website beta testing — A website beta test is a run-through of your site by someone who has never seen it, before real visitors do. This guide covers what breaks most often on marketing and content sites, how to set up the test, and a ready-to-run task your AI beta tester can start on right now.
  • Free tool: Free website test — Enter a URL, get an instant report: SEO basics, mobile, security headers, broken links and a score.

More in by test type