Unknown Owner in Google Search Console? How to Remove Them

By Glenn Lyvers · Updated September 28, 2026 · 7 min read

An owner you don’t recognize in Google Search Console almost always means someone got write access to your site or your DNS and used it to verify themselves. Removing them takes two minutes: remove their access and delete every verification token they used. But Google’s own help page is blunt about the limit of that — if you have been hacked, the attacker can simply add the token back, so the ownership is the symptom and the compromise is the job.

How you usually find out

Search Console notifies all existing verified owners whenever a new owner is added to a property. So the first sign is often an email about a new owner you never approved, sometimes sitting unread in an old inbox. The other common route is noticing a name you don’t know under Settings → Users and permissions while you are looking at something else.

It rarely arrives alone. In my cleanups, a rogue Search Console owner shows up alongside SEO spam — the Japanese keyword hack, the slot gacor gambling hack, or pharma pages — because owning the property is how the spammer gets their pages into Google quickly.

What an attacker does with ownership

A verified owner has full control of the property in Search Console. For a spammer, that means:

• Submitting sitemaps full of spam URLs so Google discovers thousands of pages in days instead of months. See hacked sitemap spam.
• Requesting indexing of individual spam pages through URL Inspection.
• Using the Removals tool against your real pages, or watching your performance data to see how the spam is ranking.
• Adding other users, so that removing one account doesn’t remove them all.
• Seeing your security and manual action notices before you do.

None of that touches your server directly, but all of it depends on an earlier compromise. They could not have verified without planting something.

How they got verified

To become a verified owner, you must place a token Google can check. Each method points at a different compromise:

Verification method	What it proves the attacker had
HTML file (google1234abcd.html in the web root)	Write access to your files — a hacked site, FTP or hosting account
HTML meta tag (google-site-verification in the homepage head)	Ability to change your theme, database or injected header code
DNS TXT record	Access to your registrar or DNS provider — a different and more serious problem
Google Analytics or Tag Manager	Edit rights on your Analytics property or GTM container, or their own code running on your page

That table is your investigation. A file token means start with the site; a DNS token means start with the domain account — see hacked DNS versus a hacked website and domain hijacking recovery. A Tag Manager token means audit your container, covered in malware in Google Tag Manager.

Removing the owner properly

Google’s documented process, in the order that actually sticks:

1. Open Settings → Users and permissions. Next to the unknown owner, click Verification details and write down every token they used before you change anything.
2. Use the menu next to their name and choose Remove access. Google then lists that person’s verification tokens.
3. Delete each token at its source: remove the google*.html file from the web root, strip the meta tag from wherever it is injected, delete the DNS TXT record, or remove their Analytics or GTM permissions.
4. Back on Users and permissions, open Unused ownership tokens. It lists tokens still present for people who are no longer owners — exactly the ones an attacker would use to reverify. Remove them and verify the removal.
5. Remove any other users the attacker added, full or restricted.

Skip step 3 and the owner reappears on the next verification check, because the proof is still sitting on your site. Google’s help page on managing owners and permissions has the current screens.

Undo what they did in Search Console

• Sitemaps: delete every sitemap you didn’t submit, and resubmit your real one.
• Removals: check for requests against your legitimate URLs and cancel them.
• Pages report: look for a surge of indexed URLs you didn’t create. Those need to return 404 or 410 once the site is clean — see removing spam URLs from Google.
• Security Issues and Manual actions: read whatever is there, and only request review once the site is clean. My guide to Search Console security issues covers writing a request that passes.

Do the same audit in Bing Webmaster Tools and Yandex Webmaster if you use them. Bing verifies with a BingSiteAuth.xml file or a msvalidate.01 meta tag; Yandex with a yandex_*.html file or a yandex-verification meta tag. Attackers who bother with Google often bother with those too.

Now fix the actual compromise

The verification token was planted using access the attacker still has. Until that access is gone, removing the owner is a temporary fix. At minimum:

• Change every credential that could write to the site or the DNS: hosting, SFTP, database, WordPress admins, registrar, and the Google account itself. My guide on rotating credentials after a hack lists them in the right order.
• Scan the site for the backdoor that let them in. File tokens and spam pages usually arrive together through the same hole — start with my free site scanner, then look for hidden admin users and web shells.
• Find and close the entry point: an outdated plugin, a reused password, a nulled theme.

If the owner has come back once already, the site is still compromised. That is precisely the situation my malware removal service is for.

Keeping it from happening again

Once you’re clean, make it easy to notice next time. Keep at least one verified owner whose email you actually read, so Google’s new-owner notification reaches someone. Turn on two-step verification for every Google account that owns the property. Prefer a Domain property verified by DNS, then lock down the registrar account with its own strong password and two-factor. And check Users and permissions whenever you log in — it takes five seconds. The rest of the hardening list is in my guide to preventing future hacks.

Common questions

How did someone become an owner of my Search Console property?

They placed a verification token Google could check: an HTML file in your web root, a meta tag in your homepage, a DNS TXT record, or through edit rights on your Google Analytics or Tag Manager. Each of those requires access to your site, DNS or Google accounts, so an unknown owner means one of them was compromised.

How do I remove an unknown owner from Google Search Console?

Go to Settings, Users and permissions, and note their verification details. Remove their access, then delete every verification token they used at its source: the HTML file, meta tag, DNS record, or Analytics or Tag Manager permission. Finally check Unused ownership tokens and remove anything left there.

Why does the unknown owner keep coming back?

Because their verification token is still in place, or the attacker still has access and planted it again. Google's own guidance warns that removing the token is only a temporary fix on a hacked site. Clean the site, change every credential, and close the entry point, then remove the owner.

Does Google notify me when a new owner is added?

Yes. Search Console sends a notification to all existing verified owners whenever a new owner is added to a property. If the only verified owner is an old email address nobody reads, that warning goes unseen, which is why keeping a monitored owner account matters.

What can a hacker do as a Search Console owner?

Submit spam sitemaps so Google indexes their pages quickly, request indexing of spam URLs, use the Removals tool, add more users, and see your performance data and security notices. They cannot change your site through Search Console, but ownership makes an existing spam hack much more effective.

Should I delete the whole Search Console property and start again?

No. Deleting the property does not remove the attacker's tokens from your site or DNS, and you lose your history. Remove the owner and tokens, clean the site, and keep the property so you can monitor the recovery.