Ask Claude to Find and Fix Broken Links in Your Documentation and Code
Broken links in documentation erode trust. A new developer clicks a link in the README expecting setup instructions and gets a 404. Claude Code can scan your project for URLs and verify they all still work.
Find all URLs in README.md, docs/, and code comments.
Check if each one is still valid. Flag any that return 404,
redirect to a different page, or point to archived/deprecated content.
Claude searches for URLs across your documentation and source files, fetches each one, and reports the results:
✓ 23 links — working
⚠ 3 links — redirect to new URLs (should update):
- docs/setup.md: old GitHub wiki link → redirects to new docs site
- README.md: Travis CI badge → project now uses GitHub Actions
❌ 2 links — broken (404):
- CONTRIBUTING.md: link to old code of conduct page
- src/config.js: comment referencing removed API endpoint docs
Target specific types of link rot:
# Check documentation links
Scan all Markdown files for links. Verify internal links point to
files that exist and external links are still live.
# Check code comments
Find all URLs in code comments across src/. These often reference
Stack Overflow answers, GitHub issues, or API docs that move.
# Check package references
Verify that all URLs in package.json — homepage, repository,
bug tracker — are correct and point where they should.
# Fix what you find
For broken links, search the web for the current URL and update it.
For links that can't be found, remove the dead reference and add
a note about what it used to point to.
This is especially valuable before open-sourcing a project or onboarding new team members — first impressions matter, and a README full of 404s signals a project that's not maintained.
Broken links are silent failures that nobody reports — let Claude find them before your users do.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.