Daily SEO Note — October 3, 2026: Google Defines What Counts as Main Content

1. SEO for Content Writers

The one editorial change worth acting on today is a definition, not a launch. Google's guide to creating helpful, reliable, people-first content now states in plain language what it counts as “main content,” and it names the four attributes Search Quality raters use to judge that content. The documentation changelog logs the revision on October 1 and the page carries a last-updated stamp of 2026-10-01 UTC. Yesterday's note covered the generative-AI half of that same revision; these two sections are the half it did not cover. Separately, the Search Status Dashboard still shows the September 2026 spam update with a start of September 24 at 16:15 UTC and no completion time — the status is unchanged from yesterday, so there is nothing new to report on it.

Google now defines “main content,” and the definition is wider than the article body

Google defines main content as “any part of the webpage that directly helps the page achieve its purpose” and then enumerates five categories: primary text and media; interactive features such as calculators, tools, games and site search; user-generated contributions such as forum threads, customer reviews and comments “when they directly fulfill the page's purpose”; tabbed or expanded sections holding things like product specifications, safety notes and reviews; and the visible page title and headings. Primary source: the helpful content guide, last updated 2026-10-01 UTC. Rollout status: live documentation, not a ranking launch — there is no dashboard entry, so nothing is rolling out and nothing will finish.

Who it affects: all content, with the sharpest edge on templated and commerce pages. If your product pages hide specifications behind a tab, that tab is main content. If your review copy sits in an accordion, that accordion is main content. If a comparison page leans on a calculator, the calculator is main content. The practical consequence is that “thin page” can no longer be argued away by pointing at a short visible intro while the substance sits one click deep — Google is saying it counts the substance, wherever the interaction puts it.

What to do differently in your next article: audit the brief against those five categories before you write, and make sure the page's purpose is served by at least one of them in depth rather than by all five thinly. Where a page's real value is an interactive feature or a specification table, write the brief so that feature is the deliverable and the prose supports it, instead of padding the intro to hit a word count. What to stop doing: treating user-generated content and tabbed sections as decoration that sits outside the editorial remit. On pages where reviews or forum answers fulfil the purpose, their quality is now explicitly your problem, which means moderation and pruning belong in the content calendar.

Effort, originality, talent or skill, and accuracy are now named as the rater rubric

The same revision spells out four attributes raters assess: effort — “the extent to which human work went into creating the content or the systems powering it”; originality — whether the content “offers unique, original information or perspectives that aren't already available on other websites”; talent or skill — whether the content shows the expertise “necessary to provide a satisfying experience for visitors”; and accuracy — factual correctness, raised for YMYL topics to “highly accurate and consistent with established expert consensus.” Primary source: the helpful content guide, dated 2026-10-01 UTC.

Note what the effort criterion actually says. It credits work that went into “the systems powering” the content, not only the keystrokes in the draft. That is a meaningful carve-out: a programmatically generated page backed by real engineering, proprietary data collection or genuine tooling is not condemned by volume alone. The thing that fails is volume without any of that, which is the behaviour the scaled content abuse policy already covers. Rollout status: documentation, informational.

What to do differently: put one sentence in every brief that answers “what is original here?” — a test you ran, a dataset you pulled, a practitioner you interviewed, a mistake you made and fixed. If that sentence cannot be written, the brief is a rewrite of somebody else's page and should be merged into an existing hub instead of published as new. For YMYL verticals, add an explicit consensus check to the workflow: name the authority you are consistent with, in the copy, where a reader can see it. What to stop doing: using “we went deeper than competitors” as the originality claim. Depth is not originality under this rubric; it is the same information, longer.

Correction: the “AI Overviews tracking parameter” was a browser extension, not Google

A widely shared report on October 2 claimed Google had begun appending ?st_source=ai_overview to links inside AI Overviews and AI Mode, which would have given publishers a way to separate AI-surface clicks from ordinary organic clicks in their own analytics. It was not Google. The report was corrected after the person who spotted it established that a Chrome extension was rewriting the URLs in his own browser, apparently to on-sell the data. Status: retracted, no action.

Keep this one in mind the next time an attribution breakthrough circulates. Google's own documentation on AI features still describes no parameter, no report and no special markup for AI Overviews or AI Mode eligibility, and nothing changed about that yesterday. The editorial takeaway is unglamorous: there is still no first-party way to attribute an AI Overview click, so do not restructure a measurement plan or a content roadmap around one.

Unconfirmed: Bing is testing a “Recommended by” block in product results

Community reports on October 2 describe a new “Recommended by” section appearing in Bing's product results, with thumbnails that link to retailers rather than to the publication credited with the recommendation. Detection source: the October 2 search forum recap. Status: unconfirmed — there is no Bing Webmaster Blog post or documentation page covering it, and the most recent post on that blog predates this by months.

Who it would affect, if it ships: commerce and reviews publishers in Bing's index, who would get surface-level attribution without the click. There is nothing to do about it today beyond noting that a second engine is experimenting with crediting a recommender in a unit that routes traffic elsewhere. Do not brief against it and do not cite it to a client as a Bing feature until Bing documents it.

Apply to your next brief

• Audit every brief against Google's five main-content categories, and name which one carries the page's purpose.
• On product and commerce pages, treat tabbed specifications, accordions and customer reviews as in-scope editorial work, not template furniture.
• Add one line to each brief answering “what is original here?” — a test, a dataset, an interview, a first-hand failure. If it cannot be answered, merge instead of publishing.
• For YMYL topics, name the expert consensus the piece is consistent with, in the copy, not just in the research doc.
• Stop using length as the originality argument; the rubric scores unique information, not word count.
• Do not build any AI-referral measurement on the st_source parameter — it was a browser extension, and no first-party AI attribution exists.

2. SEO for Developers

The most consequential engineering change today is a patch, not a feature: two advisories for the All in One SEO WordPress plugin were published on October 2, and the fixed versions are not the same number, so a partial upgrade leaves one of them open. Everything else in today's window is smaller — schema-dts caught up to Schema.org v30.1, and Cloudflare quietly made crawler log analysis affordable on every plan.

Two All in One SEO advisories landed on October 2 — patch to 5.0.2.1, not 5.0.2

Version and date: GHSA-q2wc-642f-j642 (CVE-2026-85492), published October 2, 2026, CVSS 6.1 moderate — DOM-based cross-site scripting (CWE-79) in the Google Search Preview component, affecting all versions up to and including 5.0.1.1 and fixed in 5.0.2. And GHSA-f9q5-f8p2-3w5w (CVE-2026-19856), published October 2, 2026, CVSS 6.5 moderate — arbitrary shortcode execution in versions before 5.0.2.1, fixed in 5.0.2.1. The plugin's current release is 5.0.2.1.

Breaking or non-breaking: non-breaking to upgrade, but exploitable if ignored. The XSS path requires an unauthenticated attacker to craft a URL pathname and a logged-in user with the aioseo_manage_seo capability to open the SEO Preview panel in the admin toolbar while on that URL — which is to say, your own SEO team is the delivery vehicle. The shortcode flaw is worse operationally: the advisory states that the plugin fails to identify shortcodes in user-supplied content before filtering them, letting unauthenticated users execute any shortcode registered on the site, and that sites upgraded from earlier releases can have that protection disabled outright, so no special crafting is needed.

The setting to change is the plugin version, and the number that matters is 5.0.2.1. Stopping at 5.0.2 closes the XSS and leaves the shortcode execution open. If your deploy pipeline pins plugin versions, update the pin; if it auto-updates, verify the version actually moved rather than assuming it did, because the shortcode protection being disabled on upgraded sites means a stale install fails silently.

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

# CVE-2026-85492 (DOM XSS) is fixed in 5.0.2;
# CVE-2026-19856 (arbitrary shortcode execution) is fixed in 5.0.2.1.
# Take the higher bound - 5.0.2 is NOT sufficient.
wp plugin get all-in-one-seo-pack --field=version

wp plugin update all-in-one-seo-pack --version=5.0.2.1

# Confirm the upgrade applied. On sites carried forward from older
# releases the shortcode filter can be disabled outright, so a silent
# no-op here leaves CVE-2026-19856 exploitable.
installed=$(wp plugin get all-in-one-seo-pack --field=version)
echo "installed: ${installed}"
[ "${installed}" = "5.0.2.1" ] || { echo "FAILED: still ${installed}"; exit 1; }

schema-dts 2.1.0 tracks Schema.org v30.1 and drops the TypeScript peer dependency

Version and date: schema-dts v2.1.0, published October 2, 2026 at 19:03 UTC on npm. It adds types for Schema.org release v30.1 (itself dated 2026-09-16, which added EU Digital Product Passport and common eCommerce product vocabulary), bumps schema-dts-lib to 1.1.0, and ships schema-dts-gen 2.0.1 to “address security issue if using the generator directly with untrusted ontologies.”

Non-breaking for consumers, and one quiet improvement: schema-dts-lib 1.1.0 no longer requires TypeScript as a peer dependency, which removes a common source of install warnings and version pinning conflicts in monorepos. The symptom if you ignore this release is narrow but real — you cannot type the new v30.1 vocabulary, so any Digital Product Passport or extended product markup has to be written as untyped objects and loses compile-time checking. If you run schema-dts-gen in a build step against an ontology you do not control, treat 2.0.1 as the security-relevant upgrade.

The file to change is your package manifest, then the module where you build JSON-LD. Keep emitting JSON-LD inside a script tag rather than switching to microdata; nothing in Google's structured data guidance changed today.

// npm i [email protected]
// 2.1.0 covers Schema.org v30.1; TypeScript is no longer a peer dependency,
// so this no longer constrains the compiler version in a monorepo.
import type { Article, WithContext } from 'schema-dts'

export function articleJsonLd(input: {
  headline: string
  url: string
  datePublished: string
  authorName: string
}): WithContext<Article> {
  return {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: input.headline,
    datePublished: input.datePublished,
    author: { '@type': 'Person', name: input.authorName },
    mainEntityOfPage: { '@type': 'WebPage', '@id': input.url },
  }
}

Cloudflare now keeps 31 days of adaptive analytics on every plan

Date and rollout status: announced October 2, 2026, live, no action required. Every plan now retains a minimum of 31 days of adaptive analytics — HTTP requests, security events and DNS — and will answer a 30-day window in a single request. Free and Pro zones were previously limited to somewhere between 24 hours and 8 days depending on the dataset. Aggregated datasets such as httpRequests1hGroups keep their existing per-plan limits.

Non-breaking, and the reason it belongs in an SEO note is that it makes two routine audits possible on zones that could not previously afford them. A 30-day window is long enough to see a crawl pattern rather than a snapshot: you can now watch 5xx and soft-404 rates across a full Googlebot crawl cycle on a free zone, and you can establish an AI-crawler baseline before you change a robots.txt directive rather than guessing afterwards. The symptom of ignoring it is simply that you keep paying for a third-party log tool to answer a question the edge already retains.

Nothing to configure. The change applies across the dashboard, Custom Dashboards and the GraphQL Analytics API; query each dataset's settings if you need its exact retention and window. Below is the status-code-hygiene query — the one worth wiring into a weekly check.

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

# 30 days of edge response statuses by hour, in one request.
# Spikes in 5xx during a crawl window are what you are looking for.
curl -sS https://api.cloudflare.com/client/v4/graphql \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "query": "query Hygiene($zone: String!, $since: Time!, $until: Time!) { viewer { zones(filter: {zoneTag: $zone}) { httpRequestsAdaptiveGroups(limit: 2000, filter: {datetime_geq: $since, datetime_leq: $until, edgeResponseStatus_geq: 400}, orderBy: [datetimeHour_ASC]) { count dimensions { datetimeHour edgeResponseStatus } } } } }",
  "variables": {
    "zone": "YOUR_ZONE_ID",
    "since": "2026-09-03T00:00:00Z",
    "until": "2026-10-03T00:00:00Z"
  }
}
JSON

hash_in_range() is generally available, so SEO-affecting rules can ship to a slice first

Date and rollout status: globally available for HTTP products on all plans as of October 2, 2026. The function hashes a field into an integer within a range, letting a Ruleset Engine expression select a portion of requests. Cloudflare's own examples are hash_in_range(0, 100, cf.random_seed) < 10 for a flat ten percent, and a version that reads the percentage out of hostname metadata with coalesce() for per-tenant rollouts.

Non-breaking and additive. It matters here because the riskiest edge changes in SEO are the ones that are all-or-nothing: a redirect rule, a canonical header, a cache rule that changes what a crawler sees. Until now a staged rollout meant branching at the origin or in middleware. Note the argument order — bounds first, field last — and note the field choice: hashing cf.random_seed gives you a random sample that changes per request, while hashing a stable field such as the URI path gives you a consistent slice, which is what you want when a crawler must see the same answer twice.

The setting to change is the expression on the rule itself, in Rules, or in your Terraform ruleset definition if you manage it as code.

# Stage an SEO-affecting redirect on ~10% of blog URLs before full rollout.
# Signature: hash_in_range(<lower>, <upper>, <field>)
# Hash a STABLE field (the path), not cf.random_seed - a crawler that
# refetches the URL must get the same answer both times.

(http.host eq "example.com"
  and starts_with(http.request.uri.path, "/blog/")
  and hash_in_range(0, 100, http.request.uri.path) < 10)

# Random sampling, by contrast, is for observability rules only:
#   hash_in_range(0, 100, cf.random_seed) < 10

Watch: OpenAI's crawler documentation moved, and it now lists four agents

Status: undated by OpenAI, verified by request on October 3, 2026. The URL in most robots.txt review checklists, platform.openai.com/docs/bots, now returns a 301 to developers.openai.com/api/docs/bots. The current page documents four agents, each with its own published IP range file: OAI-SearchBot (surfacing sites in ChatGPT search), GPTBot (training data for foundation models), ChatGPT-User (actions a user initiates in ChatGPT and Custom GPTs), and OAI-AdsBot (validating the safety of pages submitted as ChatGPT advertisements).

Non-breaking, but the symptom if you ignore it is that a diff-based monitor pointed at the old URL watches a redirect forever and reports no changes to crawler policy whether or not any occurred. Fix the URL in whatever watches it. On the policy itself, keep these as four separate decisions rather than one “AI bots” toggle — blocking GPTBot is a training decision, blocking OAI-SearchBot removes you from ChatGPT search results, and blocking ChatGPT-User blocks a fetch a human asked for. Also confirm your CDN is not overriding the intent: a bot rule at the WAF can refuse an agent your robots.txt allows, and robots.txt is a request while a WAF block is enforcement.

# Four agents, four separate decisions.
# Verify with the per-bot IP range files, not the user-agent string:
#   https://openai.com/searchbot.json
#   https://openai.com/gptbot.json
#   https://openai.com/chatgpt-user.json
#   https://openai.com/adsbot.json

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: OAI-AdsBot
Disallow: /

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

Ship today

1. Upgrade All in One SEO to 5.0.2.1 on every site you run, then assert the installed version rather than trusting the updater. 5.0.2 is not enough.
2. Bump schema-dts to 2.1.0, and if you run schema-dts-gen against an ontology you do not control, take schema-dts-gen 2.0.1 specifically.
3. Repoint any crawler-policy monitor from platform.openai.com/docs/bots to developers.openai.com/api/docs/bots, and add OAI-AdsBot as its own explicit decision in robots.txt.
4. Wire the 30-day edge status-code query into a weekly check now that every plan retains it, and diff it against your Search Console crawl stats.
5. Audit your robots.txt intent against your WAF bot rules, so a Disallow is not silently stricter and an Allow is not silently blocked.