Quick answer
One file in WordPress can be used by several pages, posts, custom fields or products.
Replace the file and every one of them changes at once.
So before you replace anything, find out whether that sharing is deliberate. If something outside the job you approved depends on the same file, the safe thing is to stop that row until you know what you are changing.
When sharing is what you want
One current membership application is linked from five pages.
Replace it and all five pages serve the new version. That is exactly right, and doing it any other way would mean five copies to keep in step.
When sharing is an accident
A current-policy page and a 2025 archive page happen to use the same PDF.
Replace it and you have just rewritten the archive. Nothing failed, nothing warned you, and the history is gone.
Where a file can be referenced from
- the page content itself
- blocks
- a stored reference to the Media Library entry
- a direct URL pasted into a page
- custom fields
- plugin data
- page-builder data.
The “Attached to” column in the Media Library does not show all of these. A URL somebody pasted into a paragraph will not appear there at all.
Why “outside the batch” is the line that matters
If the file is used by something you did not review, replacing it has effects you did not approve.
That is worth stopping for rather than warning about.
What you can do about a blocked row
- widen the job to include the other pages on purpose
- give one of them its own copy of the file
- point the new file somewhere else
- skip it
- publish it as a new document instead.
Check again just before the write
Somebody can add a link to that file between you reviewing the batch and running it.
The check is worth doing again immediately before anything is overwritten, not only when you first looked.
Example
A batch has 100 replacements. One PDF is also linked from an archive page that is not part of the job.
That one row stops. The other 99 carry on.
What a blocked row should tell you
A row that stops should say where it was going, how many things reference that file, which of those are outside this job, why it stopped, and what you can do about it.
“Shared file detected” on its own just makes you go and find out the whole thing yourself.
What to do, at a glance
| Situation | Safer action |
|---|---|
| Everything using it should get the new file | Approve the shared replacement |
| One page must keep the old version | Give it its own copy first |
| It is aimed at the wrong place | Send it somewhere else |
| You cannot work out what uses it | Skip it |
| It is really a new edition | Publish it as new |
Be honest about what can be found
A plugin can only look in the places it knows how to look. Custom code can hide a reference anywhere.
So there is a real difference between “nothing I can see references this” and “nothing anywhere references this”. Only the first is ever true, and anything claiming the second is overstating it.
This applies to images too
A logo or a product photo can be used on dozens of pages.
Replacing it once is often exactly what you want.
But two campaigns that happen to share one image may need their own copies, even though WordPress currently has them pointing at the same file. Shared-use checking is not only a PDF concern.
“In the batch” means pages, not filenames
Scope has to be about what is affected, not what was uploaded.
If three rows in your batch and one page outside it all point at the same file, that outside page is still going to change. Counting only the incoming files would miss it entirely.
A block should not kill the batch
One shared file should not fail the other 99 rows.
Hold that row, let the safe ones run, and come back to it. All-or-nothing turns one awkward document into a wasted afternoon.
Shared file, or two copies?
Two pages showing the same document can be built two ways: both pointing at one file, or each with its own copy.
The first makes updating everything at once easy. The second makes updating one of them easy.
Neither is right in general. What helps is being able to see which one your site is actually doing before you replace anything.
Sometimes the block is telling you something
A shared-file conflict often means the site’s content structure grew awkwardly — a current document and an archived one competing for the same file.
Forcing the replacement through is not always the answer. Sometimes the fix is to separate them properly, once, so this stops happening every year.
Summary
Shared files are useful when you meant it and dangerous when you did not.
Before you overwrite anything, ask what else points at it.
Related: Audit file references · Replace a document used on several pages · Large-batch safety