When you send materials to a developer or make a small website change, you need a clear way to access the files. SFTP lets you transfer files between your computer and a server over an encrypted connection. However, a secure connection cannot stop you choosing the wrong folder or overwriting a working version. Here is how to prepare your access and check each change, regardless of the hosting control panel you use.
1. SFTP and FTP: what is the difference?
SFTP stands for SSH File Transfer Protocol. It operates over SSH, using encryption to protect both your authentication details and the content being transferred. It normally uses port 22, although the server administrator can configure a different port.
FTP is a separate protocol. In its unencrypted form, it does not protect login details or files against interception. There is also FTPS, which protects FTP using TLS, but FTPS and SFTP are not interchangeable. A client configured for one will not automatically connect to the other.
Select SFTP explicitly in your transfer application and check that your hosting service supports it. Availability depends on the hosting configuration: having an FTP account does not necessarily mean you also have SFTP access.
If you are considering a web hosting service, check the available access methods before agreeing a workflow with your developer. SFTP protects data in transit; it does not validate the changes you make on the server.
2. Which connection details do you need?
Ask the account administrator or hosting provider for the following information. Do not assume your website password or customer account credentials will also work for file transfers.
- Server address: a hostname or IP address, which may differ from your website domain.
- SFTP port: the port specified for that service.
- Username: the account authorised to access the files you need.
- Authentication method: a password, an SSH key, or the combination required by the server.
- Working directory: the exact path for the website, test environment or submitted materials.
- Server host key fingerprint: the information used to check the server’s identity when you first connect.
When using an SSH key, the public key is registered on the server, while the private key stays under your control. Do not send your private key to a developer. Each collaborator should have separate credentials, restricted to the access they need, where the service supports this arrangement.
Share secrets through an appropriate secure channel, separately from general instructions. For guidance on access, check the frequently asked questions or request clarification before trying protocols and ports at random.
3. Prepare your files and agree what must stay unchanged
Start with a short list: which files you are sending, where they belong, and who will publish them. If you are simply supplying text, images or documents to a developer, you do not necessarily need access to the live website directory. Agree on a separate handover location, preferably outside the area accessible through a browser.
A folder name that is difficult to guess is not an access restriction. Do not upload personal information, passwords, database exports or website archives into a public directory.
- Keep the original materials locally and organise working versions separately.
- Check filenames, extensions and folder structure against the instructions you received.
- Download a copy of any existing files you intend to change and store it securely.
- For broader changes, prepare an appropriate backup, including the database if the change affects it.
- Agree a working window with your developer to avoid simultaneous edits.
SFTP transfers files, but it does not automatically export your database. With a CMS, copying the website directories is not always enough to restore the whole site.
4. Connect and check the destination
Use an up-to-date SFTP client, such as FileZilla or WinSCP, downloaded from its official source. Option names vary between applications, but the basic process is the same.
- Create a new connection and select SFTP as the protocol.
- Enter the supplied server address, port, username and authentication details.
- On your first connection, compare the server host key fingerprint with the one obtained through a trusted channel. Do not automatically accept an unfamiliar key.
- Open the specified directory and check the full path carefully. Your starting directory may be the account area rather than the website root.
- Identify which files are on your computer and which are on the server before starting a transfer.
If the application warns that the server’s identity has changed, stop and investigate. There may be a legitimate explanation, but the warning should not be ignored.
For an initial check, you can download a known, non-confidential file if you have permission. Do not test your access by deleting, renaming or editing a file used by the website.
5. Transfer files without accidental overwrites
Before uploading, configure your client to ask for confirmation when a file already exists. Avoid automatic overwrite settings and synchronisation options that delete files, especially if you are unfamiliar with the website’s full structure.
When sending materials to a developer
Upload to the agreed handover directory and use clear names for different versions. Then send a list of the files and their location. Do not replace published images or documents directly simply because the filenames appear to match.
When making a small change
- Download the current version from the server and work on a local copy.
- Compare your changes with the original and check whether someone else has updated the server copy in the meantime.
- Upload only the files you need, rather than the entire directory out of habit.
- When an overwrite warning appears, check the filename, path and content differences before confirming.
- Monitor the transfer queue and check for failed files or interrupted transfers.
Modification dates and file sizes are useful clues, but they do not prove that two files contain identical content. For code, use a content comparison. Complex changes are better handled through a test environment and a controlled deployment process than by editing the live website directly.
6. Check permissions and finish the task
After transferring the files, check the affected pages and features. A completed upload does not confirm that the website works correctly. If you have changed code, also look for errors using the tools available in your account.
Keep file permissions limited to what is necessary. Do not give everyone write access as a quick fix for an error, and do not recursively change permissions across the whole website without understanding the configuration. File ownership and the way the application runs both influence the appropriate permissions.
If access is denied, check the user account, directory and permitted operation. You can request clarification through the contact page, without including passwords or private keys in your message.
Finally, remove temporary materials when they are no longer needed and revoke access for collaborators whose work is complete. The practical rule is straightforward: confirm the destination, keep a recoverable copy, transfer only what is needed, and test the result before treating the task as finished.
