I Built a Free 500-Page Broken Link Checker — Looking for Honest Feedback
Hey Indie Hackers,
I recently built PAH Broken Link Checker, a free browser-based tool for website owners, bloggers and developers.
It can scan up to 500 pages and separates results into:
- Working links
- Broken links
- Redirects
- Internal and external links
- Blocked requests and connection errors
I built it after noticing that some link checkers classify every non-200 response as broken. For example, a 403, 429, timeout or temporary server error often requires manual verification rather than immediate removal.
The tool also shows the source page where each link was found and allows users to export the results as CSV.
I’m now trying to improve the tool based on real usage rather than adding random features.
I would appreciate honest feedback on:
- Is the interface immediately understandable?
- Do the status categories provide enough information?
- Which feature would make the tool more useful in a real SEO workflow?
- Would scheduled scans or email alerts be valuable?
You can test it here:
https://proarticleshub.com/broken-link-checker/
I’m especially interested in feedback from developers, SEO professionals and website owners. Please be direct—even critical feedback would be useful.
Thanks!
The categorization is useful, but I’m curious where users still lose the most time after the scan.
Is it figuring out which links actually need fixing, or just finding them?
Good question. Finding the links is mostly solved by showing the exact source page. The bigger challenge is deciding what actually needs fixing, especially with 403, 429, timeouts and temporary server errors. I’m considering adding a recommended action for each result, such as “replace,” “update redirect,” “retry later,” or “verify manually.” Would that be useful in your workflow?
Yes — especially if it reduces the “is this actually broken?” judgment rather than just adding another label. Have users already been asking what they should do with ambiguous results?
Not enough users yet to call it a repeated request, but it came up during my own testing when valid links returned 403s, rate limits, or temporary errors. That’s why I’m validating it before building. I’m leaning toward short recommended actions with a confidence level, while keeping the raw HTTP status visible.
That distinction is interesting — especially whether the recommended action actually saves users from making that judgment themselves. I’d be interested in digging into that a bit more privately. What’s the best email to reach you on?