Broken links can interrupt a visitor’s task, weaken trust, and make important pages harder to navigate. However, a failed automated check does not always mean that a link should be changed immediately. A destination may be temporarily unavailable, protected by authentication, blocking automated requests, or enforcing a rate limit. The safest approach is to treat every reported failure as a candidate for investigation rather than a final verdict.
This guide is for website owners, editors, content teams, and SEO practitioners who maintain internal or external links. It explains how to use the Broken Links Finder to identify possible problems and the Link Analyzer to review link context, then verify each important finding before editing a page.
A link checker requests a URL and interprets the response. A successful response usually suggests that the destination is reachable, while an error or unusual response identifies an issue to review. The result may still depend on timing, server rules, location, authentication, or how the request was made.
Verification combines the reported response with a manual review of the exact URL, the destination’s purpose, and the experience of an ordinary visitor. The correct repair may be to fix a typo, update a redirecting URL, choose a replacement, remove the link, or make no change until a temporary problem has passed.
| Outcome | Likely meaning | Recommended review |
|---|---|---|
| Page not found | The path may be wrong, moved, or deleted. | Check for typing errors, search the destination site, and look for an appropriate replacement. |
| Redirect | The URL sends visitors to another location. | Confirm the final page is relevant and safe before linking directly to it. |
| Server error | The destination server could not complete the request. | Retest later before assuming that the page has been removed. |
| Authentication required or access denied | The page may require an account, permission, or approved request. | Test as the intended audience and decide whether the restriction is clearly explained. |
| Rate limit | The server is temporarily refusing requests because too many were received. | Pause and retry later rather than editing links based on the first result. |
| Timeout or connection failure | The destination was too slow or unavailable during the check. | Repeat the test at a different time and verify manually. |
Example 1: A typo in an internal resource link. A staff guide links to a PDF, but the reported URL returns a not-found response. Manual review shows that the filename contains an extra hyphen. The corrected URL opens the intended current document. The safe repair is to correct the path, publish the edit, and test the link from the guide. Replacing it with a general document library would be less helpful because visitors expect the specific file.
Example 2: A temporary external failure. An article cites a public statistics page, and a check receives a server error. Opening the page also fails, but the organization’s main site remains available. The editor waits and retests later rather than deleting the citation immediately. If the page returns, no content change is necessary. If it remains unavailable, the editor can search the organization’s navigation for an official replacement and confirm that it supports the same statement.
Example 3: A restricted destination. An onboarding page links to an account portal that returns an authentication response. This is not necessarily broken. If the link is intended for registered users and the surrounding text says that sign-in is required, it may be functioning correctly. If the page is presented as a public help resource, the editor should replace it with a public explanation or clarify the access requirement.
A replacement should match the original link’s purpose, not merely share similar words. Confirm the publisher, topic, date, audience, and type of resource. For example, a current policy summary is not automatically a substitute for the full policy, and a category page is not equivalent to a specific downloadable form.
Redirects also require interpretation. A single redirect to the expected page may be harmless, while a redirect to a home page, unrelated article, expired domain, or generic error page provides a poor experience. Review the final destination and update the source URL only when the result is appropriate.
Safe editing rule: If you cannot confirm what the author intended or whether a replacement supports the surrounding content, record the issue for editorial review instead of guessing.
No automated link check can fully determine intent, editorial accuracy, or long-term availability. Results can vary because of network conditions, server configuration, geographic restrictions, authentication, bot controls, and rate limits. A reachable page may still contain outdated information, while an automated failure may work normally for a visitor.
Prioritize confirmed problems that block important tasks. Repair clear typos and verified moves first, monitor temporary failures, and escalate uncertain replacements to the person responsible for the content. For internal pages that were intentionally moved, consider whether navigation and redirects also need attention rather than correcting only one source link.
Does every reported failure mean a link is broken?
No. Temporary outages, timeouts, authentication requirements, access rules, and rate limits can all produce failures. Verify the URL manually and retest uncertain results.
Should I replace every redirected URL?
Not automatically. First confirm that the redirect ends at the expected resource. Updating the link can reduce unnecessary steps, but only when the final URL is stable and appropriate.
When should a link be removed?
Remove it when the destination is permanently unavailable, no trustworthy equivalent exists, and the surrounding content remains useful without it. Rewrite the sentence if removal leaves an unsupported claim or incomplete instruction.
How should I handle a page that requires sign-in?
Decide whether authentication is expected for the intended audience. Keep the link if it is useful and clearly labeled; otherwise, provide a public alternative or explain the access requirement.
What should I do after receiving a rate-limit response?
Stop repeated requests and try again later. A rate limit describes temporary request handling, not necessarily the condition of the destination page.
How do I know whether a replacement is suitable?
Compare its purpose, publisher, audience, date, format, and supporting information with the original link and surrounding text. If the match is uncertain, seek editorial confirmation rather than making an assumed substitution.
Last reviewed: July 28, 2026