Quick answer
Before you replace a file, find every place that points at it — not just the page you happen to have open.
References live in page content, blocks, stored Media Library references, URLs pasted straight into a page, custom fields, plugin data and page-builder structures.
If something outside the job you approved depends on that file, stop and sort that out before overwriting anything.
Checking where a file is used is really about checking what you are about to change.
The page in front of you is not the whole story
You open a page, you see “Download Application”, and it is natural to assume that PDF belongs to that page.
The same file might also be in the footer resources, in an FAQ, on another department’s page, in an email template, or inside a custom post type.
Replace the file and all of them change.
How the reference might be stored
A reference to the Media Library entry. Some fields store an ID like 4812 and look the file up from that.
A direct URL. Other content just has https://example.com/wp-content/uploads/.../application.pdf written into it.
A custom field. A plugin may keep the ID or the URL in its own data.
Page-builder data. The reference may be buried inside whatever structure the builder saves.
Those all need looking for in different ways, which is why “search the post content” finds only some of them.
“Attached to” does not mean “used by”
WordPress records which post a file was uploaded to. That is useful but it is not a list of everywhere it is used.
A URL somebody pasted into a paragraph will not show up there at all. Neither will a custom field pointing at it.
When sharing is deliberate
One current benefits guide is linked from 12 department pages, and the organization wants all 12 to update together.
That is the system working. Replace it once, twelve pages are correct.
When it is a mix
The same PDF is on both the Current Policies page and the 2025 Archive.
Replace it and you have changed the archive too. Not safe until those two have their own copies.
How to check
1. Know exactly what you are changing. Which file, which entry.
2. Look everywhere you can. Every place the plugin knows how to search.
3. Sort what you find into three piles: inside the job you approved, outside it, and stored somewhere nothing can read.
4. Decide. If the outside ones should change too, widen the job deliberately. If not, give one of them its own copy.
5. Check again just before the write. The site can change between you reviewing and the batch running.
Why a warning is not enough
A warning only works if somebody reads it.
In a 300-row batch, warnings become wallpaper. Every row has something on it and the important one looks like all the others.
Stopping is stronger:
This row will not run until you decide what to do about the other page.
And it protects the rest of the batch, because everything else still runs.
Example: a spec sheet on three pages
A spec sheet is linked from product A, product B and the category overview page.
The new file was only approved for product A.
The check catches that the file is shared, and you can give product A its own copy instead of quietly changing product B and the category page as well.
What if a reference cannot be found?
Nothing can promise to find every reference on every site — custom code can store a file path anywhere it likes.
So the honest statement is “nothing I can see points at this”, not “nothing points at this”. Anything that treats unsupported storage as proof of no references is telling you something it does not know.
Before you replace, answer these
- Which exact file is about to change?
- What points at it that I can find?
- Are all of those inside the job I approved?
- Could anything be storing it somewhere I cannot see?
- Has that check been run again just before the write?
If you cannot answer those, you do not yet know what the replacement will do.
Related: Shared media files · Custom fields · Replace a document used on several pages