Daily SEO Note — August 4, 2026: Next.js 16.3 Ships Stable, Clarity Splits Branded AI Queries

Window covered: 24 hours to 2026-08-04 09:00 UTC. Two verified changes, one per track. Google's ranking, spam, and Discover systems produced nothing in the window, so neither section leads with an algorithm story.

1. SEO for Content Writers

The most consequential editorial change today is a measurement change, not a ranking one. Microsoft Clarity's Citations dashboard now separates branded from non-branded grounding queries, which retires the habit of reporting "AI visibility" as a single number. The two halves answer different questions — whether AI systems reach for you because someone already named you, or because you were the best available source on a generic topic — and only the second one is evidence that your content is winning discovery.

Clarity now labels which AI queries named your brand

What changed: the Citations dashboard marks individual grounding queries as branded, breaks the Share of Authority card out by branded and non-branded, and lets you filter every view in the dashboard by either type. Microsoft published it on its Clarity blog on August 3, 2026, generally available rather than preview.

Who it affects: all content, but the split matters most to teams with an established brand name, where aggregate citation counts were quietly flattering. If a large share of your citations come from queries that already contain your brand, your measured AI visibility was partly a readout of existing demand.

What to do differently in the next article: pull the non-branded view first and treat it as your topic-coverage scorecard. The grounding queries listed there are the phrasings AI systems actually used to retrieve content — not what users typed — so they are the closest thing available to a brief written by the retrieval layer. Where a non-branded grounding query has no cited page of yours, that is a commissioning decision, not an optimisation one.

What to stop doing: stop reporting one blended citation count as an AI visibility KPI, and stop reading a rise in it as proof that new readers are finding you. Rollout status: shipped and live.

Share of Authority is now two numbers, and neither is a market share

The new breakdown is only useful if the metric's definition is understood, and it is easy to misread. Clarity's documentation states that Share of Authority is calculated at a daily level, counting only days on which your domain was cited for a given query; days where you were absent are excluded from the denominator. Microsoft says plainly that this "may lead to higher Share of authority values compared to broader calculations."

Who it affects: anyone reporting the number upward. It measures how strongly you feature when you feature at all — participation quality, not coverage. A domain cited on three queries out of a thousand can post a high Share of Authority.

What to do differently: report Share of Authority alongside the count of distinct grounding queries you appear on at all, and keep the branded and non-branded figures on separate lines. A branded Share of Authority near the ceiling is close to a tautology; a non-branded one that climbs while your query coverage widens is the signal worth acting on.

Google's editorial surfaces: nothing verified in the window

No ranking, spam, or Discover update started or completed in the last 24 hours — the Search Status Dashboard reports no incidents, the ranking updates history still ends at the June 2026 spam update completed on June 26, and the documentation changelog has no August entries, its most recent being July 29. Guidance for AI Overviews and AI Mode is unchanged since its 2025-12-10 revision.

Apply to your next brief

• Split every AI-visibility report into branded and non-branded before it leaves the team; never send the blended figure.
• Mine the non-branded grounding queries for commissioning gaps — each uncovered query is a candidate brief, phrased the way the retrieval layer phrases it.
• Pair Share of Authority with distinct-query coverage in the same table, so a high score on a narrow footprint cannot read as dominance.
• Leave titles, headings, and structured guidance unchanged today; no Google-side requirement moved, so there is nothing to retrofit.
• Re-baseline your AI reporting from August 3 forward — comparisons across the split are not like-for-like with anything logged before it.

2. SEO for Developers

The engineering story is a status change this note has been tracking for days: Next.js 16.3.0 shipped stable on August 3, 2026 at 21:03 UTC. The canary-only fixes covered on August 1 and August 3 — the not-found and adapter work — are now in a release you can actually deploy, and the stable cut adds two changes that touch crawling directly.

Next.js 16.3.0 is stable, so the not-found fixes are shippable

Version and date: v16.3.0, published 2026-08-03T21:03Z on the stable channel. Non-breaking as an upgrade from 16.2.x. The symptom if ignored is the one this note flagged on August 3: not-found routes served behind an adapter could return 200 instead of 404, which Google treats as a soft 404 and drops from the index. Previous guidance here was to verify status codes and wait for the stable cut — the stable cut has arrived, so that hold is lifted.

# Upgrade the 16.2 line to the 16.3.0 stable release
npx @next/codemod upgrade minor

# Then assert real status codes against the deployed origin, not dev
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/definitely-not-a-real-page
# expected: 404

robots.ts can finally emit non-standard directives per user agent

Version and date: added in v16.3.0 (PR #93206), documented in the robots.txt file-convention reference with a version-history row reading "Added other field for non-standard per-agent directives." Non-breaking and additive.

The symptom if ignored: before this, a generated robots.ts could express only allow, disallow, crawlDelay, sitemap, and host. Anything outside the standard — Seznam's Request-Rate, Yandex's Clean-param — had to be hand-maintained in a static public/robots.txt, which meant teams running a generated robots file silently dropped those directives. Keys preserve their casing, array values emit one line each, and everything is scoped to that rule's User-agent block. Next.js passes values through verbatim and validates nothing, so a typo ships as a live directive.

import type { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: [
      { userAgent: '*', allow: '/' },
      {
        userAgent: 'SeznamBot',
        allow: '/',
        other: {
          'Request-Rate': '10/1m',
        },
      },
    ],
    sitemap: 'https://example.com/sitemap.xml',
  }
}

// Emits, scoped to the SeznamBot block:
//   User-Agent: SeznamBot
//   Allow: /
//   Request-Rate: 10/1m

The edge runtime is deprecated, which closes the middleware migration

Version and date: "Deprecate edge runtime" (PR #93369) in v16.3.0. Not breaking in this release — it is a deprecation — but it removes the last reason to stay on the old convention. Middleware was already deprecated in favour of proxy, and proxy runs on Node only; the edge runtime was the documented reason to keep a middleware file. With the runtime itself deprecated, that exemption is on a clock.

The symptom if ignored: deprecation warnings now, and a removal in a future major that will take any edge-runtime middleware with it. For SEO specifically, middleware and proxy are where redirects, canonical rewrites, and locale routing usually live, so this is the layer where a silent breakage turns into redirect chains or hreflang drift. The codemods reference documents the transform, which also renames the four related config properties.

# Renames middleware.ts -> proxy.ts, the named export, and the config keys
# (middlewarePrefetch, middlewareClientMaxBodySize,
#  externalMiddlewareRewritesResolve, skipMiddlewareUrlNormalize)
npx @next/codemod@latest middleware-to-proxy .

# Dry-run first if redirects or locale routing run through this file
npx @next/codemod@latest middleware-to-proxy . --dry --print

Static metadata under dynamic segments now prerenders to the canonical pathname

Version and date: "Prerender static metadata under dynamic segments to canonical pathname" (PR #93873) in v16.3.0, listed as a core change rather than a breaking one. Two related routing entries shipped alongside it — "Normalize encoded dynamic placeholders in app routes" (#91603) and "Handle encoded params further" (#91627).

Why it matters: metadata rendered under a dynamic segment is where self-referencing canonicals are emitted, and a placeholder or percent-encoded path leaking into that output produces a canonical pointing at a URL that is not the served one. Treat this as a fix worth verifying rather than assuming: after upgrading, inspect the rendered canonical on a dynamic route whose params contain encoded characters, and confirm it matches the served path exactly. This item is sourced to the release-note entries; the exact prior-behaviour symptom is not spelled out in the notes.

Content-Length and ETag return for Pages Router data responses

Version and date: "restore Content-Length and ETag for /_next/data/ JSON responses" (PR #90304) in v16.3.0, filed as a bug fix. Pages Router only. Missing ETag and Content-Length on those responses cost conditional-request revalidation and made CDN caching less effective on the data payloads behind client-side navigation. Non-breaking, and it lands without configuration.

Quiet across the rest of the stack

No movement worth a pull request elsewhere in the window. Schema.org is still on version 30.0 from 2026-03-19. Lighthouse is still on v13.4.1 from July 20, 2026, expected in Chrome 152 DevTools. Cloudflare's and Vercel's August 3 changelog entries — an agent runtime preview, Python/JavaScript Workers RPC, WAF for Blob going GA — carry no crawling, caching, or rendering consequence.

Ship today

1. Upgrade the 16.2 line to 16.3.0 stable, then assert a real 404 against the deployed origin rather than dev.
2. Diff your generated robots output before and after the upgrade; confirm nothing shifted scope between User-agent blocks.
3. Run the middleware-to-proxy codemod with --dry first if redirects, canonical rewrites, or locale routing pass through that file.
4. Inspect the rendered canonical on one dynamic route with encoded params and confirm it matches the served path.
5. Add a CI assertion for robots.txt reachability and 404 status codes, so the next framework upgrade cannot regress either silently.