Quick answer
If you have a few hundred optimized images to put back onto a site, “upload the folder again” is the one approach that definitely will not work.
Match each new image to the one it is replacing, check the ambiguous names, watch out for images used in several places, back up before overwriting, and look at the actual pages afterwards.
Images have one extra complication that documents do not: WordPress makes several sizes of every image you upload. Replacing the original does not prove that every thumbnail, every responsive version, every CDN copy and every optimization plugin’s cache has caught up.
So image replacement is two jobs: replacing the file, and then checking what your site is actually serving.
Why the images are outside WordPress in the first place
Image work happens in better tools than WordPress, so batches come back from somewhere else.
Somebody has just compressed a few hundred JPEGs, re-encoded them at a different quality, color-corrected a gallery, stripped metadata, resized oversized originals, swapped out watermarked versions, fixed the crops, or prepared newly approved photography.
The new files might keep the old names, or they might come back with -final, -web, -optimized, a date or a version number stuck on.
Making the images was the easy part. Getting each one back into the right place without creating duplicates is the part that goes wrong.
The same filename is a good clue, not a guarantee
team-photo.jpg matching an existing team-photo.jpg is a strong signal.
It still does not tell you whether there are several files with similar names, whether the existing image is used somewhere outside what you are working on, whether this is actually a new image rather than a revision, whether a name clash is pointing at the wrong file, or whether the optimized version changed size or format in a way your layout will notice.
For a big batch the useful question is not “can this be automated?” It is “which rows are obvious, and which deserve thirty seconds of a person’s attention?”
One image is several files
A single upload can produce: the original, a thumbnail, medium, medium-large, large, whatever sizes your theme adds, plugin-specific crops, WebP or AVIF versions made by an optimization plugin, and variants generated by your CDN.
Replace only the original and some of those can stay exactly as they were.
Which is why checking the Media Library proves nothing. You have to look at a page.
Worth checking afterwards
- Did WordPress regenerate the other sizes?
- Is the theme still pointing at an older generated file?
- Is
srcsetserving a stale size? - Did an optimization plugin cache the previous version?
- Is the CDN still handing out the old bytes?
- Did the dimensions change enough to break a layout or a crop?
If your replacement workflow does not regenerate the sizes for you, that is a separate step you have to run — and then verify.
A workflow that works
1. Upload the optimized set on its own. Keep it away from live media until you have looked at where everything is going.
2. Let it propose matches. Filenames, what is already on the site, and any rules you have set. The obvious rows move quickly; the uncertain ones stay visible.
3. Look at size and format changes. Going from a 2400×1600 JPEG to an 800×800 WebP might be exactly what you meant. It is not a like-for-like swap, and a big change deserves a look.
4. Check shared images. One image can be on dozens of pages. If all of them should get the optimized version, brilliant. If only one should change, that row needs stopping until you have decided.
5. Back up, then replace. The copy has to exist before the overwrite.
6. Regenerate the other sizes. Run whatever your site uses for that, if the replacement did not.
7. Look at the front end. Real pages, at desktop and phone widths. Not the Media Library.
When FTP or rsync is fine
If you have an exact one-to-one path mapping and you genuinely want to overwrite those precise files, SFTP or rsync will do it, and quickly.
That works well on developer-managed sites where the paths are exact, backups already exist, somebody understands what happens to the generated sizes, and that person is going to check the result.
The argument for a batch workflow is not that lower-level tools are wrong. It is that you get the review, the shared-file check, a record of what happened and undo wrapped around the same file operation.
Example: 120 recompressed product images
A manufacturer re-exports 120 product images after improving compression.
- upload all 120
- match on product image filenames
- check the handful whose SKUs were renamed
- hold back any image that turns out to be used outside the product set
- replace the approved originals
- regenerate the other sizes if the site needs it
- purge the image and CDN caches
- look at a sample of product pages, including on a phone
- keep undo available until you have finished checking.
Far safer than treating the folder as 120 unrelated uploads.
Summary
Bulk image replacement has three layers: is this the right existing image, can it be changed without affecting something else, and is the site now actually serving the new one.
Overwriting the original is only the middle step.
Related: File replacement vs FTP · Media Library bulk replacement · Replaced file still shows old version