Quick answer
If you have replaced a PDF or an image and you are still seeing the old one, do not replace it again.
Work out what is showing you the old version first. The file on the server is very often correct while something in front of it — your CDN, your page cache, your browser, or a generated image size — is still handing out the old copy.
Go in this order:
- check the replacement actually succeeded
- open the file’s own URL, not the page that links to it
- work out whether it is your server or your CDN
- purge that one file
- rule out your own browser
- check the page HTML and, for images, the generated sizes.
Step 1: check the replacement succeeded
Look at the result of the batch.
Confirm it replaced the file you meant, that it finished, that it was not held back because the file is used elsewhere, that two files were not aimed at the same place, and that the backup was written.
If the replacement failed, no amount of cache-clearing will help.
Step 2: open the file’s own URL
Do not only load the page that links to it.
Open the file itself:
https://example.com/wp-content/uploads/.../guide.pdf
For an image, open the exact image URL the page is using.
If that shows the new file, the file is fine and something in front of it is stale — your page cache, cached HTML, your browser, a generated image size, or a different URL entirely.
If that shows the old file, the problem is closer to the file itself. Keep going.
Step 3: is it your server, or your CDN?
Sites behind Cloudflare, Fastly, Bunny, CloudFront, a host’s own CDN or an optimization layer can serve a cached copy without ever asking WordPress.
The response headers usually tell you: Age, Cache-Control, ETag, Last-Modified, and whatever cache-status header your CDN adds.
A large Age, or a straight cache hit, is your answer.
Step 4: purge as narrowly as you can
Purge that one file’s URL rather than flushing the whole site.
It is less disruptive, it is much easier to tell whether it worked, and it does not make every other page on your site slow for the next hour.
If your site caches files as though they will never change, and you are changing files in place, those two things are in conflict — see the last section.
Step 5: rule out your own browser
Try a private window, a different browser, a different device, and a hard reload.
Adding ?test=1 to the URL is a quick way to see whether the server has the new file — but remember that is not the link anybody else has, so it proves the server is fine, not that the problem is solved.
Step 6: check the page itself
Sometimes the file is new and the page is still pointing at the old one.
That happens when a page builder cached its markup, when your page cache is holding old HTML, when a shortcode’s output is cached, or when a custom field changed but the page did not get rebuilt.
Look at the actual link or image address in the rendered page and see which file it names.
Images have an extra layer
WordPress makes several sizes of every image.
The original can be new while the thumbnail, medium, large, a custom crop or a WebP version are all still the old one.
Check which of those the page is actually using. You may need to regenerate the image sizes.
PDFs: check the contents, not the filename
Browsers cache PDFs and their viewers happily.
Open the document and look for something you know changed — a date, a title, the corrected sentence, the page count. The filename tells you nothing about which version you were served.
Example: a CDN still serving the old PDF
WP Bulk Replace reports a successful replacement. The file on the server is correct. The public URL still returns the old PDF, and the response headers show a cache hit with a high Age and a long max-age.
The fix is to purge that one URL. Replacing the file a second time would change nothing.
Stable URLs and aggressive caching pull in opposite directions
Replacement workflows want the URL to stay the same, so existing links keep working.
Aggressive caching assumes a URL’s contents never change.
If you deliberately change files in place, you need a way to clear the cache when you do. If you would rather cache forever, use a new URL each time — but then existing links have to be updated, which is the thing you were avoiding.
FAQ
Would renaming the file fix it?
It would, because it creates a different URL the cache has never seen. It also breaks every link anyone already has, which is usually the reason you replaced the file in the first place.
Can WordPress’s object cache serve an old PDF?
Not usually — static files are served without going through it. But the page or the field pointing at the file can be cached separately.
Should I clear my browser cache first?
It is a quick test, so yes, but check the server and CDN too. You do not want to tell every visitor to clear their browser when the CDN is the one holding the old file.
Should I just replace the file again?
Not unless you have confirmed the first one failed. Replacing something that already worked adds noise and does not touch a cache.
Summary
Work outwards from the replacement: did it succeed → what does the file’s own URL show → is the CDN holding it → is it your browser → is the page pointing somewhere else → is it a generated image size.
Find the stale layer before you change the file again.
Related: Replace PDF without breaking links · Undoing a replacement · Optimized image replacement