Skip to content
Oday Bakkour
Back to Knowledge Hub

Daily SEO Note — September 26, 2026: Google's Spam Update Enters Day Two of a Two-Week Rollout

Oday Bakkour profile photo
Oday Bakkour
9 min read
Share
Daily SEO Note — September 26, 2026: Google's Spam Update Enters Day Two of a Two-Week Rollout

1. SEO for Content Writers

The only ranking event that matters this morning is one that has not finished. Google's September 2026 spam update opened on the Search Status Dashboard at 09:15 PDT on 24 September (16:15 UTC) and, as of 06:12 UTC on 26 September, still carries no completion timestamp. Google put a two-week ceiling on the rollout, so nothing you measure today is a verdict.

The September 2026 spam update is on day two of a fortnight-long rollout

Google's dashboard entry reads: "Released the September 2026 spam update, which applies globally and to all languages. The rollout may take up to two weeks to complete." That two-week figure is the story. Every other spam update Google shipped this year closed inside three days — the ranking update history logs March 2026 at 19 hours 30 minutes, June 2026 at 2 days 1 hour, and August 2026 at 2 days 16 hours. A fourteen-day window is roughly five times the longest of those.

This affects all content, but the spam policies tell you where to look first: scaled content abuse, site reputation abuse, and expired domain abuse. If you run a syndicated section, a coupons or reviews subfolder staffed by a third party, or a bulk-generated programmatic set, those are the surfaces a spam update touches. Rollout status: active, no end date published.

What to do differently in the next brief: change nothing on the basis of this week's numbers. Take a ranking and traffic snapshot per content type today so you have a clean pre-rollout baseline, and schedule the real diagnosis for after Google marks the incident complete. What to stop: stop reading a 48-hour dip as a penalty signal. During a rollout that long, positions move back and forth, and rewriting a page mid-flight destroys your ability to attribute the outcome to anything.

Google Posts can now be pulled for unverified contact information

Google's Business Profile content policy for posts now states: "To avoid fraud or abuse, we may remove posts with unverified contact information. This includes phone numbers, email addresses, and social media handles." The wording is live on the help page today; Google does not stamp these policy pages with a revision date, so treat the effective date as now. Rollout status: policy text published and in force.

This affects one content type rather than the whole site: local and multi-location editorial, franchise updates, event announcements, and anything a store manager writes into a profile. The practical trap is call-tracking. Dropping a rented tracking number into post copy is exactly the pattern the clause describes, because that number is not verified against the business.

What to do differently: move every contact detail out of post body copy and into the structures Google already verifies — the profile's own phone field, the call-to-action button, and a link to a page on the verified website. What to stop: stop shipping post templates with a phone number, an inbox address, or a social handle in the text. A removed post takes its impressions with it and gives you no notification to react to.

Search Console now separates web multimodal search, and it ships without queries

Google announced web multimodal Search performance reporting on 24 September. "Web" in the Search type filter now splits into text and multimodal, where multimodal covers searches that included an image — Lens, Circle to Search on Android, image uploads, and Chrome's right-click "Search this image". It appears in both the Search results report and the Generative AI features report. Rollout status: rolling out globally, and you only see the row once your site takes that traffic.

The constraint is the interesting part. Because these searches are carried by an image rather than typed words, the queries dimension is unavailable when the multimodal type is selected. You get clicks and impressions and nothing to read them against.

What to do differently: for any article whose value is visual — product comparisons, how-to walkthroughs, plant or part identification, anything photographed — stop relying on the body copy alone to carry the entity. Name the object explicitly in the alt text, the caption, and the sentence adjacent to the image, because those are the signals standing in for a query you will never see. What to stop: stop planning a rewrite around query data for this segment. It is not coming.

Ranking volatility on 23–25 September is unconfirmed

Community trackers and forum threads reported elevated volatility on 23 and 24 September, the day before and the day of the spam update announcement. Google has confirmed nothing beyond the spam update itself, and no separate incident is logged on the status dashboard. Treat this as unconfirmed and do not act on it; it is recorded here only so a reported movement does not get mistaken later for a silent update.

Apply to your next brief

  • Snapshot rankings and organic sessions per content type today. That is your pre-rollout baseline; the spam update has no end date yet.
  • Freeze substantive rewrites on pages you suspect are affected until Google marks the September 2026 spam update complete.
  • Audit briefs that touch syndicated, third-party-staffed, or bulk-generated sections against scaled content abuse, site reputation abuse, and expired domain abuse.
  • Strip phone numbers, email addresses, and social handles out of every Google Posts template; route them to the CTA button and the verified profile fields instead.
  • For image-led articles, write the subject entity into alt text, caption, and the adjacent sentence — multimodal impressions arrive with no query attached.
  • Add the multimodal Search type to your monthly Search Console pull so the segment is tracked from its first day rather than discovered next quarter.

2. SEO for Developers

Cloudflare pushed an emergency WAF release on 25 September covering an unauthenticated WordPress path-traversal and local file inclusion flaw. If your managed ruleset is pinned to an older version or running in log-only mode, four new blocking rules that landed enabled by default are doing nothing for you.

Cloudflare emergency WAF release, 25 September 2026

Four detections were added to the Cloudflare Managed Ruleset, all with a default action of Block. The headline entry is CVE-2026-87902, a high-severity path traversal and local file inclusion bug in WordPress that lets an unauthenticated attacker read arbitrary files on the host. A second rule covers a WordPress comment XSS vector. The remaining two cover JFrog Artifactory authentication bypasses, CVE-2026-42018 and CVE-2026-82329.

Breaking or non-breaking: non-breaking for legitimate traffic, but consequential if you have overridden the managed ruleset. The symptom if ignored on a WordPress origin is an unauthenticated read of wp-config.php, which hands over database credentials and salts — and on an SEO-managed site that usually means the CMS that owns your canonicals, redirects, and sitemap. Setting to change: your WAF managed ruleset version and any override that sets the action to log.

scripts/check-waf-managed-ruleset.sh
# Confirm the Cloudflare Managed Ruleset is deployed and not pinned or log-only.
# Docs: https://developers.cloudflare.com/waf/managed-rules/
ZONE_ID="your-zone-id"

curl -sS \
  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/phases/http_request_firewall_managed/entrypoint" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  | jq '.result.rules[] | {ref, action, enabled, version: .action_parameters.version}'

# Want the newest detections automatically? version should be "latest", not a pinned number.
# Any rule with action "log" is observing the exploit, not stopping it.

CVE-2026-15273: unauthenticated stored XSS in Automatic.css 4.0.0

Wordfence published CVE-2026-15273 at 02:28 UTC on 26 September. The Automatic.css plugin for WordPress is vulnerable to stored cross-site scripting via REQUEST_URI in version 4.0.0, through insufficient input sanitization and output escaping, letting attackers inject scripts that execute when an administrator opens the Activity Log settings page. CVSS v3.1 base score 6.4, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, CWE-79. Rollout status: published, with only 4.0.0 marked affected.

Breaking or non-breaking: non-breaking to install, but the symptom if ignored is script execution inside an authenticated admin session — the session that can flip a site to noindex, rewrite canonicals, or inject links sitewide. A reflected REQUEST_URI is also worth a second look for its own sake: any handler that echoes the raw request path is a candidate for junk URL variants finding their way into the index. Setting to change: the installed plugin version.

scripts/audit-acss.sh
# Identify WordPress hosts still on the single affected release.
# CVE-2026-15273 — Automatic.css 4.0.0 only (all other versions unaffected).
wp plugin get automaticcss-plugin --field=version

wp plugin list --name=automaticcss-plugin --format=json \
  | jq -r '.[] | select(.version == "4.0.0") | "AFFECTED: \(.name) \(.version)"'

# Then update off 4.0.0:
# wp plugin update automaticcss-plugin

Browser Run crawl jobs can publish lifecycle events to Queues

Cloudflare shipped crawl event subscriptions on 25 September. Browser Run crawl jobs now emit started, updated, and finished events to Cloudflare Queues, so downstream work can be triggered on completion instead of polled for. Rollout status: available, non-breaking, additive.

The symptom if ignored is nothing breaking — you simply keep paying for a polling loop. The reason it belongs in an SEO stack is that the regression monitors worth running are all post-crawl jobs: robots.txt diffing, sitemap availability and validity, canonical drift, and accidental noindex detection. Wiring those to a finished event turns a cron guess into an actual trigger. Setting to change: your crawl orchestration, plus a queue and a consumer Worker.

scripts/subscribe-crawl-events.sh
# Trigger SEO regression checks when a Browser Run crawl finishes,
# instead of polling for job status.
npx wrangler queues create seo-crawl-events

# Subscribe the queue to Browser Run crawl lifecycle events at the account level:
npx wrangler queues subscription create seo-crawl-events \
  --source browser-rendering \
  --events "crawl.started,crawl.updated,crawl.finished"

# Attach a consumer Worker that runs the checks on crawl.finished:
npx wrangler queues consumer add seo-crawl-events seo-regression-checks

VideoObject gains creator, and interactionStatistic types are pinned down

Google's documentation changelog records a 24 September update to the VideoObject structured data guide, which now carries a Last updated stamp of 2026-09-24 UTC. It adds the creator property and clarifies which interactionStatistic interaction types are supported. Rollout status: documented; recommended, not required.

Breaking or non-breaking: non-breaking. creator takes a Person or Organization and needs either name or alternateName; Google documents creator and author as interchangeable for this purpose. For interactionStatistic, the supported interaction types are WatchAction (views), LikeAction (likes or upvotes), CommentAction (comments), and ShareAction (reshares). The symptom if ignored is not an error — it is a video result carrying less attribution and less engagement context than a competitor's. File to change: whichever template emits your VideoObject JSON-LD.

app/components/VideoJsonLd.tsx
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "How to audit robots.txt for AI crawlers",
  "description": "A walkthrough of separating training, search and user-triggered fetchers.",
  "thumbnailUrl": ["https://example.com/thumbs/robots-audit-1x1.jpg"],
  "uploadDate": "2026-09-26T09:00:00+00:00",
  "duration": "PT8M41S",
  "contentUrl": "https://example.com/video/robots-audit.mp4",
  "creator": {
    "@type": "Person",
    "name": "Oday Bakkour",
    "url": "https://example.com/authors/oday-bakkour"
  },
  "interactionStatistic": [
    {
      "@type": "InteractionCounter",
      "interactionType": { "@type": "WatchAction" },
      "userInteractionCount": 12480
    },
    {
      "@type": "InteractionCounter",
      "interactionType": { "@type": "LikeAction" },
      "userInteractionCount": 317
    }
  ]
}
</script>

Ship today

  1. Confirm your Cloudflare managed ruleset resolves to the latest version and that no override has demoted the new WordPress and JFrog rules to log. This is the one change worth a same-day pull request.
  2. Inventory WordPress installs for Automatic.css 4.0.0 and update off it. Only that exact version is listed as affected.
  3. Add creator and interactionStatistic to your VideoObject template, then re-validate one URL in the Rich Results Test before rolling it across the library.
  4. If you run scheduled crawls on Cloudflare, replace the polling loop with a Queues subscription on crawl.finished and hang your robots.txt, sitemap, canonical, and noindex checks off it.
  5. Record today's date against the September 2026 spam update in your deployment log, so that a ranking change three weeks from now can be separated from whatever you ship next week.
Add Oday Bakkour as a preferred source on Google

Comments

Share your thoughts and join the conversation

Leave a Comment

Loading comments...
RELATED