Why "FTP into the server" is a warning sign in 2026
What it means when a supplier updates your website by copying files onto a server, why that method causes outages and breaches, and what replaced it.
The short answer
When a supplier says they will “FTP the files up” to update your website, they are describing a method from a different era: connecting to the live server and copying changed files onto it by hand. It means the change was tested, if at all, on their machine; nobody recorded what changed; visitors may load a page whose stylesheet has been replaced but whose HTML has not; and the only way back is a backup that may be days old. Plain FTP also sends credentials and files unencrypted across the network, and the encrypted variants keep every workflow problem while fixing only that one. The replacement has existed for years: version control and a pipeline, in which every change is committed, checked, previewed, deployed atomically and reversible in one step. If your site is still updated by file transfer, that is the first thing to change, before any feature is added.
What the method costs
| Property | File transfer to a live server | Version control and a pipeline |
|---|---|---|
| Record of changes | None; whatever is on the server is the truth | Every change, author, time, reason |
| Testing before visitors see it | On the developer’s machine, maybe | Automated checks and a preview on real infrastructure |
| What visitors see mid-change | Possibly a half-updated site | The old version or the new one, never a mix |
| Undo | Restore a backup, if recent | One-step rollback to the previous version |
| Who can deploy | Anyone with the password | Anyone with repository access, through the same checks |
| Credentials | Often plain text in transit and in a tool’s saved settings | Managed by the platform; no server password to share |
| Dependence | On one person’s local files | On the repository, which the business owns |
| Server exposure | A file transfer service running on the live server | No transfer service; the server is not touched directly |
Why it persists
- Habit: it was how websites were updated for years, and some suppliers never changed.
- Platforms that encourage it: traditional shared hosting exposes a file system and a transfer account by default.
- Small changes feel safe: one file, quickly copied, until the one file breaks the template.
- No one asked: clients rarely know how their site is updated, and the method is invisible until it fails.
What to do about it
Ask your supplier how changes reach your site. If the answer involves transferring files to a server, ask for the site to be moved into version control with a pipeline and previews. On a modern platform this is standard and takes a few hours for an existing site; on traditional hosting it is a reason to move platforms. Insist on it before the next feature, because every change made the old way is a chance for the pattern above.
What this means for you
Find out how your website is updated. If files are copied onto a live server, insist on version control and a pipeline with previews and rollback, before anything else is built. The change costs a few hours once and removes the most common way small business websites are broken by their own updates.
Frequently asked questions
Our developer has always used FTP and nothing has gone wrong. Why change?
Because nothing has gone wrong yet, and because the method has no safety net when it does: no record of what changed, no test before it reached visitors, no way back except a backup that may be days old. It also means the site depends on one person's local files. The pipeline costs a few hours to set up once and removes an entire class of outages; the FTP habit is a gamble taken on every change.
Is SFTP fine, then?
It fixes the encryption problem: credentials and files no longer travel in plain text. It does not fix the workflow: files are still copied onto a live server without version control, checks, previews or atomic deployment. Encrypted file transfer is a better tool for the wrong process. The process is what needs replacing.
What does the modern method look like from our side?
You see a preview link for each change, approve it on your phone, and the change goes live in a few minutes through an automated pipeline, with a history of every deployment and a one-step rollback. You never see a server, a file or a copy operation. The machinery exists so that publishing a change is as unremarkable as saving a document.