Blogger-hosted sites began locking on the evening of August 4, 2026, with owners receiving emails citing the “malware and similar malicious content policy.” The dashboard attached to each locked account carried a more specific number: an 89-day countdown to permanent deletion. Owners who ran their own diagnostics found nothing that would explain it.

That gap is what makes the incident more than a routine platform glitch. Affected blogs, some 12 to 18 years old, showed no flags in Search Console and none in Safe Browsing. Every external check a careful owner would run to confirm a clean bill of health came back clean, while a classifier inside Blogger had already started counting down to deletion.

Google confirmed the cause on August 5 at 19

ET, in a statement to PPC Land: “We are aware of a bug that incorrectly flagged some Blogger-hosted sites as malware for less than a day. We are working on a fix to resolve the issue as quickly as possible.” That statement resolves the question of cause. PPC Land had put six questions to Google, covering the number of blogs locked, the number restored, and whether content was permanently lost. Google’s reply addressed one of them.

Scale stays unquantified. A Blogger Community thread opened to track the pattern had grown to at least 298 marked responses from owners identifying themselves as affected, the point at which one participant logged in as the 298th person to flag the thread. That number is a floor set by who found the thread and chose to register on it, not a count of everyone the classifier touched.

The detail that turns this from a bug report into something owners need to plan around is what happened when they tried to get out. With a deletion clock attached to their accounts, several owners turned to Google Takeout to pull a full export before the 89 days expired. The export did not reliably produce one. Owners reported that the feed.atom file, the Atom XML export holding the actual post content, came back truncated on blogs with more than roughly 2,000 posts. The platform that attached a countdown to the content also, for some owners, failed to deliver a complete copy of it on the way out.

Restorations began appearing on August 5, and in documented cases arrived without an individual appeal having been filed or reviewed. One affected owner described the sequence in three short lines: “Yesterday was removal. Today is reinstatement. No appeal sent.” Recoveries arriving that way suggest something was fixed centrally rather than each account being looked at by a person, which leaves open what function the appeal button served for owners who used it during the lockout.

Automated enforcement on a hosted platform is a risk class, not a one-off incident. A site can be correctly configured and clean by every signal Search Console and Safe Browsing offer, and still get locked by a classifier that attaches a countdown with no external indication that anything is wrong. That is the operating condition for any content that lives on infrastructure someone else controls.

The response to that condition is not to wait for the next lockout. If you or a client run anything meaningful on a hosted platform, test the export path now and confirm it produces a complete archive of every post, not just images and site metadata. Finding out that an export truncates while a deletion clock is running is a far worse position than finding out in a test run today.

PPC Land reported this story, written by Luis Rijo and published August 5, 2026.