Daily SEO Note — September 7, 2026: OpenAI Quietly Refreshes the ChatGPT-User IP List

SEO for Content Writers

The most consequential editorial change in this window is a policy that stopped applying to some of your readers. On August 28, 2026 Google updated the site reputation policy so that within the European Economic Area it no longer demotes third-party sections by manual action, and lifted the manual actions already in place for readers there. The same pages remain subject to the old treatment everywhere else. One article can now be penalised for one audience and untouched for another, which makes the policy an editorial planning question rather than a compliance checkbox.

1. Site Reputation Manual Actions Were Lifted for EEA Readers

What changed: Google split enforcement of the site reputation policy by the reader's location. The spam policies documentation, last updated August 28, 2026, defines the policy as applying "where third-party content is published on a host site mainly because of that host's already-established ranking signals, which it has earned primarily from its first-party content." Outside the EEA a manual action still directly affects the portion of the site involved. Inside the EEA those pages are instead categorised separately from the main domain and left to rank on their own merits, and Google has lifted the previous manual actions for EEA results.

Who it affects: any publisher hosting third-party or partner content on a section of an established domain — coupons, casino and betting guides, sponsored directories, syndicated commercial reviews. It is not a general-content change, and nothing here loosens the policy outside the EEA. Note also what "ranking on their own merits" means in practice: the demotion is gone, but so is the borrowed authority of the parent domain. A page that only ever ranked because of the host's signals will not suddenly perform.

Do this differently: if you run a third-party section and hold a manual action, check Search Console now and read the notice by market rather than as a single verdict, then plan recovery for the EEA and remediation for everywhere else as two separate workstreams. Brief the EEA edition of that section to stand on its own reporting, because it is now competing against comparable pages instead of inheriting the domain's standing. Stop doing: treating a site reputation manual action as one global penalty with one global fix, and stop briefing partner content on the assumption that the host domain carries it.

2. ChatGPT Reads Your Page Live, Even Where You Blocked the Training Bot

What changed: OpenAI regenerated the published IP range list for ChatGPT-User on September 4, 2026, and it now carries 207 address blocks. ChatGPT-User is the fetcher that runs when a person asks ChatGPT about a specific page. OpenAI's crawler documentation is explicit that for these user-initiated requests "robots.txt rules may not apply," because a person asked for the page rather than a crawler deciding to take it.

Who it affects: all content, and it corrects a belief that is common in editorial teams. Blocking GPTBot is a training opt-out and nothing more. It does not stop your article being pulled into a ChatGPT answer at the moment a reader asks about it, because that is a different bot with a different token and a different rulebook. OAI-SearchBot, the one that governs whether you appear in ChatGPT's search answers at all, is a third separate decision. Three tokens, three questions.

Do this differently: assume the live-fetch path is open and write the top of the page for a machine reading it once, in a hurry, on someone's behalf. Put the direct answer in the first paragraph under the heading that asks the question, keep definitions self-contained rather than resolved three sections later, and give comparisons a real table instead of prose. Stop doing: describing your AI posture to stakeholders as "we blocked the AI crawlers" when what you blocked was training, and stop assuming a robots.txt line settles what ChatGPT can quote.

3. Preferred Sources Now Ships as a Button You Can Put in an Article

What changed: Google's preferred sources documentation, last updated August 20, 2026, now documents a ready-made button that lets a reader add your publication as a preferred source and return to the page they were on. Readers who select you see your content more prominently in Top Stories, and your site can carry a badge in AI Mode and AI Overviews. The standard implementation is two lines of HTML that localise themselves and follow the reader's light or dark theme.

Who it affects: news and publisher surfaces specifically, not every site. One eligibility rule decides most of it: preferred sources works at domain and subdomain level only, so a publication living at example.com/news cannot participate. If your newsroom sits in a directory, that is now a structural ceiling on a distribution feature rather than a preference.

Do this differently: this is a placement decision, and placement is editorial. The moment a reader is most willing to subscribe to you as a source is when they have just finished something good, so put the button at the end of strong reporting and on author pages, not in a sitewide header where it becomes furniture. Ask engineering for the standard implementation rather than a custom design, since the supported one already handles localisation and theming. Stop doing: nothing — this adds a surface without deprecating one.

4. No Ranking Event Is Live

In one line, because it does not deserve more: the Search Status Dashboard incident history still ends at the August 2026 spam update, which completed on August 21, the Search Central blog has published nothing since August 28, the documentation changelog has been silent since August 31, and there is no September core update.

Apply to Your Next Brief

• If you hold a site reputation manual action, read it per market: the EEA notice and the non-EEA notice are now two different problems with two different fixes.
• Brief EEA third-party sections to stand on their own reporting. They rank against comparable pages now, not on the parent domain's standing.
• Write the answer into the first paragraph under the heading that asks the question. ChatGPT-User fetches the page live and reads it once.
• Replace "we blocked the AI crawlers" in your policy docs with three named decisions: GPTBot for training, OAI-SearchBot for search, ChatGPT-User for live fetches.
• Give comparisons a real table and keep definitions self-contained, so a quoting model does not have to reassemble them.
• If you publish news at a domain or subdomain, place the preferred sources button at the end of strong articles and on author pages, not in the header.

SEO for Developers

One change in this window is worth a same-day pull request, and it is quiet enough to miss. OpenAI regenerated openai.com/chatgpt-user.json at 18:03 UTC on September 4, 2026. The file now publishes 207 IPv4 prefixes. If you allowlist, rate-limit or verify ChatGPT-User by IP address, your copy of that list is stale as of Friday, and the failure is silent: requests from the new ranges look like unverified traffic and get whatever your default rule does to strangers.

1. ChatGPT-User IP Ranges Regenerated September 4 — 207 Prefixes, Zero IPv6

Rollout identifier and date: the creationTime field inside openai.com/chatgpt-user.json reads 2026-09-04T18:03:29Z. That timestamp is the only version signal OpenAI publishes for these files — there is no changelog, no feed and no notification. Breaking for anyone pinning the list. Exact symptom if ignored: fetches from the newly published ranges fail your bot verification, and depending on your default they are throttled, challenged or served a block page, so ChatGPT retrieves an error instead of your article while every dashboard you own stays green.

The second finding matters more than the refresh and is easy to verify yourself: all four OpenAI crawler files are IPv4-only. chatgpt-user.json carries 207 IPv4 prefixes and no IPv6 prefix at all, and the same holds for gptbot.json (21 prefixes, stamped 2025-10-30), searchbot.json (35, stamped 2026-01-02) and adsbot.json (2, stamped 2026-05-12). If your origin is dual-stack and you allowlist these bots by address, every request that arrives over IPv6 fails the check by construction, because there is no published range that could ever match it.

The thing to change is whatever fixes the list in place — a hardcoded array, a Terraform variable, a WAF IP list, an nginx geo block. Fetch the files on a schedule and key your cache on creationTime rather than refreshing blindly, and fail loudly when the shape is not what you expect.

#!/usr/bin/env bash
# OpenAI publishes no changelog for these files. creationTime is the only
# version signal, so poll it and alert when it moves.
# Docs: https://developers.openai.com/api/docs/bots
set -euo pipefail

STATE="${STATE:-/var/lib/crawler-ranges}"
mkdir -p "$STATE"

for bot in gptbot searchbot chatgpt-user adsbot; do
  url="https://openai.com/${bot}.json"
  new="$(curl -fsS --max-time 20 "$url")"

  stamp="$(jq -r '.creationTime' <<<"$new")"
  v4="$(jq '[.prefixes[] | select(has("ipv4Prefix"))] | length' <<<"$new")"
  v6="$(jq '[.prefixes[] | select(has("ipv6Prefix"))] | length' <<<"$new")"

  prev="$(cat "$STATE/${bot}.stamp" 2>/dev/null || echo none)"
  if [ "$stamp" != "$prev" ]; then
    echo "CHANGED ${bot}: ${prev} -> ${stamp} (ipv4=${v4} ipv6=${v6})"
    printf '%s' "$new" > "$STATE/${bot}.json"
    printf '%s' "$stamp" > "$STATE/${bot}.stamp"
  fi

  # As of 2026-09-07 every one of these files is IPv4-only. If you allowlist
  # by IP on a dual-stack origin, IPv6 requests cannot match anything.
  [ "$v6" = "0" ] && echo "NOTE ${bot}: no IPv6 prefixes published"
done

2. OpenAI's Crawler Documentation Moved and the Old URL Now 301s

Verified by request on September 7, 2026: platform.openai.com/docs/bots answers 301 Moved Permanently to developers.openai.com/api/docs/bots, which returns 200. Non-breaking, because the redirect works. Exact symptom if ignored: link checkers and doc-freshness monitors that refuse to follow cross-host redirects report a failure, and any runbook, comment or robots.txt header pointing at the old host quietly sends the next engineer through a hop that may not survive the next reorganisation of those docs.

The thing to change is the reference itself, wherever you keep it. While you are in robots.txt, this is the moment to write the three OpenAI tokens as three separate answers, because a rule targeting one of them has no effect on the others — that is the single most common misconfiguration in this area, and it is invisible until someone audits it.

# OpenAI publishes three tokens for three different jobs. A rule on one
# does NOT apply to the others. Docs: https://developers.openai.com/api/docs/bots

# Training a foundation model. Block this for a training opt-out.
User-agent: GPTBot
Disallow: /

# ChatGPT's search index. Blocking this removes you from ChatGPT search
# answers entirely -- this is usually NOT what people mean.
User-agent: OAI-SearchBot
Allow: /

# Live fetch triggered by a person asking about a page. OpenAI states
# robots.txt "may not apply" here; treat allowing it as documentation of
# intent, and enforce at the edge if you actually need it stopped.
User-agent: ChatGPT-User
Allow: /

# Validates ChatGPT ad landing pages. Only relevant if you buy those ads;
# blocking it can stop your own ads being approved.
User-agent: OAI-AdsBot
Allow: /

3. Cloudflare Workers Deploy Limit Is Now 64 MiB, Measured Uncompressed

Version and date: Workers entry in the Cloudflare developer changelog, September 4, 2026. Workers may now deploy up to 64 MiB on every plan, and Cloudflare has stopped checking compressed size altogether — the previous 3 MB free and 10 MB paid compressed ceilings are gone, replaced by one uncompressed measurement. Non-breaking and strictly permissive; nothing that deploys today stops deploying.

Why it belongs in an SEO note: the compressed ceiling is what has historically forced edge SEO logic — redirect maps, hreflang tables, canonical rewriting, bot routing — out of the Worker and into either an origin round trip or a truncated in-Worker lookup. A full redirect map now fits at the edge. The check to change is your build gate, which is probably still asserting against a compressed number that no longer governs anything.

#!/usr/bin/env bash
# Cloudflare now checks UNCOMPRESSED bundle size only, 64 MiB on all plans.
# Source: Workers entry, Cloudflare developer changelog, 2026-09-04.
set -euo pipefail

LIMIT_MIB=64
wrangler deploy --outdir bundled/ --dry-run >/dev/null

bytes="$(du -sb bundled/ | cut -f1)"
mib="$(( bytes / 1024 / 1024 ))"

echo "uncompressed bundle: ${mib} MiB / ${LIMIT_MIB} MiB"
if [ "$mib" -ge "$LIMIT_MIB" ]; then
  echo "FAIL: bundle exceeds the uncompressed Workers limit"
  exit 1
fi

# If an old gate here still measures gzip output, delete it: compressed
# size is no longer what Cloudflare enforces.

4. Astro 7.3 Gives Image Services a Logger and Cloudflare Entrypoints finalize()

Version and date: Astro 7.3.0, September 3, 2026, followed by 7.3.1 the same day. Non-breaking. Two changes matter here. Custom image services and cache providers now receive Astro's logger — image services as a function argument, cache providers through the context object passed to onRequest() — which turns silent image-pipeline failures into log lines. Separately, @astrojs/cloudflare adds a finalize() helper that applies cookies and Cloudflare's CDN cache defaults to a response coming out of an astro/fetch pipeline in a custom worker entrypoint.

Exact symptom if ignored: a custom worker entrypoint that builds its own Response without finalize() returns one that never picked up Cloudflare's cache defaults, so pages you believe are edge-cached are revalidated on every request. That is a Core Web Vitals problem reported as a mystery rather than a bug, since nothing errors. The file to change is your Cloudflare entrypoint.

// Astro 7.3.0 (2026-09-03), @astrojs/cloudflare.
// finalize() applies cookies and Cloudflare's CDN cache defaults to a
// response produced by the astro/fetch pipeline. Skipping it is how an
// edge-cached page silently becomes an uncached one.
import { finalize } from '@astrojs/cloudflare/entrypoints';
import { App } from 'astro/app';

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const app = new App(manifest);
    const result = await app.render(request);

    // Without finalize(), Set-Cookie and the CDN cache defaults are dropped.
    return finalize(result, { request, env, ctx });
  },
};

5. Toolchain Status: Nothing to Upgrade

Stated explicitly so it is not mistaken for an omission. Next.js stable is still 16.3.4, dated August 31, 2026; canary.17 through canary.19 shipped across September 4 and 5 and none of them touch the Metadata API, app/sitemap.ts or app/robots.ts. Lighthouse stable is still 13.4.1 from July 20, 2026, with only dated nightly dev builds since. web-vitals is at 6.2.1, August 26, 2026. Schema.org remains at 30.0 from March 19, 2026, and no Google rich result type was added, restricted or deprecated in the window. Action: no action.

6. No SEO-Package Advisories in the Window

Reviewed advisories published September 4 to 7, 2026 against the CVE Program and the GitHub Advisory Database. Nothing in the window affects a sitemap generator, metadata library, structured-data package, crawler dependency or CMS SEO plugin. The critical and high-severity items published on September 4 sit in unrelated ecosystems. Action: no action.

Ship Today

1. Re-pull openai.com/chatgpt-user.json and update every allowlist, WAF IP list and verification rule that pins ChatGPT-User by address. The list was regenerated at 18:03 UTC on September 4 and now holds 207 prefixes.
2. Add scripts/refresh-openai-ranges.sh to a schedule and alert on creationTime changes. There is no feed to subscribe to, so polling is the only notification that exists.
3. If your origin is dual-stack, stop relying on IP allowlists for these crawlers: all four OpenAI range files are IPv4-only, so IPv6 requests can never match.
4. Split the OpenAI tokens in public/robots.txt into four explicit rules. A directive aimed at GPTBot does nothing to OAI-SearchBot, ChatGPT-User or OAI-AdsBot.
5. Repoint any reference to platform.openai.com/docs/bots at developers.openai.com/api/docs/bots before a link checker finds it for you.
6. If you gate Worker deploys on gzip size, switch the check to uncompressed against 64 MiB, then move the redirect or hreflang map you trimmed back to the edge.
7. On Astro with a custom Cloudflare entrypoint, upgrade to 7.3.1 and wrap the response in finalize() so CDN cache defaults and cookies survive.

Audit window: September 4, 2026 06:15 UTC to September 7, 2026 06:15 UTC, extended to 72 hours because it is Monday. Every hyperlink in this note returned HTTP 200 at the time of publishing, and the ChatGPT-User, GPTBot, OAI-SearchBot and OAI-AdsBot prefix counts and timestamps were read directly from OpenAI's published JSON rather than quoted from a secondary report. The site reputation and preferred sources items carry dates from late August and appear here because they had not run in this series before; they are labelled with their real publication dates rather than presented as today's news. Two community reports raised earlier in the month remain unconfirmed by Google and unchanged in status — Google Job Search not surfacing new listings, and AI Mode citing less generously — so they stay out of both summary blocks and no brief should be written against either. The GitHub Advisory Database index refuses requests from datacenter addresses, so the advisory check is cited to the CVE Program, which resolves.