Test Broken Links: A QA Guide

To test broken links is to deliberately check that every hyperlink on your site still resolves, before your visitors and Google find the dead ones for you. It is a repeatable quality-assurance task, not a one-time cleanup. This guide covers why links break, what they cost you, and how to build testing into your workflow with free tools, from a quick manual pass to automated pre-publish checks.

What testing broken links means

Link testing is a QA discipline. You request each URL a page points to and confirm the server returns a successful status rather than an error. The failure you are hunting is usually a 404. As MDN describes it, the 404 Not Found status code means the server cannot find the requested resource, and links leading to such pages are the broken or dead links a test is designed to catch.

A thorough test covers three link types:

• Internal links to your own pages.
• Outbound links to other websites that may have moved or vanished.
• Asset links to images, downloads, scripts, and stylesheets that can 404 just like pages.

Testing overlaps with a broken link search, but the emphasis here is on repeatable process: catching breakage as a habit rather than discovering a backlog during an audit.

Why links break

Links fail for the same handful of reasons on every site:

• Deleted or unpublished pages with no redirect in place.
• Changed URLs after a redesign, migration, or slug edit.
• Typos in hand-written href values.
• Moved media whose file path shifted while the link did not.
• Dead external destinations outside your control.
• Environment mismatches, such as staging URLs left in production content.

Because these happen continuously, a single test goes stale quickly. The value is in testing on a schedule and before every publish.

The cost of shipping broken links

Untested links carry a quiet but real cost:

• Wasted crawl budget. Google confirms in its guidance on HTTP and network errors that newly encountered 404 pages are not processed and their crawl frequency gradually decreases. Every dead link a crawler retries is attention taken from your live pages.
• Lost link equity. An internal link to a dead page passes no ranking signal, and inbound links to a 404 waste authority you already earned.
• Broken journeys. A visitor who hits a dead end may leave, raising bounce and lowering trust.
• Slower discovery. Broken internal links weaken the path crawlers use to find your newer content.

None of this is a manual penalty, but together it erodes performance. Our overview of broken links and their SEO impact unpacks each effect.

Methods to test broken links

No single method catches everything. Layer them by effort and coverage.

1. Manual spot checks. Before publishing a page, click its key links or use a link-highlighting browser extension that colors dead ones. Fast and useful for a single page, but it does not scale to a whole site.
2. Full-site crawl. A crawler such as the free tier of Screaming Frog SEO Spider requests every link and reports status codes. Filter for 4xx and 5xx to get your failure list. This is the workhorse of link testing.
3. Google Search Console. The Pages report shows URLs Google found returning Not found (404). This tells you which dead links the crawler actually hit, which doubles as a priority signal. See our Google Search Console for SEO guide.
4. Automated and scheduled checks. Command-line link checkers and CI steps can run on a schedule or on every deploy, failing the build or emailing you when a link breaks.

Build testing into your workflow

The point of testing is to make it routine so nothing rots between audits:

• Before publish: a quick manual or extension check on the specific page.
• On a schedule: a full crawl weekly for active sites, monthly for stable ones.
• On deploy: an automated link check in your pipeline for teams that ship frequently.
• Around migrations: a dedicated test on staging and again on production.

Continuous monitoring services, including 404Pulse, automate the scheduled layer by crawling on an interval and alerting you the moment a new broken link appears, so you fix one link instead of a pile.

How to read the results and fix them

A test gives you status codes. Translate them into action:

• 404 or 410: the target is missing. Correct the link, restore the page, or redirect if a replacement exists.
• 301 or 302: the link works but redirects. Update the link to point at the final URL to avoid unnecessary hops.
• 500 or 503: a server error, which may be temporary. Re-test before assuming the link is dead.
• Timeouts: often a slow external host. Re-test, and if it persists, treat the link as unreliable.

When the fix is a redirect, choose the type deliberately. Google states in its redirects documentation that a permanent (301) redirect signals the target as canonical, while a temporary (302) does not, so use 301 for permanent moves to preserve ranking. Verify the redirect resolves in one hop with a redirect checker, then re-test the original link to confirm it now passes.

Do not forget asset and speed testing

Broken links are not only anchor tags. Missing images, scripts, and stylesheets return errors too, and a broken script can degrade a page far more than a dead text link. A good test crawl reports these alongside page links. Since missing or heavy assets also affect load performance, pairing link testing with a look at your Core Web Vitals gives you a fuller picture of site health.

Common mistakes when testing links

Even teams that test regularly leave gaps. Watch for these:

• Testing only the homepage. The homepage is usually the healthiest page. Deep pages, old posts, and archived content hold most of the dead links, so test the whole site.
• Ignoring assets. A crawl that checks only anchor tags misses broken images, scripts, and downloads that also return errors and can break functionality.
• Skipping rendered and authenticated views. Links added by JavaScript or shown only to logged-in users are invisible to a basic crawl. Enable rendering and run an authenticated pass where needed.
• Trusting a single failed check. External hosts have brief outages. Confirm a failure with a re-test before you redirect or remove a link.
• Testing after launch only. The cheapest time to catch a broken link is on staging, before it ships.

Avoiding these keeps your test results honest and your fix list focused on real problems rather than false alarms.

Frequently asked questions

How do I test all the links on my website?

Run a crawler such as the free tier of Screaming Frog across your domain and filter the results for 4xx and 5xx status codes to list every failing link. Cross-check against the Not found report in Google Search Console, which shows the dead URLs Google actually encountered. Together they cover both on-page links and crawler-observed errors.

How often should I test for broken links?

Test key links before every publish, run a full-site crawl weekly for active sites or monthly for stable ones, and add an automated check on deploy if you ship frequently. Always test around migrations, on staging before launch and on production right after, since migrations create the most broken links.

Can I test broken links for free?

Yes. The Screaming Frog free tier crawls up to a set URL limit, Google Search Console reports Not found URLs at no cost, browser extensions highlight dead links on a page, and command-line link checkers can be scheduled for free. Most small and medium sites can be tested thoroughly without paid tools.

What should I do when a test finds a broken link?

Identify the failure type first. For a 404, correct the link, restore the page, or add a 301 redirect to a relevant live page. For a redirect status, point the link at the final URL. For a server error or timeout, re-test before acting, since it may be temporary. Then re-run the test to confirm the fix.

Does testing broken links improve SEO?

Indirectly, yes. Removing broken links stops wasting crawl budget on dead URLs, preserves the link equity that internal and inbound links pass, and keeps user journeys intact. Google does not reward the absence of broken links directly, but fixing them removes drag that can otherwise weaken performance over time.