Before You Hand Over Website Access, Find Out What Your SEO Team Actually Needs

Nina Okonkwo August 17, 2026

The short answer: technical access may be necessary, but FTP is not always necessary

An SEO company may ask for FTP access because it wants to implement or troubleshoot technical changes that your content management system does not expose. That can be legitimate—but the agency usually needs a safe implementation path, not FTP specifically.

FTP stands for File Transfer Protocol. With the necessary permissions, an FTP account can upload, download, modify, delete, and organize files on a web server. Those files may include templates, scripts, stylesheets, images, redirect configurations, and crawler-control files.

The crucial distinction is between analysis and implementation:

An agency can crawl and audit a public website, identify technical problems, and document recommendations without permission to change production files.
It needs implementation access only if its contracted role includes making those changes.
Even then, the appropriate route might be CMS access, SFTP, a Git repository, a staging environment, a hosting or CDN interface, or deployment by your developer.

The right method depends on the agreed scope, website platform, hosting arrangement, CMS capabilities, existing development process, and who is responsible for deployment. A custom application managed through Git requires a different workflow from a small WordPress site. A hosted website builder may not offer conventional file access at all.

Two categorical claims should therefore be rejected. Not every legitimate SEO campaign requires FTP, and an agency’s failure to request it does not prove that it is neglecting technical SEO. Some providers deliberately avoid direct production access because the client has an established development and approval process. Others are responsible only for research, content, or recommendations.

Before supplying credentials, ask one direct question:

What exact change do you need to make, and why is our existing CMS or deployment process insufficient?

A clear answer will tell you far more than the label “FTP access.”

What agencies often mean when they say “FTP access”

Some agencies use “FTP” loosely to mean any method of reaching website files. That shorthand can conceal important differences in capability and risk, so ask the provider to name the actual protocol, interface, and permission level it requires.

Access method	What it provides	Typical use	Important limitation or risk
FTP	Direct file-transfer and file-management operations	Legacy hosting environments	Credentials and contents travel without encryption
SFTP	File transfer through an SSH connection	Encrypted file access on modern hosting	Secure transport does not correct excessive permissions
FTPS	FTP protected with TLS/SSL	Hosts retaining an FTP-based setup	Configuration and firewall management can be more involved
SSH	Command-line server access	Advanced diagnostics, scripts, logs, or deployment	Potentially much more powerful than file transfer
Git repository	Version-controlled access to source code	Branches, reviews, testing, and controlled deployment	Repository access does not necessarily grant server access
Hosting file manager	Browser-based access through a control panel	File edits where no separate transfer account exists	The surrounding panel may expose unrelated systems
CMS account	Editorial or administrative platform functions	Content, metadata, plugins, and platform settings	May not expose server or application files

Traditional FTP sends usernames, passwords, and transferred file contents without encryption. SFTP transfers files through SSH, while FTPS adds TLS/SSL protection to an FTP-based connection. These are distinct protocols, not interchangeable names for the same service. If file transfer is genuinely necessary, plain FTP should not be the default because its traffic can be read if intercepted, as this FTP security overview explains.

SSH is a different proposition. It can provide command-line access for running scripts, viewing logs, managing services, or changing server configurations. That may be appropriate for a qualified developer investigating a server-level problem, but it is substantially more powerful than a restricted file-transfer account. Do not supply SSH merely because someone asked for “FTP.”

Git-based access can be more suitable when a site already follows a development workflow. The agency can create a branch, document its changes, open a pull request, respond to review comments, and allow an authorized person or automated pipeline to deploy the approved version. This makes changes easier to inspect and trace. FTP by itself does not create branches, preserve review discussions, prevent conflicting edits, or provide reliable rollback.

A hosting control panel is not a narrow substitute for FTP. Depending on its configuration, it may expose website files, databases, backups, DNS records, subdomains, email accounts, scheduled jobs, and server settings. Giving someone a master hosting login to edit one redirect rule can expose far more than the task requires.

Encryption is essential, but it solves only one part of the problem: protecting credentials and files while they travel across a network. It does not prevent an authorized account from deleting the wrong directory, overwriting a working file, uploading harmful code, or changing content outside the approved scope. It also cannot protect the site if the agency’s credentials or devices are compromised.

Evaluate the complete workflow—not merely whether the connection is encrypted.

Which SEO tasks can justify file-level or deployment access?

The strongest justification is a specific task that cannot be completed safely through a narrower interface.

Task	What may need to change	Narrowest likely access route
Redirects and URL migrations	`.htaccess`, web-server rules, application routes, platform settings, or CDN rules	CMS redirect tool, CDN interface, repository, directory-scoped SFTP, or developer deployment
Crawler controls	`robots.txt` or related server/application configuration	CMS editor, platform setting, repository, or limited file access
Structured data and template logic	Theme files, rendering components, or application code	Theme workflow, repository, staging, or developer implementation
Canonical, hreflang, or metadata rules	Templates, plugins, rendering logic, or application configuration	CMS/plugin settings, repository, or developer deployment
Performance work	Images, scripts, CSS, caching, compression, or CDN configuration	CMS, asset pipeline, CDN, hosting interface, repository, or file access
Site verification	A verification file placed at the site root	HTML tag, DNS record, CMS integration, platform method, or limited root upload
Sitemap publication	A generated or static sitemap file	CMS/plugin setting, platform integration, repository, or limited file upload
Troubleshooting and recovery	Corrupted files, conflicting installations, missing assets, or broken routes	Read-only diagnosis followed by controlled repair access
Migration or bulk transfer	Large sets of assets, templates, or application files	Migration tool, SFTP, repository, storage service, or deployment pipeline

Redirects and URL migrations

A migration may require redirects from old URLs to new ones. On one site, those rules might live in .htaccess; on another, they may be configured in Nginx, the application, a CDN, a plugin, or a managed-platform dashboard. The agency should identify where the rules belong before requesting access.

The ability to edit .htaccess does not mean it is the right place to manage every redirect. The website’s architecture and existing conventions should determine the implementation method.

Crawler controls

An agency may need to update robots.txt or related configurations when a CMS does not provide a suitable editor. These changes require care because an incorrect crawler directive can block important resources or sections of a site.

The agency should explain the intended directive, affected paths, expected crawler behavior, and validation method. File access should not be granted merely because robots.txt exists.

Templates, structured data, canonicals, and hreflang

Sitewide rules often live below the page-editor level. Structured data may be generated by a template, canonical tags may come from application logic, hreflang annotations may be assembled dynamically, and metadata may be generated from fields or database values.

Such work can justify theme, code, repository, or deployment access. It rarely justifies unrestricted access to every server directory.

Performance changes

Performance work may involve uploading optimized assets, changing how scripts or stylesheets load, modifying template code, or adjusting caching and compression. Many of these controls may already be available through a CMS, CDN, host, or build process.

Ask where the change belongs. Directly replacing production JavaScript or CSS through a file-transfer connection may bypass the testing and asset-building process used by the rest of the team.

Verification files

Some services verify site control by asking the owner to upload a file to the web root. Depending on the service and platform, alternatives may include an HTML tag, CMS integration, or DNS record.

A file-upload verification option does not make broad hosting access proportionate. A one-time upload can often be completed by the website owner or developer.

Sitemap files

If a physical file must be published, the agency should request only the access needed to place or update that file.

Troubleshooting, recovery, and bulk work

File access can be useful for investigating corrupted files, overlapping installations, missing assets, unexplained 404 responses, or changes that are not visible in the CMS. It may also help restore a known-good file after a failed modification.

Migrations and large transfers can involve many files, making individual CMS uploads impractical. In mature environments, however, those files may move through a repository, storage service, migration utility, or deployment pipeline rather than being copied manually into production.

Incorrect edits to .htaccess, functions.php, templates, redirect rules, scripts, or crawler directives can break pages, cause downtime, create redirect loops, or interfere with crawling. Agency-authored implementation guidance recommends controls such as directory-scoped permissions, staging tests, change logging, and time-limited accounts for this kind of work (see the guidance).

When CMS access—or no direct access at all—is enough

Routine SEO work often belongs in the CMS. Depending on the platform and installed tools, an authorized user may be able to edit:

Page copy and headings
Page titles and meta descriptions
Internal links
Image alt text
Navigation
Sitemap settings
Basic redirects
Plugin or extension settings
Structured-data fields
Indexing controls
Analytics or tag settings

File-transfer access may not even be an effective way to edit this material. Many CMS platforms store page content and settings in a database rather than in editable HTML files. Someone browsing server directories may see themes, plugins, scripts, and uploaded assets without finding current page copy in a form that should be manually edited. This distinction between static server files and database-managed CMS content is described in an SEO provider’s overview of common website logins.

When direct access is unnecessary or undesirable, use a developer-led workflow:

The SEO documents the problem and supporting evidence.
The SEO describes the proposed change and acceptance criteria.
The client’s developer reviews the recommendation.
The developer implements it through the established workflow.
The change is tested and deployed.
The SEO validates the live result through crawling, inspection, or analytics.

This arrangement preserves responsibility without excluding the SEO from implementation. The agency remains accountable for making its recommendations precise enough to build and test.

Staging offers another alternative. The SEO or developer can prepare changes in a non-public environment, inspect page rendering, run a crawl, test redirects, and obtain approval before production deployment. Staging is particularly useful when the change is high risk, the relationship is new, or the team is still establishing trust.

Other task-specific options include:

A CDN interface for edge redirects, caching, or image handling
A hosting interface for a narrowly defined server setting
An API or platform integration for publishing and updating content
Google Tag Manager for supported tags after its container is installed
A Git repository for source-code changes
A managed-platform role for theme or store changes
Read-only logs or diagnostic exports for investigation

Refusing to provide production credentials does not prevent an SEO engagement. An archived practitioner discussion includes examples of SEOs supplying instructions for a client’s web team to implement and then reviewing the result, with staging suggested as a safer route while trust is established (see the Moz discussion).

Start diagnosis with read-only access where possible. The ability to inspect relevant files, configurations, or logs may be sufficient to identify the problem. Write, upload, overwrite, and delete permissions can be considered separately once the required change is understood and approved.

How access needs change across WordPress, custom sites, and hosted platforms

The website platform strongly influences what access is available and what is appropriate.

WordPress

Ordinary page edits, headings, titles, descriptions, internal links, and many plugin settings generally belong in the WordPress administration interface. Create a dedicated agency user with a role suited to the assignment rather than sharing an existing owner account.

File-level or repository access may be justified for changes to:

Custom theme templates
A child theme
functions.php
Custom plugins
Configuration files
Assets not managed through the media library
Server-level redirect or caching rules

Even when these changes are necessary, editing live files directly is not the only option. A developer can implement them, or the agency can submit code through a repository and staging workflow.

Custom-coded websites

A site without a CMS may store templates, page files, routing logic, assets, redirects, and crawler controls in source code or server directories. That makes file-level or deployment access more likely.

The word “custom,” however, does not automatically justify SFTP. First determine how the site is maintained. A modern custom application may be built locally, reviewed in Git, and deployed automatically. Manual production edits could conflict with the system’s intended operation.

Git and CI/CD environments

If the site uses Git and continuous integration or deployment, preserve that process. The agency should generally work through a branch, pull request, automated tests, staging build, review, and approved release.

This approach helps prevent production from drifting away from the repository.

Wix and Squarespace

Hosted platforms such as Wix and Squarespace generally do not offer conventional raw file access. SEO work normally occurs through platform settings, administrative tools, supported code areas, integrations, or APIs. An agency asking for “FTP” to one of these platforms may simply mean it needs a platform-specific account or integration, so require it to identify the exact role or interface. An agency-authored comparison of technical access methods also distinguishes these managed-platform workflows from conventional file access.

Shopify, Webflow, and other managed platforms

For Shopify, Webflow, and comparable services, review the platform’s collaborator roles, theme workflow, integrations, APIs, and publishing controls. Theme or template access may be appropriate, but that is not the same as unrestricted server access.

The principle remains consistent: use the platform’s intended permission and deployment model rather than assuming every website exposes a traditional filesystem.

As a bounded first-party example, Searcle states that it publishes content to existing websites, including sites on WordPress, Wix, Squarespace, Webflow, Shopify, and other platforms. Its available pages do not disclose the integration method or say that Searcle uses or requires FTP. Direct publishing should not be interpreted as evidence of raw file access.

A decision tree for evaluating an agency’s FTP request

Use this sequence before activating an account.

1. Identify the exact task

Ask the agency to name:

The issue it has found
The proposed change
The files, directories, or configurations involved
The pages or systems affected
The expected result
How success will be verified

“We need FTP for technical SEO” is not sufficiently specific.

2. Test whether a narrower interface can do the job

Ask why the change cannot be completed through the CMS, a plugin, hosting or CDN settings, an API, a managed-platform integration, or your existing deployment workflow.

The agency may have a good answer. The purpose is not to obstruct the work but to make the access proportionate to it.

3. Decide who should implement it

Determine whether the agency must make the change or whether your developer can deploy it from documented instructions. Consider who understands the application, who is responsible for uptime, and who normally approves production changes.

4. Separate diagnosis from modification

Ask whether read-only access is sufficient for the first stage. Do not grant upload, edit, overwrite, or delete permissions merely because the agency needs to inspect a configuration.

5. Choose the least powerful suitable route

Possible choices include:

A restricted CMS role
A platform collaborator account
Read-only diagnostic access
Staging access
Directory-scoped SFTP
Repository access
A task-specific hosting or CDN role
Developer-led implementation

SSH or full hosting administration should appear much later in the decision process, not as the default.

6. Decide whether production access is necessary

Ask whether the change can be prepared and tested in staging. If production deployment is required, identify who will execute or approve it and when it will occur.

7. Define testing and rollback

Before the work begins, record:

The named approver
The test method
The change record
Backup confirmation
Validation criteria
The rollback trigger
The person responsible for restoration

For a redirect migration, validation might cover old and new URLs, status codes, redirect chains, loops, canonical tags, internal links, and key conversion paths.

8. Plan expiration and offboarding

Set the account’s expiration date before activation. Name the person responsible for disabling it, removing keys, rotating shared credentials, and checking logs when the work ends.

You can send the agency this response:

Please provide the business reason for access, the exact directories or configurations involved, and the read, upload, edit, or delete permissions required. Please also specify the protocol, whether access is needed in staging or production, the person who will use it, the requested duration, the test and approval process, backup confirmation, and the rollback method. We will then provide the least-privileged access suitable for the task or route the change through our developer.

If your organization operates in a compliance-sensitive or tightly controlled environment, involve the host, developer, security team, or compliance owner. Generic access advice cannot account for your contracts, data, architecture, or regulatory obligations.

How to grant technical access without handing over the keys

If file access is justified, reduce both the likelihood and potential impact of a mistake or compromise.

Create a dedicated agency account

Do not share an owner account, master administrator login, or employee credentials. A separate account makes permissions, activity, expiration, and revocation easier to manage. It also prevents a password change from disrupting unrelated users.

Use an encrypted method

Prefer SFTP or FTPS to unencrypted FTP. Where a repository and deployment pipeline already exist, preserve them instead of creating an informal path around the workflow.

Security guidance recommends combining encrypted transfer with restricted accounts, authentication, folder permissions, and audit logging rather than treating the protocol as the only control (see GoAnywhere’s security guidance).

Apply least privilege

Limit the account to the required environment, directories, and operations. Possible permissions include:

Read
Upload
Edit or overwrite
Rename
Create directories
Delete

These permissions should not be bundled automatically. An agency uploading one verification file may not need permission to delete application code. Someone inspecting a template may not need write access.

Prefer staging

Restrict access to staging where possible. Require review and explicit approval before the change reaches production. If the agency needs production access for a specific deployment, activate it only for the approved window.

Verify a restorable backup

Create a current backup before changes begin, but do not stop at confirming that a backup job exists. Determine whether the backup can be restored, what it includes, and who is responsible for initiating restoration.

A file backup may not contain database-managed content. Match the backup to the systems the proposed change could affect.

Strengthen authentication and connection controls

Use the strongest authentication the platform supports. Store credentials in an appropriate password manager rather than sending them through casual chat or email. Where operationally practical, source-IP restrictions can limit where connections originate, but they should supplement rather than replace encrypted transport, strong authentication, and narrow permissions.

Enable logging and change records

Retain a record of:

Who made the change
When it happened
Which files or settings changed
Why the change was made
Who approved it
What testing was completed
Whether the result passed validation

Keep a human-readable change ticket as well as technical logs. A connection log may show that a file was transferred without explaining the business reason.

Use version control where available

Version control can preserve differences between revisions and support review and rollback. FTP alone does not provide those functions. Downloading a copy of a file before editing it can help, but it is not a substitute for a maintained repository and deployment history.

Exclude unrelated systems

Do not grant database, DNS, email, domain-registration, or full hosting access unless a separately documented task requires it. If the agency needs one DNS verification record, that does not necessarily mean it should receive ongoing authority over the entire DNS zone. The owner should retain control of critical business accounts.

Expire and revoke access

Set a time limit and disable the account promptly when the task or engagement ends. Rotate shared credentials, remove public keys or tokens that are no longer needed, and review the relevant logs afterward. Restricted permissions, account management, current software, and audit logging are all part of the broader control model recommended in file-transfer security guidance.

No combination of controls makes external access risk-free. The goal is to reduce exposure and ensure that every change is attributable, reviewable, testable, and reversible.

Reasonable requests, warning signs, and what to do if something goes wrong

A reasonable request is task-specific. It identifies the affected files or configurations, minimum permissions, environment, responsible person, timeframe, testing procedure, approval step, and rollback method.

For example:

We need temporary write access to the staging theme directory to correct the canonical-tag logic in one template. We do not need database, DNS, email, or production access. We will submit the file diff for approval, test the affected page types in staging, and ask your developer to deploy the approved change.

That request can be assessed. “Send us your cPanel login so we can do SEO” cannot.

Warning signs include:

A demand for shared master or owner credentials
Insistence on plain, unencrypted FTP
Unexplained access to production
A request for permanent access when the task is temporary
Resistance to staging, logging, review, or backups
Refusal to identify affected files
Requests for unrelated database, DNS, email, or domain privileges
No testing or rollback process
Pressure to bypass established development controls

Secrecy about proposed changes or refusal to work through your developer is a governance concern. It does not automatically prove misconduct, but it prevents appropriate review and makes accountability difficult.

An access request also does not establish competence or trustworthiness. A provider may know how to connect to a server without understanding your application or change process. Conversely, an agency that never asks for FTP may be working effectively through the CMS, repository, integrations, or client developers.

If a harmful change occurs:

Pause further deployment.
Disable the agency account if continued access could worsen the incident.
Preserve file-transfer, application, hosting, and access logs.
Identify the modified files or settings.
Restore or roll back to the known-good version.
Test key pages, forms, navigation, scripts, redirects, and status codes.
Check important crawler directives and rendered SEO elements.
Have the appropriate developer, host, or security owner review the cause.
Document what happened and revise the access process before work resumes.

At offboarding:

Disable the dedicated account
Rotate shared credentials
Remove SSH keys, API tokens, and integrations no longer required
Review file, application, and access logs
Confirm ownership and location of files, content, and documentation
Reconcile outstanding branches or unpublished changes
Record configurations that still depend on the provider
Confirm that backups and current source code remain under your control

An FTP request is neither automatically necessary nor automatically suspicious. The governing principle is simple: grant the minimum access needed to complete an explained, approved, testable, and reversible task.

If those conditions cannot be met, keep deployment with your website’s developer and let the SEO team supply and validate the recommendations.

Frequently asked questions

Is it safe to give an SEO company FTP access?

It can be controlled, but it is never risk-free. Plain FTP should be avoided because it transmits credentials and file contents without encryption. Prefer SFTP or FTPS, a dedicated account, limited permissions, staging, logging, a verified backup, a defined expiration date, and prompt revocation.

Safety also depends on what the account can reach. Encryption will not prevent an authorized user from making a harmful edit or deleting a permitted file. The decision should therefore be based on the task, permissions, environment, provider, and change process—not only the protocol.

Does an SEO company need FTP access to WordPress?

Usually not for ordinary page content, headings, titles, meta descriptions, internal links, or many plugin settings. Those changes generally belong in the WordPress administration interface.

File-level or deployment access may be justified for custom theme templates, functions.php, custom plugins, configuration files, or server rules that WordPress does not expose. Even then, SFTP, repository access, staging, or implementation by your developer may be better than direct production editing.

Can SEO work continue if I refuse to provide FTP or production access?

Yes. The agency can audit the website, document recommended changes, define acceptance criteria, and validate the completed implementation while your developer retains deployment responsibility.

You can also offer a restricted CMS role, read-only diagnostics, staging access, a platform collaborator account, or a repository workflow. What matters is assigning responsibility clearly so approved recommendations do not remain unimplemented.

What is the difference between FTP, SFTP, and FTPS?

FTP is the traditional File Transfer Protocol and does not encrypt credentials or file contents in transit. SFTP is a distinct file-transfer protocol that operates through SSH. FTPS retains the FTP model but adds TLS/SSL encryption.

SFTP and FTPS protect data in transit more effectively than plain FTP, but neither eliminates risks caused by excessive permissions, compromised credentials, vulnerable devices, or incorrect edits.

What should I ask before giving an SEO agency website credentials?

Ask for:

The exact business and technical reason
The files, directories, or configurations involved
The minimum permissions required
The precise protocol or platform role
Whether read-only access is sufficient initially
Whether the work can occur in staging
Why the CMS or existing deployment workflow is inadequate
The person who will use the account
The access start and expiration dates
The backup and restoration owner
The testing and approval procedure
The validation criteria and rollback method
The logging and offboarding process

A competent, proportionate request should make those answers easy to provide.