Transfer website files with SFTP without confusing servers, folders or access

Choose the right route for the job

A file-transfer client gives direct access to server files. It is useful for an agreed file replacement, a controlled upload or collecting specific files for an authorized investigation. Ordinary article editing belongs in the publishing system. If a supported dashboard workflow already handles your task, direct server access may add unnecessary complexity.

The OpenSSH SFTP manual describes file operations over encrypted SSH transport. SFTP and FTPS are different protocols: FTPS is FTP protected by TLS, while SFTP uses SSH. The WinSCP protocol reference distinguishes these choices. Select the protocol the host actually supports rather than changing a label while keeping unrelated connection details.

WordPress’s file-transfer guidance recommends SFTP or FTPS instead of unencrypted FTP when supported. Ask the host for the correct protocol, hostname, port and authentication method. Do not assume that a WordPress administrator login or an existing FTP-only account also grants SFTP access.

Write a small transfer plan before connecting

Record the website, environment, responsible person, local source folder, intended remote directory and individual files involved. Include the desired result and what would justify restoring an earlier version. Keep secrets outside this plan; it should identify the connection without reproducing passwords or private keys.

For example, a fictional publisher needs to replace one stylesheet on a protected test site. Its plan names that test site, the approved theme directory, the original file to preserve and the page whose layout will be checked. “Upload the website folder” would be a much less reviewable instruction.

Separate uploading a new file from replacing an existing one, moving a directory, changing permissions or deleting content. Those actions have different consequences. If several people can edit the site, agree a short change window so that a saved local copy does not overwrite newer work without anyone noticing.

Take the recovery scope seriously. The WordPress backup handbook distinguishes files and database. Copying a theme directory does not capture articles, settings or recent orders stored elsewhere. Our restorable backup guide helps define the broader recovery plan when the change warrants one.

Confirm the server before trusting the connection

SSH host-key verification identifies the server; your password or user key authenticates you to it. These are separate checks. The WinSCP host-key guide explains why a first connection needs a trusted fingerprint and why a changed key deserves investigation.

Obtain the expected fingerprint through an established host or administrator channel, then compare the actual value shown by the client. Do not accept a previously unknown value just because the domain spelling looks familiar. If a saved connection reports a changed key, stop and confirm whether the host deliberately replaced it. A legitimate change is possible; the warning itself does not tell you which explanation is true.

Do not disable identity checks to make a connection succeed. If you were given the wrong endpoint, an outdated fingerprint or incomplete instructions, resolve that mismatch with the responsible administrator. An encrypted connection to the wrong server is still the wrong destination.

Keep access limited to the intended work

Use access issued for the person and task rather than passing a shared master password around a team. Ask the host which directory restrictions and individual accounts its platform supports. Do not claim that every SFTP account is automatically isolated from the rest of a hosting account.

The WordPress hardening handbook recommends limiting access and protecting sensitive configuration and recovery materials. Apply that principle to the transfer: someone replacing a public image should not need an unrelated site’s database credentials or a complete private backup archive.

Keep passwords, private keys and recovery files out of screenshots, public uploads and support messages. A host public-key fingerprint is an identity check, not a substitute for protecting your own private authentication material. Do not put credentials into a page URL or a filename to remember them.

If access is temporary, name who will remove it when the work is accepted. Removing a contractor’s WordPress user is not proof that a separately issued hosting or file-transfer account has also been removed.

Find the correct remote directory

Confirm the directory with the host or site administrator before uploading. A familiar name such as public_html is not enough when one account contains multiple domains, a test installation or several applications. The login directory may already be restricted to a site’s root, or it may sit above several sites.

In a graphical client, distinguish the local panel on your computer from the remote panel on the server. Read the full remote path and inspect expected files without changing them. OpenSSH likewise distinguishes local and remote directory operations. Avoid assuming that the folder currently visible is the destination from the last task.

Write the verified path into the transfer plan and compare it again at the final upload confirmation. If its identity remains uncertain, stop rather than placing a “test” file into an unknown live directory. For multiple WordPress installations, our installation-boundaries guide explains why shared administration does not make the sites interchangeable.

Upload a defined selection and inspect the confirmation

Review the selected local files before starting. The WinSCP upload instructions explain that dropping files onto an empty remote panel targets its current directory, while dropping onto a folder targets that folder. Its transfer-options confirmation provides another opportunity to inspect the destination. Other clients have their own controls.

Choose a copy or upload operation when you intend to preserve local originals. WinSCP also has upload-and-delete or move actions, so a similar-looking gesture can have a different effect. Do not turn on broad folder synchronization, deletion of destination-only files or automatic overwriting as a shortcut for one defined upload.

For an existing file, keep a private recoverable original and review the overwrite decision. Do not leave a sensitive backup beside the live file under a guessable public name. If the client reports a permission error, confirm account scope, ownership and the intended operation with the administrator; do not recursively relax permissions across the website.

Handle interrupted transfers deliberately

Read the transfer queue and result, including failures and remaining items. If a connection drops, record which files completed and which did not before retrying. A partially transferred replacement may need a different recovery decision from an untouched file.

The WinSCP resume documentation describes temporary filenames and their eventual rename, with permission and attribute implications. It also warns that resuming must use the same source version. OpenSSH gives a similar warning: combining a partial copy with different source contents can corrupt the result. Do not select Resume after editing the local file simply because it seems faster.

Client-specific temporary-file behavior is not a guarantee of an atomic website deployment. An application may depend on several files changing together, and some server capabilities differ. Keep application releases within the deployment method its maintainer supports.

Verify files and the visitor result separately

Confirm the exact remote path, filenames, completed queue and expected files. A matching timestamp or size is useful evidence, but neither alone proves that all file contents match. The WinSCP Compare Directories reference says its comparison uses timestamps by default and does not include subdirectory contents. Understand what your check actually covers.

Where the host and client support an appropriate checksum check, use the documented facility. Otherwise, an authorized download to a separate verification folder can support a local content comparison. Preserve the original source and distinguish the verified copy from a file edited afterward. SFTP encryption does not itself certify that you selected the intended source or destination.

Then test the affected page or application action in its intended environment. Check the changed feature and a neighboring route that should still work. If an old version remains visible, first establish which file the browser is requesting and which cache serves it; our cache-diagnosis guide explains that distinction. Do not repeat the upload blindly.