2026-08-20 · SEO · 15 min read

Google's August 2026 Spam Update: Do Not Rewrite Your Site Yet

Google has started another global spam update and said almost nothing about what changed. Here is what the announcement confirms, what it does not, and how to investigate a traffic drop without making it worse.

#google-search#seo#spam-update#search-console#web

On August 18, Google added a new entry to the Search Status Dashboard. The whole announcement fits into two sentences: an August 2026 spam update had been released, it applied globally and to every language, and the rollout might take a few days.[1]

That was it.

No list of targeted tactics. No examples of pages it expects to remove. No separate post explaining a new policy. The update appeared as a low-severity ranking event at 16:27 UTC, and the SEO industry immediately started trying to fill in the blanks.

I understand the temptation. If search traffic matters to a site, "a few days" can feel like a long time to sit still. Every downward line in Search Console starts looking related. Old backlinks become suspicious. An article that ranked yesterday suddenly looks thin. People begin changing titles, deleting pages and rewriting whole sections while Google is still rolling out the system they are trying to diagnose.

That is usually how a difficult investigation becomes an impossible one.

The August update is worth watching. It is also a good excuse to separate what Google has confirmed from what people are guessing, and to build a response that produces evidence before it produces edits.

What Google has actually confirmed

At the time of writing on August 20, Google's public incident data contains no completion time for the update. Its latest entry is still the original release notice.[1]

The confirmed facts are limited:

the rollout began on August 18, 2026 at 16:27 UTC;
it affects Google's ranking systems;
it applies globally;
it applies to all languages;
Google expected it to take a few days.

This is the third named spam update in 2026. The March rollout took 19 hours and 30 minutes. The June rollout took 2 days and 1 hour. The August update is still open in the dashboard data.[1]

| 2026 spam update | Started | Completed | Recorded duration |
| --- | --- | --- | --- |
| March | March 24 | March 25 | 19 hours, 30 minutes |
| June | June 24 | June 26 | 2 days, 1 hour |
| August | August 18 | Still rolling out when this was written | Not known yet |

The short March and June rollouts do not guarantee that August will finish on the same schedule. Google's August 2025 spam update ran for almost four weeks after the company warned that it could take a few weeks.[1] The wording on the current notice says a few days, but the dashboard's completion entry is the only useful finish line.

What Google has not said

Google has not said that this update specifically targets AI-written articles.

It has not described it as a link spam update. It has not named expired domains, site reputation abuse, parasite SEO, cloaking or scaled content as the special focus. It has not announced a new spam policy alongside the rollout.

Any article claiming to know the target this early is making an inference from ranking movement, client data or previous updates. That can become useful later, once enough sites show a repeatable pattern. It is not the same as an official explanation.

Google's spam systems operate continuously. A named spam update means Google made a notable improvement to those systems, which include its AI-based SpamBrain system.[2] It does not mean that every existing spam policy received equal attention, or that Google will tell us which classifier changed.

This distinction matters because a diagnosis determines the repair. A hacked site, a directory full of doorway pages and a publisher renting out its authority to a coupon provider do not have the same problem. "Write better content" is too vague to fix any of them.

A spam update is not a core update

A core update changes how Google's broad ranking systems assess content. A spam update improves systems intended to detect practices that violate Google's spam policies.[2][8]

The visible symptom can look similar. Pages lose impressions or rankings. The reason and recovery path are different.

If a legitimate page moves during a core update, the useful question may be whether competing pages satisfy the search better. If a site moves during a spam update, the first question is whether it contains a pattern Google defines as manipulation or abuse.

There is another distinction people often miss: an algorithmic spam demotion is not the same thing as a manual action.

A manual action means a human reviewer at Google decided that pages violate the spam policies. Search Console shows those actions in the Manual actions report and sends a notification.[3] Automated systems can reduce or remove a site's visibility without placing a message in that report. A green check mark there rules out a manual action. It does not prove that an algorithmic spam system had no effect.

What to do while the rollout is active

Do less, but record more.

Mark the start date

Add August 18 directly to the Search Console Performance chart. Right-click the date, choose the annotation option and add a short note such as August 2026 spam update started. Custom annotations are shared with other full users of the property and remain visible when filters change.[7]

I would keep the same note in a reporting spreadsheet or the project's repository if other people investigate traffic outside Search Console. Search Console annotations do not appear in comparison mode or the 24-hour view.[7]

Record the time zone. Google's incident began at 16:27 UTC, which was 18:27 in Poland. Daily Search Console data will not give you minute-level causation, but the correct boundary helps prevent an earlier technical problem from being attached to a later update.

Save a baseline

Export enough Search Console data to compare later:

daily clicks and impressions;
pages;
queries;
countries;
devices;
search appearance, if it matters to the site.

Use the same search type and filters for every comparison. A Web report and an Image report are different datasets. Comparing the last two partial days with two complete days from last week is also a good way to invent a crisis.

For a small site, I would save at least the 28 days before August 18. A larger or seasonal site needs a longer baseline and a year-over-year comparison.

Check whether the site itself changed

A Google update does not cancel ordinary debugging.

Look at deployments around the same date. Check robots.txt, canonical tags, noindex, redirects, status codes, sitemap generation and the URLs Google selected as canonical. Confirm that important pages still render meaningful HTML to Googlebot. Inspect the Security issues and Manual actions reports.

Google's own guide to traffic drops separates algorithm changes from technical problems, security issues, seasonality and changes in search demand.[4] The dates can overlap. A broken canonical deployed on August 18 remains a broken canonical even if a spam update started that evening.

Wait for complete data

Search Console data is not instant, and the newest numbers can be incomplete. The rollout can also move pages more than once before it finishes.

Watching is reasonable. Rebuilding the site after one bad day is not.

How to read a drop after the rollout

Once Google marks the update complete and several complete days have passed, compare the affected period with a clean period before August 18.

Start with impressions, not clicks alone.

If clicks fall while impressions and average position stay close to normal, the cause may be a change in click-through rate, the search results layout or demand. If impressions fall across many queries and pages at the same time, ranking or eligibility deserves more attention. If one directory falls while the rest of the site remains stable, audit that directory as its own system.

I use this sequence:

Compare total Web impressions before and after the completed rollout.
Open the Pages tab and sort by lost impressions.
Check whether the loss is concentrated in one template, directory or topic.
Open the Queries tab for those pages.
Split the result by country and device.
Compare Search Console with analytics and server logs.

Server logs can answer questions Search Console cannot. Did Googlebot stop requesting a section? Did the application begin returning intermittent 5xx responses? Did a bot-protection rule start challenging crawlers? Did thousands of unexpected URLs appear because an internal search endpoint was indexable?

A spam update may expose a weakness. It should not be used to explain every weakness without checking.

The policies I would audit first

Google's current spam policy page is long, but several sections are especially relevant to modern content sites.[5]

Scaled content abuse

Scaled content abuse means creating many pages mainly to manipulate rankings rather than help people. Google explicitly says the production method is not the deciding factor. The pages may be generated with AI, written by humans, scraped, translated or assembled from several sources.[5]

Using AI in a writing workflow is not automatically spam. Publishing hundreds of unoriginal pages because a keyword tool found hundreds of variations can be.

The practical audit is not "Was AI involved?" It is:

Why does each page exist?
Does it add reporting, testing, analysis, code, data or experience that the source pages do not?
Would the site publish it if Google sent no traffic?
Are near-identical pages being created for every keyword, city or product variation?

A five-page site can contain spam. A fifty-thousand-page reference site can be legitimate. Scale is part of the pattern, not the whole definition.

Expired domain abuse

Buying an expired domain is not, by itself, a spam violation. The abuse occurs when someone repurposes a domain mainly to manipulate rankings and fills it with content that offers little value. Google's examples include commercial pages placed on domains that previously belonged to government, educational or charitable organizations.[5]

This nuance gets lost in discussions about domain history. Rebuilding an old domain into a real publication is not the same as borrowing its former reputation to rank casino pages. The history can explain why a name or audience makes sense. It cannot substitute for a useful site.

Site reputation abuse

This policy concerns third-party content published mainly to exploit the host site's established ranking signals. A familiar example is a respected publication hosting white-label coupon or gambling pages that it would struggle to rank on a new domain.[5]

Third-party authors, freelance work, opinion columns and affiliate links are not automatic violations. Intent and the relationship between the host, content and audience matter. Google even lists editorial columns and opinion pieces among the examples that are not inherently site reputation abuse.[5]

Link spam

Paid links that pass ranking credit, automated link creation, excessive exchanges and other link schemes remain covered by the spam policies.[5]

Do not turn a generic spam update into a reason to disavow every unfamiliar backlink. Google did not label the August release as a link spam update. A random scraper linking to an article is not evidence that the article engineered a scheme.

If Google later confirms a link spam focus, its documentation contains an unpleasant detail: removing the effect of spammy links also removes the ranking benefit those links created. Cleaning them up does not recreate a benefit that was never deserved.[2]

Hacked and user-generated spam

The site owner does not have to create the spam personally. Attackers can inject hidden links, new pages, redirects or JavaScript. Open comments, profile pages, file uploads and internal search results can also produce indexable junk.[5]

Search for unexpected URLs and topics. Check server logs and recent database records. A small blog with no public registration can still be compromised through an old dependency, leaked credential or writable storage endpoint.

Does a blog need one narrow topic?

This question matters to Straycode because the site contains code, browser debugging, security, Soviet bus stops and Prince Rupert's drops.

Google's people-first content guidance asks whether a site has a primary purpose or focus.[6] That does not mean every article needs the same keyword or industry label. A publication can have an editorial point of view rather than one microscopic subject.

The connection here is curiosity about how things work: software, infrastructure, odd objects and overlooked systems. Those articles are written for the site's own readers and carry original structure, research and perspective. They are not white-label pages placed on an unrelated high-authority domain to capture rankings.

Topic variety becomes suspicious when it follows monetizable queries rather than an audience. A film site that suddenly grows a third-party payday-loan directory has a different shape from a personal publication whose author writes about several things he genuinely investigates.

I would make the editorial connection clear in navigation, the About page and internal links. I would not delete a good architecture article because the previous post happened to contain JavaScript.

What I would not change this week

I would not delete pages solely because impressions moved during the rollout.

I would not rewrite every introduction, replace all titles or change the site's category structure at once. Even if traffic returns, there would be no way to identify the useful change.

I would not publish a stack of hurried articles about the update to prove that the site is active. Google lists producing large amounts of search-first content and summarizing other sources without adding value as warning signs in its own guidance.[6]

I would not buy links, swap domains or move affected content into a new subdirectory to escape a classifier. Google's policy on circumvention covers moving violations to new subdomains, directories or sites.[5]

And I would not submit a reconsideration request unless Search Console shows a manual action. There is no reconsideration form for a purely algorithmic loss.

Recovery is slower than the fix

If an audit finds a real violation, remove the pattern rather than polishing a few examples.

That can mean deleting generated doorway pages, closing an indexable internal-search surface, removing rented third-party sections, cleaning a hack, correcting redirects or changing how affiliate content is produced. Document what changed and when.

Do not expect an immediate return. Google says its automated systems may need months to learn that a site complies with the spam policies again.[2] That delay makes careful measurement even more important. Otherwise each week produces another speculative repair, and the site never stays stable long enough to be reassessed.

Some losses may not return at all. If a site ranked because Google previously counted manipulative links, invalidating those links removes the artificial advantage. Recovery then requires earning visibility on the strength of the pages and legitimate references, not restoring the old shortcut.

My checklist for the August update

For now, mine is short:

Record August 18 and save the pre-update Search Console baseline.
Check deployments, indexing, security issues and manual actions.
Wait for the status dashboard to mark the rollout complete.
Allow several complete days of data before comparing periods.
Find the affected page pattern before editing anything.
Audit that pattern against the actual spam policies.
Make one explainable set of changes and keep a record.

Google may publish more detail. Independent datasets may reveal a convincing pattern after the rollout. Until then, the most accurate account of the August 2026 spam update is also the least exciting one: a global spam-system change is running, Google has not said what it targets, and two days of movement are not enough to diagnose a website.

That is not a satisfying answer. It is a better starting point than panic.