Daily SEO Note — November 3, 2026: Bing Splits AI Training From Grounding as Next.js Patches Seven Flaws

Window for this edition: the 24 hours to 06:00 UTC on November 3, 2026. Today is a Tuesday, so the weekend extension does not apply. Two items dated October 30 are carried with their real dates because their compliance deadlines are now live and this is the first edition of this series — nothing here has been published before. Every timestamp below is UTC unless a source states otherwise.

1. SEO for Content Writers

The most consequential editorial change this cycle is not a ranking shift — Google's Search Status Dashboard reported no incidents and no ranking update in flight when checked on November 2, 2026 at 22:06 PST. It is that Microsoft has formally separated permission to train on your content from permission to quote it in AI answers. For the first time a publisher can refuse model training and still be cited, which turns one all-or-nothing decision into two independent editorial choices.

Bing now treats AI training and AI grounding as two separate permissions

On October 30, 2026 Microsoft published new AI preferences for Bing that split two questions apart. "AI Training" governs whether your content may be used to train models. "AI Grounding" governs whether it may be used to help generate AI answers. Each is set independently, and each defaults to Allow when no preference is published. Grounding also has a middle setting, DisallowExtended, which permits Microsoft-operated experiences but excludes third-party grounding services such as Web IQ and the Foundry API.

This affects all content, but it matters most to publishers holding original research. The practical instruction for your next article is to answer the two questions separately rather than once. An evergreen definition or comparison page you want quoted in AI answers should keep grounding allowed. A proprietary benchmark, a survey you paid for, or first-hand testing you want to remain yours should disallow training while leaving grounding alone, so you still earn the citation without feeding the weights.

Stop treating NoArchive and NoCache as an AI opt-out. Microsoft's AI preferences documentation states the new preferences take effect as Bing recrawls from February 1, 2027, and that after March 1, 2027 NoArchive and NoCache are no longer read as training or grounding preferences. Pages that relied on them and have no recorded preference by that date default to Allow for grounding until Microsoft recrawls them. Rollout status: announced, not yet enforced.

Google will accept the same one-line opt-out, and says it costs you nothing in Search

Also on October 30, 2026, Google said on the Search Central blog that it intends to support a shared AI training control. Instead of maintaining a separate rule per AI company, a site will be able to state a training preference once in robots.txt. Google's own wording is that it "aims to support this new control along with other AI providers in 2027"; its crawler documentation puts this in early 2027. If a site opts out of training through the shared token and does not name Google-Extended explicitly, Google will treat Google-Extended as disallowed.

The line worth quoting to a nervous stakeholder is Google's: Google-Extended "does not impact a site's inclusion in Google Search nor is it used as a ranking signal." Google adds that sites allowing Google-Extended remain eligible to appear in Gemini Apps grounding responses and to receive clicks from them. So the editorial instruction is to stop writing briefs around a tradeoff that does not exist. Declining model training is not declining visibility, and the reflex to block everything costs citations in exchange for nothing.

Keep one caveat in the brief rather than the headline. The underlying IETF document is an individual Internet-Draft submitted by Kevin Kelley of Anthropic, at revision 00, dated October 30, 2026 and expiring May 3, 2027. It is marked Standards Track in intent but is explicitly not endorsed by the IETF, and Google notes the rest of the AIPREF vocabulary is still under multistakeholder discussion. Rollout status: announced by two engines, honored by neither yet.

No ranking update is in flight, so do not rewrite on the strength of chatter

Checked at 22:06 PST on November 2, 2026, the Search Status Dashboard listed no incidents across Crawling, Indexing, Ranking and Serving, with a clean timeline from October 26 to November 2. The most recent confirmed ranking update remains the September 2026 spam update, which finished rolling out on October 8, 2026. Google has not confirmed a core update since May 2026.

This affects all content and is the cheapest discipline on the list. October produced genuine volatility chatter and a steady supply of unconfirmed-update posts, none of which Google has acknowledged. The instruction for your next article is to date your evidence: if a page is scheduled for a rewrite, the justification should be a Search Console trend over a named period or a demonstrable content gap, not a forum thread. Stop attaching the phrase "after the recent update" to rewrites when no update has been confirmed. Rollout status: verified clean at time of writing.

Search Console's AI report still has no clicks or queries, and Google will not commit to them

On November 2, 2026 Gary Illyes responded on LinkedIn to a post relaying an expectation that clicks and queries were coming to Search Console's AI performance reporting. His reply, as collected by Search Engine Roundtable, was: "The team is super interested in giving more data, data that makes sense, but we don't have anything to announce yet." He did not say that clicks or queries are the data in question, and no announcement has followed.

This affects anyone who reports on performance in AI surfaces. The instruction is to write and report against the data that exists. Click and impression data remain available in the main Search Console performance reports, and the country filter there now accepts multiple selections at once, which makes genuine multi-market reporting easier. What you cannot do is attribute a click to an AI Overview or to AI Mode.

Stop promising AI Overview or AI Mode click-through rates in content performance decks, and remove them from reporting templates where a placeholder is already sitting. Where a stakeholder needs a read on AI visibility, use presence and citation tracking and label it as such rather than implying a traffic number. Rollout status: no announcement; informational only.

Unconfirmed: AI Overviews appearing in the right column on brand queries

This item is unconfirmed and is deliberately excluded from the checklist below. Beginning October 31, 2026, several practitioners reported on X that desktop searches for brand terms were showing an AI Overview in the right-hand column, in the slot a brand knowledge panel would normally occupy, with screenshots for brands including Zillow, Coca-Cola and Apple. The reports were collected on November 2, 2026. Google has made no statement, nothing appears in the Search Central documentation changelog, whose most recent entry is dated October 26, 2026, and the behavior has not been confirmed as a launch, a test, or a regional experiment.

Nothing structural should change in response to an unconfirmed layout test. What is worth doing regardless, because it pays off in every AI surface, is making sure your own brand and About pages are the cleanest, best-sourced, most quotable statement of what your organization is and does. If a model is going to narrate your brand in the slot where your knowledge panel used to be, the source material it draws on should be yours and should be unambiguous. Rollout status: unconfirmed community observation.

Apply to your next brief

• Split the AI question in two on every brief: may this page be used for model training, and may it be quoted in AI answers? Record both answers per content type, not per site.
• Flag any brief, template or runbook that relies on NoArchive or NoCache for AI exclusion as needing rework before March 1, 2027, when Bing stops reading them as AI preferences.
• Delete "block AI crawlers to protect rankings" from brief boilerplate. Google states Google-Extended is not a ranking signal and does not affect inclusion in Search.
• Do not justify a rewrite or a pruning decision with October's volatility chatter. The last confirmed ranking update completed October 8, 2026.
• Remove AI Overviews and AI Mode click-through metrics from reporting templates until Google ships them; report presence and citations instead, labelled as such.
• For proprietary data, surveys and first-hand testing, state the training and grounding decision in the brief itself so it is set before publication rather than retrofitted.

2. SEO for Developers

The single most consequential engineering change is a security release that had not yet shipped when this note closed: Next.js has a scheduled security release for Tuesday, November 3, 2026 covering seven medium-severity vulnerabilities, with advisories published alongside it. As of 06:00 UTC the newest release on the releases page was still v16.4.4 from November 2 at 16:41 UTC, so the actionable work today is preparing the upgrade window rather than running it. The larger change to carry into configuration is the robots.txt policy token that Google and Microsoft both committed to on October 30.

Next.js security release lands today: seven medium vulnerabilities, advisories on publish

Identifier and date: pre-announced October 27, 2026 for release on Tuesday, November 3, 2026. Breaking: no, this is a patch line. The symptom if ignored is seven unpatched medium-severity vulnerabilities whose impact and affected versions are not yet public — Vercel's stated practice is to publish the full advisories at release time, so you cannot assess exposure before then. For context on what a Next.js patch cycle can carry, the October 14, 2026 out-of-band release closed two Critical unauthenticated RCEs and one High denial of service.

What to change: nothing in a file yet. Put a watch on the vercel/next.js security advisories feed and the releases page, confirm which release lines you are on, and have the upgrade command ready so the patch can go out the same day it publishes rather than next sprint. If you run multiple apps, resolve the installed version per app now — a monorepo with a hoisted and a nested copy will not both be covered by one bump.

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

# What is actually installed, per workspace (not what package.json asks for)
npm ls next --all --depth=2 2>/dev/null | grep -E 'next@' || true

# Current published tags, so you can see the patch appear
npm view next dist-tags --json

# Once the November 3 advisories are out, upgrade the patch only:
#   npm install next@latest        # 16.x line
#   npm install next@15            # if you are still on the 15.x line
# Then redeploy and re-run the check above.

The robots.txt training token: User-Agent: __usage_ai-training

Identifier and date: draft-kelley-aipref-training-preference-signal-00, dated October 30, 2026. The token is "__usage_ai-training". It follows RFC 9309 product-token syntax — letters, underscore and hyphen — and is matched case-insensitively. Non-breaking: it introduces no new directives or grammar, so a robots.txt parser that does not know the token simply ignores the group. The symptom if ignored is not a problem today but a missed deadline later: Microsoft begins honoring the new preferences as it recrawls from February 1, 2027, and Google targets early 2027.

Two mistakes are easy to make here. A "User-Agent: *" group does not express a preference under this draft — the token has to be named in its own group, or share a group with other product tokens. And the token is not a crawling directive: it states a usage preference only, while your existing crawler-specific rules continue to control what gets fetched. Keep the AI preference groups separate from your Googlebot and Bingbot crawl rules in the same file.

# --- Crawl rules (unchanged: these control fetching) ---
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

# --- Usage preference: AI training (AIPREF shared token) ---
# Honored by Bing from 2027-02-01, Google from early 2027.
# NOT a crawl directive. "User-agent: *" does not express a preference.
User-agent: __usage_ai-training
Disallow: /research/
Disallow: /benchmarks/
Allow: /

# --- Vendor-specific control, still read alongside the token ---
# Omit this group entirely to let the shared token decide for Google.
User-agent: Google-Extended
Allow: /

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

Grounding has no robots.txt rule: set ai-grounding per page or per route

Identifier and date: Microsoft's AI preferences reference, October 30, 2026. There is no site-wide robots.txt preference for grounding — it is expressed only at page level, through a meta tag or an HTTP response header. The values are "ai-grounding:disallow" and "ai-grounding:disallowextended". Training can also be overridden per page with "ai-training:disallow", and a page-level training preference takes precedence over robots.txt for that page.

Two behaviors to encode in review rules. Setting a preference does not block crawling, and an Allow setting does not override a robots.txt rule that already blocks Bingbot — so an "allow grounding" header on a disallowed path achieves nothing. And because grounding is per page, the sustainable place to set it is your header configuration keyed by route, not a tag hand-added to templates, which is where this kind of directive drifts out of sync. The symptom if ignored: after March 1, 2027 any page still relying on NoArchive or NoCache falls back to Allow for grounding.

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  async headers() {
    return [
      {
        // Proprietary research: citable in AI answers, not training data.
        source: '/research/:path*',
        headers: [
          {
            key: 'X-Robots-Tag',
            value: 'Bingbot: ai-training:disallow',
          },
        ],
      },
      {
        // Licensed or syndicated text: keep it out of grounding entirely.
        source: '/syndicated/:path*',
        headers: [
          {
            key: 'X-Robots-Tag',
            value: 'Bingbot: ai-grounding:disallow',
          },
        ],
      },
      {
        // Middle setting: Microsoft's own surfaces only, no third-party
        // grounding services (Web IQ, Foundry API).
        source: '/premium/:path*',
        headers: [
          {
            key: 'X-Robots-Tag',
            value: 'Bingbot: ai-grounding:disallowextended',
          },
        ],
      },
    ]
  },
}

export default nextConfig

Next.js 16.4.4 is backports only, and swaps jsonwebtoken for fast-jwt

Identifier and date: v16.4.4, published November 2, 2026 at 16:41 UTC. The release notes state it is backporting bug fixes and explicitly does not include all pending features and changes on canary. Non-breaking. Seven items shipped, and two are worth reading closely if you render with Partial Prerendering or run a strict Content Security Policy.

The first is #100907, which emits the Turbopack shared-runtime bootstrap during the PPR resume so that it receives the CSP nonce. The symptom if ignored is inline bootstrap script being refused by a strict CSP on resumed PPR responses, which fails silently for a crawler fetching the HTML and can leave a page that renders for a user but not for a renderer. The second is #100885, replacing the jsonwebtoken dependency with fast-jwt — a dependency swap rather than a behavior change, but one worth noting if you pin transitive dependencies or run an allowlist in CI. Also present: #100866 reverts "Optimize strict module factory chunks", and #100619 reloads on missed Turbopack startup CSS updates.

Canary caching fixes name three stale-render bugs worth tracking

Identifier and date: v16.5.0-canary.37, November 2, 2026 at 23:49 UTC, on the Next.js releases page. Status: canary, not stable — this is a watch item, not a deployment. It carries three fixes that each describe a way cached HTML can go wrong underneath a crawler: #101037 fixes revalidation for caches with short stale times, #101035 makes the use of headersToExcludeInCacheKey consistent, and #100854 fixes navigations rerendering fully static ISR pages under next start. Earlier in the same window, canary.32 on October 29 included #100861, fixing an adapter so revalidation is preserved for metadata prerenders.

The symptom if these land in your stack unfixed is the quiet kind: a crawler served a stale ISR document after the content changed, or cache entries keyed inconsistently when an excluded header varies between requests, which can mean two users and one Googlebot each getting a different body from the same URL. There is no file to change today. What is worth doing is adding an assertion to CI that a known-revalidating route returns fresh content and the expected cache headers after a publish, so that a regression in this area is caught by your own pipeline rather than by a ranking drop.

Vercel adds vercel.toml, and starts blocking known-malicious npm packages at install

Two changes on November 2, 2026, both non-breaking. First, projects can now be configured with vercel.toml, supporting the same configuration properties as vercel.json while allowing comments and a flatter structure. The one hard constraint is that a project should use exactly one configuration file — vercel.toml, vercel.json or vercel.ts — so this is a migration to schedule deliberately, not a file to add alongside the one you have. For SEO-relevant config this is where your redirects, rewrites and headers live, and being able to comment a redirect with the ticket that caused it is a real maintenance gain on a file that accretes for years.

Second, Vercel now blocks known-malicious npm package versions before and during installation, checking supported lockfiles, including dependencies restored from build cache, and blocking affected downloads during install so malicious install scripts do not execute. It is on by default on all plans with no configuration required. The symptom is a failed deployment naming the offending package and version; the fix is to update the dependency to a safe version, update the lockfile and redeploy. This matters directly for the SEO supply chain, where sitemap, metadata and schema packages are small, numerous and rarely audited — so treat a block as a real finding rather than a flaky build, and do not retry the deploy to get around it.

# One config file per project: vercel.toml, vercel.json OR vercel.ts.
# Do not keep vercel.json alongside this file.
"$schema" = "https://openapi.vercel.sh/vercel.json"

# Consolidate a legacy URL, with the reason recorded inline -
# the comment support is the actual reason to migrate.
[[redirects]]
source = "/blog/old-seo-guide"       # retired 2026-11; see TICKET-4821
destination = "/blog/seo-guide"
permanent = true

[[rewrites]]
source = "/api/(.*)"
destination = { service = "backend" }

[[headers]]
source = "/research/:path*"

[[headers.headers]]
key = "X-Robots-Tag"
value = "Bingbot: ai-training:disallow"

Ship today

1. Put a watch on the Next.js security advisories and releases pages, confirm your installed version per app, and upgrade the moment the November 3 release publishes its seven advisories.
2. If you render with PPR behind a strict Content Security Policy, take v16.4.4 now for the nonce fix in #100907 rather than waiting for the security patch to carry it.
3. Add a __usage_ai-training group to public/robots.txt stating your intended training preference. It is inert until 2027 and costs nothing to land early.
4. Grep the codebase, CDN rules and CMS templates for NoArchive and NoCache, and open a ticket to replace them with ai-training and ai-grounding directives before March 1, 2027.
5. Move grounding preferences into route-keyed header configuration instead of page templates, and add a review rule that an allow preference on a Bingbot-disallowed path is a no-op.
6. Add a CI assertion that a known-revalidating route serves fresh content and the expected cache headers after a publish, ahead of the canary caching fixes reaching stable.
7. Schedule any vercel.toml migration for a quiet sprint, and verify only one project configuration file exists when you do it.