SFTP and FTP can both move website files, but their similar names conceal an important security difference. Choosing the wrong connection type may expose credentials or fail entirely even when the host, username, and password appear correct. The protocol must match what the server actually provides.
SFTP uses SSH for its transport. Traditional FTP does not inherently protect credentials and file contents with encryption, while FTPS adds TLS to FTP. SFTP and FTPS are different protocols, not two spellings of the same feature. Your hosting control panel should identify which service is enabled and how to verify its identity.
This getaboutcolumbia article explains how to select a secure file-transfer method, test the connection, and avoid turning a successful upload into an incomplete website deployment. It also separates file access from the database and application changes that may be required alongside it.
Choose the supported secure protocol
The OpenBSD SFTP manual, maintained with OpenSSH, describes file operations over encrypted SSH transport. Many VPS environments already use SSH for administration, making SFTP a natural option. Shared hosting may provide a restricted SFTP service or offer a different secure transfer method; confirm the provider’s instructions rather than assuming shell access is included.
FTPS is defined by the IETF specification for securing FTP with TLS. Its configuration involves the FTP service and TLS protection, and client settings must match the server. An SFTP client cannot connect to an FTPS endpoint merely by changing a password or using a familiar port number.
Ask the host for the protocol, hostname, port, authentication method, starting directory, and identity-verification information. Do not infer the protocol from the word FTP in an old support article. If only unencrypted FTP appears available, ask about supported secure alternatives before uploading sensitive configuration or credentials.
For SFTP, understand SSH key access and recovery before switching authentication methods. A private key belongs to its authorized user or automation process and should not be shared casually. Where a passphrase and agent are used, confirm how the transfer client accesses the key without embedding the passphrase in scripts.
Server identity is separate from your login identity. The OpenSSH protocol overview describes server authentication within the protected transport. Verify a new host fingerprint through a trusted channel or an established administration process. If a previously known identity changes unexpectedly, investigate instead of automatically dismissing the warning.
For FTPS, validate the server certificate and hostname rather than accepting arbitrary certificates. A connection can be encrypted yet connected to the wrong endpoint. Keep client software current and use the provider’s supported settings; disabling identity checks to suppress an error removes an important part of the connection’s protection.
Transfer files as part of a controlled deployment
Use an account limited to the site or directory being maintained when the host supports it. A content contractor uploading images should not need unrestricted access to every website in the account. Check the effective directory boundary after login, including whether parent directories or other accounts are visible.
Confirm the destination before the first write. Hosting accounts often contain staging, production, archives, and multiple document roots. Upload a harmless test file to an approved location, verify its expected result, and remove it. This small check can prevent an entire release from landing in the wrong environment.
File transfer does not create a database backup. A WordPress backup and restoration process must account for both application files and database state. Downloading the public website directory alone may omit orders, settings, posts, and other records stored by the database service.
For code changes, avoid overwriting a live application file by file when a partial release could break requests. Use the deployment method supported by the application and host, which may involve a staging directory, a release switch, or a maintenance window. The safest option depends on whether the application can tolerate mixed file versions.
Check transfer results and file permissions after deployment. A client may report individual failures while leaving most files in place. Confirm required files exist, expected file sizes or checksums match where appropriate, and the web process can read what it needs. Do not solve ownership problems by granting broad write access indiscriminately.
Plan rollback before the upload. Preserve the previous release through your approved backup or deployment system and understand whether a database migration makes file-only rollback unsafe. Test a representative page and the relevant business action after the change, not simply whether the client reports that the transfer queue is empty.
For automated transfers, use a dedicated identity with limited access and an auditable process. Keep credentials out of scripts that may be committed or shared. Record the job’s exit status and a useful failure message without printing secret values. Alert the owner if a scheduled transfer silently stops working.
Mistakes to avoid
Do not treat changing a port as a security replacement for authentication and access control. Do not upload an entire local working directory without reviewing what it contains; development configuration, repository metadata, and old archives may not belong on the public server.
Avoid accepting recursive permission changes suggested without context. WordPress file permissions depend on ownership and the host’s execution model. A transfer that finishes successfully can still leave files writable by unintended users or unreadable by the application.
Two final recommendations
Save a documented connection profile for each environment with an unmistakable name and destination. Keep the protocol and identity verification details current, while storing secret values through the approved credential mechanism. Distinct staging and production profiles reduce routine operator mistakes.
Give every transfer a validation step proportional to its impact. Image uploads may need a media check; application releases need functional checks and a rollback path. This makes secure transport part of a reliable workflow rather than the only measure of success.
Conclusion
SFTP is an encrypted SSH-based file-transfer protocol, while FTPS is FTP protected with TLS. Traditional unencrypted FTP should not be mistaken for either secure option.
Select the service your host supports, verify the server identity, limit the account’s access, and confirm the result after uploading. Include database state and deployment behavior when the change affects the application.
Use secure transfer as one controlled step in website maintenance. A correctly authenticated connection is valuable, but the right destination, complete release, and tested recovery path determine whether the operation succeeds.
