Broken Link Scanner — Check Page Links and HTTP Errors

Broken Link Scanner At a Glance

A page can contain dozens of links that look correct until a visitor follows one. Deleted articles, reorganized product collections, mistyped paths, and external websites changing their URL patterns can all leave a trail of dead destinations. This scanner reads the links from a supplied HTML page, resolves relative paths against its original address, removes repeated destinations, and offers a limited live status check. Results identify confirmed failures without treating every inaccessible site as broken. A 403 response can mean a website is protecting itself; a timeout may reflect temporary congestion. Neither proves that the destination has disappeared. The report includes individual URLs, anchor text, status codes when available, final addresses, and a JSON download for follow-up work.

How to Check Links on a Webpage

Enter the full address of the webpage you want to examine, including its HTTP or HTTPS prefix. Leave the inspection method on public URL to retrieve its HTML, then choose whether to inspect only links on the same host or include outside destinations. You can include asset links as well, although a stylesheet, image, or downloadable PDF calls for different follow-up than a navigational link. Adjust the maximum number of links before running the scan; this version checks no more than 24 distinct destinations during one review. Once collection is complete, each selected link is checked individually, and its latest recorded status appears in the table. Export the report before moving on to another page if you need an audit record.

Interpreting 404, 410, 403 and 500 Responses

HTTP codes are clues about a destination, not interchangeable labels. A 404 indicates that the requested resource was not found at the time of the check; a 410 states that the resource is gone and is generally a clearer signal of deliberate removal. A 403 means the server refused the request, which can result from permissions, bot protection, or access policies. A 429 suggests rate limiting. A 500-series response points to a server-side failure and may be temporary. A healthy 200 response does not guarantee that the page contains the right material, while a 301 or 302 may lead visitors to a perfectly suitable replacement. Inspect redirects before treating them as broken. When the final URL matters, the redirect chain checker records the sequence instead of reducing it to a single label.

Internal Links Versus External Destinations

Internal links are usually easier to repair because the website owner can change both the linking page and the destination. A renamed category, an inconsistent trailing slash, or a deleted attachment may affect navigation, breadcrumbs, and editorial references. External links require a different decision: the original resource may have moved, become restricted, or stopped serving the subject it once covered. Start with internal links that appear in primary navigation or frequently visited pages. Then assess external references according to whether they still substantiate the surrounding passage. A working link to an unrelated homepage is not necessarily better than a reported 404. Fixing the destination is as important as removing the error.

Why Some Links Cannot Be Verified

Website operators use firewalls, geographic rules, login requirements, and bot detection, and some servers respond differently to HEAD and GET requests. A scan may therefore show an access restriction even when the page opens in a personal browser. The inspection endpoint operates under a strict response-size limit, checks robots.txt, validates public DNS addresses, and stops after a bounded redirect chain. It may refuse an otherwise valid page if these checks cannot be completed. Such outcomes belong in an unresolved review queue, not in the confirmed-broken total. Recheck a small number manually before requesting changes from developers. Do not bypass a site's access controls to force a green status.

Working from Saved HTML and Audit Exports

If your server is temporarily unavailable, or a website refuses automated retrieval, switch to the source-analysis method. Paste the HTML saved from the target page or choose a local HTML file, then supply the original URL so relative references resolve correctly. The scanner will extract linked destinations and anchor text, but it will not claim to know which remote servers are currently online. This can still be valuable when reviewing a staging-page export, comparing planned navigation with a launch checklist, or locating repeated URL patterns in a large content block. For a broad audit, collect several representative pages rather than assuming one page tells the story of the entire domain.

Repairing Link Errors Without Creating New Problems

When a linked resource has moved permanently, update the hyperlink to the most relevant current destination. If you control the original URL and it receives existing traffic or legitimate references, a permanent redirect may be appropriate. Avoid redirecting every removed page to the homepage regardless of subject; users expect the new page to answer the same question. For external references, find an authoritative alternative that supports the precise statement, or revise the claim when suitable evidence is no longer available. After changes, check the affected pages again, including navigation and canonical URLs. If the issue relates to status behavior rather than page content, an HTTP status checker offers a closer look at the server response.

Avoiding False Positives During a Crawl

Not every unusual status requires a site change. Redirects may be deliberate; blocked pages may be private; dynamically generated links may depend on authentication or JavaScript. A link with a fragment identifier can point to a heading inside the same document even though the fragment is never sent in an HTTP request. Search filters and tracking parameters can create several URL strings representing one underlying resource. The scanner removes duplicate normalized URLs but does not assume that different query strings are equivalent. Review destination content and navigation context before combining or removing links. Record the date of a scan because a failing external website can recover without any action by you.

Prioritizing Repairs by Visitor Impact

A useful repair queue combines technical evidence with the importance of the linking location. A dead checkout or contact link deserves urgent attention even if it appears on one page; a stale citation in an old article may be less immediate. Sort findings by confirmed error status, internal or external ownership, and whether the destination is exposed in menus, frequently shared pages, or key instructions. If you maintain several site sections, keep each scan's source page and timestamp together so that fixes can be traced to the right editor. The XML sitemap validator can help identify sitemap structure issues, but a valid sitemap is not a substitute for checking the links people actually click.

What the Scanner Cannot Establish

A status report does not determine whether a page is useful, safe, current, or relevant to a reader. The scanner does not execute all site JavaScript, submit forms, log in to accounts, or crawl an unlimited website in one operation. Its live checks depend on public network access and the hosting server’s PHP capabilities. Robots.txt restrictions are respected, and targets that cannot be safely resolved to public addresses are refused. A source-only report is deliberately labeled unverified because extracting an href does not test an HTTP response. Treat the results as one piece of an editorial and technical review, especially when repairing content on a site with redirects, login areas, and region-specific pages.

Checking Links After a Redesign or Domain Change

Website redesigns introduce particular link risks because templates, content editors, and redirect rules change at the same time. Before switching a site to a new design, gather a sample of existing high-traffic URLs and pages that contain menus, product cards, table links, or image captions. Run a scan on the old and new versions, preserving separate reports so unexpected new errors are easy to identify. Watch for staging hostnames accidentally appearing in production HTML, old image paths that no longer exist, and relative references that behave differently when a page moves into a deeper directory. Query strings can also break when redirects omit their parameters. Once the release is live, repeat the check from the public domain instead of relying only on a local preview. Fix the source link when you control it, and confirm that any planned redirect leads to the specific resource the visitor wanted. A careful post-launch review catches mistakes before they are repeated across dozens of pages by a shared template.

Frequently Asked Questions