What Access Should an SEO Consultant Have to Your Website?

Why does access deserve its own conversation?

Most people hiring an SEO consultant spend their time on price, scope and results. Access gets a passing mention, usually when the consultant says "I'll need logins," and the client sends a spreadsheet of passwords without a second thought. That's understandable. It's also how businesses end up with a stranger holding the keys to their website, their data and sometimes their domain.

Access isn't an afterthought. It's where trust becomes real. It decides what a consultant can see, what they can change and what could go wrong if something does. Getting it right takes an hour and protects an asset worth far more.

What does Google's guidance say?

Google's hiring guidance, in its Search Central documentation, advises limiting access and notes that for an initial audit you can give read-only Search Console access rather than write access. It also says that if an SEO has FTP or server access, they should explain every change they make. The principle running through it is simple: grant what's needed, no more, and insist on transparency.

That's a sound rule for any provider, and it's one a good consultant will happily agree with. If a candidate objects to starting small, that's worth noting.

Why start read-only

Read-only access lets a consultant see the data they need to diagnose problems, without the ability to change anything. If they turn out to be a poor fit, you've lost nothing but time.

What are the real risks of too much access?

Accidental damage is the most common. A well-meaning edit to a template, a redirect rule or a robots.txt file can ripple across hundreds of pages. Then there's security: more people with logins means more ways in for attackers. There's also dependency: if someone controls your accounts, leaving them becomes harder. And there's deliberate misuse, which is rare but not unheard of.

You don't need to assume bad faith to be careful. Good security practice is the same whether you trust someone completely or not at all. It's simply how responsible businesses handle shared systems.

Think of it like a spare key

You'd give a visitor a spare key for a specific purpose, for a limited time, and you'd want it back. Treat digital access the same way.

What can a consultant do with read-only access?

Quite a lot, as it turns out. A surprising amount of high-value SEO work needs nothing more than the ability to look.

That's good news, because it means a safe start is also a productive one.

What does Search Console reveal?

Search Console shows which queries bring impressions and clicks, which pages perform, which pages are indexed and which aren't, reasons for exclusion, Core Web Vitals status, manual actions and security issues, sitemap status and more. A consultant can diagnose a large share of problems from this data alone: indexing gaps, canonical issues, soft 404s, blocked pages and traffic changes.

Reports such as crawled, currently not indexed and discovered, currently not indexed show how much can be read without any write access.

What it doesn't show

Search Console doesn't show how visitors behave on your site or which actions they take. For that you need analytics.

What does analytics add?

Google Analytics 4 shows traffic by channel, landing pages, engagement and, if set up properly, conversions such as form submissions and calls. With read-only access, a consultant can see how organic visitors behave, which pages lead to enquiries and whether tracking looks healthy. That's essential for judging whether SEO is paying off.

If tracking is broken, the consultant can often spot it from the data: missing events, duplicated conversions, spam traffic or odd channel splits. Fixing it later may need more access, but diagnosing it doesn't. What good tracking looks like is covered under measuring organic leads in GA4.

Public information needs no access at all

A crawl of your public website, a review of search results and an audit of your Business Profile as customers see it all need no logins whatsoever.

What do Search Console's permission levels mean?

Search Console has a clear permission model, and understanding it helps you pick the right level instead of defaulting to the highest one.

Google's help page, "Managing owners, users, and permissions," sets out the levels.

What can each level do?

Google also notes that verified and delegated owners have the same permissions. The difference between owner and the rest is who can control access, which is why ownership should stay with you.

Which level for a consultant?

Start with restricted or full user depending on the work. For an audit, restricted or read-only access to data is typically enough. For ongoing work such as submitting sitemaps or handling issues, full user is usually sufficient. Owner is rarely needed.

Why should the owner be you?

Because owners control who else has access. If a consultant is the sole owner, you can lose the ability to manage your own data if the relationship ends badly. Create the property under an email address your business controls, add a second internal owner as a backup, then add the consultant at a lower level.

The same logic applies everywhere. Whoever owns the account owns the history, and years of data are valuable. Don't let them sit under someone else's login. A broader take on this appears in the questions to ask an SEO consultant before hiring.

Check who has access now

Open Search Console's settings, then users and permissions. You may find old agencies and former employees still listed. Remove anyone who shouldn't be there.

When does a consultant need more than read-only access?

Eventually, most hands-on work needs some write access. That's normal. The key is to widen access deliberately, for a defined task, rather than all at once.

Here's how that tends to unfold.

Which tasks justify broader access?

Submitting sitemaps and handling indexing requests, which a full user in Search Console can do. Editing titles, content and internal links, which needs CMS access. Changing redirects, caching or server rules, which needs hosting or server access. Installing or editing tracking, which needs tag manager access. Managing your local listing, which needs Business Profile manager access. Making template or code changes, which usually goes through a developer.

Each task has a natural level of access, and the principle is the same: give the lowest level that lets the task be done. If a task can be handled by sending a ticket to your developer instead, that's often safer still.

Ask for the task first, then the access

A good consultant will say, "To fix X, I need Y access, for about Z days." Vague requests for "everything" are a signal to slow down.

What about CMS access?

If the consultant will edit content, give them a named user account with the lowest role that allows it. On most platforms that's an editor or similar role, not an administrator. Admin rights can install plugins, change settings and edit code, which is far more than content work needs. Turn on any available logging of changes and make backups before significant edits.

Ask them to work on a staging copy for anything structural, and to get your approval before publishing. It slows things by a little and prevents a great deal of grief.

Don't share your own login

Never give out your personal credentials. Shared logins make it impossible to know who did what, and they're a security risk. Create a separate account for each person.

What about hosting, FTP and server access?

This is the highest-risk tier, and it deserves extra caution. Server access lets someone change files, redirects, caching and sometimes the database. Used well, it's powerful. Used carelessly, it can take a site offline.

Google's hiring guidance explicitly flags it.

When is server access legitimate?

For certain technical work: setting up redirects at server level, adjusting caching and compression, fixing server errors, configuring HTTPS, editing robots.txt on a platform that doesn't expose it in the CMS, or investigating performance. Some of these can be done through a developer, which is often the better route for a business without in-house technical staff.

If the consultant does need access, the same rules apply: named account, lowest permission, written scope, backups first and a clear explanation of every change. Google's guidance says an SEO with FTP or server access should explain every change they make. Hold them to that.

Prefer a developer as the hands

A consultant who diagnoses and writes a precise ticket, with your developer implementing and testing, gives you a second pair of eyes and a safer process.

How do you make server access safer?

Use individual credentials, not a shared account. Use SFTP rather than plain FTP where possible. Take a full backup before any change. Use a staging environment for anything risky. Set up logging so changes can be traced. Consider time-limited access that expires automatically. And agree in writing which directories and settings can be touched.

Keep a record of what was done. If something breaks, a change log shortens the investigation from days to minutes. A technical SEO consultant should use this approach for every engagement.

Revoke it the moment the task ends

Don't leave server access open "just in case." It takes a minute to remove and a lot longer to clean up after a problem.

Who should own your accounts?

Ownership is separate from access, and it's the single most important protective habit. Whoever owns an account controls its history, its permissions and its future.

The rule is simple: your business owns everything important.

Which accounts should be in your name?

Your domain registration. Your hosting account. Google Analytics. Google Search Console. Google Tag Manager. Your Google Business Profile. Any advertising accounts. Your CMS admin accounts. Your email and DNS provider. Social profiles tied to the business.

Register each with an email address your business controls, such as a role-based address rather than one person's inbox, and keep the recovery details current. Record where each account lives and who the owners are, in a shared document stored securely.

Beware of agency-owned properties

Some providers set up accounts under their own logins "for convenience." If they leave, you may lose data, listings or even the domain. Insist on ownership before work begins.

How do you protect ownership in practice?

Add at least two internal owners so that nobody's absence locks you out. Use strong, unique passwords and multi-factor authentication on every account that supports it. Store credentials in a password manager rather than in emails or spreadsheets. Review owners and users quarterly.

If you've inherited accounts and aren't sure who owns what, start with an access audit. It's a dull afternoon that can save a crisis. An SEO audit begins with exactly that kind of inventory.

Use role addresses

An address like web@yourcompany.co.uk survives staff changes. A personal inbox doesn't.

How do you grant access safely?

Method matters as much as level. Even the right permission can be granted in an unsafe way.

A few habits make the difference.

What are the safest ways to share access?

Use each platform's built-in user invitation rather than sharing a password. Search Console, Analytics, Tag Manager, Business Profile and most CMS platforms let you invite a named user with a chosen role. That keeps logs clean, lets you revoke access without changing passwords and avoids exposing your own credentials.

Where a password is unavoidable, share it through a password manager, never by email or chat, and change it afterwards. Turn on multi-factor authentication wherever possible. Ask the consultant to use a business email address, and to enable multi-factor authentication on their own account.

Name every user

Individual accounts create accountability. A generic "seo@" login hides who did what.

What should you write down?

A simple access register: who has access, to which platform, at what level, for what purpose, granted on what date and due for review on what date. Add the consultant's agreed scope, and note any conditions, such as "staging only" or "no publishing without approval."

Keep a second copy somewhere safe. It's your map of who can touch what, and it makes reviews and offboarding quick. It also shows the consultant that you take security seriously, which tends to raise the standard on both sides.

What should a consultant do to look after your access?

Access is a two-way responsibility. A professional will treat it carefully, and you can check that they do.

Ask these questions before granting anything.

Which security practices should you expect?

Multi-factor authentication on their accounts. Use of a password manager. A separate, business-owned device or secure workspace for client access. No sharing of credentials with subcontractors without your written consent. Prompt notification if they suspect a breach. And a clear explanation of how they store and handle your data.

If they use freelancers or tools that touch your data, ask who they are and what they can see. Under UK data protection rules, you remain responsible for how personal data is handled, so a professional will be comfortable discussing it. How access is handled is part of a clear SEO consulting process.

Ask about insurance

Professional indemnity and cyber insurance can matter if something goes wrong. A reputable provider should be able to say what they carry.

What should you ask about subcontractors and tools?

Whether any part of the work is done by someone else. Which tools will connect to your accounts and what permissions those tools request. How the consultant would handle a data breach. And whether they'll agree to a data processing arrangement where personal data is involved.

Many SEO tools ask for broad access to Google accounts. Check what each one requests, and revoke any you don't need. A tidy list of connected apps is another quiet security win.

Keep the list short

The fewer tools and people touching your accounts, the smaller the attack surface.

What does good offboarding look like?

Work ends. People move on. A clean exit is part of a professional engagement, and it's the moment most businesses forget to check.

A short routine covers it.

What's the offboarding checklist?

Remove the consultant's users from Search Console, analytics, Tag Manager, the CMS, hosting, the domain registrar, the Business Profile and any other platform. Change any shared passwords and revoke any API keys or tool connections. Review the access register and update it. Check that you hold copies of all deliverables, documents and notes. Ask for a summary of work in progress and any credentials they were holding.

Then verify. Log in as an owner on each platform and confirm that the list of users is what you expect. Don't rely on a promise. Check.

Do it on the last day

Delays create risk. Make it a fixed step in the agreement, with a date.

What if the relationship ended badly?

Move fast. Change passwords, remove access and review recent changes for anything unexpected: new users, new redirects, altered content, new tracking codes. Check Search Console for security issues and manual actions, and review your Business Profile for unauthorised edits. Document everything.

If you can't get access back because the provider owns the accounts, contact the platforms' support with evidence of ownership, such as company records and domain registration details. It's slower than doing it right in the first place, which is the whole point of owning accounts from the start. Warning signs worth catching earlier are listed among the SEO consultant red flags.

Keep calm and keep records

A methodical review beats a panicked one. Work through each platform in turn and note what you find.

What does a sensible access plan look like in practice?

Let's pull it together. This is a hypothetical example for a small business, showing how access might evolve over a first few months.

It's a model, not a rule.

Weeks one to four: look, don't touch

The consultant gets read-only access to Search Console and analytics, and does a public crawl. No CMS, hosting or tag manager access. All findings go into a written diagnosis and ranked list of recommendations. The business reviews the list and approves the first set of changes. The access register is created and the consultant's scope is written down.

At this stage, nothing on the live site has changed unless the business or its developer changed it. That's exactly where you want to be before you know whether the relationship works.

What you've risked

Almost nothing. The most the consultant could do is read data you'd have shared with an employee anyway.

Months two and three: widen with care

As tasks are approved, access widens. The consultant becomes a full user in Search Console to submit sitemaps. They get an editor account in the CMS for agreed content changes, with backups and a change log. Technical fixes go through the developer, via clear tickets. Tag manager access is granted for a specific tracking fix and removed afterwards. Everything is recorded in the register.

At the review point, the business checks the change log against the plan, confirms nothing unexpected has happened and decides whether to continue. If it does, access stays at the minimum needed. If it ends, offboarding is quick because everything is documented. A typical engagement follows an SEO consulting process, and an SEO audit is the natural place to begin.

The principle to keep

Trust is earned in steps. Access should follow trust, not lead it.

What about Google Business Profile, tag manager and other platforms?

Search Console and the CMS get most of the attention, but a handful of other platforms matter too. Each has its own roles, and a few quirks are worth knowing before you invite anyone in.

Here's a quick tour.

How should you handle Google Business Profile access?

Add consultants as managers, never as primary owners. The primary owner controls the listing, can add and remove other managers and can transfer ownership. Keep that role with someone in your business, and add a second owner as a safeguard. If an agency or consultant becomes the sole owner and the relationship ends badly, recovering the listing can be slow and stressful.

Review the list of managers every few months. Old agencies and former staff often linger. Careless edits and uncontrolled access can lead to trouble with a suspended Business Profile, and a clear record of who changed what is so valuable.

Don't hand over a personal Google login

Use the platform's invitation system. Sharing a personal Google account exposes your email, documents and everything else it can reach.

What about Google Tag Manager and tracking?

Tag Manager lets people add scripts to every page of your site, which is powerful and risky. A bad tag can slow the site, break forms or leak data. Give consultants the lowest role that fits: read-only for review, edit for a specific tracking task. Use workspaces and version notes, and publish only after review.

Keep a log of containers, tags and who changed them. When the task ends, remove access or downgrade it. Tracking code that nobody owns tends to accumulate and cause problems later, so keep it tidy.

Check what's already installed

Many sites carry old tags from previous agencies. A quick audit of tags and connected accounts often finds things nobody remembers adding.

What about domain registrar and DNS?

Rarely needed, and very high risk. Changes to DNS can take a site or email offline. If a consultant must make DNS changes, such as for verification or a migration, it's usually safer to have your developer or IT provider make them under written instruction. Keep the registrar account in your name with multi-factor authentication, and never share its login.

If you give anyone temporary access, record it, set a removal date and check afterwards. The domain is the most valuable single asset of the website, so protect it accordingly.

The registrar lock

Many registrars offer a transfer lock and extra verification for sensitive changes. Turn them on.

How do you review access over time?

Access isn't a one-off decision. People change roles, projects end and tools get connected and forgotten. A short routine keeps the list honest.

Think of it like checking the smoke alarms.

What does a quarterly review involve?

Open each platform's user list and compare it with your access register. Remove anyone who no longer needs access. Downgrade anyone who has more than they use. Check connected apps and revoke the ones you don't recognise. Confirm multi-factor authentication is on. Update the register and note the date.

It takes perhaps half an hour for a small business. It's one of the cheapest security improvements you can make, and it also keeps you aware of what's connected to your most important accounts.

Add it to the calendar

A recurring reminder on the first Monday of each quarter is usually enough. Without a reminder, it never happens.

What should trigger an immediate review?

A staff member leaving. The end of a contract. A suspected security incident. A suspicious email or login notification. A migration or redesign. A change of provider. Any of these is a reason to check access straight away, rather than waiting for the next quarter.

An SEO audit and a technical SEO consultant both start with an inventory of what exists and who controls it. Access is boring until it matters, and then it's the only thing that does.

What should you do if you've already shared too much?

It happens a lot. A password sent in an email years ago, an old agency still listed as an owner, a freelancer with admin rights who hasn't touched the site in a year. The good news is that it's fixable, and you can do most of it in an afternoon.

Don't blame yourself. Just start.

How do you clean up in one afternoon?

Make a list of every platform: domain registrar, hosting, CMS, Search Console, analytics, Tag Manager, Business Profile, advertising, email and social. Open each user list. Note who's there and why. Remove anyone you don't recognise or no longer need. Change passwords on shared accounts, turn on multi-factor authentication and move the credentials into a password manager.

Then look at connected apps and API access in your Google account and platforms, and revoke the ones you don't use. Finally, write the access register, even if it's a rough first draft. You can refine it later.

Check for surprises

While you're in each platform, look at recent activity if it's available. Unexpected logins, new users or recent setting changes are worth investigating.

When should you get help?

If you find signs of unauthorised changes, if you can't regain control of an account, or if a former provider is holding something hostage, don't struggle alone. Contact the platform's support with evidence of ownership, and consider a security review from your IT provider. Take a methodical approach, keep records and protect the most valuable assets, the domain and the analytics history, first.

Once the immediate risk is under control, set up the routine described above, so it stays tidy. A small amount of regular attention is far cheaper than an emergency.

Where to go next

With access sorted, the next step is making sure you're working with the right person in the first place. The red flags and the questions to ask before hiring cover that.