For a public page, the W3C Link Checker accepts its URL and checks links, anchors, and referenced objects. Start with one page. Keep recursive checking off until you need a wider crawl and have defined its scope.
Check the page at the address readers will use
Open the finished public URL, copy that address into the checker, and run the check. A local file path such as C:/work/resources.html is not a public URL the remote service can retrieve. Keep private pages in your authorized local or internal checking process; publishing a private draft merely to scan its links adds an unnecessary exposure.
Record the page URL and check date with the findings. Relative links resolve from that location, so a file tested in one folder can behave differently when published elsewhere. The relative-path guide explains that distinction.
Sort the findings before changing links
| Finding | What to investigate |
|---|---|
| 404 | Check the spelling and whether the target moved or was removed |
| Redirect | Open the final destination and confirm it is the intended replacement |
| 401 or 403 | Check the required access; do not assume the page is missing |
| Timeout or temporary server failure | Retry later and inspect the destination directly |
| Missing fragment target | Compare the text after # with the target document's IDs |
MDN's HTTP status reference distinguishes successful responses, redirects, and client or server errors. Keep those categories separate in your repair list. A checker denied access may be unable to evaluate a page that your signed-in readers can open.
Leave redirect details visible on the first pass. A redirect to a replacement article may be fine; a redirect to a generic home page may leave the original question unanswered. Recursion can multiply findings across many pages, so expand it only after fixing and understanding the first page's results.
Compare a small resource list with its intended destinations
This original fictional review shows why both automated and human checks matter. The outcomes are illustrative, not a live scan:
| Link text | Observed condition in the example | Repair decision |
|---|---|---|
| Registration | Opens a working page for a previous event | Replace with the confirmed current event URL |
| Preparation guide | Returns 404 after a filename changed | Find the maintained guide and update the href |
| Refund terms | Page opens, but #cancellations has no matching section |
Use the current section ID or link to the page |
| Staff checklist | Requires an authorized staff login | Confirm that the intended audience has that access |
Do not replace the staff link with a public copy simply to obtain a green result. The intended audience and access requirement determine whether the link is useful.
Repair the source, then rerun the same scope
Find the reported link in the maintained HTML. Check both its href and visible text. If the resource changed, its old label may misdescribe the replacement even after the URL works.
For an in-page link, use a unique destination ID and the matching fragment. The anchor-link guide covers that syntax. For a downloadable file, confirm the actual file and format rather than changing an extension to make the address look right.
After saving and publishing through your normal process, rerun the checker against the same page and reopen each repaired destination. Confirm the relevant title, date, section, or file content. Test the links a reader must use to complete the page's main task, including the current registration destination in the example.
Keep unresolved findings with a concrete reason: access required, replacement unknown, or a temporary failure awaiting another check. Finish with a page whose links lead to the intended resources, plus a short list of anything you still cannot verify.