How to Check If a Link Is Broken Before Citing It

A link that fails to load may be temporarily blocked, redirected, or unavailable only to an automated checker—not necessarily gone for good. Before citing a source, check the link’s HTTP response, open the destination in a browser, and judge whether the page is actually suitable evidence.

Key Takeaways

• Use an HTTP status check as a first clue, not a final verdict.
• Open the link in a browser and confirm that it reaches the expected page and content.
• A 403 or 429 response does not, by itself, prove that a page is permanently unavailable.
• If a source is gone, look for a replacement or an archived copy, then assess the source’s credibility and relevance separately.

Check the link’s HTTP response

Copy the complete URL, including its https:// scheme, and check it with an HTTP status checker or a command-line client. For example, with curl installed:

curl -sS -L --max-time 20 -o /dev/null \
  -w 'HTTP %{http_code}\nFinal URL: %{url_effective}\n' \
  'https://example.com/article'

This sends a GET request, follows redirects, discards the response body, and prints the final response code and URL. Replace the example URL with the link you want to check. The time limit helps the check finish if a server is slow, but it does not guarantee that every destination will respond within 20 seconds.

A response code is useful evidence, but it is not a complete account of what happened:

• 2xx, such as 200, usually indicates a successful response. Still check that the page contains the expected material.
• 3xx indicates a redirect. Following it may lead to the current page, a login screen, or an unrelated destination.
• 403 Forbidden means the server refused the request. Access controls, automated-request filtering, or other server rules can cause this; it does not establish that the page is permanently gone.
• 429 Too Many Requests means the server is limiting requests. Stop retrying rapidly and try again later or use a browser.
• 404 Not Found means the server did not find a current representation at that address. It does not prove the material never existed or cannot be found elsewhere.
• 5xx responses indicate a server-side problem and may be temporary.

A HEAD request can be quicker because it asks for headers without a response body, but some servers handle HEAD differently from GET. If a checker relies on HEAD, confirm an unexpected result with a normal browser visit or GET-based check.

Confirm the destination in a browser

Open the original link in a browser, preferably in a private window if you suspect a login session is affecting the result. Check these details:

1. Does the page load? Note whether you see an error, access-denied notice, login prompt, or security challenge.
2. Where did it take you? Compare the final address and page with the cited title. A successful redirect to an unrelated page is not a working citation.
3. Is the cited material still there? Search the page for the relevant quotation, data, or claim. A homepage or a changed article is not necessarily an adequate substitute.
4. Can another reader access it? A page available only through your institution, account, or region may not be accessible to your audience. Explain access limits when they matter.

Automated checks and browsers can produce different results because servers may treat automated requests and people’s browsers differently. A checker’s 403 alongside a page that opens normally in a browser is a reason to record the discrepancy—not to declare the link dead.

If the link does not work

First, rule out a copying error: check for missing characters, punctuation accidentally included at the end, and incomplete URLs. If the address redirects, decide whether the new page is genuinely the same source and still supports your citation.

If the page remains unavailable:

• Search the exact article title, author, organization, or a distinctive phrase in a search engine. Prefer the publisher’s current page or another primary source over a repost with unclear provenance.
• Search the publisher’s website, publication records, or the relevant organization’s site for a replacement URL.
• If no current copy is available, check the Internet Archive’s Wayback Machine for a saved version. An archived copy can help readers inspect an earlier page, but note its capture date and do not imply it reflects later updates.
• If you cannot verify the claim from a dependable replacement or archive, remove the claim, qualify it, or state that the source could not be retrieved. Do not cite a search-result snippet as if you reviewed the underlying page.

When you replace a dead link, revisit the cited passage and verify that the replacement supports the same claim. A similar title is not enough.

A working link is not automatically a good source

Link availability and source quality are separate questions. A 200 response does not establish that a page is accurate, authoritative, current, or relevant. A page may be reachable but outdated, misleading, or unrelated to the statement you cite. Conversely, an authoritative report may be temporarily inaccessible to an automated checker.

Assess the source itself: identify who published it, whether the author or organization is qualified for the subject, when it was published or updated, and whether it provides evidence for the specific point. For important claims, seek a primary document or independent corroboration. Choose a source because it supports the claim—not merely because its link works.

Common Mistakes

• Treating every non-200 result as proof that a source is gone.
• Assuming a 200 response means the destination contains the expected article.
• Checking only the redirect’s status without inspecting the final URL and page.
• Replacing a dead citation with an unverified repost or a search-result excerpt.
• Confusing link availability with credibility, accuracy, or relevance.

Best Practices

• Check links shortly before publishing, especially for time-sensitive work.
• Keep the original title, author, publisher, and access date with your research notes so you can search for a replacement.
• Use a browser to resolve ambiguous status-check results.
• Record an archive’s capture date when citing an archived page, and make clear that it is an earlier copy.
• Re-check the exact claim against any replacement source.

Conclusion

To check if a link is broken, combine an HTTP response check with a browser visit and a review of the destination’s content. If the source is unavailable, search for a trustworthy replacement or archived copy—and assess whether it is suitable to cite independently of whether it loads.

References

• RFC 9110: HTTP Semantics — Status Codes