Did GPTBot start rendering JavaScript? What the 2026 logs show

You read that OpenAI's crawlers now run JavaScript, and you wonder whether the client-rendered part of your site is suddenly fine. The AI crawler guide rests on a December 2024 measurement: no major AI crawler executed JavaScript. In autumn 2026, several site owners published logs that say otherwise for some of OpenAI's bots. Here is what each report can prove, what it cannot, and how to check your own log.

What the September 2026 report saw

A Japanese freelance marketplace built on the Next.js App Router published its logs on September 30, 2026. Requests were checked against OpenAI's published IP lists, and fakes were dropped.

From September 25, two things changed:

• Volume. GPTBot went from 34 requests on September 10 to 152,009 on September 28, and from one IP a day to between 36 and 131.
• Request type. On September 28, 97% of GPTBot requests and 84% of OAI-SearchBot requests were Next.js prefetches, URLs ending in ?_rsc= plus a short random string.

The prefetch signal is the interesting part. In the App Router, a <Link> prefetches its route as it enters the viewport, in production builds. So the request comes from client code running in a page. A fetcher that only parses HTML has no reason to request ?_rsc= URLs, so the author reads them as rendered pages and counts distinct Referers on them to estimate how many.

The author is careful about the limits: no OpenAI announcement, one main site plus a few on the same server, and no idea how OpenAI picks sites to render. Most of the spike is prefetch amplification, so request counts overstate pages read.

What argues the other way

A WordPress plugin vendor published a 30-day log from one news site on September 24, 2026, the day before the reported change. Its table counts page requests and script files per bot:

OAI-SearchBot loaded one article like a browser on September 24, seven scripts within five seconds. The vendor matched bot names in the log without checking IP addresses, and says so. It also notes two blind spots of any host log: cached responses never reach it, and a CDN can answer script requests on its own.

So the two reports do not contradict each other as much as they look. One ends on September 24, the other starts seeing prefetches on September 25.

The state in November 2026

A roundup updated on November 11, 2026 collects the later evidence and splits the two crawlers:

• OAI-SearchBot: summarised as rendering "on some sites, after a delay". One analytics vendor logged OAI-SearchBot, from OpenAI's ranges, calling an endpoint nothing links to and only a script can reach. A second log, October 8 to 22, saw script files fetched a median of 32 minutes after the HTML. A beacon test that ran for 80 days logged no beacon from OAI-SearchBot.
• GPTBot: labelled disputed. The same beacon test logged seven calls from an inline script, from two addresses on OpenAI's list, and none from a React component.

OpenAI's crawler page lists GPTBot, OAI-SearchBot, ChatGPT-User and OAI-AdsBot with their user agents and IP lists. It says nothing about JavaScript, rendering or prefetching. The roundup found no OpenAI announcement as of November 9.

Verdict: some OpenAI crawlers render some pages, sometimes, later. ChatGPT-User, the fetcher behind a user's question, shows no rendering in any of these reports.

Check your own log

Logs from other sites tell you what happened there. Yours take five minutes. Download the three IP lists named on OpenAI's crawler page:

for f in gptbot searchbot chatgpt-user; do curl -s -o "$f.json" "https://openai.com/$f.json"; done

Each file holds a prefixes array of CIDR ranges. This script reads a combined-format access log, drops lines whose IP is not in a published range, and counts per bot:

# oai_log_check.py: python3 oai_log_check.py access.log gptbot.json searchbot.json chatgpt-user.json
import ipaddress, json, re, sys
from collections import defaultdict

LINE = re.compile(r'^(\S+) \S+ \S+ \[[^\]]+\] "\S+ (\S+) [^"]*" \d+ \S+ "([^"]*)" "([^"]*)"')
BOTS = ("GPTBot", "OAI-SearchBot", "ChatGPT-User")

nets = []
for path in sys.argv[2:]:
    with open(path) as f:
        for p in json.load(f)["prefixes"]:
            cidr = p.get("ipv4Prefix") or p.get("ipv6Prefix")
            if cidr:
                nets.append(ipaddress.ip_network(cidr))

stats = defaultdict(lambda: {"rsc": 0, "js": 0, "other": 0, "unverified": 0, "rendered": set()})
with open(sys.argv[1], errors="replace") as log:
    for line in log:
        m = LINE.match(line)
        if not m:
            continue
        ip, path, referer, ua = m.groups()
        bot = next((b for b in BOTS if b in ua), None)
        if not bot:
            continue
        s = stats[bot]
        try:
            verified = any(ipaddress.ip_address(ip) in n for n in nets)
        except ValueError:
            verified = False
        if not verified:
            s["unverified"] += 1
        elif "_rsc=" in path:
            s["rsc"] += 1
            s["rendered"].add(referer)
        elif path.split("?")[0].endswith(".js"):
            s["js"] += 1
        else:
            s["other"] += 1

for bot, s in stats.items():
    print(f'{bot:14} other {s["other"]:>7}  js {s["js"]:>6}  _rsc {s["rsc"]:>6}  '
          f'pages rendered ~{len(s["rendered"])}  unverified {s["unverified"]}')

How to read it:

• _rsc above zero for a verified bot: something ran your Next.js client code. The rendered-pages column is the honest number, not _rsc.
• js above zero with _rsc at zero: scripts were downloaded. That is not proof they ran.
• Everything zero but other: your log shows HTML reads only. Check whether your CDN served the scripts before you conclude anything.
• A large unverified count: someone is borrowing the user agent.

On a site without Next.js there is no _rsc signal. The beacon tests above use a script that requests a URL nothing else links to; that is the equivalent check.

What to do with the answer

Even if your log shows prefetches, the page still has to work for the fetchers that do not render: ChatGPT-User in the reports above, and every plain HTTP client. Rendering "after a delay" also means the text a crawler reads can lag behind the page. Keep the main content in the first response, and test that response, not the rendered one. The server-side rendering check covers the cases where a quick grep gets it wrong.

Test it yourself

Fetch one of your pages without a browser and search for a sentence from the main content:

curl -sL -H 'Accept-Encoding: identity' https://example.com/ | grep -c "a sentence from the main content"

Zero means a non-rendering reader gets the page without that text, whatever GPTBot does this month.

SiteRender API runs the same kind of read: a static fetch by default, returning the main content as Markdown, text or HTML. "Every request fetches the page live; there is no cache." When the main content is missing, it flags the page with a THIN_CONTENT warning or a CRAWL_NOT_RENDERED error instead of returning the empty shell. Paste your URL into the playground to check whether a static fetch is enough.