Daily SEO Note — September 4, 2026: Google Confirms AI Mode Stopped Citing Sources

SEO for Content Writers

The one editorial change that matters today: Google confirmed that AI Mode has stopped linking to and citing sources on many queries, and said it is not intended. Nothing else on the ranking side moved. The Search Status Dashboard reported no incidents across Crawling, Indexing, Ranking and Serving as of 23:03 PDT on September 3, and the Search Central documentation changelog has been quiet since August 31.

Google Confirms AI Mode Stopped Citing Sources

Since Gemini 3.8 Flash took over AI Mode on September 2, users have been posting AI Mode answers that carry no links and no citations at all, concentrated on broad top-of-funnel queries. Gagan Ghotra posted screenshots on September 3, and Glenn Gabe followed with more. Robby Stein, VP of Product for Google Search, replied the same day: “Hey — thanks for flagging. This isn't working as intended, and we'll roll out a fix soon.” Rollout status as of 06:00 UTC on September 4: acknowledged bug, fix announced, not yet shipped.

This affects everyone who reports on AI visibility, not one vertical and not one content type. We noted the model swap itself yesterday; what changed today is that the citation drop now has a Google explanation attached to it. If your team tracks AI Mode citations or watches referral volume from AI surfaces, the decline you are looking at this week is a model regression, not a verdict on your content.

What to do differently in the next brief: freeze any editorial decision that was going to be justified by this week's AI citation data. Do not rewrite pages, restructure answer formats, or add and remove definition blocks and comparison tables on the theory that AI Mode changed what it quotes. Wait for the fix to land, then re-baseline against a clean week.

What to stop doing: treating a single week of AI Overviews or AI Mode citation counts as a stable metric at all. Google's guidance on AI features and your website still says there are no additional requirements or special optimizations for AI Overviews and AI Mode beyond ordinary Search fundamentals. That has not changed. Today is a reminder that the surface itself moves underneath the measurement.

Merchant Center AI Performance Insights Reaches Four More Markets

Google's AI performance insights report in Merchant Center has moved past its US-only pilot. The Merchant Center help page now reads: “AI performance insights are currently available for English-language queries for Merchant Center accounts in Australia, Canada, India, New Zealand, and the United States.” Search Engine Roundtable flagged the expansion on September 3; the help page is the source of record. Rollout status: live in five markets, English-language queries only.

This affects product and commerce content only. The report sits under Analytics, then Products, then the AI performance tab, and gives you share of voice against comparable brands, your competitors' average share, frequency, and which of your products are actually surfacing across AI experiences in Search and Gemini.

For editors in the four new markets, this is the first Google-supplied benchmark for whether your product content is being pulled into AI shopping answers, rather than an inference from traffic. Use it to order your rewrite queue: let share of voice pick which category and comparison pages get attention first. The English-only limit is the part to plan around — a Canadian French or Indian-language product page produces no data here, so keep those transcreation decisions resting on other evidence.

No Ranking or Spam Update Is Running

The Search Status Dashboard shows no active incident on any of the four services. The most recent confirmed ranking event remains the August 2026 spam update, which ran from August 18 to August 21 and finished two weeks ago. Rollout status: nothing in progress.

That matters because it removes an excuse. Any ranking movement you see this week is not attributable to a running Google update, which puts the cause back inside your own site — cannibalization between overlapping articles, pages that have decayed and need consolidating or pruning, or a technical regression on the engineering side. Check the dashboard before the words “algorithm update” go into a client report.

Unconfirmed: Content Dropping Out of the Google News Tab

Unconfirmed, and labelled as such. Publishers report that articles appear in the All tab of Google Search but are missing from the News tab, sometimes reappearing much later. Barry Schwartz documented cases across WSJ, Bloomberg and his own site on September 3 and described the pattern as random. He asked Google publicly and had received no response at the time of writing. There is no primary source and no Google statement, so this stays out of the checklist below.

If you publish news, the useful response is evidence-gathering rather than remediation. Record the URL, the timestamp, and what both tabs returned each time you see it. If Google does eventually confirm something, you will have dated examples instead of a recollection, and you will know whether your own publishing changes correlate with it.

Apply to Your Next Brief

• Do not justify any brief, title or outline change with this week's AI Mode citation data. The drop is a Google-confirmed bug with a fix pending.
• Re-baseline AI visibility reporting only after the fix ships, and annotate the gap in the report so nobody reads the dip as a content failure.
• Publishing products into Australia, Canada, India or New Zealand: pull the Merchant Center AI performance tab before your next category brief and let share of voice set the rewrite order.
• Do not build localization or transcreation plans on AI performance insights. It covers English-language queries only.
• Check the Search Status Dashboard before attributing any ranking movement this week to an update. Nothing is running.
• Publishing news: log dated All-tab versus News-tab examples instead of acting on the unconfirmed News tab reports.

SEO for Developers

One verified engineering change landed inside the window: Next.js moved its bundled web-vitals dependency to v6 on canary and began reporting soft navigations. The rest of the developer surfaces were quiet. The Cloudflare changelog has no entry dated September 3 or 4, no SvelteKit or Astro release fell inside the window, and the September 3 batch of reviewed GitHub security advisories touched no sitemap, metadata, crawler or SEO package — it was almost entirely siyuan/kernel, plus toml, phoenix and stream-json.

Next.js Canary Upgrades web-vitals to v6 and Reports Soft Navigations

Version and date: v16.4.0-canary.16, published 2026-09-03 at 23:47 UTC. The changelog line is “Upgrade web-vitals to v6 and report soft navigations” (#97232). It was the only Next.js canary published that day, and it has not reached a stable 16.4 release. Rollout status: canary only.

Non-breaking today, precisely because it is canary. The symptom if you ignore it arrives later: once this reaches stable, useReportWebVitals will fire metric events for client-side route changes that previously produced nothing, so any pipeline that counts one report per page view, or that dedupes on metric name alone, will start double-counting Core Web Vitals. Separately, web-vitals v6.0.0 (2026-07-21) flipped the includeProcessedEventEntries default to false, so INP attribution payloads you were storing will quietly stop carrying processed event entries unless you opt back in.

The file to change is your web-vitals reporting component. Key every report by metric.id, which is already unique per metric instance, and pass navigationType through to your endpoint so soft navigations can be bucketed separately downstream instead of contaminating your hard-navigation LCP and CLS distributions.

'use client'

import { useReportWebVitals } from 'next/web-vitals'

export function WebVitals() {
  useReportWebVitals((metric) => {
    // web-vitals v6 reports metrics for soft navigations as well as
    // hard navigations. Send navigationType through and bucket on it
    // downstream rather than assuming one report per page view.
    navigator.sendBeacon?.(
      '/api/vitals',
      JSON.stringify({
        id: metric.id, // unique per metric instance - dedupe on this
        name: metric.name,
        value: metric.value,
        rating: metric.rating,
        navigationType: metric.navigationType,
        path: window.location.pathname,
      }),
    )
  })

  return null
}

Action: watch rather than ship. Pin your Next.js version, but stage the reporting change now so the code is already correct on the day 16.4 goes stable and your Core Web Vitals dashboards do not step on a rake.

Re-Audit Your Four OpenAI Crawler Decisions

Housekeeping rather than a dated release, and worth stating plainly: platform.openai.com/docs/bots now returns a 301 to developers.openai.com/api/docs/bots, verified 2026-09-04. OpenAI publishes no dated changelog for that page, so this is not a claim that it changed inside the 24-hour window. It is a claim that the URL pinned in your runbook or quoted in a robots.txt comment is now the wrong one.

The page documents four separate agents, and they remain four separate decisions: GPTBot for model training, OAI-SearchBot for ChatGPT search results, ChatGPT-User for user-triggered fetches, and OAI-AdsBot for ad-safety validation. Conflating them is the expensive mistake. Blocking GPTBot to opt out of training while also blocking OAI-SearchBot removes you from ChatGPT search answers entirely — which is the engineering half of the citation-eligibility question the writers' section is arguing about. OpenAI also states that ChatGPT-User is not an automated crawl and that robots.txt rules may not apply to it, so do not treat a Disallow there as an enforcement boundary.

# Opt out of model training, stay eligible for ChatGPT search answers.
User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: OAI-AdsBot
Allow: /

# User-triggered fetch. OpenAI states robots.txt may not apply here.
User-agent: ChatGPT-User
Allow: /

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

Then verify the file your CDN actually serves rather than the one in your repository. Edge bot rules and WAF policies can answer a crawler before the origin's robots.txt is ever read, which silently overrides the intent you committed. Fetch it from outside your network with the crawler's own user agent string and diff it against the file in the repo; make that diff a scheduled check, not a one-off.

Ship Today

1. Stage the web-vitals reporting change in your Next.js app: dedupe on metric.id and pass navigationType to your analytics endpoint, so 16.4 stable cannot silently double your Core Web Vitals event volume.
2. Decide explicitly whether to re-enable includeProcessedEventEntries if you read INP attribution. web-vitals v6 turned it off by default.
3. Update every runbook, comment and doc that points at platform.openai.com/docs/bots to the developers.openai.com path.
4. Re-read robots.txt as four separate OpenAI decisions and confirm you are not blocking OAI-SearchBot as a side effect of blocking GPTBot.
5. Fetch your live robots.txt through the CDN with a crawler user agent, diff it against the committed file, and schedule that diff as a recurring check.