Why do visitors still see an old PDF after you replace it?
A manufacturer corrects a dimension in a catalogue and uploads a replacement PDF. A colleague opens the website and still sees the previous document. Asking every visitor to clear their browser is an unreliable release process. Start by identifying the exact document and link involved, then investigate cached copies. The manufacturer here is an illustrative example, not a reported client incident.
Make the version visible inside the document
A filename and cover image may remain identical across revisions. Put a version identifier and the actual update date inside the PDF. Choose the corrected table as another inspection point and record which row changed. This turns a vague report about an old file into a repeatable comparison. Check the downloaded document itself rather than relying on the browser tab title.
Separate caching instructions from deletion
MDN’s caching guide distinguishes browser and shared caches. no-cache requires validation before reuse; it does not mean nothing is stored. Adding no-store does not automatically erase existing cached copies. Versioned URLs let changed assets have new addresses. Diagnose which layer supplies an old response before changing the whole site’s caching policy.
Use a stable page with a versioned file
An illustrative /documents/assembly/ page can remain the permanent entry point while its download button targets assembly-v2.pdf. A later correction changes the target to v3 without another promotional page. Display language, scope and version beside the link. Visitors can bookmark the stable page, while the downloaded file has an unambiguous identity. This is a publishing recommendation, not a requirement for every document system.
Decide what an older link promises
An earlier PDF address might appear in a quotation. Decide whether that address represents a historical edition or the latest available information. Silently replacing an archived document can make the quotation difficult to interpret later. Give the sales team the stable download-page link for future sharing. Ask the content owner which versions must remain available instead of applying one redirect rule to every file.
Check three routes to the document
First, open the new file directly and inspect its internal version. Next, use the actual download button and confirm the same content appears. Finally, repeat the journey in a previously used browser. A fresh session only represents a fresh visit. If a CDN is involved, inspect its relevant refresh mechanism for both page and document. Disabling caching everywhere is a poor substitute for locating the mismatch.
Keep a matched rollback pair
Preserve the earlier page and document together. If the new PDF contains an incorrect measurement, changing only the button may leave a misleading version label. Record the file address, document version, verification time and result. A compact release note gives the next editor a reliable starting point. Include older shared links in the verification record so their intended behaviour is explicit.
Include downloads in website acceptance
The technical document library guide covers organisation; this article addresses which revision opens. Include that journey in a website project acceptance checklist. A successful upload notification is intermediate evidence. The useful outcome is a visitor opening the intended document, including when arriving through an older shared link.
Frequently asked questions
Is changing the filename enough?
No. Update the download target and visible label, then inspect the downloaded file.
Should every previous PDF be deleted?
Not automatically. Review archive and quotation needs, and keep the route to the current edition explicit.