Testing Tools

Broken Link Checker: Beyond 404s — Test Where Links Actually Go

HelpMeTest

HelpMeTest

— 6 min read
Broken Link Checker: Beyond 404s — Test Where Links Actually Go

Broken link checkers find links that return 4xx or 5xx HTTP responses. They do not check whether the links that return 200 actually go to the right place. A navigation link that sends users to a competitor's site returns 200 OK. A checkout button that redirects to the homepage returns 200. This guide covers both levels of link checking — and why the second level is more important.

Key Takeaways

404 is not the only way a link can be broken. A link pointing to the wrong page is broken. A redirect chain with incorrect final destination is broken. A link to a page that renders but silently fails is broken.

Traditional broken link checkers miss destination accuracy. They verify status codes. They do not verify that the destination is the intended destination.

The most expensive link failures involve user flows. A "Proceed to Checkout" button that redirects somewhere else is a revenue problem, not a crawl problem.

Checking links means checking journeys. The end-to-end path from link click to expected outcome is what matters — not just whether the URL responds.

Automated link monitoring catches changes you didn't make. Redirects from third-party services change. CDN rules get updated. Automated checks catch destination drift.

Your broken link checker came back clean. Zero 404s. Every link on the site returns 200 OK.

But your "Start Free Trial" button sends users to an old pricing page that no longer has a sign-up form. The page loads. The URL responds with 200. The link passes the checker. And every user who clicks that button hits a dead end.

Broken link checking is useful. But it only catches the obvious failures. The subtler ones — and the more expensive ones — require a different approach.

A broken link checker crawls your site, extracts every <a href> and resource URL, requests each one, and reports on the HTTP response.

They catch:

  • 404 Not Found (page deleted or URL changed)
  • 410 Gone (explicitly removed)
  • 5xx Server errors (server-side failure)
  • Connection timeouts (server unreachable)
  • Invalid URL formats

They miss:

  • Links that return 200 but lead to the wrong page
  • Redirect chains that land somewhere unexpected
  • Links that work on desktop but break on mobile
  • Links inside JavaScript (SPAs, dynamic routing)
  • Links that require login to test
  • Destination pages that load but fail functionally

The 404 check is the floor, not the ceiling.

Wrong destination (returns 200)

A link returns 200 OK, but the page it lands on is not what the link implies.

Examples:

  • "Blog" in the navigation sends users to an old subdomain that now shows a parking page
  • "Download" button links to a file path that now 302-redirects to the homepage
  • An email campaign link points to a landing page that was replaced with a different offer

The URL responds. The page loads. The user is not where the link promised they would be.

Redirect chains ending in wrong destination

A URL has been through several redirects — old slug → new slug → another new slug — and the final destination is not the intended one.

Example:

  • /features → redirects to /product → which redirects to /pricing
  • Your navigation still links to /features
  • Every user who clicks "Features" ends up on a pricing page

The link checker reports the final destination. If the final destination returns 200, the link passes — even if the destination is unrelated to what the link said.

Many links on a site only work correctly when a user is logged in. Link checkers typically crawl unauthenticated, so they either:

  • Get redirected to a login page (200) and report the login page as the destination
  • Report the link as working because the login page returned 200

They do not verify that clicking the link while authenticated actually takes the user to the correct place.

Single-page applications and JavaScript-heavy sites generate many links dynamically. A traditional crawler fetches HTML and parses <a href> tags. It does not execute JavaScript, so it cannot see links generated by React, Vue, Angular, or similar frameworks.

This means a large portion of modern web application navigation is invisible to standard link checkers.

Destination pages that fail functionally

A link points to a page that loads correctly. But the primary action on that page — a form, a checkout button, a download trigger — does not work.

The link is not broken in the traditional sense. But from the user's perspective, clicking that link leads to a dead end.

Level 1: Standard HTTP checks (the baseline)

Run a traditional broken link checker to find 404s and server errors. This is the minimum.

Free tools: Screaming Frog (free up to 500 URLs), W3C Link Checker, Dead Link Checker

What to check:

  • All internal page links
  • Navigation links (header, footer, sidebar)
  • Images, scripts, and stylesheets
  • Canonical and hreflang tags

Run it: Before launches, after content migrations, after changing URL structures.

Level 2: Destination verification

For critical links — navigation, CTAs, key user flow links — verify not just that they respond, but where they land.

How to do it manually:

  1. Click the link
  2. Verify the page you landed on is the correct destination
  3. Check that the page content matches the link text/context

How to automate it:

Check navigation links for example.com:

1. Go to the homepage
2. Click "Features" in the navigation
3. Verify the URL is /features and page title contains "Features"
4. Go back to homepage
5. Click "Pricing" in the navigation
6. Verify the URL is /pricing and page title contains "Pricing"
7. Go back to homepage
8. Click "Sign Up" button
9. Verify the signup form is visible on the resulting page

This kind of check runs through links as a user would, not as a crawler would. It catches wrong destinations that return 200.

For links that are part of user flows — "Proceed to Checkout," "Confirm Email," "Download Now" — verify the complete journey that the link initiates.

"Proceed to Checkout" check:

  1. Add item to cart
  2. Click "Proceed to Checkout"
  3. Verify checkout page loads with cart items
  4. Verify payment form is present and functional
  5. Complete test purchase
  6. Verify confirmation

A link check that stops at step 2 passes even if step 5 fails. The end-to-end check catches flow-level failures.

After a migration or redesign

URL structure changes are the most common source of broken links. When you change /blog/post-title to /resources/post-title, every link to the old URL is a potential failure — even if you set up redirects.

What to check post-migration:

  • All redirects from old URLs lead to the correct new pages
  • Internal links have been updated (not just relying on redirects)
  • External links from other sites (you can't control these, but monitor for them)
  • Email campaigns and documents that link to old URLs

After a third-party URL change

You link to documentation, a partner's page, or an external resource. That page changes its URL. Your link now goes somewhere wrong — or nowhere.

This is a background failure. It happens without any action on your part.

After a JavaScript or routing change

A SPA routing change can make paths that previously worked return 404, or redirect to unexpected places. Standard link checkers may not catch this if they don't execute JavaScript.

Running link checks manually before launches is table stakes. Links also break between launches — from deployments, third-party changes, and CMS edits.

A monitoring approach:

Daily automated checks on critical paths:

  • Main navigation links all lead to correct destinations
  • Primary CTAs ("Sign Up," "Start Trial," "Contact Us") lead to correct pages
  • Checkout and account flows are navigable

Weekly automated checks on broader content:

  • Blog/resource links
  • Footer links
  • Sitemap URLs all respond correctly

On-demand checks after changes:

  • Full crawl after any URL structure change
  • Redirect verification after migrations

HelpMeTest can monitor link destinations on a schedule:

Monitor primary navigation for example.com:

Every 15 minutes:
- Verify "Home" leads to /
- Verify "Features" leads to /features with correct content
- Verify "Pricing" leads to /pricing with pricing table visible
- Verify "Sign Up" leads to /signup with registration form
- Verify "Login" leads to /login with login form

When any destination changes or fails, you get an alert.

Before launch

  • All internal links return 200 (run Screaming Frog or equivalent)
  • No redirect chains longer than 2 hops
  • All navigation links lead to correct destinations (manual check)
  • All primary CTAs lead to correct pages
  • All links in email templates are correct
  • 404 page exists and has navigation back to main site

After URL/structure changes

  • All old URLs redirect to correct new URLs
  • Redirects lead to correct final destinations (not just any 200)
  • Internal links updated to use new URLs directly
  • Sitemap updated

Ongoing monitoring

  • Navigation links monitored continuously
  • Primary CTAs monitored continuously
  • Checkout flow links monitored continuously
  • Weekly crawl for 404s across all pages

Start Checking What Actually Matters

  1. Run a basic 404 check first. Use Screaming Frog or an equivalent tool to find any dead links. Fix them.
  2. Manually verify critical link destinations. Click every link in your main navigation and every primary CTA. Verify you end up where you should.
  3. Set up automated destination monitoring. Use HelpMeTest to run the critical path checks on a schedule.
  4. Add checks to your deployment process. After every deployment, verify that navigation and CTAs still lead to the right places.

Zero 404s is a passing grade on the easy test. The harder test — do all links lead to the right places, and do those places work — is where the real work is.

Read more