At a glance
Check a PDF download as an anonymous reader, follow permitted redirects and verify the actual response is the intended document. Record the final address, observed outcome, date and source revision. A working authenticated browser tab is not sufficient evidence of public availability.
An HTTP outcome explains retrieval, not the accessibility of the downloaded PDF.
| Observed outcome | Interpretation | Owner follow-up |
|---|---|---|
| 200 with PDF bytes | Retrieval succeeded | Check current revision and document usability |
| 200 with HTML login | Not a public PDF response | Provide an appropriate public route |
| 403 | Request refused | Review anonymous access policy |
| 404 | Resource not found | Fix stale link or publication |
| 429 | Request rate limited | Respect policy and retry allowance |
Scroll sideways to see all columns. Use arrow keys when the table is focused.
Remove session assumptions
Use a private browser session or a controlled request without account cookies. Check both the page link and the direct download. A viewer can hide a redirect, use a cached file or fetch from a signed endpoint, so keep the final retrieval result in the log.
Inspect the content type and the actual document bytes through an approved tool. A .pdf extension and a 200 response are useful hints, but neither proves that the response is a PDF. A server can return a human-readable error page with a success status.
- Record the page that exposes the download link.
- Test the link without a signed-in session.
- Record each relevant redirect and the final outcome.
- Confirm the intended PDF revision and count result.
Keep an actionable, safe issue log
Store the address, request kind, observed HTTP code when present, fixed reason label, attempt date and owner action. Do not copy response bodies, session cookies or authorization headers into a spreadsheet. Remove credentials and temporary tokens from shared URLs.
Keep refused, missing, timed-out and rule-skipped addresses distinct. A rule skip was not a request to the server. A request failure may be temporary, while a wrong link can require a publication change. Record a new test separately instead of overwriting the earlier observation.
Verify the fix in the same context
After the owner corrects a link or access policy, repeat the anonymous retrieval and compare the final document revision. Preserve the previous outcome so the fix is traceable. If a new export changes the bytes, do not reuse an old count or accessibility finding as if the document were unchanged.
A clean link audit establishes retrieval within its tested context. It does not establish accessible reading order, labeled forms, usable tables or comprehensive site discovery. Use the linked conversion and accessibility guides for those separate checks.
| Field | Record |
|---|---|
| Before | Observed failure and time |
| Change | Owner’s link or hosting correction |
| After | Anonymous result and source revision |
| Next check | Count and document-review outcome |
Scroll sideways to see all columns. Use arrow keys when the table is focused.
Sources and scope
Methods, worksheets and illustrative examples are DocAccessible editorial contributions. These references support the technical or product details described above. W3C techniques are informative guidance; they are not a certification scheme.
- RFC 9110: HTTP Semantics
HTTP response meanings, including redirects, refusals and missing resources.
- RFC 9309: Robots Exclusion Protocol
How crawl rules work; robots rules are not access authorization.
- DocAccessible PDF inventory
The counting workflow, report options and purchase boundary.
Written by the DocAccessible team under our editorial policy. Suggest a correction if a source or product detail needs updating.
See the evidence in a working example
Explore the public sample inventory report to try its table, full-screen view and missing-count reasons. The downloadable counting fixture check records what the local counter returned for seven self-authored inputs, with hashes and explicit limits.