Daily SEO Note — August 2, 2026: The AI Opt-Out Has an Undocumented Edge

1. SEO for Content Writers

The most consequential editorial decision on the table today is not a ranking update — Google shipped none. It is the Search generative AI control, the Search Console toggle that removes a site from AI Overviews, AI Mode, and the generative features in Discover. Google still describes it as rolling out "to a subset of website owners," and the help page does not state what happens when a traditional result feature is rendered inside an AI feature. That gap is the story: the toggle is presented as a clean binary, and the documentation does not describe its full blast radius.

Google's AI Opt-Out Does Not Document Its Own Edge Cases

Google's help page is specific about what the control does and does not touch. Selecting "Exclude my site's links and content from Search generative AI features" removes the site from AI Overviews, AI Mode, and generative AI features in Google Discover. Google states it is not a ranking or inclusion signal for the rest of Search, does not affect Merchant Center or Google Ads, and does not govern model training — that remains a Google-Extended decision. Exclusion generally takes effect within one to two days, though Google warns some content takes longer because of caching. Rollout status: partial, subset of owners, no completion date published.

What the page does not answer is what happens to a conventional SERP feature that Google chooses to render inside an AI surface. Search Engine Journal reported on August 1 that Top Stories carousels are now appearing within AI Overviews, and asked exactly this question. Treat the placement itself as unconfirmed — Google has not documented it — but the documentation gap is verifiable, and it is the part that should govern your decision. If a feature you depend on for referral traffic can be hosted inside a surface you have just opted out of, the toggle is not the low-risk experiment it reads as.

Concrete instruction: before anyone touches this setting, pull the share of your organic sessions that arrives through news and Top Stories placements, and hand that number to whoever is signing off. For newsroom and publisher properties, the opt-out is a business decision, not an SEO housekeeping task. Stop describing it internally as "turning off AI" — it is a scoped exclusion whose interaction with adjacent features Google has not yet written down.

Google-Extended, nosnippet, and the Console Toggle Are Three Separate Decisions

These three controls get collapsed into one line in briefs, and they are not interchangeable. Google-Extended is a robots.txt directive that governs generative model training. The nosnippet family — nosnippet, data-nosnippet, and max-snippet — governs preview text, and using it to stay out of AI answers also strips your snippet from ordinary results. The Search Console toggle is the only one of the three that removes a site from AI features without a snippet or ranking trade-off.

Google's own guidance on AI features and your website has not moved since its last update on December 10, 2025, and it still says there are "no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary." There is no separate AI-visibility checklist to write. What there is, is a permissions and policy question about which of the three switches your organization has actually thrown, and whether anyone wrote it down.

Concrete instruction: add a single line to your content brief template naming which of the three controls applies to the property the piece is published on. Stop writing briefs that say "optimize for AI Overviews" — Google has published no criteria to optimize against, and the sentence sends writers chasing a spec that does not exist.

Your Analytics ID Field Is an Editorial Permissions Problem

A high-severity advisory published on July 31 is worth a writer's attention precisely because it is not a developer-only story. In the ApostropheCMS SEO module, the Google Analytics and Google Tag Manager ID fields were written straight into a script tag with no validation, which meant anyone holding a standard editor role could put executable JavaScript into a site-wide setting. Details are in GHSA-wf43-fpp3-cf65. The engineering fix is in Section 2.

The editorial lesson survives the patch. Site-wide SEO and analytics settings tend to live in the CMS next to genuinely editorial fields — meta descriptions, canonical overrides, social cards — and they inherit the editor role by default because that is where they visually sit. They are not editorial fields. A tracking ID, a verification token, and a raw script slot are configuration, and configuration that renders inside a script tag is code.

Concrete instruction: ask your engineering counterpart which fields in your CMS render into a script tag or into raw head markup, and get those moved out of the editor role. Stop treating "it is in the SEO tab" as evidence that a field is safe for the content team to edit.

Google's Ranking, Spam, and Policy Surfaces Logged Nothing

No verified change: the Search Status Dashboard reported no incidents across crawling, indexing, ranking, and serving for July 25 through August 1; the Search Central blog has published nothing since July; and the documentation changelog's most recent entry remains July 29. Second consecutive quiet day.

Apply to Your Next Brief

• Before any property flips the Search Console AI opt-out, produce the share of organic sessions arriving via news and Top Stories placements and attach it to the approval.
• Add a field to the brief template naming which control governs the property: Google-Extended, the nosnippet family, the Console toggle, or none.
• Delete "optimize for AI Overviews" from brief boilerplate; Google publishes no criteria for it and the instruction is unactionable.
• Do not present the AI opt-out as reversible-at-no-cost in internal docs — exclusion propagates in one to two days, but Google has not documented how it interacts with features rendered inside AI surfaces.
• Audit which CMS fields your editor role can write that end up inside a script tag, and hand the list to engineering this week.
• No ranking, spam, or Discover policy change shipped today — do not rewrite existing briefs on the strength of volatility chatter.

2. SEO for Developers

The item that leads today is a high-severity advisory in an SEO package, not a framework release. GHSA-wf43-fpp3-cf65 was published on July 31, 2026 against @apostrophecms/seo, and it turns a routine analytics field into stored cross-site scripting on every page of the site. The patch has been on npm since June, which is the uncomfortable part: if you pinned this package, you have been exposed for seven weeks without an advisory to tell you.

@apostrophecms/seo ≤ 1.4.2: Stored XSS Through the Analytics ID Field

Identifier and date: GHSA-wf43-fpp3-cf65 / CVE-2026-53608, CVSS 3.1 base score 8.7 (High), vector AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, CWE-79. The CVE record was published June 12, 2026; the reviewed GitHub advisory carrying a patched version landed July 31, 2026. Affected: all versions up to and including 1.4.2. Patched in 1.5.0, published to npm on June 10, 2026; current release is 1.6.0 from July 10, 2026. Rollout status: fix available, advisory public.

Breaking or non-breaking: this is a security upgrade within a stable major, so non-breaking to consume. The symptom if ignored is not subtle. The Google Analytics tracking ID and Google Tag Manager ID are interpolated into a script tag body with JavaScript template literals and no validation, in lib/nodes.js. Any account with editor-level access can patch the global document with a payload such as G-FAKE'); alert(document.cookie); // and publish it, at which point the injected JavaScript executes for every visitor on every page — including administrators, whose session cookies are then in reach. Scope is Changed in the CVSS vector for exactly that reason.

The setting to change is the dependency range in package.json. Upgrade to 1.6.0, then verify no editor-supplied value is still sitting in the global document — the patch stops new injection, it does not clean a payload that was already stored. If you maintain a similar field anywhere in your own codebase, the advisory's own remediation is the right pattern: validate against (G\-|UA\-|GTM\-)[A-Z0-9\-]+ before accepting the value, and serialize with JSON.stringify() rather than interpolating into a template literal.

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

# CVE-2026-53608 / GHSA-wf43-fpp3-cf65 — stored XSS in @apostrophecms/seo <= 1.4.2
# Patched in 1.5.0 (2026-06-10); current release 1.6.0 (2026-07-10).

npm install @apostrophecms/seo@^1.6.0
npm ls @apostrophecms/seo
npm audit --audit-level=high

# The upgrade blocks new injection. It does NOT remove a payload already
# stored in the global doc — inspect the persisted values as well.
# Expected shape: G-XXXXXXX, UA-XXXXXX-N, or GTM-XXXXXX. Anything else is suspect.

Next.js 16.3.0-canary.106 Deprecates experimental.useCache and Fixes not-found Behind Adapters

Version and date: v16.3.0-canary.106, published 2026-08-01T23:56:54Z on the canary channel. Two changes: a deprecation warning for experimental.useCache (#96448), and a fix for hybrid Pages Router / App Router not-found rendering when an adapter is in play (#96392). Rollout status: canary only — not in a stable 16.3.0 release yet.

Non-breaking today, breaking on a timetable you do not control. The deprecation is a warning, so builds keep passing; the symptom if ignored is that the flag disappears in a later release and your build fails on an upgrade you were treating as routine. The not-found fix matters more for search than its changelog line suggests. An application that serves both routers behind an adapter could render the wrong not-found output, and a not-found page that returns 200 with page-shaped markup is precisely how a soft 404 gets minted at scale — Search Console reports it as "Soft 404" and the URLs drop out of the index without ever having been asked to.

The setting to change is next.config.ts. Drop the experimental.useCache flag and move to the stable cacheComponents configuration on canary, and if you run a hybrid router setup behind an adapter, take canary.106 or wait for the stable cut before shipping. Verify the fix the only way that counts: request a URL you know does not exist and assert the status code, not the rendered output.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    // Removed in v16.3.0-canary.106 — emits a deprecation warning.
    // useCache: true,
  },
  // Stable replacement on the canary channel:
  cacheComponents: true,
}

export default nextConfig

// Verify not-found status codes after upgrading — a 200 here is a soft 404:
//   curl -s -o /dev/null -w '%{http_code}\n' https://example.com/definitely-not-a-real-url

The AI Opt-Out Is a Console Setting — Do Not Ship It as a robots.txt Change

Engineering keeps getting handed "opt us out of AI" as a ticket, and it is not a file change. The Search Console Search generative AI control is the only mechanism that removes a site from AI Overviews and AI Mode without a ranking or snippet trade-off, and it lives at Settings → Search generative AI. It applies automatically to child properties unless overridden. Rollout status: subset of owners, ongoing.

What you can ship in a file is a different decision. Google-Extended in robots.txt governs generative model training and nothing else; it does not remove you from AI Overviews. The robots meta tag family governs preview text, and nosnippet or max-snippet:0 suppresses your snippet in ordinary results as well as in AI answers — which is why it is the wrong tool for this job. Google's AI features documentation (last updated 2025-12-10) still states there are no additional technical requirements for AI surfaces beyond standard indexability.

If the ask is training-only, the robots.txt below is the whole change, and it is orthogonal to the Console toggle. Ship the file change and the Console change as two separate tickets with two separate approvers, because they have different consequences and different people should own them. Verify crawler identity by reverse DNS against the published crawler list rather than trusting the user-agent string.

# Training opt-out only. This does NOT remove the site from AI Overviews
# or AI Mode — that is the Search Console "Search generative AI" setting.
User-agent: Google-Extended
Disallow: /

# Keep the search crawler allowed so ordinary indexing is unaffected.
User-agent: Googlebot
Allow: /

Sitemap: https://example.com/sitemap.xml

Quiet Engineering Surfaces

Checked and unchanged in the window: Schema.org remains at release 30.0 from 2026-03-19; Lighthouse remains at v13.4.1 from July 20; web-vitals remains at v6.0.1 from July 27; the Cloudflare changelog and the Vercel changelog both stop at July 31 with nothing crawler-, cache-, or SEO-facing. Nuxt sitemap sits at v8.3.2 from July 30, and neither Astro nor SvelteKit has shipped since July 29.

Ship Today

1. Upgrade @apostrophecms/seo to 1.6.0 if you run ApostropheCMS, then inspect the stored global tracking-ID values for an already-injected payload.
2. Audit your own codebase for user-editable values interpolated into script tag bodies; replace template-literal interpolation with JSON.stringify() and add format validation.
3. Remove experimental.useCache from next.config.ts and move to cacheComponents before the flag is deleted upstream.
4. If you run a hybrid Pages/App Router app behind an adapter, assert not-found status codes with a curl check in CI so a soft 404 regression fails the build.
5. Split any "opt out of AI" ticket into two: the Google-Extended robots.txt directive for training, and the Search Console generative AI setting for AI surfaces.