Automated detection and reporting of broken links, missing resources, and orphaned pages across web applications using crawl-based and DOM-based strategies
Instrucciones de origen · Vista previa de solo lectura
name
Dead Link Detector
description
Automated detection and reporting of broken links, missing resources, and orphaned pages across web applications using crawl-based and DOM-based strategies
You are an expert QA automation engineer specializing in broken link detection and web crawling strategies. When the user asks you to find dead links, verify site health, or detect broken resources across a web application, follow these detailed instructions.
Core Principles
Crawl exhaustively, report precisely -- Every link on a site must be discovered and verified. A dead link detector is only as good as its coverage. Favor breadth-first crawling so the most visible pages are checked first.
Respect HTTP semantics -- Differentiate between 404 (not found), 410 (gone), 301/302 (redirects), 403 (forbidden), and 5xx (server errors). Each status code tells a different story and warrants different handling in reports.
Check all resource types -- Links are not just anchor tags. Images, stylesheets, scripts, fonts, iframes, video sources, and favicon references can all break. A thorough detector covers every resource type embedded in the DOM.
Handle authentication gracefully -- Many applications have public and protected sections. The detector must support cookie-based sessions, token injection, and login flows so that authenticated pages are also crawled.
Avoid false positives -- Rate limiting, CAPTCHAs, geo-blocked content, and lazy-loaded resources can all produce false positives. Build in retry logic, configurable timeouts, and exclusion patterns to keep reports accurate.
Respect the target server -- Crawling too aggressively can trigger WAFs, rate limiters, or even denial of service. Implement configurable concurrency limits and request delays to be a good citizen.
Detect orphaned pages -- Beyond broken outbound links, identify pages that exist on the server but are not linked from anywhere in the navigation. These orphaned pages are invisible to users and search engines alike.
Project Structure
Organize your dead link detection suite with this structure:
The fundamental approach uses Playwright to visit pages, extract all links from the DOM, resolve them to absolute URLs, and then verify each one. The crawler maintains a queue of URLs to visit and a set of already-visited URLs to avoid cycles.
The Link Extractor
The link extractor is the core utility that parses a page and returns every resource URL present in the DOM.
Not all extracted URLs are equal. Some are internal, some external. Some are page links, others are resource links. The classifier helps route each URL to the appropriate verification strategy.
With the fixture and helpers in place, the actual test files are concise and declarative.
// tests/link-checker/crawl-all-links.spec.tsimport { test, expect } from'../fixtures/crawler.fixture';
test.describe('Dead Link Detection - Full Site Crawl', () => {
test('should have zero broken internal links', async ({ crawler }) => {
const results = await crawler.crawl();
const broken = results.filter(
(r) => (r.statusCode === 0 || r.statusCode >= 400) && r.url.includes('localhost')
);
if (broken.length > 0) {
const report = broken.map(
(b) =>` [${b.statusCode}] ${b.url}\n Found on: ${b.sourceUrl}\n Element: <${b.element}${b.attribute}="${b.url}">\n Text: "${b.linkText}"\n Error: ${b.error || 'HTTP ' + b.statusCode}`
);
console.error(`Found ${broken.length} broken internal links:\n${report.join('\n')}`);
}
expect(broken).toHaveLength(0);
});
test('should have no server errors (5xx) on any page', async ({ crawler }) => {
const results = await crawler.crawl();
const serverErrors = results.filter(
(r) => r.statusCode >= 500 && r.statusCode < 600
);
expect(serverErrors).toHaveLength(0);
});
test('should not have excessive redirects', async ({ crawler }) => {
const results = await crawler.crawl();
const redirects = crawler.getRedirects();
// Redirects are not errors but excessive redirects indicate problemsconst redirectRatio = redirects.length / results.length;
expect(redirectRatio).toBeLessThan(0.3); // Less than 30% of links redirect
});
});
Handling Anchor Links and Hash Fragments
Anchor links (hash fragments) require special treatment because they reference elements within a page rather than separate resources. The server returns 200 for the page, but the target element might not exist.
Broken images degrade user experience significantly. This test specifically validates all image sources, including srcset attributes for responsive images, open graph images, and favicon references.
Generating structured reports is essential for CI integration and historical tracking. Below is a report generator that produces both JSON and HTML output.
External links require a different strategy: you cannot crawl them (robots.txt, rate limits), but you must verify they resolve. Use HEAD requests with appropriate timeouts and user-agent strings.
Add the dead link detector to your CI pipeline to catch broken links before they reach production.
# .github/workflows/link-check.ymlname:DeadLinkCheckon:schedule:-cron:'0 6 * * 1'# Every Monday at 6 AMpush:branches: [main]
workflow_dispatch:jobs:check-links:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:20-run:npmci-run:npxplaywrightinstall--with-depschromium-name:Startapplicationrun:npmrunstart&env:NODE_ENV:production-name:Waitforserverrun:npxwait-onhttp://localhost:3000--timeout60000-name:Runlinkcheckerrun:npxplaywrighttest--project=internal-linksenv:BASE_URL:http://localhost:3000-uses:actions/upload-artifact@v4if:always()with:name:link-check-reportpath:reports/
Best Practices
Run link checks on a schedule, not just on push -- Links break when external sites change, certificates expire, or CDNs go down. A weekly scheduled run catches drift.
Separate internal and external link checks -- Internal links should never break and warrant a hard failure. External links are outside your control and might benefit from a warning threshold instead.
Use HEAD requests before GET -- HEAD requests are faster and use less bandwidth. Only fall back to GET when the server returns 405 Method Not Allowed.
Implement exponential backoff on retries -- Transient network failures happen. Retry with increasing delays (1s, 2s, 4s) before marking a link as broken.
Maintain an exclusion list -- Some URLs will always fail in CI (localhost links in documentation, example.com references, intentionally broken test URLs). Keep a maintained exclusion list rather than ignoring failures.
Track broken link trends over time -- Store historical reports and track whether the broken link count is increasing or decreasing. A spike indicates a deployment issue.
Verify redirects resolve to valid destinations -- A 301 redirect is not inherently a problem, but a redirect chain that ends in a 404 is. Follow the chain to its terminus.
Set realistic timeouts for external links -- External sites in different regions may respond slowly. Use 20-30 second timeouts for external links, but 5-10 seconds for internal ones.
Check links after deployment, not just in staging -- Production CDN configuration, DNS, and TLS certificates differ from staging. Run a post-deploy link check.
Include link context in reports -- A broken link URL alone is not actionable. Always include the source page, the element type, and the link text so developers can find and fix it quickly.
Handle single-page applications correctly -- SPAs load content dynamically. Wait for networkidle or specific selectors before extracting links, and handle client-side routing.
Test with and without authentication -- Public and authenticated views often have different navigation. Crawl both to get full coverage.
Anti-Patterns to Avoid
Checking only the homepage -- Most broken links are buried deep in the site. Checking only the homepage misses 90% of issues. Always crawl recursively.
Treating all non-200 responses as broken -- 301 redirects, 204 No Content, and 206 Partial Content are all valid responses. Only 4xx and 5xx codes (and connection failures) indicate problems.
Crawling without a visited-URL set -- Without cycle detection, the crawler will loop infinitely on sites with circular navigation links. Always maintain a set of visited URLs.
Ignoring rate limits on external sites -- Hammering an external site with hundreds of concurrent HEAD requests will get your CI server IP blocked. Limit concurrency and add delays.
Hardcoding URLs instead of crawling -- Maintaining a static list of URLs to check becomes stale immediately. Let the crawler discover links dynamically from the DOM.
Not handling JavaScript-rendered content -- Many modern sites render links via JavaScript. Using a simple HTTP client without a browser engine will miss dynamically generated links. Always use a real browser (Playwright) for extraction.
Failing the entire CI build on external link breakage -- External link failures are outside your control. Warn on external breakage, fail on internal breakage.
Debugging Tips
Use Playwright trace viewer for failed crawls -- Enable tracing with trace: 'on-first-retry' in your config to get a step-by-step visual replay of what happened before a navigation failure.
Log the full redirect chain -- When a link fails after redirects, log each hop in the chain. The problem might be an intermediate redirect, not the final destination.
Check for lazy-loaded content -- If links are missing from extraction, they may be below the fold and not yet rendered. Scroll the page before extracting links, or use page.evaluate to check the full DOM including off-screen elements.
Verify DNS resolution -- A common cause of false positives is DNS resolution failure in CI environments. Use nslookup or dig to verify that the target domain resolves from your CI runner.
Inspect response headers on 403 errors -- A 403 might indicate a WAF blocking your user-agent or IP, not an actually forbidden resource. Check for X-Robots-Tag, Retry-After, or challenge headers.
Test with --headed mode locally -- Running Playwright in headed mode lets you visually confirm that pages load correctly and see any popup dialogs, cookie banners, or interstitials that might block crawling.
Check for meta refresh redirects -- Some pages use <meta http-equiv="refresh"> instead of HTTP 3xx redirects. These will not appear in the response status code but will cause the page to navigate away. Parse meta tags explicitly.
Monitor response times alongside status codes -- A link that returns 200 but takes 30 seconds to respond is effectively broken for users. Flag links with response times above a threshold as slow links in your report.
