WordPress file transfers: managing site files with SFTP

If you need to edit a website file but see dozens of folders in the transfer client, your first question should be: where am I connected? WordPress, hosting control-panel and file-transfer accounts may be separate. Knowing the admin password does not mean you already have a secure way to manage files.

Consider being asked to maintain a small studio's website: the owner needs to replace a child-theme stylesheet while retaining a way to recover. The following operating guidance is based on official documentation. It does not involve connecting to your host, nor does it assume every host uses the same paths or permissions.

Get complete connection details from the host

FTP is a transfer protocol; SFTP encrypts connections through SSH, while FTPS protects FTP with TLS. Their names are similar, but they connect differently. Prefer SFTP when the host supports it. If FTPS is provided, configure encryption according to the host's documentation rather than switching to unencrypted FTP merely to connect.

Required details include the server address, port, username, authentication method, accessible directories and host-key fingerprint. Use the port shown in the control panel. A website domain may point to a CDN and cannot simply be assumed to be the SFTP host. Name production and staging connections separately to reduce wrong-site connections.

For key-based sign-in, the public key is configured on the server and the private key stays on a protected computer. Do not send private keys or complete connection profiles to a group chat. For outsourced work, ask the hosting administrator about a separate account with a narrower scope, then revoke it at completion instead of sharing the highest-privilege account indefinitely.

Create a Site Manager connection and verify its identity

In FileZilla, for example, open Site Manager from the File menu, create a new site, select SFTP, and enter the address, port and specified login method. Use an identifiable name, such as “Studio staging site,” rather than only an IP address. When the first connection displays a host-key prompt, compare the fingerprint with the administrator's supplied value before proceeding.

The fingerprint identifies the remote server; it is not your own login public key. The value shown on a first connection cannot prove its own trustworthiness. Obtain comparison information from the hosting control panel or an administrator whose identity you have verified. A sudden fingerprint change on an existing connection may indicate a migration or replacement server, or the wrong host. Find out why before continuing.

1. Confirm in the hosting control panel which website the account belongs to and record its document root.
2. Explicitly choose the protocol and login method in Site Manager instead of accepting defaults without checking.
3. After verifying the host key, browse the directories first; do not yet drag files to upload or synchronize a whole folder.

Find the site root and separate files from the database

After sign-in, the local computer is usually on the left and the remote server on the right. A folder named public_html or www is not proof that it belongs to the intended site: the host may use multiple domains or isolated directories. Compare the control panel's specified path, then check for WordPress directories such as wp-admin, wp-includes and wp-content. Stop making changes if anything is uncertain.

Themes and plugins usually occupy the corresponding subdirectories of wp-content, while physical media files are commonly in uploads. Posts, users and many settings are stored in the database. Downloading a site folder does not automatically export that database. Likewise, placing a photo directly in uploads does not create a complete attachment record in the Media Library.

Prepare a full backup of both files and database, then also download the individual file you intend to change. Store backups in a protected local location, keeping the original path and date. Do not rename a password-bearing configuration file to .bak or a text file and leave it in a public directory where visitors might download it.

Change only one clearly defined target at a time

For design adjustments, check whether you are editing a child theme. Changes made directly to parent-theme or plugin source files may be overwritten by updates. If an admin setting can achieve the change, there is no need to edit code files. When editing is necessary, use a suitable local plain-text editor and retain the original extension and encoding.

Before uploading, compare the filename, complete remote path, size and original version. Do not drag the entire local website into the production root or use a synchronization mode that unconditionally deletes extra remote files. It could remove media currently in use or files someone else has just updated.

After transfer, check the queue for failures. A large plugin or multi-file software update that uploads only partly can leave mixed old and new versions; use the proper update or deployment process for that work. For a single stylesheet, first validate it on staging, then apply it during an agreed maintenance window.

For permission errors, check ownership and hosting rules first

Common Linux configurations use 755 for directories and 644 for ordinary files as a starting point, but official guidance also stresses that users and groups differ across hosts. These numbers are not a universal repair trick, and managed platforms may deliberately protect some files. If writing is denied, first check the account's scope, file owner, disk quota and destination path.

Do not set the entire site to 777 or recursively change every directory to solve a problem with one file. Configuration files such as wp-config.php need more careful access control; actual values depend on how the host runs the site. Giving support the error time and a path with sensitive details redacted can locate the issue faster than blindly widening permissions.

If FileZilla does not show dotfiles such as .htaccess, first check hidden-file display settings and server restrictions. Do not create an empty file with the same name and overwrite the original merely because it was not listed. Hidden files can control redirects or access, and omitting them can also leave a backup incomplete.

Finish with a recoverable result

After editing, reopen both the public site and admin area and check the pages actually affected. For style changes, test mobile widths and clear relevant caches if necessary; a successful-transfer message is not enough. If the layout breaks or a code error appears, restore the original file and verify the result before adding another unexplained change.

At minimum, log the time, site, file path, purpose, verification result and original-file location. Restoring a file restores only that file's contents; it does not automatically reverse orders or database updates made at the same time. Close the connection after maintenance, and ensure temporary accounts and sensitive local files remain managed under the handover rules.

Read the full description

Four boxes show host verification, downloading the original file, a limited upload and public-site testing.

Create a full backup of files and database

Troubleshooting a website 500 error

• Tutorials
• Apps & software
• Websites & e-commerce
• WordPress