How can you regain control of your Search Console after parting ways with your SEO agency?

What is the difference between token verification and delegated access?

The Search Console offers two distinct mechanisms for managing access. The first level is property verification: you prove to Google that you control the site via an HTML tag, a file, a DNS record, or even Google Analytics. The second level is delegated access: a verified owner can invite other users without them needing to verify the site themselves.

The problem arises when your former provider was verified by their method — typically a HTML token or a file placed on your server. In this case, they are not just a guest: they are a verified owner just like you. Removing their account from the user list in the interface does not change the fact that they can reconnect at any time as long as their token remains in place.

Why does Google make this technical distinction?

It is a matter of hierarchy of permissions. A directly verified user holds a higher status than a delegated user. Google considers that if someone has technical access to your source code or your DNS configuration, they have proven a level of control over the site that justifies permanent access — until you physically remove the verification method.

This logic often conflicts with the reality of client-agency relationships. Many owners believe they have regained control by removing the agency from the user list, while in reality, the agency retains the technical access key. This presents a potential security flaw that few SEOs adequately anticipate during the handover.

How can you identify the type of verification used by a former provider?

In the Search Console, go to Settings > Users and Permissions > Manage Property Owners. You will see each verified user with the method used: HTML tag, HTML file, Google Analytics, Google Tag Manager, DNS, or other. If multiple methods are listed for the same user, it means they have verified the site through multiple channels — multiplying the access points that need to be cleaned up.

Some clever providers combine multiple verification methods to safeguard against accidental revocation. This is technically legitimate during collaboration, but it complicates the breakup significantly if things go south. Let's be honest: in 80% of cases, the client doesn't even know what method was used initially.

• A delegated access can be revoked instantly from the Search Console interface without touching the site's code.
• A token-verified owner retains the ability to reconnect as long as the token (HTML tag, file, DNS) remains in place.
• Regularly checking the list of active verification methods is a good security practice, especially after a provider change.
• The Search Console does not automatically notify when a former owner reconnects via a verification method that remains in place.
• Physically removing all obsolete tokens should be part of the handover protocol between agencies.

Does this statement truly cover all scenarios?

No, and that's where it gets tricky. Google is deliberately simplifying a topic that can become quite technical very quickly. For example, the statement does not mention the case where a provider was verified via Google Tag Manager: removing their access to the Search Console does not necessarily remove their access to the GTM container, which itself may contain tokens or Analytics configurations used for other verifications. The cascading dependencies are not addressed.

Another point: what happens if the former provider configured a DNS record that you cannot easily modify because you do not have access to your registrar? Or if the verification tag is embedded in a WordPress theme of which you have lost the sources? Google tells you to "remove the token," but in practice, some clients lack the skills or access to do so. [To be verified]: Google does not specify if there is an automatic expiration deadline for tokens or if they remain valid indefinitely.

What real risks do you face if you do not clean up properly?

The main risk is persistent access to data. Your former provider can continue to view your performance, queries, backlinks, crawl errors — in short, all your SEO intelligence. If the breakup did not go well, this data could be used to advise a direct competitor. This is not paranoia: it happens.

More insidiously: a malicious provider could technically submit a disavow of links, request a massive re-crawl of unnecessary pages to saturate your crawl budget, or even modify certain geographic or international targeting parameters if permissions allow. I've never seen this documented publicly, but technically, nothing prevents it as long as they remain a verified owner. And if the Google Analytics account is linked, they can also retrieve business insights that far exceed SEO.

Could Google improve this revocation process?

Clearly, yes. Other platforms (Facebook Business Manager, for example) have a system of hierarchical revocation: when you remove a partner, all associated accesses are automatically revoked, even those obtained through technical methods. Google could implement an option "revoke all accesses from this user, including direct verifications" with a clear warning.

The fact that this is not already in place suggests that Google views technical verification as an equal property right rather than a mere access convenience. This is philosophically defensible — if someone controls your DNS or your server, they indeed have a level of site control that justifies privileged status. But it creates shaky situations in client-provider relationships where the "legal owner" of the site does not necessarily have total technical control in the tool.

What practical steps should you take when changing your SEO provider?

First step: establish a handover protocol even before breaking off. Ask your current provider to list all the verification methods they have implemented, all third-party accesses (Analytics, GTM, Data Studio, etc.), and all the tools connected to the Search Console (like Ahrefs, SEMrush, or other crawlers). This transparency should be part of the departure contract, but it rarely is.

Next, create your own independent property verification before removing the agency. Preferably use a DNS method if you have access to your registrar — it’s the most challenging to lose accidentally. Once your verification is active, you can begin cleaning up the accesses of your former provider without risking being locked out yourself.

How can you identify and remove all obsolete verification tokens?

Inspect the source code of your homepage (and possibly key templates) to find the meta tags name="google-site-verification". There may be several — keep only the one(s) you control. Check also the root of your site for HTML verification files (they look like googleXXXXXXX.html). Remove those you do not recognize.

On the DNS side, log into your registrar and look for TXT records related to the Search Console. They usually contain "google-site-verification=" followed by a hash. If you are unsure whether a record is still used by you, create a new one before deleting the old — the Search Console accepts multiple simultaneous verifications. Finally, check your Analytics and Tag Manager properties: some may serve as indirect verification methods.

What critical mistakes should you absolutely avoid?

A classic mistake: removing ALL verification tokens at once, including yours, and ending up locked out. The Search Console does not allow you to revoke the last verified owner, but if you delete the physical tokens without having created a new verification first, you lose access. And re-verifying it can take time if you need to go through support or if you have DNS issues.

Another trap: forgetting the domain properties that cover all subdomains and protocols. If your former provider has access to a domain property, they see EVERYTHING — www, mobile, all subdomains. Check both types of properties (URL prefix and domain) and clean up both. And do not overlook old archived properties: they may still contain sensitive data and active accesses.

• List all active verification methods in Settings > Users and Permissions.
• Create your own DNS verification or HTML tag before removing the provider's.
• Inspect the source code and the root of the site to identify all physical tokens.
• Check the Google Analytics, Tag Manager, and other related Google services accessed.
• Revoke delegated accesses in the interface AFTER deleting the physical tokens.
• Document all changes in a handover file for future reference.