Removing Users from Search Console: Old Agency, Owner or Employee

How does removing users from Search Console work for an old agency or employee?
Removing users from Search Console means an owner takes a person off the property's users list. A delegated owner or user leaves the list directly. A verified owner only loses access once you delete their verification token from your site or DNS. Follow the right order and the old agency loses access while you stay in control.
Do not panic, but do not rush either. The order matters, because one wrong deletion can lock you out. Follow these steps in sequence:
- Confirm that your own Google account already owns the property.
- Check whether the person is an owner, a full user or a restricted user.
- For a delegated owner or user, remove access from the users list.
- For a verified owner, delete the token from your site or domain records.
- Clean up linked Google Analytics and Tag Manager access separately.
However, this article covers this single situation only. For general use of the tool, read our Search Console guide. For every detail below, the sources are Google's Search Console help page on owners, users and permissions and the site ownership verification help page, so return there if menu names change.
How do you see who has which permission before removing users from Search Console?
Start with a record. Open the users and permissions list in the property settings, then copy every email address and role into a table. Google's help page says only property owners manage users. So if you cannot see the list, your account is not an owner, and you need to find the real owner first.
Also, menu names can change over time. The help page describes Settings, then Users and permissions in the English interface. Your interface may show a similar section under a slightly different name.
If you spot addresses you do not recognize, do not delete them yet. For example, one could belong to a former intern, a previous agency or a software vendor. Find out who it is first, then decide. That way you will not cut off an integration that still works today.
- The person's email address and role.
- When and why you added them, if you know.
- Whether they still work with you.
- Whether they need access for another job.
Then fill in this table for each property separately. A domain property and a URL-prefix property can show the same site but keep two separate user lists.
What is the difference between a verified owner and a delegated owner?
A verified owner proves ownership with a verification token. A delegated owner receives ownership from another owner and needs no token. According to Google's help page, both have the same full control over the property. However, the difference shows up when you try to remove them.
An existing owner can take a delegated owner off the users list. For a verified owner, removing the list entry is not enough. Ownership rests on a token that sits on your site.
| Feature | Verified owner | Delegated owner |
|---|---|---|
| How they become an owner | By proving ownership with a token | Another owner grants the role |
| Permission level | Full control | Full control |
| How you remove them | Delete the token from the site or DNS | Remove access from the users list |
| Common mistake | Removing the list entry but leaving the token | Not knowing who granted the role |
In short, never act before you know which type of owner the old agency is. The wrong type changes the whole result.
What can a full user, a restricted user and an associate do?
The help page lists four roles: owner, full user, restricted user and associate. A full user sees most data and can take some actions. For example, a full user can upload a disavow file and submit a sitemap. A restricted user mostly views data and cannot do much else.
Therefore this split affects your decision. If the old agency is a full user, it can still change your sitemap. If it is a restricted user, the risk is lower, but it still sees your report data.
- Owner: full control and user management.
- Full user: sees most data and takes some actions.
- Restricted user: mostly views data.
- Associate: a third-party account you set up for specific tasks, without direct access to the interface.
You can also lower a role instead of removing it. For instance, move an employee who has not finished a project from full user to restricted user. Then they keep reading reports but cannot change property settings.
How do you remove a delegated owner or a user step by step?
This is the easiest path, so start here. Sign in to Search Console with an owner account and pick the right property. Open the users and permissions section in the settings. According to the help page, you then open the menu next to the person and choose the option to remove access. In the English interface, that option reads Remove access.
- Make sure you picked the right property, because a domain property and a URL-prefix property keep separate lists.
- Open the users and permissions list.
- Open the menu on the row of the person you want to remove.
- Choose the remove access option and confirm.
- Refresh the list and check that the person is really gone.
If you defined several properties for the same site, repeat the steps in each one. A user list in one property does not carry over to another. Also, agencies leave this detail behind more often than any other.
For example, a business removes the agency from its domain property but forgets a URL-prefix property it opened years ago. The agency keeps seeing reports there.
Why does removing a verified owner require deleting the verification token?
Verified ownership depends on a token that sits on your site. Google's help page says that removing an owner from the list does not delete their verification tokens. As long as the token stays, the old owner can verify the property again. So the real shutdown happens when you remove the token.
Google also checks regularly that the token is still present and valid. Once you delete it, that person's owner status drops. In other words, ownership lives in the proof on your site, not in anyone's email address.
Here is the one danger. If the only token on your site came from the agency, deleting it locks you out too. The help page says a property needs at least one verified owner. Therefore add your own token first, then delete the old one.
You cannot always tell from a record who a token belongs to. So test each method one at a time and check your access after every deletion.
Which verification method sits where, and how do you clean it up?
The help page describes six methods. Five of them matter to you: an HTML file, an HTML tag, Google Analytics, Google Tag Manager and a domain name provider (DNS). The sixth is automatic for Google Sites and Blogger. Because each method keeps its token in a different place, check them all.
| Method | Where the token sits | How to clean it up |
|---|---|---|
| HTML file | A special file in your site's root folder | Delete the file from the server |
| HTML tag | The top of the homepage, or theme and plugin settings | Remove the tag from the theme or plugin |
| Google Analytics | The tracking code and edit rights on it | Remove the code or the person's Analytics access |
| Google Tag Manager | The Tag Manager container | Remove the item from the container and the person's access |
| DNS record | The record list at your domain provider | Delete the verification record |
If you struggle to find records, our DNS lookup tool lists the records of your domain. For the Tag Manager side, our Google Tag Manager guide helps.
Many sites use several methods at once. So do not delete one token and call it done. Check each method separately.
In what order should you work so you do not lose access?
The order is simple: add first, remove second. Verify your own Google account with a method that does not depend on the agency's tokens. Then open the property at least once and confirm you see reports. Then do not delete anything before that check.
- Add a new verification method with your own account, for example a DNS record.
- Confirm that the verification succeeds.
- Keep more than one method, because the help page recommends that for redundancy.
- Then remove the old users from the list.
- Finally, delete the old tokens one by one.
- Open the property after each deletion to test your access.
Redundancy matters. The help page reminds you that a template change can drop a tag by accident. If you rely on one method, you can lose ownership on the day you redesign your site.
So run the same check before any big site change. Our website migration SEO checklist covers the rest.
Why should the business's own Google account own the property?
First, ownership should belong to the business, not to a person. If an agency's or employee's personal account owns the property, control leaves with them. Besides, recovering access for someone whose account has closed is hard.
So use a Google account that the business can manage. A shared company address is safer than one person's email. However, store that account's password in a safe place and turn on two-step verification.
- First, add the business's own account as an owner.
- Then give the agency the full user role, and do not make it an owner unless needed.
- Also, use a separate account for each person and never share one password.
- Review the role list on a regular schedule.
For a general plan on who owns which account, see our digital asset management guide. It shows how to put every asset, from domain to ad account, into one inventory.
What should a handover checklist include when an agency or employee leaves?
A checklist writes down who did what. That way, the settings the departing person created do not vanish quietly. Build the list before they leave, while you can still reach them.
- The list of properties, including domain and URL-prefix properties.
- Users and roles in each property.
- The verification methods in use and where each token sits.
- The sitemaps you submitted.
- Any disavow file you uploaded.
- Linked Analytics and Tag Manager accounts.
- The addresses that receive report and alert emails.
Also, keeping the list in a shared sheet is the most practical way. If you update it during the engagement, only a final check remains on the last day. The next person also starts from the same sheet.
Record the indexing status too. For example, compare your list of unindexed pages before and after the handover. Then you can see whether anything broke along the way.
Which other connections and accesses should you check besides Search Console?
Search Console is not the only door. Also, the same agency probably has rights in Analytics, Tag Manager and your ad account. So closing one door and leaving the others open is only half the job.
Besides, when your verification method depends on those accounts, one move affects two things. If you verified with Analytics and then remove the Analytics code, you also drop ownership. So build the backup method first.
- Analytics: the user list and property access.
- Tag Manager: account and container users.
- Google Ads: manager account links; read our guide to agency access in Google Ads for details.
- The domain provider and the hosting panel.
- The site admin panel and plugin accounts.
Each one has its own menus, so use that platform's official help for the steps.
For example, the old agency still has admin rights in your Tag Manager container. A change there could break your conversion tracking and your verification at once. That is why Tag Manager access is often more sensitive than Search Console access.
How do you confirm that access really ended after removing users from Search Console?
Seeing the person vanish from the list is not enough. For verified ownership especially, test the shutdown separately. A token may still sit somewhere else.
- Refresh the users and permissions list and check that the address is gone.
- Review the verification methods and make sure none from the agency remains.
- If possible, ask the former person to confirm they cannot open your property.
- Open the list again after a few days and check that nobody new has appeared.
Google checks tokens on a regular schedule, so the effect may not show up right away. Therefore look again after a day or two. Write down the result, because a record helps if the same question comes up later.
Is the process different for a former employee or freelancer?
The technical steps stay the same. However, the difference shows up with personal accounts. Employees often joined with a personal Gmail address. In that case, control of the property hangs on that person's account.
So build your own ownership first. Then remove the employee's access and clean up any tokens they set. If you have a good relationship with the person, ask where the tokens sit. If not, find them yourself with the lists above.
Also, freelancers add one more detail. Several people may have worked on the project. Therefore never delete unfamiliar addresses without asking first.
If there is a legal dispute, this article is not legal advice. Ask a professional to review your contract.
What mistakes come up most often when removing users from Search Console?
Most mistakes come from haste and a mixed-up order, so the table below sums up the common ones.
| Mistake | Result | The right way |
|---|---|---|
| Deleting the token before adding your own | Nobody can open the property | Add your own method first |
| Removing the user but leaving the token | The old owner can verify again | Remove the token too |
| Cleaning only one property | Access continues in the other | Check every property one by one |
| Relying on a single method | Ownership drops after a theme change | Keep more than one method |
| Forgetting Analytics and Tag Manager | Access continues through those accounts | Clean up the linked accounts too |
Another mistake is giving the new agency too much power. Ask the same question for every new agency: does it really need to be an owner to do this job? Most of the time, the full user role is enough.
Last, many teams keep no records. If you do not know where a deleted token sat, rebuilding it later becomes harder.
Does removing a user affect the property's data and reports?
First, removing a user closes that person's access. The property itself and its other users stay untouched. Report history belongs to the property, not to a person.
However, the real risk is losing all owners. According to the help page, a property needs at least one verified owner. Otherwise nobody has access, and you must verify the property again.
Also, the settings the old agency made stay in place. For example, a sitemap it submitted or a disavow file it uploaded does not disappear. Review them and update them yourself if needed.
You will not see a sudden jump in reports, because data collection depends on your site, not on the user list. Still, check your reports for a week. If you see an unexpected drop, review your verification methods first.
If a new property shows no data, do not panic. Our article on the processing data message explains the wait.
How do you set up ownership correctly from day one with a new agency?
The best fix is never having the problem, so plan ahead. Create the property yourself with the business account and verify it. Give the agency the full user role. Then it can do its work without owning your property.
- Open the property with the business's account.
- Do not give the agency ownership unless needed.
- Manage the verification tokens yourself.
- Add access end dates and a handover note to the contract.
- Review the user list every three months.
Also ask about access policy when you choose an agency. A good agency finds it natural to leave ownership with the client. For selection criteria, see our comparison of agencies and freelancers.
How do domain and URL-prefix properties change the removal process?
You can find two kinds of properties for the same site in Search Console. A domain property covers all subdomains and protocol variants. A URL-prefix property covers only the address you typed. Google's help center describes property types separately, so here we only cover why they matter for removal.
The key point is that each property has its own user list and its own verification method. A domain property usually verifies through DNS. A URL-prefix property can verify through a file, a tag, Analytics or Tag Manager.
- For a domain property, check the DNS records.
- For URL-prefix properties, check the file, the tag and the linked accounts.
- Clean the user list in each property separately.
- Include old properties you no longer use.
Cleaning one property and forgetting another is like locking the door and leaving a window open. So write the property inventory as the first line of your handover checklist.
What should you tell the old agency or employee before removing access?
Communication is half the job, because it matters as much as the technical side. Tell the departing person in writing which accesses will close and when. That way there are no surprises, and they can hand over their work in an orderly way.
Also, keep the message short and clear. State the closing date, the deadline for the handover note and a contact person. Avoid blame. A good handover often depends on the other side's cooperation.
- The date the access will close.
- The scope of the handover note you expect.
- A call to ask where tokens and settings sit.
- A thank-you and the next steps.
However, if the other side does not reply, do not stop the process. You can build your own ownership, clean the list and find tokens yourself. If you hit trouble, follow the ownership steps in the official help center.
Which tasks and settings should you record when an agency leaves?
If an agency worked in Search Console for years, it left traces in the property. Those traces stay after the removal, so record them. So knowing them also helps the next agency.
| Item to record | Why it matters | Where to look |
|---|---|---|
| Submitted sitemaps | They affect how pages get discovered | The sitemaps report |
| Disavow file | It affects how links to your site count | The related tool in the property |
| Linked Analytics account | It may link reporting and verification | Property and Analytics settings |
| Alert email addresses | Notices may reach the wrong person | Account notification settings |
Take a screenshot of each row and add a date. Then decide which settings to keep. For example, leave a correct sitemap alone, but show the disavow file to a specialist.
If you have sitemap trouble, start with our article on the sitemap could not be fetched error. An old agency's sitemap may no longer apply.
In an example scenario, how does a small business remove its old agency?
The flow below is only an example scenario and describes no real client. For example, a small shop worked with an agency three years ago. The agency verified the property with its own account, and the owner joined as a full user. Now the owner wants to own the property.
- The shop owner signs in to the domain provider and creates a new DNS verification record.
- In Search Console, the owner verifies the domain property with their own account.
- Then the owner notes the settings in the agency's old property.
- Once the owner's account holds ownership, the owner deletes the agency's old verification records.
- Finally, the owner removes the agency's access and refreshes the list.
The critical point is the first step. So the owner builds their own ownership before touching the agency's property. So they never enter a period where nobody can reach the data.
Real life can surprise you. For instance, DNS records may sit at another company. In that case, first find out who owns the domain with our WHOIS lookup tool.
How do you schedule regular reviews of the user list?
Also, access management is not a one-time job. People come and go, projects end and accounts age. If you set a schedule, you will not face the same problem again.
Still, a ten-minute check every three months is usually enough. Open the list, look at each address and ask whether it is still needed. If not, remove it.
- Review the user list every three months.
- Recheck all verification methods at every agency change.
- Close access on the day a person leaves.
- Keep changes in a dated note.
Also, think of user management together with general security habits. For example, give priority to accounts without two-step verification. Also remove any account that shares a password.
How can our team help with this process?
As Talha Aslan and team, we see access handovers often, and we know the common traps. First, listing properties, finding token locations and documenting the handover is most of the work. When we help, we leave ownership in your account.
We cannot promise any outcome, because every site is set up differently. Still, the right order sharply reduces the risk of a lockout. If you want broader help on the SEO side, look at our SEO consulting service.
This article is technical information and is not legal advice.



