Google September 2026 Spam Update is Now Over – Here’s What To Do Next

1. What Happened? – Google September 2026 Spam Update is Now Over – Here’s What To Do Next

Google’s September 2026 spam update has finished rolling out.

According to the Google Search Status Dashboard, it was released on 24 September 2026 at 09:15 US Pacific time and was confirmed complete on 8 October 2026, with the completion notice posted at 01:37 Pacific (04:37 Eastern, 09:37 in the UK). The dashboard records the rollout at 13 days and 16 hours. It applied globally and in all languages.

Google described it as a normal spam update: nothing new in what it targets, simply its spam systems running again against the existing spam policies. It was not a link spam update. Google did not say what proportion of searches were affected.

Search Engine Roundtable tracked three distinct waves of volatility during the rollout:

• 25–27 September, the first weekend
• around 30 September
• 4–7 October, the final stretch

The same report notes, rightly, that those dates assume Google ran no other changes during the same fortnight, which nobody outside Google can confirm.

This is the fourth spam update of 2026, after March, June and August.

We saw the first wave in our own data. Our UK desktop SERP tracking, published last week in related searches gain SERP share, showed related searches falling from around 92% of results pages on 23 September to roughly 78% on 26 September, before recovering to 93.68% by 2 October. That is page layout rather than rankings, but it lines up with the first wave to the day.

Two things most coverage will get wrong

“It took unusually long.” Only by 2026’s standards. The previous three spam updates this year finished in 20 hours, 2 days and 2.7 days, and against that this one took roughly seven times as long. But across the full history, the median general spam update since 2021 took seven days. October 2023 took 16 days, March 2024 took 15, and August 2025 took 27. Two weeks is normal for a spam update. The two-day rollouts were the exception.

“It was just a normal update.” In substance, perhaps. In rhythm, no. The gaps between spam update releases this year have been 92 days, then 55, then 37. Whatever is in each update, they are arriving faster.

2. Why Does It Matter? – Google’s September 2026 spam update has finished rolling out.

A two-week update makes diagnosis harder, and most advice ignores that

The standard advice after any update is to compare your recent impressions and clicks with previous weeks. With a two-day rollout, that works: a clean before, a short during, a clean after.

A two-week rollout with three waves breaks it. Over a fortnight, your traffic also moves because of content you published, seasonal demand, competitors’ changes, SERP layout changes, your own technical changes, and any unannounced Google changes. Comparing “the last two weeks with the two weeks before” mixes all of that together and calls it the update.

It gets worse once you look at which weeks you are comparing.

In 2026, one day in four has had a confirmed ranking update

We counted every confirmed ranking update on Google’s Search Status Dashboard since 1 January.

	Days
Days in 2026 to 8 October	281
Days with any confirmed ranking update rolling out	69 (25%)
Excluding the February Discover update	47 (17%)

So “compare with previous weeks” very often means comparing one update window with another. The clean windows – stretches with no confirmed update at all – are the only defensible baselines, and there are only six of any length this year:

Clean window	Length
1 January – 4 February	35 days
27 February – 23 March	25 days
9 April – 20 May	42 days
2 June – 23 June	22 days
27 June – 17 August	52 days
21 August – 23 September	34 days

The right baseline for diagnosing September’s update is 21 August to 23 September: the 34 days between the end of the August spam update and the start of this one.

Two UK cautions on that window. It contains the August bank holiday on Monday 31 August and the tail of the school holidays, and September brings the return to school and work. So compare the same day of the week rather than raw daily averages, and sanity-check against the same weeks of 2025. And if you rely on a rank tracker’s volatility score, note that the tooling we track recalculated its volatility baseline on 18 September, inside this window. That affects volatility scores, not Search Console data.

“Clean” only means no confirmed update. Google changes things constantly without announcing them. A clean window is the best baseline available, not a guarantee.

The cadence is the real news

Ninety-two days between the March and June spam updates. Fifty-five between June and August. Thirty-seven between August and September.

We would not extrapolate a line from three points, and Google has said nothing about schedules. But the direction matters for planning, and it fits other things Google has said. In the internal timing data Gary Illyes presented this month, covered in Google’s crawl, index and serve timings, spam update recovery is described as one to two weeks where systems update continuously, and months where recovery depends on batch refreshes. Google’s own spam update documentation says changes may help “if our automated systems learn over a period of months that the site complies with our spam policies.”

Put those together and the working assumption should be: spam enforcement is becoming a near-continuous process, and recovery happens on refresh cycles you cannot see or schedule. A clean-up made now is evaluated whenever the next refresh lands, not on a date you can plan around.

“Was it you?” has to be answered by fingerprint, not by feeling

Google’s spam policies list a long set of practices. A traffic drop during a spam update does not tell you which one, or even that it was the update. The honest way to answer the question is to match three things:

1. Timing. Does the drop start in one of the three waves, at daily resolution?
2. Shape. Is the loss concentrated in one section, template or page type, or spread evenly across the site? Spam systems usually act on a type of page. An even, site-wide loss points more often at something else.
3. Policy match. Do the pages that lost traffic fit a specific policy?

If all three line up, you have a diagnosis. If they don’t, you probably don’t – and acting as if you do will cost you months.

The policies legitimate businesses actually brush against

Most of the spam policies describe practices no legitimate business is accidentally doing: cloaking, sneaky redirects, malware, scam sites. A handful catch ordinary businesses regularly, and four deserve attention.

Location pages: doorways and keyword stuffing. This is the one most UK service businesses do not realise applies to them. Google’s doorway abuse policy names, explicitly, “having multiple domain names or pages targeted at specific regions or cities that funnel users to one page.” The keyword stuffing policy names “blocks of text that list cities and regions that a web page is trying to rank for.” Those two sentences describe the standard local SEO programme: a page per town, near-identical except for the place name, ending in an “Areas we cover” list of forty towns. Location pages are not against the rules. Location pages that exist only to rank, and say nothing that could not be said about any other town, are exactly what the policy describes. We set out how to measure the difference in templated pages deindexed.

Scaled content. The policy covers content generated at scale mainly to rank, “no matter how it’s created”, with generative AI explicitly named. It also gives the remedy in one line: “If you’re hosting such content on your site, exclude it from Search.” Google is telling you how to fix it.

Thin affiliation. Affiliate pages that copy merchant descriptions without original testing, comparison or information. Not every affiliate is thin; the policy is explicit that original reviews, testing and comparisons add value.

Hacked content. This is the one behind most “we were hit unfairly” stories. A site can be caught by a spam update because the spam on it is real – someone else put it there. The hacked content policy describes page injection: attackers adding new spammy pages, often without touching the pages you look at every day. A site owner who audits their own content and finds nothing wrong may be looking at the wrong pages. Section 4C has a detector for this.

Site reputation abuse is probably not what hit a third-party section

Publishers with sponsored, coupon or partner sections will reasonably wonder whether this update targeted them under the site reputation abuse policy.

The policy describes a different enforcement route: detection leads to human review, and outside the European Economic Area the result is a manual action, notified in the Manual actions report and the Search Console message centre. Inside the EEA, affected sections are instead categorised as separate from the main domain. We covered that split in Google manual actions.

So if a third-party section lost traffic during this update and there is no message in the Manual actions report, the cause is more likely to be another policy – scaled content, thin affiliation – or something unrelated. Check the report first. It takes a minute and changes the whole diagnosis.

What not to do

Do not move content to a new subdomain or subfolder. Google’s policy circumvention section names exactly this – “using existing or creating new subdomains, subdirectories, or sites with the intention of continuing to violate our policies” – and says it can lead to broader action across the site, including loss of eligibility for features like Top Stories and Discover. Moving the problem makes it bigger.

Do not start a disavow project in response. This was not a link spam update. Spending a month disavowing links will not address whatever this update acted on.

Do not make sweeping site-wide changes before you have a diagnosis. Changing templates, navigation and content at once makes it impossible to tell later what helped, and adds new variables to a recovery that already takes months.

Do not look for a reconsideration form. Reconsideration requests exist for manual actions. An algorithmic demotion from a spam update has no appeal route. The only lever is changing the site and waiting for systems to re-evaluate it.

Do not assume you were targeted if you cannot find a cause. Search Engine Land’s report on the completion says it plainly: some sites that are not spamming get hit by spam updates. If your diagnosis finds nothing – no timing match, no concentrated loss, no policy match, no injected pages – the honest conclusion may be that something else moved, and the right action is to keep investigating rather than to start rewriting.

3. Who Is Affected?

Service businesses with location page programmes. The doorway and keyword stuffing policies describe the usual template almost word for word. Highest priority for review if you have pages per town and an “areas we cover” list.

Sites publishing at scale with generative AI. Scaled content abuse applies however content is made. If volume came before value, review it now.

Affiliate publishers. Thin affiliation is a named policy. Original testing and comparison are the defence.

Publishers with sponsored, coupon or partner sections. Mostly a manual-action risk under the site reputation policy, with a different outcome inside and outside the EEA. Check the Manual actions report before assuming this update was the cause.

Any site accepting user-generated content. Reviews, comments, forums, profiles and uploads are all named routes for user-generated spam. We covered the hardening in Gemini 4 Argon as an SEO guide, where the same content also carries a prompt injection risk.

Sites on unpatched CMS installs or old plugins. The commonest route for injected pages, and the commonest hidden cause of an “unfair” spam hit.

Anyone who has bought an expired or aged domain. Expired domain abuse is a named policy, and repurposing a domain mainly for its ranking history is exactly what it describes.

Finance, sports and news. These topped the volatility table in our UK tracking during the rollout. That is not evidence that the update targeted them. Google gave no targeting detail. It is a reason for sites in those categories to check their own data first.

In-house teams reporting Q3 and Q4 performance. Every quarterly comparison that crosses 24 September to 8 October now needs annotation, and in 2026 so do many earlier ones.

Less affected: sites that saw no meaningful change. But no change is not proof of compliance. With updates now five weeks apart, it may only mean nothing has caught up with you yet.

4. What Should Businesses Do?

The work is diagnosis first, then targeted fixes, then patience. In that order.

4A. Everyone: diagnose in the right order

1. Confirm the drop, and date it. Use daily data from Search Console, not weekly totals. Look at clicks and impressions. A fall in impressions points at visibility. A fall in clicks with steady impressions points at click-through, which may be SERP layout, as our answer capture ratio work showed. Mark the three waves on the chart.

2. Check the Manual actions and Security issues reports. One minute, and either one changes the diagnosis completely. A manual action has a reconsideration route. A security issue means you may be hacked.

3. Rule out the technical causes. Crawl errors, indexing changes, server problems, robots.txt changes, migration side effects. If crawling or indexing changed at the same time, see Google’s crawl, index and serve timings before you blame the update.

4. Segment the loss. By section, template or page type, against the 21 August – 23 September baseline, weekday-matched. Concentrated or diffuse? The script in 4C does this.

5. Match the losing section to a policy. Location pages → doorway and keyword stuffing. Bulk-generated pages → scaled content. Affiliate reviews → thin affiliation. Partner sections → site reputation, and check the Manual actions report again. Unknown URLs → hacked content.

6. Check for injected pages. Even if you think you know the cause. 4C has the detector.

7. Decide, page type by page type: improve, consolidate, noindex, or remove — or, if nothing matches, do nothing yet and keep investigating.

Annotate your reporting. 24 September to 8 October, with the three waves marked. Every Q4 performance conversation will come back to these dates.

4B. For the content and marketing team: fix the pages that match a policy

Location pages – the doorway test

Ask one question of every location page: is this page a destination, or a funnel?

A destination page answers the searcher’s question on the page: who serves this town, from where, how quickly, at what price, with what local knowledge, reviews and proof. A funnel page exists to rank and push the visitor somewhere else – usually a generic service page or a contact form.

Then apply four specific fixes:

• Delete “areas we cover” lists. Replace them with a coverage map or a short, honest statement of the service area. A block of forty town names is the exact pattern the keyword stuffing policy names.
• Give each page something only true of that place. Travel time from the nearest base, local housing stock or conditions that change the job, named local engineers or staff, local reviews, projects completed there. If you cannot write that for a town, you probably should not have a page for it.
• Consolidate the towns you don’t genuinely serve from a nearby base into a regional page.
• Make the location pages a real hierarchy – region, then town – that a person can browse, not a flat set of near-duplicates. The doorway policy names “substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy.”

The method for measuring how distinguishable your location pages are, with code, is in templated pages deindexed.

Scaled and AI-generated content

Sort it into three groups: pages that add something real (keep and improve), pages that duplicate each other (consolidate), and pages that exist only to rank (exclude from Search, as the policy says, or remove). Be ruthless with the third group. A smaller site that meets the policy will recover. A larger one that doesn’t, won’t.

Affiliate content

Add what the policy names as value: original testing, real photographs, measured comparisons, pricing history, and a clear account of how products were chosen. Rewriting merchant descriptions in different words does not change what they are.

Third-party and partner sections

Google’s site reputation policy gives four factors for judging whether a section is genuinely part of your publication. Use them as an audit checklist for every partner section:

1. Presentation – does it look and work like the rest of the site?
2. Quality – does it meet the same standard as your own content?
3. Authorship – is there a named author and a responsible editor?
4. Duplication – does the same content appear on other sites in identical or near-identical form?

A section that fails three of the four is the one to fix first.

Reporting and communication

Brief leadership with the honest version: the update is complete, here is what our diagnosis shows, here is what we are changing, and recovery – if we were affected – is measured in months and arrives on Google’s refresh cycle, not ours. Setting that expectation now prevents the “why haven’t we recovered yet?” conversation every fortnight.

4C. For the development team: measure the loss, find injected pages, find place-name lists

1. Attribute the loss to waves and sections. This compares each wave against a weekday-matched baseline from the clean window, by section, and shows how concentrated the loss is.

python

import pandas as pd

# Baseline: the last clean window before the update — no confirmed ranking
# update between the end of the August spam update and 24 September.
BASELINE = ("2026-08-21", "2026-09-23")
WINDOWS = {
    "wave_1 (25-27 Sep)": ("2026-09-25", "2026-09-27"),
    "wave_2 (30 Sep)":    ("2026-09-30", "2026-09-30"),
    "wave_3 (4-7 Oct)":   ("2026-10-04", "2026-10-07"),
    "post (8 Oct+)":      ("2026-10-08", "2026-10-21"),
}

def section(url: str) -> str:
    """First path segment as a stand-in for template. Replace with your own template map."""
    path = url.split("://", 1)[-1].split("/", 1)[-1]
    first = path.split("/", 1)[0]
    return f"/{first}/" if first else "/"

def wave_report(df: pd.DataFrame) -> pd.DataFrame:
    """df: one row per date x page with columns date, page, clicks (Search Console export)."""
    df = df.copy()
    df["date"] = pd.to_datetime(df["date"])
    df["section"] = df["page"].map(section)
    daily = df.groupby(["section", "date"], as_index=False)["clicks"].sum()
    daily["dow"] = daily["date"].dt.dayofweek

    b0, b1 = map(pd.Timestamp, BASELINE)
    base = (daily[(daily.date >= b0) & (daily.date <= b1)]
            .groupby(["section", "dow"])["clicks"].mean())          # weekday-matched baseline

    rows = []
    for name, (s, e) in WINDOWS.items():
        s, e = pd.Timestamp(s), pd.Timestamp(e)
        w = daily[(daily.date >= s) & (daily.date <= e)]
        if w.empty:
            continue
        for sec, g in w.groupby("section"):
            expected = sum(base.get((sec, d), 0.0) for d in g["dow"])
            actual = g["clicks"].sum()
            rows.append({"window": name, "section": sec, "expected": round(expected),
                         "actual": int(actual),
                         "change_pct": round(100 * (actual - expected) / expected, 1) if expected else None,
                         "lost": max(0.0, expected - actual)})
    out = pd.DataFrame(rows)

    # Window-level change: concentration only means something if the window lost materially.
    tot = out.groupby("window")[["expected", "actual"]].transform("sum")
    out["window_change_pct"] = (100 * (tot["actual"] - tot["expected"]) / tot["expected"]).round(1)

    # Concentration: what share of each window's lost clicks sits in a single section?
    lost_total = out.groupby("window")["lost"].transform("sum")
    out["share_of_loss_pct"] = (100 * out["lost"] / lost_total.where(lost_total > 0)).round(1)
    out.loc[out["window_change_pct"] > -5, "share_of_loss_pct"] = None   # immaterial window: don't over-read
    return out.drop(columns="lost").sort_values(["window", "change_pct"])

How to read it. A window with a material loss, where one section carries most of that loss, is a fingerprint: that section is your candidate, and you match it against the policies. A loss spread evenly across sections points away from a spam action towards something broader. Replace the section() function with your real template mapping – location pages, product pages, articles – because path segments are only a rough proxy.

The materiality guard on the last line matters. Without it, a window where the whole site moved by 1% can show one section carrying “100% of the loss”, which looks dramatic and means nothing.

2. Find pages you didn’t create. Compare the URLs Google knows about – Search Console page exports, or URLs Googlebot requested in your logs – against every URL your CMS and sitemaps say should exist. Anything unknown gets checked; anything with spam signatures gets checked first.

python

import re
from urllib.parse import urlsplit, unquote

# Tokens common in injected spam. Tune to your site — a pharmacy or casino operator needs its own list.
SPAM_TOKENS = re.compile(
    r"(viagra|cialis|tadalafil|casino|slots?[-_]?(online|games?|machines?)|betting[-_]?tips|payday|replica|"
    r"cheap[-_]?(jerseys|bags|watches)|crypto[-_]?airdrop|escort|porn|essay[-_]?writing)", re.I)
CJK = re.compile(r"[぀-ヿ一-鿿가-힯]")   # Japanese, Chinese, Korean
RANDOM_SEGMENT = re.compile(r"/[a-z0-9]{24,}(/|\.|$)", re.I)       # long machine-generated path segments

def normalise(url: str) -> str:
    p = urlsplit(url.strip())
    return f"{p.netloc.lower()}{unquote(p.path).rstrip('/') or '/'}"

def find_unknown_urls(seen_urls, known_urls, site_uses_cjk=False):
    """seen_urls: URLs Google reports (Search Console exports) or Googlebot requested (logs).
       known_urls: every URL your CMS and sitemaps say should exist."""
    known = {normalise(u) for u in known_urls}
    findings = []
    for url in sorted(set(seen_urls)):
        if normalise(url) in known:
            continue
        reasons = []
        decoded = unquote(url)
        if SPAM_TOKENS.search(decoded):                   reasons.append("spam_token")
        if CJK.search(decoded) and not site_uses_cjk:     reasons.append("unexpected_cjk")
        if RANDOM_SEGMENT.search(urlsplit(url).path):      reasons.append("random_segment")
        findings.append({"url": url, "reasons": reasons or ["unknown_url"],
                         "priority": "HIGH" if reasons else "review"})
    return sorted(findings, key=lambda f: f["priority"] != "HIGH")

Unexpected Japanese or Chinese characters in URLs on an English-language site are the signature of a well-known keyword injection hack. Long random path segments are another common sign. Set site_uses_cjk=True if your site genuinely publishes in those languages.

If this finds injected pages: remove them, find and close the hole (usually an outdated plugin, theme or CMS version), change credentials, check the Security issues report, and then follow Google’s guidance on cleaning a hacked site. Removing the pages without closing the hole means they come back.

3. Find place-name lists. Give it your own list of locations and it flags blocks where many of them are packed together – the pattern the keyword stuffing policy names. It leaves genuine sentences that mention a few places alone.

python

import re

def find_place_lists(text: str, places: list[str], min_places: int = 8, window_words: int = 60):
    """Flag blocks where many of YOUR OWN location names appear packed together."""
    names = sorted({p.strip() for p in places if p.strip()}, key=len, reverse=True)   # longest first
    rx = re.compile(r"\b(" + "|".join(re.escape(n) for n in names) + r")\b", re.I)

    flagged = []
    for block in re.split(r"\n\s*\n", text):                    # paragraph or list block
        words = block.split()
        if not words:
            continue
        hits = [m.group(0) for m in rx.finditer(block)]
        unique = {h.lower() for h in hits}
        density = len(hits) / max(len(words), 1)
        if len(unique) >= min_places and (len(words) <= window_words or density >= 0.25):
            flagged.append({"places": len(unique), "words": len(words),
                            "density": round(density, 2), "excerpt": " ".join(words[:18]) + " …"})
    return flagged

Run it across every page template, not only location pages. “Areas we cover” blocks often live in footers and sidebars, which puts them on every page of the site.

4. Exclude content from Search the right way. Where the decision is to keep a page for users but take it out of Search, use <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header. Do not use robots.txt for this. A page blocked in robots.txt can’t be crawled, so Google never sees the noindex, and the page can stay indexed indefinitely.

5. Harden user-generated content. Mark user-submitted links with rel="ugc" (or nofollow), hold first posts from new accounts for moderation, rate-limit account creation, and remove dormant spam profiles. The sanitising approach in the Argon article covers the hidden-text and injection side.

6. Watch for new URLs, permanently. Alert whenever Googlebot requests a URL that doesn’t exist in your CMS inventory and returns 200. Injected pages are usually found by Google before their owner notices. This alert reverses that.

4D. Rolling it out: the next 30 days

Week 1 – diagnose

1. Daily click and impression chart with the three waves marked.
2. Manual actions and Security issues reports checked.
3. Technical causes ruled in or out.
4. Wave attribution report run against the clean baseline.

Week 2 – identify 5. Losing sections matched to policies. 6. Injected-page check run and acted on. 7. Place-name list check run across all templates.

Weeks 3-4 – fix 8. Location pages: lists removed, thin towns consolidated, hierarchy fixed. 9. Scaled and affiliate content sorted into keep, consolidate, exclude. 10. Partner sections audited against the four site reputation factors. 11. New-URL alert deployed. 12. Changes logged with dates, so the next refresh can be read against them.

4E. Governance

Keep a dated change log. With recovery arriving on refresh cycles months away, the only way to know what worked is a record of what changed and when.

Write a rule against circumvention. Moving a problem section to a subdomain or a new site is the instinctive fix and the one Google names as making things worse. Put “we don’t relocate content to avoid a policy” in writing, so nobody tries it under pressure.

Decide who can noindex or remove content at scale. Excluding content from Search is the policy’s own remedy and a big commercial decision. It needs an owner, criteria and sign-off.

Set a two-quarter horizon. Google’s own wording is “a period of months”. Judge the fixes on two quarters, against the same clean-baseline method, and report progress monthly without expecting a single recovery date.

Make location page governance permanent. Each new location page needs a real local reason to exist and content that could only be written about that place, approved before it is published. That one rule prevents most of the doorway risk.

5. What We’re Watching Next

Whether the cadence keeps shortening. 92 days, then 55, then 37. If the next spam update lands within about a month, spam enforcement is moving towards something close to continuous, and “update recovery” stops being an event and becomes a standing condition. We will update the calendar when it does.

Whether a core update follows soon. There has been speculation that one is close. If a core update lands in October, separating its effects from this spam update’s will be harder still. The clean-baseline method still holds; it just needs both windows marked.

Whether sites hit in August recovered in September. The August spam update ended on 21 August. If refresh cycles are shortening, some sites hit then should have seen movement during this rollout. That is visible in our tracking, and we will report what we find.

Whether Google explains the longer rollout. Google called this a normal spam update. A return to long rollouts after three short ones may simply be how this run behaved, or it may reflect a change in how the systems are deployed. We would not read anything into it until Google says more.

How the results page settles. Related searches and image modules both moved sharply during the first wave in our UK tracking. Whether the layout settles where it now sits, or keeps shifting into Q4, decides how much of the “update impact” people report was really page layout rather than rankings.

6. About Szymaniak Digital

Szymaniak Digital is an enterprise AI SEO consultancy. After every update, the most valuable thing we do is usually the least dramatic: working out whether a drop was the update at all, which pages it touched, and which policy those pages match – before anyone rewrites anything.

If you lost traffic between 24 September and 8 October and can’t yet say which section, which wave and which policy, the diagnosis in section 4A is where we would start. It takes days, not months, and it decides whether the next six months go into the right fix.

Contact Us!