Search Console Users and Permissions: The Access Decision You Make Once and Live With
How to add users to Google Search Console, what each role can do, and why deleting a verified owner does not remove them. Written for agencies and handovers.
Search Console has three permission levels and two kinds of owner, and the difference between the two owner kinds is the only part that ever causes a real problem. The shape of it:
- Three roles: Owner does everything including adding people. Full user does the work but cannot manage access. Restricted user mostly looks. Permissions are per property, never per account.
- Two kinds of owner: A verified owner holds a verification method on the site. A delegated owner was granted ownership by someone else. Same powers, completely different to revoke.
- The trap: Deleting a verified owner in the interface does not remove them. Their verification token is still on the site, so they can re-verify. You have to remove the token too.
- How to add someone: Settings, then Users and permissions, then Add user. Email address and a role. They need a Google account on that address and nothing else.
- For agencies: The client verifies and adds you as a full user. Never verify a client's property with your own DNS record: it makes offboarding a request rather than a click.
Domain properties cover every subdomain, so access to one is access to all of them. Check what you are handing over before you hand it over.
This is Google's access model, not a CrawlRaven feature, and it applies whatever tooling you use on top. It matters here for one reason: connecting any tool to Search Console, ours included, runs through the permissions below. Try CrawlRaven free: 1 site, no credit card →
Nobody reads the permissions documentation until something has gone wrong, and by then the problem is usually the same one: a former agency, contractor or employee still has access, and removing them in the interface did not work.
The model is small enough to learn in ten minutes. Doing that before you hand out access is the difference between an offboarding that takes a click and one that takes an email you would rather not send.
How to add a user to Search Console
Four steps, and the only prerequisite is that you are an owner of the property.
- Open Search Console and select the property from the picker at the top left.
- Go to Settings, then Users and permissions.
- Click Add user, and enter the email address of the Google account you are granting access to.
- Pick a permission level, then confirm. Access is immediate and the person gets an email.
If there is no Add user button, you are a full or restricted user rather than an owner. Managing access is owner-only, and no amount of full-user permission unlocks it.
The three roles, and what each can actually do
The names undersell the gap between them. Full user sounds like everything and is not, and the missing pieces are the ones that matter in a handover.
What each Search Console role can do
| Action | Owner | Full user | Restricted user |
|---|---|---|---|
| View Performance and Indexing reports | Yes | Yes | Yes |
| Use URL Inspection | Yes | Yes | Limited |
| Submit and remove sitemaps | Yes | Yes | No |
| Request removals | Yes | Yes | No |
| File a reconsideration request | Yes | Yes | No |
| Use the disavow tool | Yes | No | No |
| Add and remove users | Yes | No | No |
| Link to Analytics, Ads or other products | Yes | No | No |
| Change property settings | Yes | No | No |
Full user is the correct default for almost every real person: it covers the entire day-to-day job without letting anyone quietly widen the circle. Restricted is for stakeholders who want the numbers and should never touch a control.
Owner is for the people who are accountable for the property existing, which in most organisations is one or two people, not the SEO team.
Verified owner against delegated owner
This is the distinction the whole page exists for. Inside Search Console the two are identical. Outside it, they are nothing alike.
Verified owner against delegated owner
The asymmetry is the point. A delegated owner exists entirely inside Search Console, so Search Console can remove them. A verified owner exists because of something on your website, and only changing your website removes them.
Which verification method you used therefore decides who holds the keys long-term. The methods themselves, and why DNS is the durable one, are covered in the Search Console guide.
Removing someone, properly
Offboarding has two different procedures and using the wrong one is why people end up here.
- A full user, restricted user or delegated owner. Settings, Users and permissions, the three-dot menu, Remove access. That is genuinely all of it.
- A verified owner. Remove their verification token from the site first, whether that is a DNS record, an HTML file, a meta tag, or their access to the Analytics or Tag Manager account that verified them. Then remove them in the interface.
- Check the order. Removing the user first and the token later leaves a window in which they can re-verify, and nothing warns you if they do.
- Confirm the token is really gone. If they verified with an HTML meta tag, the free meta tag checker reads what your page actually serves, which is not always what your CMS believes it serves.
- Confirm afterwards. Reopen Users and permissions a day later. An owner who came back is a real thing that happens.
This is also the moment to think about what leaves with them. If the departing party held the only API credentials, any reporting built on the Search Console API stops the same day, quietly.
What a permission actually covers
Permissions attach to a property, not to a person or a domain, and the property type decides how far the grant reaches.
- A domain property covers everything. Every subdomain, both protocols. Granting access to it grants access to your staging subdomain, your help centre and anything else you forgot lives there.
- A URL-prefix property covers one prefix. Narrower by design, which occasionally makes it the right choice for a shared section with separate owners.
- Nothing is inherited. Access to a domain property is not automatically access to a separate URL-prefix property on the same site. They are unrelated objects.
- Platform properties are separate again. Verifying a social account creates its own property with its own user list, as covered in adding social media to Search Console.
Agencies: the setup that survives an offboarding
Client access is decided in week one and felt in the final week. Four common setups, and only one of them ends cleanly for both sides.
Four ways agencies set up client access
The recommendation is unglamorous: the client verifies the property, the agency is added as a full user. It costs the agency nothing in capability and costs the client nothing in trust.
Agencies that verify client properties with their own token usually are not being sinister. It is faster, the client does not have DNS access to hand, and it gets the engagement moving on day one.
It still creates a hostage. When the relationship ends badly, and some do, a client discovering they cannot revoke their own Search Console ownership turns a business disagreement into a technical one. Take the extra day and let them verify.
Service accounts and tools count as users
Anything reading your property programmatically holds a permission, and that permission is granted on this same screen.
- Service accounts are users. Add the email ending in
.iam.gserviceaccount.comexactly as you would a colleague. Creating it in Google Cloud grants nothing on its own, which is the most common cause of a 403 from the API. - Restricted is usually right for them. A reporting integration reads. Give it full only when it genuinely submits sitemaps or acts on the property.
- OAuth connections are tied to a person. A tool connected through someone's sign-in loses access when that person does, which is a failure mode people meet on somebody's last day.
- Audit them like people. A service account for a pipeline nobody has run since last year is standing access with no owner watching it.
The access audit worth running once a year
Ownership propagates quietly, because every owner can add further owners and nobody is notified when they do. An hour a year keeps it honest.
- Open Users and permissions on every property. Read the list out loud. Names you cannot place are the finding.
- Separate verified from delegated owners. The verified ones are the list that needs a site change to revoke, so they are the list that matters.
- Check Ownership verification details. If verification runs through one person's Analytics or Tag Manager account, move it to a DNS record on a company-controlled domain.
- Downgrade anyone who does not need their level. Most owners should be full users, and most full users are stakeholders who only read.
- Remove service accounts for dead pipelines. Then confirm nothing broke, because sometimes the pipeline was not dead.
Do this on the same day you export the links report and check your data pipelines, and the whole housekeeping job fits in one afternoon a year.
Key Takeaways
- →Three roles: Owner does everything including managing access. Full user does the day-to-day work but cannot add people. Restricted user mostly reads. Full is the right default for real humans.
- →Two kinds of owner, one hard to remove: A delegated owner exists inside Search Console and can be removed there. A verified owner exists because of a token on your site, and only removing that token revokes them.
- →The removal order matters: Take the verification token off the site first, then remove the user. Do it the other way round and there is a window in which they can silently re-verify.
- →Permissions are per property, and scope varies: A domain property covers every subdomain and both protocols. Granting access to one hands over staging and everything else living under that domain.
- →Agencies: let the client verify: Client verifies, agency is added as a full user. An agency-held verification token turns offboarding into a request to a company the client just stopped paying.
- →Service accounts are users too: Add the .iam.gserviceaccount.com address here or the API returns 403 forever. Restricted is usually the right level, and they need auditing like people.
- →Audit once a year: Every owner can add owners and nobody is notified. Read the list, move verification to company DNS, downgrade what you can, and remove pipelines nobody runs.
Primary sources
Frequently asked questions
How do I add a user to Google Search Console?
Open the property, go to Settings, then Users and permissions, then Add user. Enter their email address and pick a permission level: Owner, Full or Restricted. They need a Google account on that address, and nothing else. Only owners can add users, so if you cannot see the Add user button, you are a full or restricted user on that property.
What are the permission levels in Google Search Console?
Three. Owners can do everything, including adding and removing users, changing settings, linking other Google products and using the disavow tool. Full users can view all data and take most actions, such as submitting sitemaps and requesting removals, but cannot manage access. Restricted users can view most reports with limited ability to act.
What is the difference between a verified owner and a delegated owner?
A verified owner proved ownership themselves through a verification method: a DNS record, HTML file, meta tag, Analytics or Tag Manager. A delegated owner was simply granted ownership by an existing owner and holds no verification of their own. Their powers inside the property are the same; how you revoke them is not.
Why is a removed owner still showing in Search Console?
Because you removed the user, not the verification. A verified owner's claim rests on a token still sitting on your site, such as a DNS TXT record or an HTML file. Deleting them in Users and permissions does not touch it, so they can re-verify at any time. Remove the token from the site as well, then remove the user.
How do I give my SEO agency access to Search Console?
Verify the property yourself, then add the agency as a full user in Settings, then Users and permissions. Full is almost always the right level: it lets them submit sitemaps, request removals and read everything, without letting them add other people or change your settings. When the engagement ends, you remove one user.
Should an agency verify a client's Search Console property?
No, if it can be avoided. An agency that verifies with its own DNS record or HTML file becomes a verified owner, and the client cannot fully revoke that alone: the token has to come off the site. It turns a routine offboarding into a request to a company you have just stopped paying. Let the client verify.
Does Search Console access cover subdomains?
It depends on the property type, and this catches people out. A domain property covers every subdomain and both protocols, so granting access to it grants access to your staging subdomain and everything else under the domain. A URL-prefix property covers only that exact prefix. Check which one you are sharing before you share it.
Can a full user add other users to Search Console?
No. Managing access is owner-only, by design. A full user can do essentially all the day-to-day work, including sitemaps, removals and reconsideration requests, but the Add user control is not available to them. If you need someone to manage a team's access, they need ownership, not a full-user upgrade.
How many users can a Search Console property have?
Enough that the practical limit is your own discipline rather than Google's cap. The more useful question is how many should have it: every owner can add further owners, so ownership propagates quietly across contractors and former staff unless someone audits it. Review the list once a year.
Do I need to add a service account as a user for the API?
Yes. Creating a service account in Google Cloud grants it nothing in Search Console. You have to add its email address, the one ending in .iam.gserviceaccount.com, as a user on the property, exactly as you would add a person. It is manual, needed once per property, and it is the most common cause of a 403 from the API.
What happens to a property if the owner leaves the company?
If they were a delegated owner, another owner removes them and nothing else changes. If they were the verified owner and verification ran through their personal Analytics or Tag Manager access, their departure can break verification for everyone. Verify through DNS on a company-controlled domain so ownership never rests on one person's account.
15+ years of growing SaaS websites through SEO | Author, 200-Point Audit Checklist
Aditi has spent 15+ years helping SaaS companies scale organic traffic through technical SEO and content strategy. She is the author of the CrawlRaven 200-Point Audit checklist used by agencies and in-house teams to systematically improve search performance.