














✅ 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.
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.
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.
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.
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:
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.
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.
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.
Several theories circulating in Facebook groups and YouTube videos are contradicted by the thread itself:
.blogspot.com subdomain with zero monetisation in the three-account test above.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:
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.403 challenges to Google crawling IPs, and disabled them 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.
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.
There is no separate public appeal form. The appeal lives inside your dashboard.
Info tab. Under "Note: this blog has been locked," click REQUEST REVIEW.Official policy: appeals are typically decided within 10 business days, though complex cases take longer. See Google's blogger policy.
Multiple users hit this. Working around it:
Product Experts are volunteers, not Google staff, but they can escalate patterns. Give them something they can forward:
blogId=)That last line is the most useful data point you can contribute right now.
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.
Deselect allExport once, or schedule exports every two months for a year.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 hereYes. 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.
feed.atomUnzip 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:
Settings → Import content can read it — fixing a long-standing bug where restores silently drop posts and comments.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.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.
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.
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.
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.
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.
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.
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:
.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.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.
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.
As of August 12, 2026:
If your blog is back: export it today, leave your template alone, and treat the restoration as provisional.
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.
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.
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.
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.
No guarantee. Observed restorations ran roughly 6 to 20 hours from lock. Official policy allows up to 10 business days.
Not if you act. Removed blogs are permanently deleted within 89 days. Export before then.
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.
Try Takeout — it works for some locked blogs and not others. Request it now, and again after restoration.
No. Deleting forfeits your appeal and your 89 days.
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。