Daily SEO Note — October 6, 2026: Chrome 155 Ships While the Spam Update Runs Long

Audit window: 24 hours to 2026-10-06 09:00 UTC. Two tracks, two audiences, one rule — every item below traces to a primary source with a date and a rollout status. Industry blogs were used to detect stories, never to certify them. Where today produced nothing verifiable, that is stated in a line rather than padded.

1. SEO for Content Writers

The most consequential editorial fact today is not an announcement — it is a rollout that will not end. The September 2026 spam update has been live for twelve days with no completion timestamp on Google's own dashboard. The three spam updates before it finished in two to three days. If your traffic moved in the last fortnight, the ground is still moving underneath the measurement, and that changes what you should be doing with the data.

The September spam update is running four times longer than its predecessors

Google's Search Status Dashboard records the September 2026 spam update as beginning 2026-09-24 at 16:15 UTC and carries no end timestamp as of this morning. That is a twelve-day rollout against a stated expectation of up to two weeks. The comparison that matters is with the recent past: the August 2026 spam update ran three days, June ran two, and March closed in a single day.

Affects all content, with the sharpest exposure on sites that publish at volume or carry user-generated and syndicated material — the surfaces Google's spam policies name under scaled content abuse and site reputation abuse. A long rollout is not evidence of a larger update, but it does mean intermediate rankings are not a stable baseline.

Editorial instruction: freeze diagnosis, not publishing. Keep shipping planned work, and do not start rewriting or pruning pages on the strength of position changes recorded while an update has no end date. Snapshot your top fifty pages now so you have a clean before-and-after once Google marks the rollout complete.

Stop doing: attributing this fortnight's movement to anything you changed this fortnight. Rollout status: active, no completion timestamp (primary, 2026-09-24).

Google's generative-AI content guidance now speaks in Quality Rater language

On 1 October 2026 Google's documentation changelog logged an update to the using generative AI content guide, described as adding "information from the Search Quality Raters guidelines." This is a documentation change rather than a ranking launch, and it is more useful than that sounds.

Affects all content, and specifically any workflow where a model drafts and a human signs off. The significance is that the public guidance and the rater-facing vocabulary are converging: the language raters use to judge whether a page shows evidence of human effort, expertise, and originality is now the language you can read directly.

Editorial instruction: stop treating AI disclosure as the compliance question and make demonstrable added value the test. For every model-assisted piece, require at least one thing a model could not have produced — original testing, proprietary data, a named practitioner's judgment, or primary reporting — and make that element visible above the fold rather than buried in a closing section.

Stop doing: shipping competent model-drafted summaries of consensus information on the theory that a human edit pass makes them original. Rollout status: documentation live, 2026-10-01 (primary).

Google's own clocks for discovery, refresh, and recovery — reported from Barcelona, not published

At Search Central Live Deep Dive Europe in Barcelona on 2 October 2026, Gary Illyes presented internal timing tables for crawling, indexing, and serving. As reported by Search Engine Roundtable and corroborated across several independent recaps, the typical figures were roughly 20 hours for Google to discover a new URL, about 1.5 hours for end-to-end indexing once the pipeline runs, around 30 days to refresh a URL Google already knows, one to three months for a site move to settle, and three to six months to recover from a core update — with "never" appearing as the slowest case for quality-related situations.

Labelled unconfirmed as a citation: this is conference reporting, and Google has published no page carrying these numbers. It is excluded from the checklist below for that reason. It is included here because the refresh figure reframes a decision writers make weekly.

If roughly 30 days is the typical refresh interval for a known URL, then updating a page and expecting to see the effect inside a week is a measurement error, not an SEO failure. The practical read: batch your content refreshes and judge them on a monthly cadence, and reserve the expectation of fast re-evaluation for genuinely new URLs. Treat the three-to-six-month core-update recovery figure as a reason to commit to a remediation plan rather than abandoning it at week six.

VideoObject gains a creator property — video credits become a structured field

Google's changelog records that on 24 September 2026 the VideoObject documentation added the creator property, noting support for author, and updated interactionStatistic to document which interaction types are supported. Affects one content type: video, and publishers who embed it.

This is the video analogue of the byline work editorial teams already do for articles. Where you have been crediting video to a channel or leaving it attributed to the site, there is now a named field for the person or organisation that made it — which matters because credits are one of the few machine-readable expertise signals available on a page with very little text on it.

Editorial instruction: add a named creator to the brief for every video asset, with a link to the same author page your written work points to, so one entity accumulates the credential rather than two. Rollout status: documentation live, 2026-09-24 (primary). The markup itself belongs to Section 2.

No change to AI Overviews eligibility guidance — and the controls are still blunt

Checked and found unchanged: Google's AI features and your website guidance still carries a last-updated stamp of 2025-12-10 and still states there are no additional requirements to appear in AI Overviews or AI Mode and no special optimisations necessary. Pages need to be indexed and eligible to show with a snippet. That is the whole eligibility story, and nothing in the audit window altered it.

What writers should take from a non-change is that the only levers are the snippet controls — nosnippet, data-nosnippet, and max-snippet — and each one buys exclusion at the cost of the ordinary search snippet too. There is no setting that keeps your result in Search while withholding it from AI Overviews.

Editorial instruction: if a client or stakeholder asks to be removed from AI Overviews, put the trade in writing before acting — the same directive suppresses the snippet that drives the organic click. Where you want citation rather than exclusion, the formats that get quoted are still the ones that answer cleanly: a tight definition near the top, a comparison table with real values, and first-hand data no one else holds.

Apply to your next brief

• Do not open a rewrite or pruning project on rankings observed during an update with no completion timestamp — snapshot your top fifty pages instead, and wait for the dashboard to close.
• Add a required field to every brief: the one element a language model could not have produced. Original testing, proprietary numbers, a named practitioner's judgment, or primary reporting.
• Move that element above the fold. If the first screen reads like a consensus summary, it is one.
• Judge content refreshes on a monthly cadence, not a weekly one, and batch them accordingly.
• Give every video asset a named creator in the brief, linked to the same author page as your written work.
• Before agreeing to suppress AI Overview appearance, document that the same directive removes the organic snippet.
• Keep writing the quotable shapes — a definition in one sentence, a comparison table with values, and data only you have.

2. SEO for Developers

Two things landed inside the window and both touch measurement rather than ranking. Chrome 155 reached stable today, and web-vitals v6.2.3 shipped yesterday morning fixing two bugs that were quietly corrupting the field data you make decisions from. The second one is the same-day pull request. One explicit negative: no AI-crawler policy change was verifiable in this window — OpenAI, Perplexity, and Cloudflare published nothing that alters a robots.txt decision.

web-vitals v6.2.3 fixes an LCP attribution bug and an INP memory leak

Version v6.2.3, tagged 2026-10-05 at 10:00 UTC, is a two-line patch with outsized consequences. Per the CHANGELOG: "Fix negative resourceLoadDuration in LCP attribution" (#803) and "Fix INP clean-up bug causing memory leak" (#799). Non-breaking — it is a patch release with no API change.

Symptom if ignored, and this is the part worth reading twice: your LCP attribution has been reporting negative resource-load durations, which means any dashboard that averages or sums that sub-part has been skewed toward a conclusion that your LCP resource loads faster than it does. Teams who used that breakdown to decide against image or font work were working from corrupted inputs. Separately, the INP observer leaked memory across a session, which degrades long-lived single-page sessions — the exact sessions where responsiveness complaints originate.

The file to change is your lockfile, and the thing to do afterwards is treat pre-upgrade LCP attribution breakdowns as unreliable rather than reconciling them against the new numbers.

# Patch the collector, then redeploy your RUM beacon
npm install [email protected]

# Verify the resolved version is actually 6.2.3 and not a stale transitive copy
npm ls web-vitals

import { onLCP, onINP, onCLS } from 'web-vitals/attribution'

// After 6.2.3, resourceLoadDuration no longer goes negative.
// Guard anyway: historical rows in your warehouse still contain bad values.
onLCP(({ value, attribution }) => {
  const load = attribution.resourceLoadDuration
  send('LCP', {
    value,
    resourceLoadDuration: load >= 0 ? load : null, // drop, do not clamp to 0
    element: attribution.element,
  })
})

onINP(({ value, attribution }) => {
  send('INP', { value, interactionTarget: attribution.interactionTarget })
})

onCLS(({ value, attribution }) => {
  send('CLS', { value, largestShiftTarget: attribution.largestShiftTarget })
})

Chrome 155 reaches stable today with JPEG XL decoding

Chrome 155 hit the stable channel on 6 October 2026. The release notes list two entries that change page-loading behaviour: JPEG XL decoding support, with progressive decoding, and a permission policy that pauses audible media playback in iframes that are not visible. Non-breaking in both cases — these are additive capabilities.

JPEG XL matters because it is the first time in years that a new still-image format has become worth serving from a content site, and progressive decoding specifically helps the perceived-load half of the LCP problem. The caveat is the one that governs every format rollout: Chrome 155 is one browser at one version, so JPEG XL belongs behind content negotiation, never as a bare replacement.

Serve it from a picture element with ordered sources so non-supporting browsers fall through to AVIF or WebP. The media-pause policy is worth knowing about if you embed video players in long pages — background iframes will no longer keep audio alive, which removes a long-standing source of main-thread work during scroll.

<!-- Ordered fallback: the browser takes the first type it can decode -->
<picture>
  <source srcset="/img/hero.jxl" type="image/jxl" />
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img
    src="/img/hero.jpg"
    alt="Descriptive alt text that earns the image result"
    width="1200"
    height="630"
    fetchpriority="high"
    decoding="async"
  />
</picture>

Next.js canary moves metadata work into build output — stable is still 16.3.8

Next.js v16.4.0-canary.61 published 2026-10-05 at 23:47 UTC. Three entries are relevant to anyone generating metadata at scale: "Record parameter matching usage in build metadata" (#99594), "Collect root param dependencies for 'use cache' at build time" (#99274), and "Keep compile-mode metadata outside configuration" (#99491). The release also stabilises forbidden() and unauthorized() and adds ESLint 10 support.

Action: watch, not ship. This is a pre-release and nothing here is a fix you need today. The reason it is in this note is the direction of travel — root-param dependency collection for use cache is the groundwork for correct cache invalidation on localised and dynamic route trees, which is where generateMetadata and hreflang generation most often go wrong.

The stable channel remains 16.3.8, released 2026-09-30, and that one is not optional: it carries fixes for a metadata image route bypass via dynamicParams and an SSRF in image optimisation. If you are self-hosting below 16.3.8, that upgrade is the real same-day task — a bypass on metadata image routes means Open Graph image endpoints can be coaxed into serving for parameters you never meant to expose.

# Stable channel: take this one if you are below it
npm install [email protected]        # or [email protected] on the 15.x line

# Canary is for evaluation only — do not pin production to it
npm install [email protected] --save-exact

proxy-addr CVE-2026-90711 breaks IP-based Googlebot verification

Not new this window — the advisory published 2026-09-15 — but it belongs in a dev-side SEO note because almost nobody classifies it as an SEO bug. CVE-2026-90711 is a critical (CVSS 9.1) flaw in proxy-addr, the package Express uses to resolve a client IP from X-Forwarded-For. Affected versions 1.1.0 through 2.0.7; patched in 2.0.8.

The mechanism is a trust-subnet misconfiguration that compiles cleanly: writing an IPv4-mapped IPv6 range as ::ffff:10.0.0.0/8 instead of ::ffff:10.0.0.0/104 makes every IPv4 address match instead of the intended block, letting an unauthenticated client spoof X-Forwarded-For and defeat IP-based trust. Breaking in the security sense, silent in the operational sense.

The SEO consequence is specific. If you verify Googlebot by IP, or route geo and language variants from client IP, a spoofable forwarded header means an attacker can present as Googlebot and be served your crawler-only response — and it means your own crawler logs cannot be trusted as evidence of what Google fetched. Google's verifying Googlebot guidance calls for reverse DNS, not a header, and this is why.

// 1) Patch first
//    npm install proxy-addr@^2.0.8

// 2) Fix the mask. /8 on an IPv4-mapped range matches everything.
app.set('trust proxy', [
  'loopback',
  '::ffff:10.0.0.0/104',   // correct — NOT /8
  '::ffff:172.16.0.0/108',
  '::ffff:192.168.0.0/112',
])

// 3) Never verify a crawler from a header. Use reverse DNS.
const { promises: dns } = require('dns')

async function isGooglebot(ip) {
  const [host] = await dns.reverse(ip)
  if (!/\.(googlebot|google)\.com$/.test(host)) return false
  const forward = await dns.resolve(host)        // confirm the round trip
  return forward.includes(ip)
}

Vercel Speed Insights drops First Input Delay on 1 November 2026

The Vercel changelog entry of 1 October 2026, "Speed Insights deprecates First Input Delay on November 1st," is filed as requiring no action. For most teams that is right, and for anyone with a dashboard, alert, or quarterly report keyed to FID it is wrong.

Breaking for consumers of the metric, on a dated deadline. FID was replaced as a Core Web Vital by INP some time ago; this is the measurement plumbing catching up. Symptom if ignored: on 1 November a panel goes blank or an alert silently stops evaluating, and nobody notices a responsiveness regression because the monitor that would have caught it was watching a metric that no longer exists.

The change to make is in whatever defines your performance monitors. Grep your repository and your dashboard config for FID before the deadline, and make sure the INP thresholds you replace it with are the real ones — 200 ms for good, 500 ms for poor, assessed at the 75th percentile.

# Find every surviving reference before November 1
grep -rniE 'first[-_ ]?input[-_ ]?delay|\bFID\b' \
  --include='*.ts' --include='*.tsx' --include='*.js' \
  --include='*.json' --include='*.yml' --include='*.yaml' .

# Replacement thresholds, 75th percentile, per web.dev
#   INP  good <= 200ms   needs-improvement <= 500ms   poor > 500ms
#   LCP  good <= 2500ms  needs-improvement <= 4000ms  poor > 4000ms
#   CLS  good <= 0.1     needs-improvement <= 0.25    poor > 0.25

Ship today

1. Upgrade web-vitals to 6.2.3 and redeploy the RUM beacon. Then mark every pre-upgrade LCP attribution breakdown as unreliable instead of trying to reconcile it.
2. If you are self-hosting Next.js below 16.3.8 (or 15.5.27), upgrade now — the metadata image route bypass and image-optimisation SSRF are in the stable channel's fixes, not the canary's.
3. Patch proxy-addr to 2.0.8 and audit every IPv4-mapped IPv6 mask in your trust-proxy list for the /8-versus-/104 error.
4. Replace any IP-or-header Googlebot check with a forward-confirmed reverse DNS lookup.
5. Grep for FID across code and dashboard config, and move the monitors to INP thresholds before 1 November 2026.
6. Put JPEG XL behind a picture element with AVIF and WebP fallbacks — do not swap formats at the img tag.

What did not change

Stated so the absence is on the record: no verified change to AI-crawler policy in the window — no new or altered user agents from OpenAI, no robots.txt-relevant publication from Cloudflare's changelog, and no revision to RFC 9309. Schema.org remains at version 30.1 from 16 September 2026, and Lighthouse remains at v13.5.0 from 18 September. Google's documentation changelog recorded nothing after 1 October, and the Search Central blog published nothing in October at all.