Quick answer
Plenty of WordPress files are attached through a custom field rather than sitting in the page content or being obvious in the Media Library.
Before replacing one, you need to know what the field actually holds: a reference to the Media Library entry, a full URL, a file path, or something the plugin made up.
A replacement has to keep that relationship intact and change the right file underneath — without assuming every custom field works the same way, because they do not.
Why this matters more than it sounds
Most established sites use custom fields for exactly the documents people need to replace in bulk:
- product manuals
- brochures
- policy PDFs
- staff documents
- forms
- course documents
- spec sheets.
The page looks completely ordinary. The file is attached somewhere a bulk tool never thinks to look, which is why a batch can report success and change nothing.
What the field might be storing
A reference to the Media Library entry. The field holds something like 4812 and WordPress looks the file up from there.
A full URL. The field holds the whole web address of the file.
A file path. The field holds a path rather than a URL.
Something structured. The plugin stores its own arrangement of data.
Each of those needs handling differently, and a tool that assumes they are all URLs will get three of them wrong.
Why “which attachment is it” is the wrong question
The thing that actually matters is:
the Manual field on product X
not:
file number 4812
The second one changes every time somebody uploads a new manual. The first one is stable, and it is what you want to match against.
Example: an ACF file field
You have a product page with a Manual field, and the manual for product 410 needs updating.
What matters is the field, not whichever file happens to be in it today. Point a batch at 410-manual-revC.pdf and it goes into the Manual field on product 410 — leaving the field itself, and the page around it, exactly as they are.
This is what WP Bulk Replace Pro adds. Your file, image and gallery fields are listed by name when you set up a batch, including the ones inside repeater rows.
A field with nothing in it yet
An empty field is not a failed match. It is a field waiting for a file, and the batch can simply fill it in.
That is a different thing from a file with nowhere obvious to go, which you should be asked about before anything happens. Both are normal; they just need telling apart.
Matching against fields
There is much more to go on than a filename: the page title, the post type, the name of the field itself, a SKU or course code, and any abbreviations you have explained.
410-manual-revC.pdf matched against “the Manual field on product 410” is a far stronger match than the same filename compared against a list of Media Library entries.
When one file is in two fields
Two custom fields can point at the same file.
If only one of them should change, replacing the underlying file changes both. That is why checking where a file is used matters as much here as anywhere else — arguably more, because nothing on either page shows you the connection.
Example: product spec fields
A manufacturer has 100 products. Each one has a Manual field and a Spec Sheet field.
A batch of 120 documents arrives.
A good run matches each file to a product and to which of the two fields it belongs in. Matching against Media Library filenames alone would put half of them in the wrong field and look perfectly successful doing it.
Fields that point somewhere else entirely
Some fields hold external URLs, or values managed by another system.
Not every file-shaped field is a local file the plugin can write to. When it cannot tell what it is looking at, the right behavior is to stop and say so rather than write into it and hope.
Fields get renamed
Sites change. A field gets renamed, or replaced, or removed.
If a saved batch points at a field that no longer exists, it should refuse to run rather than guess at the nearest similar field. That matters most for recurring jobs, which are exactly the ones set up months ago by somebody who has since left.
Which plugins are supported
WP Bulk Replace Pro supports ACF file, image and gallery fields, including inside repeater rows, and WooCommerce product images, galleries and customer downloads.
That is a specific list on purpose. A tool claiming to support every field plugin and every page builder is claiming something nobody can test.
Summary
Custom-field replacement is safe when the tool understands all four things: the page, the field, what that field stores, and the file underneath.
Reduce that to filename matching and it will look like it worked.
Related: Resource libraries · Check where a file is used · Bulk replace files