Broken Link Checker - One Page, Up to 40 Links

Give it a single page address. It reads the links in that page and requests each one, then groups the results into broken, redirected and working, with the failures first.

One page, up to 40 links. This is not a site crawler.

It reads the page you name and stops there. It does not follow internal links into the rest of the site, so run it per page on the pages that matter rather than expecting a whole site report. Only the first 40 unique links on the page are requested, and you are told when there were more. Anchors, mailto and tel links are skipped because there is nothing to request.

The requests come from a ToolForte server, not from your browser, and identify themselves as ToolForteBot/1.0. Sites are entitled to block that user agent, and some answer automated requests with a 403 or a challenge page, so treat a single failure on a big site as a hint rather than proof. Each link is probed with a lightweight HEAD request, which a minority of servers refuse with 405 even though the page itself is fine. Always open a reported failure once before you edit the link.

Finding dead links on a page that matters

This checker takes one page address, reads the anchor tags in the HTML that comes back, and then requests each unique destination to see what it answers. Results are grouped into three buckets: broken, meaning a 4xx or 5xx status or no answer at all, redirected, meaning the link works but bounces through another address first, and working. Failures are listed first, each link is marked internal or external, and every entry stays clickable so you can confirm the verdict yourself in one click.

The people who need it usually have one specific page in mind. A blogger updating an article written four years ago, when half the tools it recommends have since been bought or shut down. A developer checking a footer or a documentation index after a route rename. A marketer auditing a landing page before a campaign, where a single dead link in the pricing table costs real money. It is a scalpel, not a site audit, and it is fastest when you already know which page you are worried about.

Links are extracted from the delivered HTML, so anything a JavaScript framework renders after load is invisible here, exactly as it is to a simple crawler. Anchors that stay on the page, along with mailto, tel and javascript links, are skipped because there is nothing to request. Each destination is probed with a HEAD request through four parallel workers, with a timeout of eight seconds per link and a hard stop after four redirect hops. Private and internal addresses are refused outright, so you cannot use this to probe a network from the inside.

The limits are worth knowing before you read the numbers. A maximum of 40 unique links per page are requested and you are told when the page held more. Only that one page is read, with no crawling into the rest of the site. A HEAD request is cheap but a small share of servers reject it with 405 while serving the same URL fine over GET, and bot protection can turn a healthy page into a 403. Two or three false positives in a long list is normal, which is why every result stays a live link.

Once you have a list of failures, the follow up work sits elsewhere on ToolForte. Look up an unfamiliar code in the HTTP Status Codes reference, plan the replacements with the Htaccess Redirect Generator, and use the HTTP Headers Checker to see whether a suspicious 403 is bot protection rather than a genuinely dead page. If the links are fine but the page still underperforms, the Meta Tag Checker is the better next step.

How the Broken Link Checker Works

  1. 01Enter one page address. This tool reads that page only and does not crawl the rest of the site.
  2. 02A ToolForte server fetches the page as ToolForteBot and extracts the unique http and https destinations from its anchor tags, up to a maximum of 40.
  3. 03Each destination is probed with a lightweight HEAD request through four parallel workers, with an eight second timeout and a limit of four redirect hops per link.
  4. 04Results are grouped into broken, redirected and working, with counts at the top and the failures listed first so the work is obvious.

Turning a list of failures into actual fixes

Read the broken group first and open each entry once before you touch anything. A 404 is usually genuine and means the page moved or died, so either find the new address or remove the link and rewrite the sentence around it. A 403 is more often bot protection than a dead page: many sites answer any unfamiliar user agent with a refusal while serving the same URL fine to a browser, and that is why every result here stays clickable. A 500 or a dead entry with no status at all can be a temporary outage, so it is worth re-running the check an hour later before you edit anything. A 405 usually means the server dislikes HEAD requests rather than the URL. The redirected group is a different kind of work. Those links function, so nothing is urgent, but each one costs the visitor a round trip and passes through an extra hop that can be broken later by whoever maintains the target. Updating the link to the final address it already lands on is a small, safe improvement, and it is especially worth doing for links that appear in a template or a footer, where the cost is multiplied across every page. Internal links are marked separately for that reason: those are the ones you control.

When to Use the Broken Link Checker

Use it on individual pages that carry weight rather than as a site wide sweep, because it deliberately checks one page at a time. Old articles are the best candidates, since link rot compounds with age and a post from four years ago will point at several products that have since been acquired or shut down. Resource lists and link roundups need checking most often of all. Run it on a landing page before a campaign starts, on documentation after a route rename, and on any page that lives in a template such as a footer or a navigation index, because one dead link there repeats across the whole site.

Common Use Cases

  • Refreshing an old blog post before you republish it, when half the tools it recommends may no longer exist.
  • Checking a resource list or link roundup, the page type where link rot does the most damage to trust.
  • Verifying a landing page before a campaign, where one dead link in a pricing table costs real money.
  • Planning replacements for the URLs that came back as 404 so visitors and search engines land somewhere useful. .htaccess Redirect Generator - Apache & Nginx
  • Deciding whether a suspicious 403 is bot protection rather than a genuinely dead page. HTTP Status Codes - Complete Reference

Expert Tips

  • Re-run a check an hour later before editing anything based on a 500 or a timeout. Transient outages produce failures that fix themselves.
  • Fix internal redirects even though they work. Those links are yours to control, and each hop is a round trip the visitor pays for on every page that shares the template.
  • Link to a stable landing page rather than a deep URL when you are citing an external resource. Deep paths are the first thing a redesign breaks.
  • When a page holds more than 40 links, check the section you care about on its own if it is reachable at its own address, rather than trusting a sample of the top of the page.

Frequently Asked Questions

Does this crawl my whole site?→
No, and that is deliberate. It reads the single page you give it and checks the links found on that page. It never follows an internal link to fetch another page of your site. If you want coverage across a site, run it on the handful of pages that actually matter, starting with old articles, resource lists and anything in a shared template.
Why is only part of my page covered?→
A maximum of 40 unique links per page are requested, in document order. When the page contains more you get a clear notice saying so, and the results are a sample of the top of the page rather than the whole thing. Navigation and header links usually consume the first few slots, so a page with a large menu has fewer slots left for its body content.
One of the failures works fine when I click it. Why?→
Three usual reasons. The site blocks the ToolForteBot user agent or answers automated requests with a challenge page. The server refuses HEAD requests with a 405 while serving GET normally. Or the site was briefly down when the check ran. That is why every reported link stays clickable: confirm it yourself before editing, and re-run the check later if a failure looks suspicious.
Are anchor links and email addresses checked?→
No. Links starting with a hash stay on the same page, and mailto, tel and javascript links have no address to request, so all of them are skipped before any requests are made. Only http and https destinations are checked, and private or internal addresses are refused outright for safety.

Related tools

12 suggested