Search Console User Permissions for Agency Access

When an SEO agency gets into a client's Search Console, both sides take on risk. The client opens its site data and settings to outsiders. The agency builds its work on access that could vanish after one email. Most problems come from vagueness rather than bad intent: nobody knows who owns the property, a verification file sits on a former developer's server, and when the contract ends nobody remembers to switch access off.

Short answer: for most agency work, owner access is not needed. According to Google's Search Console help page, adding and removing users, managing owners and linking a Google Analytics account belong to owners only. A full user can do most monitoring and fixing work, while a restricted user is mostly a viewing role. Start with the narrowest role that covers the job and widen it only when a real task requires it.

The advice is for agency managers and for the site owners they work with. Interface names follow Google's English help page. If you use the interface in Turkish or another language, menu names may look different. Role lists and limits in Google's documentation can change, so check the current help page before acting.

Owner, full user, restricted user: what each role covers

Search Console has four concepts to keep apart: owner, full user, restricted user and associate. Google's help page on managing owners, users and permissions (Opens in a new tab) defines them.

Verified and delegated owners

An owner has full control of the property: adding and removing users, changing settings, viewing all data and using all tools. There are two types. A verified owner proved ownership with a verification token such as an HTML file or a tag. A delegated owner was granted ownership by an existing owner without a token. The permissions are identical; the practical difference is that adding or removing a verified owner means adding or removing a token on the site.

Full user: what is allowed

A full user has view rights to all data plus some actions. Per the help page, the list includes submitting sitemaps, full URL Inspection, disavow links, reconsideration requests, verify fixes and sharing report links. For change of address, index coverage, crawl rate settings and removals, the help page lists view-only access.

Restricted user: mostly viewing

A restricted user has simple view rights on most data. The page names links, performance, rich result status reports and a view of all reports. This role receives only the messages that specifically affect them, and URL Inspection is limited to fetch. Verifying fixes and submitting sitemaps are not part of it.

Associates: connected but not inside

Associates are people or accounts that can take certain actions for the site or reach certain data, but they cannot open or view the Search Console account directly. What they can do depends on the association type. This is rarely relevant in agency contracts, but it explains why someone listed as connected may still not see the property.

Role comparison table

Google can rename roles and tools, so open the current help page before you rely on this table. The owner column follows from the statement that owners can use all tools.

Which role fits which engagement

An agency that only prepares monthly performance reports can often work as a restricted user. One that fixes technical issues and asks Google to verify them, manages sitemaps or prepares reconsideration requests needs a full user. Owner access belongs in the discussion only when owner-only tasks, such as user management, property verification or an Analytics link, have to be handed to the agency. Many of those can stay with the client.

Role choice: a three-row screen

In every case, start with the narrowest role that meets the need.

Least access: mapping tasks to roles

Least privilege means giving a person only the access their work needs. For agencies it cuts both ways: it protects the client, and it protects the agency, because an accidental settings change cannot be blamed on a role that never allowed it.

From task list to role

List the tasks the agency will actually perform, then map each to the narrowest role that supports it. Most tasks are viewing and reporting. Sitemap submission, verification of fixes and reconsideration requests call for a full user. Owner-only tasks usually happen once and can stay with the client.

Widening access later

Starting restricted and moving to full user as the work grows is straightforward. The help page says owners can change the permission level of users who are not verified owners. Record each change in writing. Narrowing access later is just as easy from the same screen.

Named personal accounts

A shared agency login is convenient, but the client loses sight of who is using access. Add each agency employee with their own Google account. When someone leaves the agency, only their access has to go, and the client need not change anything else. Remember also that the help page caps non-owner users at 100 per property, which matters for large teams.

Client approval for irreversible actions

Uploading a disavow file, filing a change of address or sending a reconsideration request can have consequences that are hard to reverse. Even if a full user can do them, tie them to written client approval. Add a clause to the contract: actions that are difficult to reverse are not taken without the client's sign-off.

Placing this in the onboarding plan

Access belongs to the start of an engagement. For the broader list of what to collect at kickoff, see the SEO project kickoff checklist for agencies; that article is general, while this one stays on access and permissions. If the client is still deciding whether to hire outside help at all, the comparison in hiring an SEO agency vs in-house is relevant, since the access model depends on that choice.

The access request: email, steps and what to avoid

The first email sets the tone of the relationship. Clients often do not know what Search Console is or which role to grant, and the agency's job is to make the decision easy.

Five things the request should state

Keep the email short and make sure it states five things: which property you need, which role you are asking for, why that role is enough, how long access will last and how the client can grant it. Spelling out the steps reduces your burden because, according to the help page, only owners can add users, and the client has to know which screen to look for.

The steps for the client

1. Open the property in Search Console.
2. Go to Settings, then "Users and permissions".
3. Click "Add user".
4. Enter the agency employee's Google Account email. The help page says email groups are not allowed, so it must be an individual account.
5. Choose the requested permission level and save.

Menu labels here are from Google's English help page. If you use the interface in another language, they may look different. Only owners see this screen, so the request has to reach the right person.

Sample request email

Subject: Search Console access for [brand], [role] level. Hello [name], we are working with [site] on [scope] and would like access to your Search Console property. The "[full user / restricted user]" role is enough for this work, and we are not asking for owner access. Access would run for [contract term] and we will ask you to remove it when the engagement ends. To grant it: Search Console, Settings, Users and permissions, Add user, then [employee Google account]. If any screen looks different from what we describe, send us a screenshot and we will help. Please let us know once it is done.

Phrases and requests to avoid

Do not say "just add us as owner, it is quickest". The client may accept, but ownership is harder to retract, and the help page explains that removing a verified owner means removing verification tokens as well. Avoid asking for access for a shared mailbox too. Personal accounts show who is using the access.

When nobody knows who owns the property

Example scenario: A project management software company hires an agency. Their Search Console was set up years ago by a contractor, and nobody on the current team knows who the owner is. The agency asks the marketing manager to open Users and permissions. The screen does not load for her, which according to the help page means she is not an owner. The first task becomes finding the owner or verifying a new one, before any role discussion begins. The agency notes the issue in its register and does not start reporting work until a client-side owner is in place.

Key events in Analytics

If the agency will report on conversions, it needs to know which events are marked as key events in Google Analytics. Google's help page on key events (Opens in a new tab) says a key event measures an action that is particularly important to the business, that any collected event can become one, and that reports show them in a dedicated column. That page does not cover Analytics access roles, and the documentation there says nothing on the subject, so plan Analytics access separately using the relevant help pages. Asking the client for the current key event list prevents the agency from reporting the wrong measure.

The access register

The most neglected part of access management is the record. A simple table showing who got access to which property, when and why, is a safety net for both client and agency.

Useful columns

Review rhythm

A quarterly review is a reasonable working suggestion. Google gives no interval. At each review compare the real user list in Search Console with the register. A user who appears in one but not the other is a difference to investigate at once.

Tying the register to reports

The register also supports reporting. Knowing which property each number came from makes sources easy to state. For the structure of a monthly report, see how to create an SEO report with a monthly template. Adding a data source line to the report that matches the property name in the register helps the client check the work.

Client-side checks

• Do you know who owns the property?
• Does the role granted match the work being done?
• Was every agency employee added with a personal account?
• Are end dates written in the contract and the register?
• Is there a written approval rule for actions that are hard to undo?
• Have you listed the verification tokens the agency installed?
• Is it clear who will close access when the contract ends?

Agency-side checks

• Did the request email explain why the role is enough?
• Are you using personal accounts, not a shared one?
• Do you log the changes you make to settings?
• If you need owner access, did you explain in writing why?
• Is the handover note and token list ready for the closing day?

Ending a contract: closing out access

When the contract ends, the agency's access should end too. Leaving a former agency with live access is a security, privacy and reputation risk. A written closing record also protects the agency from later questions about who changed what.

Steps to close out

1. Write the contract end date and the planned closing date in the access register.
2. List everything the agency set up: submitted sitemaps, uploaded disavow files, linked accounts, scheduled reports.
3. The client's owner opens Users and permissions and uses the menu next to each agency user to choose "Remove access".
4. If a warning says the user may regain access, remove the verification tokens it lists.
5. Remove any verification methods the agency installed, such as an HTML file, a meta tag or a DNS record.
6. After closing, review the user list once more and look for anyone you do not recognize.

Verification tokens that outlast the contract

According to Google's page, unused ownership tokens stay valid after an owner is removed, so the former owner can verify again and regain access. Current owners are notified if that happens. To remove a verified owner properly you first remove the delegated owner entry, then delete every token that person used. The page adds that one token may also verify other services such as Merchant Center or Google Workspace, so deleting it can affect them. Check where a token is used before deleting it.

A property with no owner left

If all verified owners are removed, the help page says remaining users lose access after a grace period. Data collection continues, but nobody can see it until someone verifies ownership again. When the agency happens to be the only verified owner, have the client verify before the agency leaves.

Spotting an unfamiliar owner

The help page warns that an owner you do not know may mean you have been hacked, and advises securing the site or consulting a security professional. The ownership history view on the same screen logs owner changes and verification attempts, and it is worth checking once after closing.

Handover note

Give the client a short note at the end: what was done, what remains open, where the reports live and which settings were changed. It helps a new agency or an in-house team pick up. If the agency delivers white-label work, handover terms can be agreed earlier; the guide to the white-label sponsored posts agency workflow covers how such arrangements are structured.

Where access arrangements go wrong

A few mistakes explain most access trouble. Knowing them saves time for both sides.

A change of agency mid-project

Changing agencies is the riskiest moment. The client should save a screenshot of the current user list, add the new agency with the narrowest role, receive a handover from the outgoing agency, allow a short overlap written into both contracts, then remove the old users and tokens and check ownership history. Example scenario: a software company leaves an agency whose HTML verification file still sits at the site root. Removing the agency's users is not enough, because the unused token keeps working, as the help page explains. The company verifies itself by another method, deletes the old file and updates the register.

Properties that sit under one another

The help page says that someone who already owns a parent property can only be added as an owner of a child property, and a message like "This user may only be added as 'Owner'" points to that case. If an agency employee already holds ownership higher up, their effective power may be larger than expected. Check parent properties when you review the user list.

Adding an email group

A group address such as seo@agency.example seems tidy, but the help page says email groups are not allowed. Individual accounts are necessary and also better for the record.

Access granted without a written scope

Access is given but nobody wrote down what the agency may and may not do. When a setting changes, the two sides remember different things. Add a short permission scope to the contract or project notes: which tools, which roles and which actions need approval.

Rankings promised through access

Google's Search Essentials (Opens in a new tab) says appearing in results is free and that meeting every requirement does not guarantee crawling, indexing or serving. Wider access does not buy better rankings, so keep that expectation out of the access discussion and out of the contract.

Frequently Asked Questions

How do a full user and a restricted user differ?

According to the help page, a full user sees all data and can submit sitemaps, verify fixes, disavow links and send reconsideration requests. A restricted user has simple view rights on most data, can only fetch in URL Inspection and gets only the messages that specifically affect them.

Should the agency be made an owner in Search Console?

Usually not. Google's help page says adding and removing users, managing owners and linking Google Analytics belong to owners only. If the agency reports on data, a restricted user is enough; if it also submits sitemaps or verifies fixes, a full user typically covers it.

How is an agency removed when the contract ends?

An owner opens Users and permissions and uses the menu next to the user to choose Remove access. If a warning appears, remove the verification tokens it lists, because unused tokens stay valid and the person could verify again. Menu names may look different if you use another interface language.

Can an agency employee be added through an email group?

No. Google's page says email groups are not allowed. Each employee should be added with a personal Google Account, which also shows in the register who is using the access.

Will deleting a verification token affect other Google services?

It can. The help page notes that the same token may verify services such as Merchant Center or Google Workspace, and removing it could affect them. Check where a token is used before you delete it.

How often should the access register be reviewed?

Google specifies no interval. A quarterly review is a reasonable working suggestion. Compare the actual user list in Search Console with the register and investigate any difference.

Related guides: SaaS SEO: What to Do in the First 90 Days, Agency Content Approval Workflow: Revision Limits and Sign-off, Alternative and Comparison Pages: An Honest Writing Guide.

Conclusion

Should an agency get owner access or a restricted user role? Start with the narrowest role the work needs. Google's Search Console help page reserves user management and the Analytics link for owners, lets full users handle sitemaps, fix verification and disavow, and keeps restricted users mostly to viewing. Add each agency employee with a personal account, write the scope of access down, keep a register and, when the contract ends, remove both the users and the verification tokens. Access is not a ranking promise, and no contract term should treat it as one.

Once access is in order and you want to grow a client's authority safely, you can review the backlink packages on Akua Adforce; scope and terms are listed on that page.