Unknown Search Console Owner After a WordPress Hack

Search Console sends a notice about a new owner, or you find an unfamiliar address in a property’s access list. Take it seriously, but do not start by removing every user or deleting every verification record you can find. You may be looking at the wrong property, an address used by an authorized agency, or a DNS token that another approved Google service also relies on.

Short answer: open Search Console through an address you enter yourself, confirm the exact property and account, and preserve the notice and access list. Distinguish a verified owner—who proved control using a verification method—from an owner who received access from someone else. Remove access that you have confirmed is unauthorized, then remove its verification method or token after making sure a legitimate owner can still manage the property. Finally, secure the systems that could allow the token to be re-added; removing a name from a list may not stop it from verifying again.

If the alert coincides with changed WordPress files or content, follow the WordPress hacked-site response guide and the WordPress security guide. Search Console access is only one part of an incident; it does not replace checks of the CMS, hosting account, registrar, DNS, or Google accounts.

Confirm the alert and the exact property

Do not follow links in an unexpected email. Open Search Console through an address you already trust, sign in to an authorized organizational account, and select the exact property named in the notice. Search Console can show Domain properties and URL-prefix properties for different protocols or subdomains; more than one Google account may also manage different sites. Check the spelling and scope before changing anything.

Preserve the original notice, receipt time, sender, named account, property, and a screenshot of the owner list. If the organization uses an SEO agency, domain manager, migration vendor, or outside developer, contact them through details already on file—not a phone number or link in the message. Record the response and any approved change ticket. This helps distinguish a legitimate handoff from an unauthorized change when several people work on a site.

Do not forward a live verification link or token into a public channel. Limit internal evidence to people handling the incident and redact private addresses that are not needed. Record the time zone and account used to view the property.

Distinguish verified owners from delegated access

Review the property’s users and owners in Search Console. A verified owner proved control through a verification method. A delegated owner or user received access through someone who already had owner privileges. Google documents how to manage owners in its Search Console ownership guide and provides help for an owner you do not recognize.

Record each account, access type, who added it if that information is available, and the verification method shown. An unfamiliar owner is not automatically an attacker: it might be an agency address, an organizational account, or an unrecorded migration. But access that no one can explain should not remain indefinitely. Assign an internal owner and a deadline to verify each account.

Removing the property from your own Google account is not the same as revoking someone else’s access. Make sure you are using the user/owner controls for the correct property. If the account is a verified owner, locate and address its verification token. If it was delegated, identify who granted access and review the associated permissions. Follow the instructions shown in your account because interface labels can change.

Keep a legitimate owner path

Before removal, confirm that the organization still has at least one authorized owner account that can sign in. Use a managed organizational account where possible, not an unknown personal mailbox or an ownerless shared address. Confirm that a legitimate backup owner is authorized and that the verification method can be recovered. Removing the only valid owner path can delay incident response and monitoring.

Establish who controls each Google account: the Workspace administrator, mailbox owner, agency, or former employee. If a Google login may have been taken over, secure that account through the organization’s normal process before relying on Search Console. Review recovery methods, sessions, third-party access, and security activity from a trusted device. Each user should authenticate through an official channel; do not ask them to send you a password or verification code.

For a business, document approval with the domain owner, SEO team, IT staff, and vendor as required by policy. A DNS change may affect more than one property or service. Do not remove a record with a familiar-looking value until the domain administrator has confirmed who uses it.

Revoke access and the method that permits re-verification

Once an owner is confirmed unauthorized, remove the account using Search Console’s property controls. For a verified owner, identify the associated method and token, then remove it from any location the unauthorized person could control—for example, a verification HTML file, a meta tag, a DNS record, or a connected service. The correct action depends on how the property was verified; not every site stores a token in WordPress.

Removing an owner’s name while leaving a verification token in place may allow that person to verify ownership again. Google explains how to manage verification methods in its site ownership verification help; follow the method shown for the affected property. Before deleting a DNS TXT record or third-party access, check whether a legitimate owner, another Google service, or an organizational system uses it. Coordinate a replacement method first if it is shared.

If a token appears to be in WordPress, review the SEO or verification plugin, theme, must-use plugins, webroot files, tag manager, and deployment pipeline. Do not remove every plugin or code snippet blindly; identify the owner and any valid property that depends on it. For a DNS token, ask the domain administrator to review registrar change history. Preserve the record details before making a change, while limiting access to sensitive values.

After removal, refresh the property settings, confirm the unauthorized owner is no longer listed, and save the result. Watch for re-verification notices. If the owner returns, another token may remain, a legitimate Google account may be compromised, or the person may still control WordPress or DNS. Do not stop at deleting the displayed user.

Close the access route that exposed the token

Review how the verification method could have been added. Check WordPress file and plugin changes, administrator users, registrar and DNS accounts, hosting, CDN, repository/deployment access, Google Tag Manager, and every Google identity with permissions. Record available change events and their times. Some providers do not keep complete audit logs, so ask the host or domain administrator to preserve whatever is still available.

If an unfamiliar file or code is found, preserve a copy and record its location before replacement. Check core and plugin versions against trusted sources, unused components, accounts and sessions, and possible scheduled tasks. A clean scan is not proof that the site is clean. If the symptom repeats or you cannot distinguish legitimate files from unauthorized changes, escalate to the host or an incident-response specialist.

Rotate credentials that may have been exposed from a trusted device after the active access route is controlled. Prioritize organizational email, Google, registrar, DNS, hosting, deployment, and WordPress according to their privileges. Use unique passwords, multifactor authentication where available, individual accounts, and least privilege. Changing every secret before closing active access can expose new credentials to the same attacker; agree on an order and record the actions.

Review Search Console impact and monitor

After access is restored, review Security Issues and Manual Actions reports, other users, sitemaps, URL removals, property changes, and relevant notifications. Compare findings with the incident timeline. Search Console can provide example URLs and warnings, but examples may not cover every affected URL and a report is not proof that the site is otherwise clean.

Do not remove every sitemap, request mass URL removals, or submit pages for reindexing just because an unknown owner appeared. Identify affected pages, fix the compromise, and follow Google’s current instructions for the specific issue. Deleting an owner does not clean content or restore files. Record any requests and results, then monitor for the account, token, or unfamiliar pages returning.

Keep an inventory of owners and verification methods. Review it after staff or vendor changes, retain an authorized backup owner, monitor DNS and deployment changes, and limit who can add verification tokens. A periodic access review makes the next alert easier to investigate without leaving former vendors’ accounts in place.

Frequently asked questions

Does an unfamiliar owner notice prove that WordPress was hacked? Not on its own. Confirm the property, account, agency, and change history first. If nobody authorized the change, treat it as an access incident and investigate the token route and website.

Why can a removed owner come back? A verification token may remain, a legitimate Google account may be compromised, or the person may still be able to change files, tags, DNS, or a connected service. Remove the correct access and token source, then secure that route.

Can I delete every verification TXT record? No. A record may support an authorized owner or another service. Identify its owner and use before changing DNS; preserve the current record and coordinate with the domain administrator.

What if I am the only legitimate owner? Secure your Google account and recovery methods, and keep that owner access working. Document an approved backup path before removing an unfamiliar account or token.

If you cannot establish who changed a verification file, DNS record, or account, contact the website incident-response team. Provide the property name, notice time, verification methods, and available logs—never a verification code or password.