Daily SEO Note — September 3, 2026: Gemini 3.8 Flash Takes Over AI Mode

1. SEO for Content Writers

The model behind AI Mode changed yesterday. On September 2, Google shipped Gemini 3.8 Flash into AI Mode in Google Search, three weeks after 3.7 Flash landed there. Nothing in the ranking systems moved alongside it: the Search Status Dashboard lists no active core, spam, or Discover update, and the last documentation change was August 31. So if your AI Mode citations look different this week, the model swap is the only Google-side event that can explain it.

Gemini 3.8 Flash is now the model answering in AI Mode

Google announced Gemini 3.8 Flash on September 2, 2026 and listed "AI Mode in Google Search" among the surfaces it ships to on day one. In Search it is live for Google AI Pro and Ultra subscribers worldwide, picked from the model selector in the AI Mode input bar; the free tier still gets the previous model. That makes this a partial rollout, not a global flip, and it means two people searching the same phrase this week can be reading answers from two different models.

Google frames the gain as reasoning rather than knowledge: improvements over 3.7 Flash "across software engineering, agentic tasks, and multi-step reasoning," driven by the model taking extra reasoning steps and calling tools iteratively before answering. The editorial read is that comparison, procedure, and "which one should I pick" queries are the ones most likely to get recomposed — those are the queries that decompose into steps. Plain definitional queries have less room to move.

The concrete instruction for your next article: make each section survive being lifted alone. A model that decomposes a question into sub-questions and pulls a source per sub-question rewards a page where the definition, the comparison table, and the finished procedure are each complete inside one heading — not a page where the answer accumulates across four scroll depths. Write the comparison as a table with the criteria named in the header row, and keep the direct answer to the H2's question in the first two sentences under it.

Stop treating citation-share readings collected before September 2 as current. Re-run your AI Mode checks, stamp them with the date and note which account tier you ran them from, because an Ultra account and a free account are no longer looking at the same system. Google's post says nothing about grounding or source-selection changing, and its AI features documentation is unchanged — so treat any citation shift you observe as an observation, not as a documented policy change.

Google Trends can now filter Explore by category with no query

Google Trends announced on September 2 that the new Explore page accepts a category filter on its own, without a query in the box. Previously the documented path was query first, category second — the Trends help page still describes it that way: search a term, then click "All categories." The change lets you sit at the category level and read what is rising inside "All Books & Literature" or any other bucket, filtered by region and timeframe.

This affects the research step of every brief, and it is most useful where your head term is ambiguous across categories. The old workflow forced you to name a term before Trends would show you anything, which quietly biased research toward terms you already knew. Category-first browsing surfaces the demand you did not think to query.

Do this differently starting today: before you lock an outline, open Explore, set the category with no query, and read the rising terms for your market and timeframe. Use the same category filter to disambiguate any head term you do query, so a term that spans two verticals is not scored on the wrong audience's volume. Stop pitching a cluster off a single head-term trendline that was never category-scoped.

Ranking, spam, and Discover systems: nothing is running

The Search Status Dashboard shows no active ranking update. The most recent entry is the August 2026 spam update, which started August 18, ran two days and sixteen hours, and completed. Crawling and indexing both read "no recent incidents reported." The Search Central blog has published nothing since August, and the documentation changelog stops at August 31's refresh of the European Search Dataset Licensing Program page.

The editorial consequence is a negative one worth stating plainly: a traffic movement this week is not a Google update. Do not open a core-update recovery sprint, do not rewrite a page because it slipped four positions, and do not let a client brief cite "the September update." There is no September update.

Unconfirmed: Bing testing snippets without site names

Community reports on September 2 describe Bing testing result snippets rendered without the site name above them, collected in the day's search forum recap. Microsoft has published nothing, and there is no Bing Webmaster blog post — that blog's most recent entry is still February 2026. Label this unconfirmed and do not act on it. It is listed here so you recognise it if you see it in a screenshot this week, and it is deliberately kept out of the checklist below.

Apply to your next brief

• Re-run AI Mode citation checks and date-stamp them; note the account tier you ran them from, because Pro and Ultra now see a different model than the free tier.
• Retire every AI Mode citation benchmark taken before September 2, 2026 from client decks and internal baselines.
• Structure each H2 so the answer to its own question is complete inside it: definition in the first two sentences, comparison as a real table, procedure finished before the next heading.
• Open Google Trends Explore with a category and no query before the outline is signed off, and record the category-level rising terms in the brief.
• Apply the category filter to any head term that spans verticals, so you are not sizing demand from the wrong audience.
• Remove "September core update" from any plan or client note — no ranking, spam, or Discover update is running.

2. SEO for Developers

Two host-identity bugs entered GitHub's reviewed advisory database on September 2, which is the date Dependabot starts opening pull requests for them. Both end in the same failure: your code decides a request belongs to one host, and the request reaches a different one. That is the exact class of bug that poisons canonical tags, hreflang pairs, and absolute sitemap URLs, so both are worth a same-day patch even though neither is filed as an SEO issue.

fastify: numeric trustProxy still lets X-Forwarded-* be spoofed (CVE-2026-16732)

Moderate, CVSS 6.1, patched in fastify 5.12.1; affected range is 5.8.3 through 5.12.0. The earlier fix for CVE-2026-3635 added a guard that blocks spoofing for the IP, CIDR, and custom-function forms of trustProxy. The numeric form — trustProxy: 1 — was left behind, because its predicate structurally ignores the address argument, so the guard never runs. Anyone who can reach the origin directly, bypassing your CDN, can set X-Forwarded-Host and X-Forwarded-Proto to whatever they like.

The symptom if you ignore it is not an error page. It is host injection in every URL your app generates from the request: canonical tags, hreflang alternates, Open Graph URLs, redirect Location headers, and absolute sitemap entries. Cache poisoning follows, because a poisoned response gets stored under a legitimate key. Upgrade, then move off the numeric form to a predicate that actually inspects the connecting address — and while you are in there, stop deriving canonical URLs from request headers at all.

import Fastify from 'fastify'

// CVE-2026-16732: `trustProxy: 1` ignores the connecting address.
// Use a CIDR list (or a function) so the hop is actually validated.
const app = Fastify({
  trustProxy: ['173.245.48.0/20', '103.21.244.0/22', '10.0.0.0/8'],
})

// Never build canonical/sitemap URLs from request headers.
const SITE_ORIGIN = new URL(process.env.SITE_ORIGIN!) // e.g. https://example.com

app.get('/canonical-demo', async (req, reply) => {
  const canonical = new URL(req.url, SITE_ORIGIN).toString()
  reply.header('Link', `<${canonical}>; rel="canonical"`)
  return { canonical }
})

Advisory of record: CVE-2026-16732, published August 18, 2026, GitHub-reviewed September 2, 2026 (GHSA-3m5p-2c4r-xxw2). Non-breaking as a version bump; changing the trustProxy form is a config change you must verify against your real proxy chain.

fast-uri: resolve() returns a host that re-parses to something else (CVE-2026-75931)

High, CVSS 7.5, patched in 2.4.5, 3.1.6, and 4.1.3. fast-uri is a URI parsing and resolution library, and almost nobody installs it deliberately — it arrives transitively through ajv, and through ajv into fastify and a long tail of JSON-schema tooling. When resolve() handles a scheme-relative reference such as //host/ against a base URI with an explicit scheme, it returns the host in its original form instead of converting it to ASCII. Re-parsing the resolved URI then yields a different host than the one resolve() handed back.

The symptom if ignored is a validation bypass with a very familiar shape to anyone who has debugged internationalized domains: your allowlist check passes against one hostname while the fetch goes to another. If you resolve URLs during sitemap generation, feed ingestion, or link rewriting, that is a path to emitting URLs pointing at a host you never approved. Check the transitive tree first — the direct dependency will usually be ajv, not fast-uri.

# Find every path that pulls in the vulnerable resolver
npm ls fast-uri

# Force the patched versions across the tree, then re-audit
npm install [email protected] --save-exact   # or 3.1.6 / 2.4.5 for older majors
npm audit --audit-level=high

# pnpm/yarn equivalents
pnpm why fast-uri
yarn why fast-uri

Advisory of record: CVE-2026-75931, published August 23, 2026, GitHub-reviewed September 2, 2026 (GHSA-5jgf-p345-68v8, plus three sibling advisories on the same package). Non-breaking patch releases on all three majors.

Two more in the metadata toolchain: @xmldom/xmldom and link-preview-js

@xmldom/xmldom, moderate, CVSS 6.3, patched in 0.8.15 and 0.9.12 (the unscoped xmldom package has no patch at all and should be replaced). An EntityReference node whose name contains XML markup characters is serialized without validation or escaping under { requireWellFormed: true }, so real elements can be injected into the output fragment. If you build or post-process sitemap XML, RSS, or Atom with this parser, the symptom is a feed that validates locally and carries injected markup in production.

link-preview-js, high, CVSS 7.5, patched in 4.0.4. This is an incomplete fix of an earlier SSRF: the library validates the resolved IP through resolveDNSHost but then calls fetch() with the original hostname, never anchoring the connection to the address it validated. An attacker running the DNS server answers with a public IP for the check and a loopback or internal address for the real connection. Anything that fetches a third-party page server-side to read its Open Graph tags — link previews, social cards, editorial embed tooling — is in scope.

#!/usr/bin/env bash
set -euo pipefail

# CVE-2026-83610 - XML injection via EntityReference nodeName
npm install @xmldom/[email protected]   # or 0.8.15 on the 0.8 line

# CVE-2026-61704 - SSRF via DNS rebinding in the OG-preview fetcher
npm install [email protected]

# The unscoped `xmldom` package (<= 0.6.0) has no fix - remove it
npm ls xmldom || true

npm audit --audit-level=moderate

Advisories of record: CVE-2026-83610 (published August 21, GitHub-reviewed September 2) and CVE-2026-61704 (published June 23, GitHub-reviewed September 2). Both are non-breaking upgrades; the xmldom fix does add creation-time validation that rejects invalid XML names, so a generator that was silently emitting malformed node names will now throw.

Cloudflare Images can now rasterize text and set response headers directly

Shipped September 2, 2026, additive and non-breaking. The Images binding gained a .text() method for rasterizing text with font, size, and color options, and the draw array in cf.image now accepts a text key for overlays. The same release lets you pass a headers option to .response() instead of rebuilding the Response object to attach cache directives.

For SEO work this is the piece that makes edge-generated Open Graph images practical without a headless browser: title text composited onto a template at the edge, with a correct immutable Cache-Control on the way out. The header option matters more than it sounds — an OG image served without a long cache lifetime is re-generated on every crawler and scraper fetch, which is how a social card endpoint becomes your slowest route.

// Cloudflare Worker - edge-composited OG image (1200x630)
export default {
  async fetch(request, env) {
    const title = new URL(request.url).searchParams.get('title') ?? 'Untitled'

    const text = await env.IMAGES.text(title, {
      fontSize: 64,
      color: '#0b0b0c',
      fontFamily: 'Inter',
    })

    const image = await env.IMAGES.input(await env.ASSETS.fetch('/og-base.png'))
      .draw(text, { top: 220, left: 96 })
      .output({ format: 'image/png' })

    // New: set headers without rebuilding the Response
    return image.response({
      headers: { 'Cache-Control': 'public, max-age=31536000, immutable' },
    })
  },
}

Primary sources: the Cloudflare changelog entry dated September 2, 2026, and the Images bindings documentation. Rollout status: generally available on the Images binding.

Quiet surfaces, checked and empty

Everything else in the engineering audit surface produced nothing inside the window. Next.js stable is still 16.3.4 (August 31), the release that re-enabled AVIF image optimization; the only movement since is 16.4.0-canary.15, published September 2 at 23:52 UTC, carrying Turbopack cache compression and a React bump — watch, do not ship. astro 7.2.10 and @astrojs/sitemap 3.7.4 both date to August 31 and are unchanged.

web-vitals is still 6.2.1 (August 26). Lighthouse stable is still 13.4.1 (July 20); only dated dev builds have published since. Schema.org is still on release 30.0 from March 19. Chrome's desktop stable 152.0.7977.65/.66 began serving September 1 at 20:50 UTC, just outside this window, and September 2 shipped only ChromeOS stable plus beta channels. Google's common crawlers documentation still carries its July 14, 2026 timestamp, and OpenAI's bots documentation is unchanged apart from now living at developers.openai.com after a 301 from the old platform.openai.com path — update any internal runbook that deep-links the old URL.

Ship today

1. Run npm ls fastify — if you are on 5.8.3 through 5.12.0, upgrade to 5.12.1 and replace any numeric trustProxy value with a CIDR list or a predicate that inspects the connecting address.
2. Run npm ls fast-uri and pin 4.1.3 (or 3.1.6 / 2.4.5) across the tree; the pull is almost always transitive through ajv.
3. Upgrade @xmldom/xmldom to 0.9.12 or 0.8.15 anywhere it touches sitemap, RSS, or Atom generation, and remove the unscoped xmldom package, which has no patch.
4. Upgrade link-preview-js to 4.0.4 if any server-side route fetches third-party pages to read Open Graph tags.
5. Grep the codebase for canonical, hreflang, and sitemap URLs built from request headers, and rebuild them from a configured origin constant instead.
6. If you generate Open Graph images at the edge on Cloudflare, add the new headers option to .response() so the card ships with an immutable Cache-Control.