Daily SEO Note — August 16, 2026: web-vitals 6.1.1 Fixes Silent INP Data Loss

1. SEO for Content Writers

The most consequential editorial change today is a sentence in OpenAI's own documentation, not a Google announcement. OpenAI states that because ChatGPT-User fetches are initiated by a person asking a question, robots.txt rules may not apply to them. That one line decides whether the file your team treats as the on/off switch for AI visibility actually governs the bot most likely to read your page aloud to a reader in real time. Google's ranking, indexing and serving surfaces logged nothing at all in the window.

Robots.txt is not the switch you think it is for ChatGPT

OpenAI's crawler documentation separates three bots and gives each a different robots.txt story. For OAI-SearchBot, the search index crawler, it recommends allowing it so your site appears in results. For GPTBot, the training crawler, it says a Disallow "indicates a site's content should not be used in training generative AI foundation models." For ChatGPT-User — the fetcher that opens your page when a reader asks ChatGPT about it — the documentation says: "Because these actions are initiated by a user, robots.txt rules may not apply." Rollout status: documented and live, verified against the page today. OpenAI publishes no revision date on it, and the wording was surfaced widely on August 14, 2026.

Who it affects: all content, and it cuts in both directions. If you disallowed AI crawlers to keep your work out of chat answers, that block may never have covered the path that matters most — the live fetch triggered by someone already asking about your topic. If you allowed them hoping to be quoted, the same fact is good news. Either way, the decision you thought you made in a text file was only ever a decision about two of the three bots.

What to do differently in the next brief: write on the assumption that anything you publish can be read into a live answer, and put the answer where a model quoting to a reader will actually find it. A definition in the first two sentences under the heading that asks the question. A comparison as a real table rather than as prose. A number sitting next to the date you measured it. What to stop doing: stop treating robots.txt as an editorial gate, and stop telling stakeholders that a Disallow line keeps content out of AI answers. It is a crawler instruction, not a privacy control, and for the user-triggered case OpenAI's own documentation declines to promise otherwise.

Google, Bing and the ranking surfaces published nothing

No verified Google editorial change in the window. The Search Central blog has published nothing newer than July 2026, the documentation changelog has had no entry since July 29, 2026, and the Search Status Dashboard reported Crawling, Indexing, Ranking and Serving all available with no incidents as of its August 15, 23:03 PDT refresh. The Bing Webmaster Blog has not posted since February 10, 2026. No core update, no spam update, no snippet or rich result change to act on.

Unconfirmed: an AI Mode model change with no primary source

Trade coverage on August 14, 2026 reported that Gemini 3.7 Flash became selectable in AI Mode for Google AI Pro and Ultra subscribers in English, sourced to a post on X by a Google Search product lead rather than to any Google publication. We found no Search Central post, no blog.google entry, and no help-centre page documenting the model picker. Labeled unconfirmed and deliberately kept out of the checklist below. Even if accurate, a model swap inside AI Mode carries no documented editorial lever: Google's AI features documentation, last updated 2025-12-10, still states there are "no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary."

Apply to your next brief

• Stop describing robots.txt as the control that keeps content out of AI answers. For user-triggered fetches, OpenAI documents that it may not apply.
• Assume every published page is quotable in a live answer. Write the first two sentences under each heading as a standalone answer to that heading.
• Put comparisons in real tables and set every number next to the date it was measured — those are the formats that survive extraction into an answer.
• Route any "block us from AI" request to engineering as an edge-enforcement task, not as a robots.txt edit. The file only settles the training and search decisions.
• Change nothing in titles, meta descriptions, or structured data today. Google published no SERP appearance or rich result change in this window.
• Do not brief against the AI Mode model report until Google documents it somewhere citable.

2. SEO for Developers

web-vitals 6.1.1 shipped at 07:19 UTC on August 15, 2026 and fixes a silent measurement failure: several onINP() calls on one page shared a single interaction counter, so with soft-navigation reporting enabled all but one of them could report nothing at all. If your INP field data looks implausibly clean, this is a live candidate cause. Everything else in the window is quieter — a Next.js canary refactor of the metadata pipeline, and no advisories touching SEO packages.

web-vitals 6.1.1 stops multiple onINP() instances from erasing each other

Version and date: web-vitals v6.1.1, tag created 07:19 UTC and published to npm at 07:20:52 UTC on August 15, 2026. The changelog entry is a single line — "Scope the navigation interaction count to each InteractionManager (#783)" — and the rollout status is stable, on npm now, a patch off 6.1.0 from August 5.

Non-breaking as an upgrade, but the bug it fixes is the worst kind, because it loses data without erroring. Per pull request #783, initUnique() gives every onINP() call its own manager, yet prevInteractionCount lived in shared module state — so "several instances on a page shared one counter." With reportSoftNavs enabled, whichever instance processed a soft-navigation entry first reset that counter, and the others reported no INP at all. The symptom if ignored: your RUM returns fewer INP samples than page views and misses exactly the fast soft navigations the library was extended to capture, which biases your field data toward looking better than the page actually is.

The setting to change is the dependency version in package.json, plus wherever you initialise the library. You are most exposed if you call onINP() yourself alongside a vendor RUM snippet that also calls it — two instances on one page is precisely the broken case, and neither vendor will report an error when it happens.

// web-vitals 6.1.1 (published 2026-08-15T07:20Z) scopes the interaction counter
// to each InteractionManager. Before this patch, every onINP() call on a page
// shared one prevInteractionCount. With reportSoftNavs on, whichever instance
// handled a soft-navigation entry first reset that counter and the others
// reported no INP at all -- no error, no warning, just missing samples.
//
//   npm install [email protected]
//
import { onINP, onLCP, onCLS } from 'web-vitals'

type Metric = { name: string; value: number; id: string; navigationType: string }

function send(metric: Metric): void {
  // sendBeacon survives the unload that INP reporting usually races.
  navigator.sendBeacon('/rum', JSON.stringify(metric))
}

// Soft-navigation reporting is the configuration that exposed the bug.
// On 6.1.0 and earlier, a second onINP() anywhere on the page -- including one
// inside a third-party RUM snippet -- could silence this one.
onINP(send, { reportAllChanges: true, reportSoftNavs: true })
onLCP(send, { reportSoftNavs: true })
onCLS(send, { reportSoftNavs: true })

Enforce AI-fetcher policy at the edge, because robots.txt does not cover the user-triggered case

Identifier and date: no version number — this is OpenAI's standing documented behaviour, verified live today against developers.openai.com/api/docs/bots and widely surfaced on August 14, 2026. The page carries no revision date, so treat it as current policy rather than as a dated change. It earns a slot because the engineering consequence is concrete even where the publication date is not.

Non-breaking, but it invalidates a control you may believe you already have. The documentation says of ChatGPT-User: "Because these actions are initiated by a user, robots.txt rules may not apply." The symptom if ignored is a compliance gap rather than a crawl error — you report that content is excluded from AI answers on the strength of a Disallow line OpenAI does not commit to honouring for this fetcher, and nothing in your logs contradicts you. Note the asymmetry: OAI-SearchBot and GPTBot are both documented as robots.txt-governed, so those two decisions genuinely do belong in the file.

Files to change: public/robots.txt for the two bots it does govern, and your WAF or edge rules for ChatGPT-User — matched by verified IP range from openai.com/chatgpt-user.json rather than by user-agent string, which is trivially spoofed. That file is unchanged since the 20:03 UTC August 14 regeneration, still 204 IPv4 prefixes. The same reverse-DNS-then-forward-confirm discipline Google documents for verifying Googlebot applies here. Keep the three decisions separate: training, search, and user-triggered are not one policy.

# public/robots.txt
#
# OpenAI documents three separate bots with three separate robots.txt stories.
# Treat them as three separate decisions -- training, search, user-triggered.

# Search index. OpenAI recommends allowing this one to appear in ChatGPT search.
User-agent: OAI-SearchBot
Allow: /

# Training. A Disallow here signals your content should not train foundation
# models. This bot IS documented as governed by robots.txt.
User-agent: GPTBot
Disallow: /

# Google's AI training / grounding control, same idea.
User-agent: Google-Extended
Disallow: /

# ChatGPT-User fetches your page when a reader asks about it in the moment.
# OpenAI's docs: "Because these actions are initiated by a user, robots.txt
# rules may not apply." Keep the line for the bots that honour it, but do NOT
# treat it as enforcement -- enforce at the edge, by verified IP range from
# https://openai.com/chatgpt-user.json, never by user-agent string.
User-agent: ChatGPT-User
Disallow: /private/

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

Next.js canary.20 continues the metadata pipeline rework — watch only

Version and date: v16.3.1-canary.20, published 23:52 UTC on August 15, 2026. The SEO-relevant change is pull request #97388, "Extract metadata resolution primitives," which moves the route-layer operations — wrapping generateMetadata and generateViewport, loading file-based metadata, merging values — into a dedicated module. Rollout status: canary only. Stable is still 16.3.1 from August 13.

Informational, no action today. The pull request states the change "is intended to be behavior preserving: traversal order, eager generator invocation, parent promise behavior, warnings, and rendered metadata and viewport tags are unchanged." What makes it worth logging is the pattern: this is the second consecutive canary touching this subsystem, after #97387 landed in canary.19 a day earlier. The layer that emits your canonical, hreflang and Open Graph tags is under active restructuring. Nothing in your generateMetadata implementations needs editing — the right move is to diff rendered head output on representative routes when this reaches stable, not to pre-empt it. Also in canary.20: PR #97321, a test-side fix for back-before-hydration recovery assertions, with no runtime behaviour change.

No advisories touching SEO packages, and no framework SEO releases

No verified advisory in the window. The GitHub Advisory Database lists nothing published August 15 or 16, 2026 affecting sitemap generators, SEO plugins, structured data libraries, or crawler dependencies. On the tooling side, npm publish timestamps confirm no movement: next-seo is still 7.3.0 (July 29), @nuxtjs/sitemap 8.3.4 (August 9), @astrojs/sitemap 3.7.3 (May 26), and schema-dts 2.0.0 (March 23). One standing flag rather than a change: next-sitemap has not shipped since 4.2.3 in September 2023, which is worth a look on its own if you still depend on it. Schema.org remains at version 30.0 from 2026-03-19, and neither Astro nor SvelteKit published a release in the window.

Ship today

1. Upgrade web-vitals to 6.1.1. It is a patch off 6.1.0 and it closes a silent INP data-loss path — npm install [email protected].
2. Grep for more than one onINP() call reaching a single page. Your own instrumentation plus a vendor RUM snippet is the exposed configuration.
3. Compare your INP sample count against page views. A ratio well below 1 on 6.1.0 or earlier is the fingerprint of this bug, not of a fast site.
4. If you run reportSoftNavs, re-baseline or discard INP field data collected on 6.1.0, since some instances may have reported nothing at all.
5. Move any "block ChatGPT" requirement out of robots.txt and into an edge rule matched by verified IP from openai.com/chatgpt-user.json. Leave robots.txt to govern GPTBot and OAI-SearchBot, which are documented as honouring it.
6. Stop matching AI fetchers by user-agent string alone at the WAF. Verify by published IP range, then forward-confirm.