Blogger Malware Lockout: What Happened and What to Do

✅ RESOLVED — Updated August 12, 2026
Google has fixed the bug behind the August 4 mass lockout, and Blogger Product Experts have confirmed the root cause is resolved. Most blogs were back within 24 to 48 hours.
You can edit your theme again. The advice to freeze your template applied during the incident and has now been formally lifted. If your blog is still locked, request a review — blogs that never appealed may not be in the review queue at all.

What follows is the full record: what happened, why restored blogs kept getting locked a second time, and how to make sure a platform-side classifier can never take your archive offline again.

The resolution: what Google and the Product Experts confirmed

On August 9, a Blogger Gold Product Expert posted that the issue had been resolved and that confirmation had come from the team responsible, pointing to an official announcement published in the Spanish-language Blogger community. The thread's original poster, a Diamond Product Expert, followed with a summary that is now the marked Recommended Answer:

The root cause has been resolved. Most blogs were back online within the first 24 to 48 hours. Blogs still locked should click Request review in the dashboard, or wait if they have already done so. Not all reports are false positives, and each case is reviewed individually.

— Blogger Diamond Product Expert, August 9, 2026

Three details in that summary matter more than the headline.

Editing your theme is safe again. The same summary states that anyone whose blog was reinstated, or never affected, can return to normal — publishing posts and editing themes included. During the incident the pinned advisory had been amended to tell users to temporarily hold off on theme and layout edits, explicitly on the basis of community reports. That caution is now withdrawn.

Not every locked blog was a false positive. This is the line most coverage has skipped. The Product Expert states plainly that each case is reviewed individually and that not all reports in the thread were misclassifications. A blog still locked after the fix is not automatically owed a restoration.

If you never appealed, appeal now. A second Diamond Product Expert noted that the official announcement suggests only blogs that requested a review will be reviewed. There is some ambiguity in the wording, and the safe reading is the cautious one: an un-appealed blog may simply be sitting outside the queue.

The support thread has since been soft locked, with only Product Experts and the original poster able to reply. It finished with 531 "I have the same question" votes.

What happened on August 4

The finding that mattered most during the incident sat buried 140 comments deep in Google's own support thread: restored blogs were being locked again within minutes, and the common thread in almost every re-lock was a write to the template — not a new post. Here is the full record.

The first wave

On August 4, 2026, Google's automated systems began locking Blogger blogs en masse, citing the Malware and Similar Malicious Content policy. Owners received an email saying their blog had been removed. The dashboard showed a red padlock and a notice that the blog was removed for violating Blogger's Community Guidelines.

The first wave hit around 2:15 PM Eastern on August 4. Reports followed in sequence around the world: Brazil at roughly 2:30 PM local, France and Italy through the evening, Korea at about 2:00–2:15 AM KST on August 5, then India, Indonesia, Vietnam and the Gulf through the morning.

A Blogger Diamond Product Expert posting as WebLove.PL opened a tracking thread and stated plainly that the volume of identical reports pointed to misclassification by automated systems, adding that false positives happen, but not at this scale. The Blogger engineering team was notified.

That thread went on to draw over 170 replies and more than 500 "I have the same question" votes. For roughly the first day it was the only acknowledgement of any kind — Google published nothing on its blog, its status dashboard or its social channels before issuing a brief statement to BleepingComputer on August 5, confirming a bug had incorrectly flagged Blogger-hosted sites and saying a fix was in progress. No postmortem, affected-blog count, or technical explanation has been published since.

The scale is not normal

Counting distinct blogs named in the thread and adjacent threads gives a partial list running well past a hundred, across at least sixteen languages — English, Korean, Arabic, Portuguese, Spanish, French, German, Italian, Greek, Indonesian, Thai, Vietnamese, Romanian, Dutch, Polish and Hindi.

The affected sites have nothing in common except the platform:

• whomyouknow.com — 31,200+ posts, offline about 20 hours
• dynamictutorialsandservices.org — an educational site running since 2008, 4,600+ pages
• raidersofthelostscent.blog — vintage perfume archive, active since 2009, 3M+ pageviews
• tknt-hsu.blogspot.com — the official academic blog of the Faculty of Design and Art, Hoa Sen University, Vietnam
• mediablog.ro — a Romanian journalism site of more than 15 years
• spata-artemis.com — a Greek local news archive
• One Arabic blogger reported four blogs and over 10,000 posts locked at once
• A Korean blogger reported that six blogs were suspended simultaneously
• One user reported 20 million lifetime views on a purely educational blog

Also caught: an 18-year-old Spanish maths blog, a 14-year-old quilting blog, a devotional lyrics site, a dog care blog in Hinglish, a Lombardy events calendar, a baseball news site, and — as one user noted with some irony — an account suspended for "spam" whose only post was pictures of a kitten.

One report deserves particular weight. A blogger running three separate blogs on three different Google accounts watched all three lock inside a fifteen-minute window. They decompiled and pretty-printed the minified JavaScript in their theme files, checked for redirects and hidden iframes, and ran multi-engine analysis through VirusTotal plus a sandbox behavioural report. Zero detections across every engine. Search Console is clean on all three properties.

That is about as close to a controlled experiment as a support forum ever produces, and it points squarely at the classifier rather than the content.

The re-lock loop: why restored blogs went down again

Restorations began around mid-morning UTC on August 5. Emails went out saying the blog had been reviewed and reinstated. Relief lasted, for many people, under an hour.

What follows is compiled from more than a dozen independent reports in the thread, and it forms a consistent pattern:

What the user did after restoration	Outcome
Edited the template HTML	Locked again
Uploaded/imported a theme to a new blog	New blog locked within minutes
Applied a theme change to an unaffected blog	Locked ~10 minutes later
Removed image gadgets from layout	Locked again
Inserted ad code into the theme	Locked again ~90 minutes later
Removed ad-network scripts from theme HTML	Locked again
Checked Mediavine settings	Locked ~5 minutes later
Clicked Stats in the dashboard	Locked immediately
Published a new post only	Mostly stayed up
Edited and republished existing posts/pages	Stayed up

One blogger stated the distinction outright after testing across several of their own blogs: removal fires after updating the homepage or making template changes, while editing and republishing posts or static pages leaves the blog alone.

Two independent users confirmed the sharpest version of this. Each created a brand-new blog and imported their content successfully — then applied their theme, and the fresh blog was disabled within minutes. One noted the new blog was fine right up until the theme upload.

The practical implication at the time: whatever misfired on August 4 appeared to re-evaluate a blog whenever the template or layout was written to. That held until Google shipped a fix.

What this meant then — and what applies now

During the incident, the guidance was to freeze the template completely: no theme edits, no gadget changes, no layout rearranging, no inserting or removing ad code. Reverting a change was itself a template write, and at least one publisher was re-locked doing exactly that.

That guidance is no longer in force. Blogger Product Experts have confirmed normal editing is safe again. The lasting takeaway is narrower but more useful: during any platform-wide enforcement event, stop writing to anything you don't have to write to. Publish nothing, change nothing, export everything. The blast radius of an automated classifier is widest at exactly the moment you are most tempted to fix things yourself.

One piece of housekeeping the Product Experts did recommend once things settled: clear out broken external links, since a link that now resolves to something unsafe is a genuine signal, and delete third-party scripts and gadgets you no longer use. Stale embedded code is both a performance drag and a real risk if the domain it loads from changes hands.

What is not causing this

Several theories circulating in Facebook groups and YouTube videos are contradicted by the thread itself:

• "It's only custom/third-party themes." Popular among affected users, and templates from Templateify and other paid vendors do appear frequently. But a Brazilian blogger using a stock Blogger theme with only CSS tweaks for dark mode and rounded image corners was locked too. Custom themes may raise your odds; they are not a requirement.
• "It's AdSense or ad networks." Blogs with no ads at all were hit, including a .blogspot.com subdomain with zero monetisation in the three-account test above.
• "You must have added something." Blogs with no changes for months were locked. One had not been touched in over a year.
• "It's a real malware infection." Search Console reports "No issues detected" for essentially every affected user who checked. Google Safe Browsing Transparency Report shows clean. VirusTotal shows clean. When Google's own security tooling disagrees with Google's enforcement system, the enforcement system is the outlier.

The pre-lock signals worth knowing about

Several users found anomalies in the hours immediately before their lock. These are individual reports rather than confirmed causes, but the cluster is interesting enough to document:

• Bot floods. The perfume archive owner found roughly 400 bad bots hitting simultaneously in the minutes before removal, per StatCounter.
• Suspicious traffic spikes. The Lombardy events blog saw traffic jump from a few hundred daily users to nearly 4,000, heavily from Singapore, Hong Kong and Tokyo, with about five seconds average engagement and an 86.9% homepage bounce rate — textbook automated traffic against a site whose audience is almost entirely Italian.
• Crawler 429s. At least two users found Meta's Sharing Debugger receiving HTTP 429 (too many requests) from Google and being redirected to Google's /sorry/index anti-abuse page when trying to scrape their Blogger posts. Both say this began days before the lockdown.
• Cloudflare blocking Googlebot. One owner discovered Cloudflare's Bot Fight Mode and Block AI Bots were returning 403 challenges to Google crawling IPs, and disabled them as a precaution.
• Blogger API access. Two users had recently created Blogger API credentials for personal scripts. One deleted the credentials as a precaution.

If you run Cloudflare in front of a custom-domain Blogger blog, checking that Googlebot is not being challenged costs nothing and rules out one variable.

The 89-day clock

Here is the detail that should set your priorities, and it is printed on the lock screen itself rather than in the email: a removed blog is permanently deleted within 89 days.

That is your real deadline. Not the appeal, not the review — the point at which the content stops existing. Google's own Content Policy states that appeals are typically decided within 10 business days and that, unless noted otherwise, restrictive actions are global and permanent.

Eighty-nine days sounds generous. It is not, if your appeal sits unanswered for six weeks and you have not exported anything.

Back up first. Appeal second. If you only do one thing today, take the Takeout export.

Step 1: Request a review (the appeal)

There is no separate public appeal form. The appeal lives inside your dashboard.

1. Sign in at blogger.com.
2. If you have multiple blogs, click the blog name in the left sidebar to open the selector, and pick the one with a red exclamation mark next to its title.
3. Open the Info tab. Under "Note: this blog has been locked," click REQUEST REVIEW.
4. Some users also receive an appeal link directly in the removal email. Either route feeds the same queue.

Official policy: appeals are typically decided within 10 business days, though complex cases take longer. See Google's blogger policy.

If the Request Review button is missing or the form won't open

Multiple users hit this. Working around it:

• Form redirects to your blog instead of opening. Sign out of all Google accounts, then sign back into only the account that owns the blog. Multi-account sessions are the usual cause. An incognito window works too.
• No Request Review button under Info. Confirm you're on the right blog in the selector, and that you are the blog's Administrator rather than an Author. Authors do not see enforcement controls.
• Email says "deleted" rather than "locked." These are different enforcement states. Several users with "deleted" emails still had the blog visible in the dashboard and could submit a review — check the dashboard regardless of what the email says.
• The appeal dead-end. This one has no clean fix yet. Several users were reinstated, re-locked, and then found the appeal page told them their original appeal was already received and still under review, with no option to file a second one. If you are stuck here, post your case in the Blogger Help Community with your Blog ID so Product Experts can batch-escalate it. It is not satisfying, but it is currently the only channel.

What to include when you post to the community

Product Experts are volunteers, not Google staff, but they can escalate patterns. Give them something they can forward:

• Blog URL and Blog ID (from the dashboard URL after blogId=)
• Date and time of the lock, with timezone
• The exact policy quoted in your email
• Screenshot of Search Console showing Security Issues: No issues detected
• Whether you were reinstated and then re-locked, and what you did in between

That last line is the most useful data point you can contribute right now.

Step 2: Back up with Google Takeout

Blogger's old one-click XML export in Settings is gone. Since July 1, 2025, Takeout is the only way to export posts, pages and comments.

1. Go to takeout.google.com
2. Click Deselect all
3. Scroll to Blogger and tick it
4. Choose Export once, or schedule exports every two months for a year
5. Pick .zip and a maximum file size. 2GB is fine for most blogs — if your archive is larger, Google splits it across multiple files automatically, so there is no wrong answer here
6. Choose a destination. Do not use Google Drive as your only copy — if your Google account is ever locked, your backup locks with it
7. Wait for the email with the download link. Minutes for small blogs, hours or days for large accounts
8. Download within one week. Google expires the archive after that

Does Takeout work while your blog is locked?

Yes. The Blogger Product Expert running the incident thread confirmed that anyone wanting to back up their blog should be able to do so even while it is locked, and linked users straight to the Blogger section of Takeout: takeout.google.com/settings/takeout/custom/blogger

A handful of users during the incident reported that exports were missing their posts, or that their blog was entirely absent from the archive. Given the confirmed guidance, the likely explanation is timing and queue delay rather than the lock state itself. Takeout snapshots on request; large accounts can take hours or days. If your first export looks wrong, request it again rather than concluding your content is gone.

One practical note from the same guidance: if you run many blogs, or one very old and large one, expect to download a substantial number of archive files.

Step 3: Understanding feed.atom

Unzip the Takeout archive and open the Blogs folder. Inside each blog's folder, two files matter:

File	Contains
feed.atom	Every post, page and comment, including drafts. The direct replacement for the old Settings XML export.
theme-layouts.xml	Your theme and most widgets.

Everything else can be deleted.

What you need to understand about feed.atom:

• It is Atom XML, not Blogger's old export XML. Same information, different structure. Since June 2025, Blogger's Settings → Import content can read it — fixing a long-standing bug where restores silently drop posts and comments.
• It includes draft posts. Genuinely useful if you lost drafts, and worth knowing for anyone whose unpublished work is now behind a padlock.
• It contains no images. This is the one that catches people. feed.atom stores the HTML that renders your images from Google's servers under blogger.googleusercontent.com. The pictures themselves are not in the file. Takeout does export your image files separately — but only the ones uploaded by the account making the request. On a multi-author blog, your co-authors' images are only in their Takeout archive.
• It preserves inline formatting only, not styling defined by your theme.
• You can read it without Blogger. Open it in any text editor. It is dense XML and unpleasant to read, but your writing is in there. Several users pasted theirs into an AI tool to extract clean plain text — a reasonable move if you want a human-readable archive today rather than a restorable one.

That third point is the whole argument for treating feed.atom as a migration file rather than a backup. A backup whose images live on servers controlled by the company that just locked you out is not a backup in any meaningful sense.

Step 4: If you want to rebuild on Blogger

You can import feed.atom into a fresh blog via Settings → Import content. Two warnings, both from bloggers who tried it this week:

Do not import your theme. As documented above, this is what re-triggers the lock. Import content, use a stock Blogger theme, and wait.

Test on a dummy blog first. One reader found the safest route was to create a throwaway Blogger site, apply the theme there, and confirm it survived before touching the live blog. It would have cost five minutes and would have saved several people in the support thread a second lockout. Credit to commenter Lem Revival for posting this while the incident was still live.

Two things that can turn a false positive into a real violation

Both come directly from the Blogger Product Experts, and neither appears in most coverage of the incident.

Do not create a new blog to repost the same content. Duplicating your archive onto a fresh blog while the original is under appeal can itself be treated as spam, which would convert a mistaken enforcement into a genuine one. If you are rebuilding, do it because you have given up on the appeal, not alongside it.

Do not remove Blogger from your Google account. Deleting the Blogger service or your Blogger profile deletes your blogs, and it cannot be undone. This is worth saying plainly because it is exactly the kind of thing a frustrated publisher does at hour eighteen of an outage while trying to "reset" something. There is no undo, no appeal, and no Takeout export after the fact.

Read Google's policy line first. Blogger's Content Policy explicitly states that if you have had a blog disabled, you should not create a replacement blog engaging in similar activity. In a genuine false positive, that guidance is arguably unfair — but it is the written policy, and rebuilding while an appeal is pending carries some risk. Weigh it.

The custom domain trap

If you run a custom domain, this section matters.

It can be reconnected. One user confirmed it works: Takeout export, create a new blog, point the same domain at it, and republish gradually. They were about 10 posts into 1,139 and reported it going smoothly, aside from a slider in their paid theme not loading.

But you pay for it. As another user pointed out, search engines treat the reconnected domain as a new site. Crawl history, visit metrics and accumulated authority reset. And cycling a domain between deleted and new Blogger blogs repeatedly risks getting the domain itself flagged.

So: reconnecting works once, at a real SEO cost. It is a rescue, not a strategy. If you are going to move your domain anyway, moving it somewhere that cannot lock you out is a better use of the same disruption.

Step 5: Moving to WordPress

Let me be straight about the argument rather than dressing it up.

Blogger is free, and it has genuinely helped a lot of people for a very long time. Several blogs in that thread have been running since 2007. Nobody should feel foolish for having built there.

But this week established something concrete: an automated classifier at Google can remove your blog with no warning, no explanation, no human review, a ten-business-day appeal window, and an 89-day deletion clock. When it misfired at scale, the public accounting amounted to three sentences given to a news outlet — no postmortem, no affected-site count, no explanation of the fault. 

People in that thread describe livelihoods stalled, AdSense applications caught mid-review, and 18 years of work sitting behind a padlock they could not open. Several could not access their own dashboard to inspect what had supposedly triggered it.

That is the actual risk profile. It has nothing to do with whether WordPress is nicer to use.

Why now specifically

Blogger has received essentially no meaningful development in years, while Google retired the services around it — Album Archive, FeedBurner's core features, and the one-click backup. The direction is maintenance mode. Meanwhile, the practical gap has closed: WordPress 6.9+ on entry-level shared hosting is fast enough to pass Core Web Vitals without a developer, and as AI-driven search reshapes referral traffic, owning your own schema, internal linking, and email list matters more than it did two years ago.

If you are going to move, moving before your archive grows another two years is cheaper and less painful.

The migration path, honestly

WordPress's built-in Blogger Importer is broken against the new export format — it was written for the old XML, and Google changed the file. Two free plugins handle feed.atom directly:

• BtW Importer — upload the .atom file, imports in batches, downloads embedded images into your WordPress media library, rewrites Blogger URLs to local ones, and sets featured images from the first image in each post. Reviewers report ~80 posts per run; click again to resume.
• Feed Importer for Blogger — same core job, also pulls images off Google's servers and rehosts them locally.

That image rehosting step is the entire point. It is what finally cuts your archive loose from blogger.googleusercontent.com. Until you do it, every image on your site is a link to a server Google controls.

One practical note the BtW Importer developer flags: Nginx-based hosts run these imports noticeably slower than Apache or LiteSpeed. For a large Blogger archive, this is the difference between an afternoon and a weekend of timeouts.

Do not skip redirects. Set up 301 redirects from your old Blogger URLs to the new permalinks, or you will lose the rankings you spent years building. On a custom domain, this is straightforward. On .blogspot.com you will lose some link equity — plan for it.

Hosting

For a migrating Blogger site specifically, Hostinger is a sensible landing spot: it runs LiteSpeed, which is the practical difference between a Blogger import that finishes and one that times out halfway through 1,000 posts. You also get free SSL, a free domain on annual plans, one-click WordPress install, and automatic daily backups you actually control.

Use code freeup at checkout for an extra 20% off the current plan price.

The honest version: no host makes you immune to everything. WordPress has its own exposure — we covered a critical REST API RCE in July. The difference is that you can patch your own server; you cannot patch someone else's classifier. What changes is who holds the off switch. On Hostinger, your posts sit in a MySQL database you can export any time, your images sit in a folder you can download, and no classifier can revoke your login at 2 AM.

Disclosure: Cyber Kendra earns a commission on purchases made through this link, at no additional cost to you. We recommend Hostinger because we use it.

Current status

As of August 12, 2026:

• Resolved. Blogger Product Experts confirmed the root cause was fixed, with confirmation from the team responsible and an official announcement posted in the Spanish-language Blogger community.
• Most affected blogs were restored within 24 to 48 hours of the initial lockout.
• Normal editing is safe again, including themes and layout code.
• Blogs still locked remain under review. Volume is the bottleneck, and blogs that never submitted a review request may not be queued at all.
• Not every locked blog was a false positive — each case is reviewed individually.
• Google's only public comment remains its three-sentence statement of August 5. No postmortem, no affected-blog count, and no technical explanation of the fault has been published.
• The incident thread is now soft-locked, with 531 users reporting the same problem.

If your blog is back: export it today, leave your template alone, and treat the restoration as provisional.

FAQ

Is it safe to edit my Blogger theme or template now?

Yes. Blogger Product Experts confirmed on August 9 that publishers whose blogs were reinstated or were never affected can resume normal activity, including publishing posts and editing themes. The advice to hold off applied only while the faulty classifier was live.

My blog is still locked. What should I do?

Check that you actually submitted a Request review from the Info tab of your dashboard. Guidance from the Product Experts suggests that only blogs that requested a review are being reviewed, so an unappealed blog may not be in the queue. If you have already appealed, wait — the backlog is large, and resubmitting resets your place in it.

Why has my blog not been restored when everyone else's has?

Two possibilities. Either your appeal is still in the backlog, or your blog was not part of the false positive. The Product Experts made it clear that not all reports were misclassifications and that each case is assessed individually. If your blog has broken external links, outdated third-party scripts, or gadgets loading from domains that have changed hands, those are worth auditing on their own merits.

Can I create a new blog and repost my content while I wait?

No, and this one carries real risk. Duplicating your content onto a new blog while the original is under appeal can be treated as spam, turning a mistaken enforcement into a genuine violation. Wait for the appeal to conclude.

How long until my blog comes back?

No guarantee. Observed restorations ran roughly 6 to 20 hours from lock. Official policy allows up to 10 business days.

Will I lose my content?

Not if you act. Removed blogs are permanently deleted within 89 days. Export before then.

Can I check whether my blog really has malware?

Yes, and you should, so your appeal is honest. Check Search Console under Security Issues, the Google Safe Browsing Transparency Report, and run your domain through VirusTotal. Essentially, everyone who checked found all three clean.

My blog is locked, and I can't reach the dashboard. Can I still export?

Try Takeout — it works for some locked blogs and not others. Request it now, and again after restoration.

Should I delete my blog and start over?

No. Deleting forfeits your appeal and your 89 days.

Does this affect AdSense earnings?

While the blog is locked, it serves no ads and earns nothing. If you want to quantify what an outage like this costs, our AdSense earnings calculator will do the maths. Several users report pending AdSense applications caught mid-review.

---

Google never published a postmortem. If your blog is still locked, drop your Blog ID and appeal date in the comments — the pattern is still worth tracking.