Quick answer
Overwriting a file over SFTP, SSH, rsync or your host’s file manager is a perfectly reasonable thing to do when you know the exact path and you already have your own backup and checking process.
A replacement workflow is the better fit when the hard part is not copying the file but deciding which file goes where, making sure nothing else uses it, coping with a run that stops halfway, recording what happened, and undoing one item.
This is not “FTP bad, plugin good”. FTP is a file operation. A replacement workflow is everything around the file operation.
When FTP is simply the right tool
It is direct, and sometimes direct is all you need:
- one PDF needs correcting
- you know its exact path
- the URL has to stay the same
- nothing in WordPress needs to change
- you have a backup
- you are going to check the result yourself.
Opening the uploads directory and overwriting the file is faster than installing anything. That is a valid workflow and nobody should feel bad about it.
Why it comes up in every support thread
WordPress’s upload flow is built to create new media, not to replace existing files.
So people hit the same four things: the file lands in this year’s folder, WordPress adds -1 to the name, they end up with duplicate entries, and all their existing links still point at the old file.
FTP appears to fix all four at once, because it writes underneath WordPress straight to the path you name.
What FTP does not know
It knows about directories and files. It does not know:
- which page uses that file
- whether ten other pages also use it
- whether this new file was actually meant for that path
- whether two of your new files are aimed at the same path
- whether this is part of a larger job
- whether a previous attempt already did it
- whether anybody approved the match
- which backup belongs to this change
- what to tell you afterwards.
You can supply all of that yourself. The point is that the protocol does not.
Scale changes the answer
You have 200 new PDFs.
If all 200 map exactly to 200 server paths, rsync is excellent and you should use it.
If 160 map exactly and 40 have inconsistent names, that is a different job — and a filesystem loop will make 40 wrong replacements faster than any other method available to you.
A batch takes the obvious 160, sets the 40 aside, lets somebody resolve them, backs up, replaces, and tells you exactly what happened. That is what the extra machinery is for.
Shared files
FTP overwrites the file. Every page pointing at it now serves the new version.
Sometimes that is precisely the goal.
Sometimes you thought you were changing one page. You find out which when somebody notices.
A replacement workflow makes that visible before the write instead of after.
Backups and undo
With FTP, recovery is whatever you set up beforehand: a local copy, a server snapshot, a hosting backup, an rsync archive, a renamed original.
That can be perfectly solid — it just depends on you remembering to do it every time.
A replacement workflow ties the backup to the specific change, writes it before the overwrite, and makes undoing that one file a deliberate action rather than an archaeology exercise.
When the file is not the only thing changing
For a lot of document replacements, nothing in WordPress needs to change and a filesystem overwrite works cleanly.
Other jobs do need more: assigning a file to a field, attaching a document for the first time, custom fields that store references, metadata that needs preserving.
That is the other point where FTP alone stops being the whole answer.
Images are different
Images have generated sizes.
Replacing the original over FTP does not regenerate the thumbnail, the medium and large versions, your theme’s custom sizes, or any WebP versions an optimization plugin made.
That does not make FTP wrong. It means image replacement has a second step, and skipping it leaves half your pages showing the old picture.
Security
“FTP” should mean SFTP or something else over SSH rather than the plaintext original.
But the bigger risk with a replacement is not the transport. It is whether you are writing to the path you think you are, and what happens if you are not.
The quick version
Use FTP when the paths are known, the job is small or predictable, you are technical, you have reliable backups, and there is nothing ambiguous to review.
Use a replacement workflow when filenames need matching, other people are involved, the files live in different WordPress structures, shared-file checks matter, the run might be interrupted, you want per-item undo and a history, and you will be doing it again.
Example: 75 revised forms
A developer receives 75 revised forms.
If the folder mirrors the uploads directory exactly, rsync will be done in a minute.
If the filenames have department abbreviations, dates and a few renamed forms in them, this is no longer “copy 75 files”. It is “make 75 decisions, then copy the ones you approved”.
That is the line between a transfer tool and a replacement workflow.
Summary
FTP is not the enemy here. It is often the right lower-level tool.
Use it when you are certain about the mapping and you own the safety process.
Use a workflow when the real cost is the mapping, the reviewing, the keeping track and the getting back.
Related: Bulk replacement vs custom script · Date-based upload folders · Replacement checklist