Daily SEO Note — October 31, 2026: Google and Bing Back One AI Training Opt-Out

Audit window: 24 hours to 06:00 UTC on Friday 31 October 2026. Both tracks produced verified change, and for once they produced the same change from two directions: on 30 October, Google and Microsoft each announced support for a single shared AI-training preference in robots.txt.

1. SEO for Content Writers

The one editorial change that matters today: the question "do we let AI use our work?" stopped being one question. Microsoft's 30 October announcement splits AI training from AI grounding and makes them independent, page-level choices — and training is the one that feeds models, while grounding is the one that gets you cited. Google's companion post the same day commits to the same shared signal. Nothing is enforced today; the deadlines land in early 2027, which makes this a decision week, not a deployment week.

One robots.txt line will speak for every participating AI provider

Google announced on Friday 30 October 2026 that it plans to support a shared AI training control in robots.txt, built on work from the AIPREF working group at the IETF. Instead of maintaining a separate instruction per AI company, a site states its training preference once using a shared "policy token." Microsoft announced support the same day. Rollout status matters here: Google says it aims to support the control "along with other AI providers in 2027," and Microsoft will begin honoring it on 1 February 2027. Today, nothing changes in how either company behaves.

This affects all content on every site, not a vertical or a content type. It is also not really a robots.txt task — it is a rights decision that happens to be expressed in robots.txt. The engineering change is a few lines; agreeing what the answer should be, per section and per market, is the slow part, and it belongs to editorial and legal before it reaches a repository.

For your next brief: nothing. For your next planning meeting: get a written position on AI training for each content area you own — original reporting, evergreen explainers, reference tables, syndicated wire copy — because the single site-wide answer that robots.txt made convenient is now the answer most likely to be wrong somewhere.

Stop treating "AI opt-out" as one yes-or-no switch. From today it is at least two switches, and on Bing it is three values.

Blocking training is not blocking citations — Bing just made the split explicit

Microsoft's post defines the two uses separately. AI Training covers using an asset to modify the learned parameters of a generative model. AI Grounding covers using content as input to help inform an AI-generated response. Microsoft states that indexing and ranking pages in traditional search results is not grounding, and that neither preference changes eligibility for ordinary Bing results.

Grounding has three values, set per page: Allow (the default), Disallow, and a new middle option, DisallowExtended, which limits grounding to Microsoft-operated experiences such as AI Mode, AI Overview, Copilot and Microsoft 365 while excluding the grounding services Microsoft provides to third parties, such as Web IQ and grounding through API access in Foundry.

Microsoft is unusually blunt about the trade: choosing DisallowExtended or Disallow "will significantly reduce your content's visibility in AI-generated experiences," and it adds that neither choice guarantees inclusion, traffic, or payment. That is the sentence to quote in the meeting where someone proposes blocking everything.

The concrete editorial instruction: decide grounding per section, not per site. Reference pages, definitions, comparison tables and how-to steps are the formats that earn citations, and they are the ones where Allow buys you something. Original reporting, proprietary benchmarks, licensed data and anything your commercial team sells access to are the candidates for DisallowExtended or Disallow. Hand engineering a list of templates, not a single instruction.

If your pages still emit NoArchive or NoCache, you have a 1 March 2027 deadline

Microsoft is retiring NoArchive and NoCache as training and grounding preferences, and the transition has four dates. On 15 December 2026, temporary grounding transition preferences open in Bing Webmaster Tools — available only to sites using NoArchive or NoCache as of that date. On 1 February 2027 the new preferences begin to be honored as Bing crawls. 1 March 2027 is the deadline to keep existing restrictions. Any temporary preference expires on 30 September 2027.

The detail that turns this from housekeeping into a risk: both preferences default to Allow. Microsoft states that if you do not record a temporary grounding preference by 1 March, pages using NoArchive or NoCache default to Allow for grounding until Bing recrawls them and finds a new preference. Inaction does not preserve your current restriction — it reverses it.

There is a second trap for anyone used to thinking in publish-and-done terms. Microsoft notes that publishing a setting is not the same as activating it: Bing must crawl the page to discover it, and IndexNow can raise the chance of a recrawl but cannot guarantee a date. For a large archive, "we updated the template" and "our preference is in force" are months apart.

Your action this week is an inventory, not a change: list every template and section that currently sets NoArchive or NoCache, and who owns the decision for each. Microsoft's FAQ documents the settings and the transition safeguards.

Allowing Google-Extended is now an explicit lever on Gemini Apps citations

Two sentences in Google's post couple the shared signal to Gemini visibility. First: when a site uses the policy token to opt out of training and Google-Extended is not explicitly specified, Google plans to interpret that as if the publisher had disallowed Google-Extended. Second: websites that specifically allow Google-Extended "are eligible to appear in responses and receive clicks via grounding in Gemini Apps."

Read together, a broad training opt-out quietly removes Gemini Apps grounding eligibility unless you also say yes to Google-Extended on purpose. Google is explicit that company-specific controls keep working alongside the shared signal, so the combination is available — but it has to be deliberate. The default outcome of a one-line opt-out is that you lose a citation surface you may not have meant to give up.

Keep the crawler boundaries straight when this comes up, because they are easy to blur. Googlebot covers Search, including AI Overviews and AI Mode; Google-Extended is the separate control for Gemini training and grounding. Blocking Google-Extended does not remove you from Search or from AI Overviews. If someone in the room says "let's block Google's AI," ask which of the two they mean, because the answers have opposite consequences for traffic.

Rank movement on 29–30 October is unconfirmed — do not rewrite against it

Labelled unconfirmed: tracker chatter reported two bursts of ranking volatility this week. Against that, the primary record is quiet. Google's Search Status Dashboard shows no new ranking event in the audit window; its most recent ranking entry remains the September 2026 spam update, which began on 24 September 2026. Google's documentation changelog records nothing newer than 26 October.

The editorial instruction is restraint. Volatility without a confirmed update is not a brief. Log the movement by query cluster and landing page, wait for confirmation, and resist the request for "recovery content" that follows a bad week in a rank tracker. Rewriting a page that was fine, against an update that may not exist, is how a stable section becomes an unstable one.

Quiet surfaces, for the record: no core or spam update started or completed in the window, and no rich result type was added, restricted or deprecated.

Apply to your next brief

• Add an "AI usage" line to the brief template: training allowed or not, grounding allowed / Microsoft-only / not, decided per section rather than inherited from the site.
• Flag any brief covering original data, first-hand testing or proprietary benchmarks as a grounding decision for an editor, not a default Allow.
• Keep writing the formats that get quoted — tight definitions, comparison tables, direct answers near the top — for every section where you chose to allow grounding.
• Do not pair a broad AI training opt-out with an assumption that Gemini citations survive it; that needs an explicit Google-Extended allow.
• Hand engineering a list of templates that still emit NoArchive or NoCache, with an owner per template, before 15 December 2026.
• Hold all rewrites attributed to this week's volatility until Google confirms an update; log affected clusters instead.

2. SEO for Developers

The most consequential engineering change today is a patch, not an announcement: CVE-2026-119200 lets a dot-segment request render a Nuxt page while Nitro's route rules and server middleware never run, which means canonical redirects and security headers silently do not apply to a URL that still renders and can be indexed. Patch to 4.6.3. Everything else today is preparation for 2027 enforcement dates.

Nuxt 4.6.x: dot-segment requests skip route-rule redirects and headers — upgrade to 4.6.3

Identifier and date: CVE-2026-119200 / GHSA-9v7c-q64q-vv33, Moderate, CVSS v3.1 base score 6.5, published to the GitHub Advisory Database on 30 October 2026 (advisory 27 October, NVD 29 October). Affected: the npm packages nuxt and @nuxt/nitro-server from 4.6.0 up to but excluding 4.6.3. Patched in 4.6.3. Breaking if ignored.

Mechanism: starting in Nuxt 4.6.0 the framework resolves "." and ".." segments — including percent-encoded forms such as %2e — before rendering a page, while Nitro's routing, route rules and server/middleware still see the unresolved path. A request for /%2e/admin therefore renders the /admin page, and every server-side check keyed on /admin is skipped.

The exact symptom for a search surface, which is why this is in an SEO note rather than only a security feed: route rules for redirect and headers do not fire. A canonical-enforcing redirect does not happen, so you get a renderable duplicate of the page at a URL your redirect layer believes it owns, and response headers you rely on — Content-Security-Policy, or an X-Robots-Tag that was supposed to keep a route out of the index — are absent on that duplicate. Handlers in server/api and server/routes are unaffected, and Nuxt 3.x and 4.0.0 through 4.5.x return 404 for these requests.

Fix the version. If you cannot upgrade immediately, the advisory's workarounds are an early server middleware that rejects dot segments, or a reverse proxy or CDN that normalizes paths before forwarding — and it warns that checking getRequestURL(event).pathname is not sufficient, because that leaves percent-encoding intact. Three further advisories landed for Nuxt on the same day (CVE-2026-119198, CVE-2026-119199 and CVE-2026-119201), but all three are development-server exposures rather than production paths.

# CVE-2026-119200 — patched in Nuxt 4.6.3
npm install nuxt@^4.6.3

# Verify: a dot-segment request must 404, not render the page.
# 200 here means you are still vulnerable.
curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/%2e/admin'

# Confirm the resolved versions of both affected packages
npm ls nuxt @nuxt/nitro-server

The shared AI training token is its own robots.txt group — and `User-agent: *` does not match it

Identifier and date: draft-kelley-aipref-training-preference-signal-00, "Machine-Readable Training Preference Signal," by Kevin Kelley of Anthropic, published 30 October 2026 and expiring 3 May 2027. Status to be precise about: this is an individual Internet-Draft intended for the Standards Track, not endorsed by the IETF and with no formal standing in the IETF standards process. Non-breaking today.

The token is __usage_ai-training, and it goes in the User-agent line of an ordinary robots.txt group. The draft deliberately adds no new directives and no new grammar, so RFC 9309 path matching and precedence apply unchanged. Two properties are easy to get wrong: a wildcard User-agent: * group does not match the token, and the preference is independent of any rule written for a crawler's own product token.

The second trap is semantic. The token sits where a crawler name normally sits, but Disallow under it expresses a usage preference, not crawl access. Microsoft states the point directly: these settings govern use of content, not crawl access, and an Allow setting does not override a robots.txt rule that blocks Bingbot from crawling. Blocking the crawler and declining the use are still two separate edits.

The file to change is public/robots.txt — or, if you generate it, app/robots.ts. Symptom if ignored: nothing in 2026, and then from February 2027 your training preference is expressed only to the providers you happened to name individually.

# 1. Crawl access — unchanged, and separate from usage preferences
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

# 2. Shared AI training preference (draft-kelley-aipref-training-preference-signal-00).
#    Honored by Microsoft from 2027-02-01; Google aims to support during 2027.
#    NOTE: a `User-agent: *` group does NOT match this token.
User-agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

# 3. Provider-specific controls still work alongside the shared signal.
#    Without this explicit Allow, Google plans to read the opt-out above
#    as a Google-Extended disallow, which also drops Gemini Apps grounding.
User-agent: Google-Extended
Allow: /

Bing's page-level preferences are a meta tag and an X-Robots-Tag — grounding has no robots.txt form

Date and rollout: announced 30 October 2026, honored as Microsoft crawls from 1 February 2027, with NoArchive and NoCache no longer read as training or grounding preferences after 1 March 2027. Breaking for any site that relies on NoArchive or NoCache today, because the replacement default is Allow.

AI Training can be set site-wide or per path in robots.txt, and Microsoft extends the same preference to the page level, where the page-level setting overrides robots.txt. AI Grounding is page-level only; there is no site-wide robots.txt grounding preference. Both are expressed against the Bingbot token, either as a meta tag or as an X-Robots-Tag response header:

• <meta name="Bingbot" content="ai-training:disallow"> or X-Robots-Tag: Bingbot: ai-training:disallow
• <meta name="Bingbot" content="ai-grounding:disallow">, or ai-grounding:disallowextended for the Microsoft-only middle option

Where to change it depends on how granular your decision is. A per-section rule belongs in your header layer, which on Next.js means the headers() block in next.config.ts; a per-page rule belongs in the page's own metadata. Note that Next.js has no first-class field for a vendor-prefixed directive like this, so it goes through the other key of the metadata object or through a header.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  async headers() {
    return [
      {
        // Premium research: decline training and third-party grounding,
        // but stay eligible for Bing results and Microsoft-operated AI.
        source: '/research/:path*',
        headers: [
          {
            key: 'X-Robots-Tag',
            value: 'Bingbot: ai-training:disallow',
          },
          {
            key: 'X-Robots-Tag',
            value: 'Bingbot: ai-grounding:disallowextended',
          },
        ],
      },
    ]
  },
}

export default nextConfig

Cloudflare: an emergency rule for Nuxt Image / IPX, and two bot-facing defaults moved

Three entries dated 30 October 2026 matter here. The emergency WAF release adds a Cloudflare Managed Ruleset rule, "Nuxt Image / IPX - Explicit GIF or Animation Modifier Exposure," which is disabled by default and offers only partial coverage; Cloudflare's own guidance is to follow the advisory and patch to the latest version rather than rely on the rule.

The change most likely to break an assumption is Workers subrequests preserving context for BYOIP destinations. Bot Management fields on the destination zone — bot score, verified bot status, JA3/JA4 fingerprints — now reflect the original end-user connection instead of the internal Cloudflare connection, and cross-zone subrequests set CF-Connecting-IP to a fixed Cloudflare address. If you allow or rate-limit crawlers by bot score or verified-bot status behind a Workers subrequest, that logic was reading the wrong connection and is now reading the right one. The values will move; re-check the rules before concluding a crawler changed behavior.

Separately, Browser Run now runs Chrome 152, moving the default Quick Actions User-Agent from Chrome 119; update any allowlist that matched the old string. Treat all three as a prompt to confirm the edge is not quietly overriding robots.txt intent, and to re-run reverse-DNS verification against your logs per Google's verification guidance rather than trusting a user-agent string — a point Gary Illyes reinforced this week in noting that bot impersonation has gotten worse.

#!/usr/bin/env bash
# Confirm a claimed Googlebot hit is really Googlebot: forward-confirmed reverse DNS.
# A user-agent string proves nothing on its own.
set -euo pipefail

IP="${1:?usage: verify-googlebot.sh <ip>}"

HOST="$(dig +short -x "$IP" | sed 's/\.$//')"
if [[ -z "$HOST" ]]; then
  echo "FAIL $IP — no PTR record"; exit 1
fi

case "$HOST" in
  *.googlebot.com|*.google.com|*.googleusercontent.com) ;;
  *) echo "FAIL $IP — PTR $HOST is not a Google domain"; exit 1 ;;
esac

# Forward-confirm: the hostname must resolve back to the same IP.
if dig +short "$HOST" | grep -qx "$IP"; then
  echo "OK   $IP — $HOST"
else
  echo "FAIL $IP — $HOST does not forward-resolve to $IP"; exit 1
fi

Next.js canary preserves revalidation for metadata prerenders

Version and date: v16.5.0-canary.32, published 29 October 2026 as a pre-release. The relevant entry is #100861, "fix(adapter): preserve revalidation for metadata prerenders." The same canary also fixes hangs and crashes for 204 responses from route handlers and deduplicated fetches (#100159). Non-breaking, and canary-channel only — this did not reach a stable release inside the audit window.

Symptom if ignored: on adapter-based deployments, prerendered output from generateMetadata could keep serving past its revalidate window, so a corrected title, description or canonical stays stale after the content behind it has already updated. That is the kind of defect you discover in a rank tracker rather than in a build log, because the page looks right when you fetch it and wrong in the index.

Action: watch, not ship. Do not put a canary into production for this; pin your current minor, add a test that asserts metadata actually changes after the revalidate window, and re-check when the fix lands in a stable 16.5 release.

export const revalidate = 3600 // the window the canary fix keeps honest

export async function generateMetadata(
  { params }: { params: Promise<{ slug: string }> }
) {
  const { slug } = await params
  const post = await getPost(slug)

  return {
    title: post.seoTitle,
    description: post.metaDescription,
    alternates: { canonical: `https://example.com/blog/${post.slug}` },
    other: {
      // No first-class field for a vendor-prefixed directive; use `other`.
      'Bingbot': 'ai-grounding:disallowextended',
    },
  }
}

Vercel merged Data Cache into Runtime Cache

Dated 30 October 2026: Data Cache is exiting beta and merging into Runtime Cache, which Vercel describes as bringing faster performance under load, 8–10x more cache storage per project, and deeper observability. Announced as a move rather than a breaking change.

The setting to change is none; the thing to change is where you look. Any runbook, dashboard link or incident playbook that names Data Cache when diagnosing stale ISR output or an unexpected revalidation now points at the wrong surface. Given the metadata-revalidation fix above is still in canary, the cache layer is exactly where you would go to confirm whether a stale title is a framework bug or a cache hit — so it is worth updating those references before you need them.

Ship today

1. Upgrade nuxt and @nuxt/nitro-server to 4.6.3, then assert that a /%2e/ request returns 404 rather than rendering. This is the only item here with an exploit path and a patch available now.
2. Audit for dot-segment duplicates that may already be indexed, and confirm route-rule redirects and security headers apply on the paths you thought they covered.
3. Inventory every template emitting NoArchive or NoCache and attach an owner to each, ahead of the 15 December 2026 Bing Webmaster Tools window.
4. Re-check any edge rule that allows or limits crawlers by bot score or verified-bot status behind a Workers subrequest, and update allowlists matching the old Browser Run user agent.
5. Add a robots.txt regression test that asserts the __usage_ai-training group exists as its own group, is not merged into User-agent: *, and that Google-Extended is set deliberately.
6. Update runbooks that reference Vercel Data Cache to point at Runtime Cache.

Watch, do not ship: the shared training token itself has no enforcement before 2027, and the Next.js metadata fix is canary-only. Quiet surfaces in the window, for the record: no Chrome stable release, no Lighthouse release (13.6.0 remains the latest, from 27 October), no schema.org release (30.1, from 16 September), no change to Core Web Vitals thresholds, and nothing newer than 26 October in Google's documentation changelog.

One unconfirmed item, excluded from the lists above and flagged as such: community reports describe Gemini dropping the utm_source=gemini parameter it had been attaching to cited URLs. The tagging was never documented by Google, so there is no primary source to confirm a change either way. If you built AI-referral reporting on that parameter, verify against your own logs before trusting the dashboard.