Search Console fires off 'new owner' emails that aren't new

On the morning of August 24, 2026, many people who manage websites woke up to a scare in their inbox: emails from Google Search Console (GSC) warning about a new owner added to the property. The problem, as Search Engine Roundtable reported, is that these "new" owners weren't new at all. In many cases, they were users who had already had access to the account for years.

Barry Schwartz, the author of the post, received some of these notifications himself and described the reaction in a sentence that sums up the mood well: he was alarmed, but then relieved to realize it was someone who already had access. Strange, but harmless.

What happened, in practice

The email subject line started with "new owner...", exactly the format Google uses when someone actually gains owner permission on a verified property. The difference is that, this time, the trigger fired for old accounts.

Reports gathered by the source, scattered across Google Webmaster Help Forums, Reddit, and X, show the pattern:

• An agency received several "owner added" emails naming users who had been included a long time ago, some since 2021.
• Another administrator woke up to more than two dozen notifications, and described that "every single one of the alerts was wrong": all the users named were already existing owners.
• A third summed up the suspicion bluntly: "Either this is a fantastic phishing campaign, or Google is smoking crack again."

Schwartz doesn't categorically state the cause, but concludes: "It must be some kind of bug." As of the source's publication, there is no official confirmation from Google about the origin of the issue.

Why this matters for site administrators

The detail that turns an annoying bug into a real risk is the context. A new-owner notification in Search Console is exactly the kind of legitimate alert that no one should ignore. When an attacker manages to verify themselves as the owner of a property, they gain visibility into performance data, can remove URLs from the index, submit malicious sitemaps, and, in worse scenarios, use the access as a foothold to hijack the site's search presence.

In other words: GSC has (rightly) trained everyone to react to this email. Now, by firing off dozens of false alerts, it risks producing the opposite effect, that of alert fatigue. Anyone who gets 24 wrong notifications in one morning tends to mark everything as noise and, next time, might ignore the email that is actually true.

For the Brazilian administrator, who often manages dozens of client properties, the problem multiplies. A bug like this turns into a flood of messages from frightened clients asking if the site was hacked, and hours of support work explaining that it wasn't.

Bug or phishing: how to tell them apart

The trickiest part is that scammers love exactly this kind of window. A known wave of legitimate but confusing emails is the perfect environment to inject fake messages that mimic Google's layout and lead to cloned login pages. That's why the right reflex is neither to trust the email nor to ignore it, but to verify inside the tool itself.

The safe path:

1. Don't click the link in the email. Open search.google.com/search-console by typing it into your browser or using a bookmark.
2. Go to Settings → Users and permissions on the property named.
3. Check whether the list of owners matches what's expected. If someone unknown shows up with owner status, then there is a real incident.
4. If the user named in the email was already on the list for years, it's the bug, not a compromise.

A useful technical signal: check the sender and the headers. Legitimate GSC emails pass SPF, DKIM, and DMARC authentication for Google's domains. A message that fails these checks or that points to a strange domain in the link is a strong candidate for phishing, regardless of the bug.

What remains unclear

Google has not yet explained what triggered the alerts. The most plausible hypotheses, given the pattern of reports, involve some reprocessing in the permissions backend (a data migration or a reindexing of the owners table) that reissued old events as if they were new. It's the kind of classic side effect that happens when a system treats a reprocessed record as a brand-new event.

Until there's an official position, the practical guidance is conservative: treat every alert as potentially true until you confirm it through the interface, but don't panic over the volume. If all the names mentioned were already known, you're most likely looking at the same bug that hit the global community on August 24.

It's also worth documenting the episode for clients before they ask. A short notice explaining that there was a known Search Console glitch, that no new access was actually granted, and that the team checked the permissions tends to save a lot of noise, while also reinforcing that the agency is genuinely monitoring security alerts, not just when the email arrives.