Broken Link Checker
Pull every link off one public page, test a sample for dead ends and redirect hops, keep the anchor text in view, then copy a CSV fix list.
A broken link checker takes one public page, pulls every link out of its live HTML server-side, then tests a controlled sample of the unique destinations so you can act on real problems instead of guessing. Paste a URL and pick your scope: chase only your own internal links first, or pull the external citations into the sample too. It chases the redirect hops so you see where each link actually lands, folds the duplicate destinations together, and parks the source anchor text right next to every reading. The point is that a hard 404, a link limping through a migration redirect, and an empty anchor are three different problems that want three different fixes, so it keeps them apart instead of burying them under one tidy score. Then it hands you a CSV you can work through one fix at a time. Built for the cleanup after a migration, a heavy content edit, or a theme swap that left a pile of old paths dangling.
Queries run through the PeopleAreGeek lookup service. We log nothing.
Page-level broken link repair audit
Give me one public page. I'll yank every link out of it. You decide whether I stick to your own URLs or pull the external ones in too, I chase the redirect hops so you see where a link actually lands, and I keep the truly dead stuff separate from the redirects you can tidy up whenever. Then you copy a short fix list and move on. Honestly it's just the thing I run after a migration or a heavy content edit, or when some theme swap leaves a pile of old paths dangling.
One page at a time, on purpose. I cap the sample of unique URLs so your browser doesn't seize up. Still plenty to surface the dead internal paths and stale redirects that actually bite.
What a broken link checker should help you fix
A broken link checker isn't really about the status code. On a live site a dead link is a broken promise, dropped right in the middle of someone reading. They click your guide, or a tool, or whatever you pointed them at, and instead of the next step they hit a wall. When the dead one is yours, you own both ends: the page it sits on, and the place it was supposed to send people. So internal links sit near the top of my maintenance list. Maybe higher than they should, honestly.
So I built this for the boring part. The repair part. It reads the anchors already in your HTML, folds the duplicate destinations together, then asks the site API what status and redirect path each unique URL comes back with, and parks the source anchor text right next to it. You get more than one angry red number. Because a hard 404 and a link limping through a migration redirect aren't the same problem, and an empty anchor is a third thing again, and the same nav link repeated forty times is barely a problem at all. They don't want the same fix.
Broken links, redirects and intentional removals are different
A 4xx or 5xx in your sample? Yeah, look at that one. A 301 chain is sneakier though. It can land on a perfectly healthy page and still be quietly telling you the source HTML is stuck on some old URL structure. And an intentional 404 or 410? Totally fine, when the content's gone and nothing good would replace it. What's not fine is a fresh internal link still aimed at it. The fix depends on the case: swap the URL, or reword the sentence, or just kill the call to action. Redirect only when a genuinely close substitute exists. Don't redirect to make the red go away.
- Checked URLs is the tested batch. Each unique destination, the status it finally settled on, and how many redirect hops it took to get there.
- Link inventory keeps every anchor I pulled, before I collapse the duplicates, so nothing slips past you.
- Source anchors tells you which wording (and how many repeated rows) point at a given destination.
- CSV copy hands you a tight little file for whoever's doing the editorial or migration cleanup.
- Scope is your call. Chase your own internal URLs first, or pull the external ones into the sample too.
A human repair workflow after a migration or content pass
- Go where the traffic is first. Nav, hubs, the evergreen guides, the tools people actually land on. Readers and crawlers keep circling back to those.
- Kill the obviously dead internal links before you fuss over external citations or footer noise nobody clicks anyway.
- If a redirected internal URL sits on a page you own, point it straight at the current destination. You control it, so why keep the detour.
- Read the words around the fix, not just the URL. A link can hand back a clean 200 and still leave the reader wondering what they were promised.
- Retest the page you edited. And if this started with a bigger site move, run it past your sitemap and redirect checks too.
Why this page-level check matters for SEO and trust
Technical SEO hurts a lot less when the paths a crawler follows actually match the site you're trying to keep alive. Clean internal links move people to the next page without a detour. They also make migrations far less brittle, and they stop your templates quietly advertising old URLs you forgot existed. Look, I'm not saying every link has to be flawless forever. That's a losing game. The journeys that matter just shouldn't rot while you keep stacking new stuff on top of them.
Frequently asked questions
Does this crawl my whole website?
No. That's deliberate. I look at the single page you hand me and test a sample of its unique URLs, nothing past that. Keeps the output small enough to actually act on instead of burying you. When you genuinely need the whole domain crawled, reach for a site-wide crawler or a scheduled job. Different tool, different day.
Should I fix redirected internal links even when they end in 200?
If it's your HTML, usually yes. The redirect earns its keep for old bookmarks and external links you can't reach. But inside your own pages a direct link is just cleaner. One less hop, and one less thing for whoever maintains this after you to babysit.
What is the difference between a 404 and a soft 404?
A real 404 is honest. The page is gone, the server says so, everyone moves on. A soft 404 is the one that causes grief: the page is empty or missing, but the server still hands back a 200, so search engines assume there's real content sitting there and get confused. Something's gone? Give it a true 404 or 410. Don't make a crawler guess.
Should I redirect or remove a broken link?
Depends what happened to it. Content just moved? 301 the old URL to the new home, done. Truly gone with nothing to replace it? Let it 404 or 410. That's the honest answer. The one thing I'd genuinely beg you not to do is funnel everything to the homepage. Google reads that as a soft 404 anyway, so you eat the downside and the redirect helps nobody.