Our Changelogs Drew 14x More Live AI Fetches Than Our Service Page

Two dated changelog posts drew 984 verified live ChatGPT and Claude fetches in 30 days. Our service page drew 70. That is a 14x gap on the same site, in the same month, and a problem for anyone reselling service-page rewrites as AI SEO.

I used to tell clients that rewriting a service page was AI visibility work. I was wrong to make it the centerpiece. When someone asks an assistant a specific, time-bound question, a page with dates, changes and a direct answer gives it something to retrieve. A general description of a service gives it much less. Our log cannot tell us what the assistant ultimately said, but it can tell us which pages its live fetchers requested. If you run an agency, that distinction should change what you buy and what you report.

First, separate live fetches from bot noise

Our nginx edge log covers 30 of 30 days in the window. It records requests claiming AI bot user agents, but those requests are not interchangeable. I split them into three counts:

That last count is the one I use here. AI bots have different jobs: training, search retrieval and user-triggered live fetch. Live fetchers account for about 3% of AI bot hits in the analysis cited here. The rest of the traffic cannot be rolled into a live-answer count just because the user agent contains an impressive name.

A fetch is not proof of a citation, a recommendation or a sale. An edge log sees the request, not the finished answer. That limit matters, but it does not make the request useless: it shows which of our pages assistants reached for during live conversations. Start there before discussing visibility.

The 30-day page-level split

The source for every count in this table is our own 30-day nginx edge log, filtered to verified requests. The second changelog’s verified-hit total and the service page’s verified-hit total were not broken out in the draft analysis, so I will not fill those cells by guesswork.

The two changelogs total 984 live-answer fetches against 70 for the service page. Divide 984 by 70 and you get 14.05; I call it 14x because the decimal changes nothing. Same site, same window, same verification method. Not the same kind of page.

That comparison does not isolate page format from every other possible cause. It does give a reseller a better question than “How many pages did the provider optimize?” Ask which URLs verified live fetchers requested. Then ask what those pages answered.

Finding 1: a dated answer gives the fetcher a reason to visit

The top page, /post/google-ads-updates-2026, drew 577 live-answer fetches. The second dated changelog added 407. Our /for-businesses page drew 70. The mechanism I would test is straightforward: a question about what changed and when calls for a page that names the change, dates it and explains what follows. A service page is built to explain what a company sells. That is useful, but it answers a different question.

There is a broader directional match, though not a direct comparison. In a 500-query crawl of Google AI Overviews, sources appeared on 96% of informational queries and 90% of YMYL queries, versus 32% of transactional and 10% of local queries. Those are Google AI Overview figures, not ChatGPT or Claude fetch rates, and they do not prove why our pages were requested. They do illustrate why I would be cautious about pitching a transactional service page as the main route into AI answers.

This is where a white-label deliverable can go wrong. Three revised headlines on /services may improve the page as a sales page. They do not, by themselves, give an assistant an answer to a dated buyer question. Call the work what it is. If the contract promises AI visibility, demand pages built to answer the questions behind live retrieval.

Finding 2: ChatGPT and Claude leave different traces

The two live fetchers did not look identical in our log. ChatGPT-User went to content URLs, pulled the page and left. Claude-User also checked robots.txt: 1,071 requests in the same 30-day window. Those permission checks belong in the analysis, but not in the content-fetch total. Count them as demand and a report can look busy without showing one more page read.

That distinction follows the bots’ separate jobs. Anthropic runs training, live-fetch and search-indexing bots; OpenAI separates GPTBot, OAI-SearchBot and ChatGPT-User. A robots rule aimed at training is not the same decision as a rule affecting search or live fetching. Before a provider recommends a block, make them name the bot and the job they mean to stop.

Permission is also not a reliable identity check on its own. Anthropic bots use public cloud IPs, which makes IP blocking unreliable and per-bot robots.txt directives the relevant control. OpenAI user-agent strings can be spoofed, so vendor IP lists matter when verifying a claimed bot. Separate permission checks, verified content fetches and errors. Otherwise, the report tells you more about its counting method than about your pages.

Finding 3: a claimed bot is not a verified reader

A request saying ChatGPT-User is not automatically a request from ChatGPT. Forged strings can probe /.env and /.well-known/jwks.json instead of reading a blog post. That is why a useful bot report checks IP ranges and reverse DNS rather than ranking pages by raw user-agent hits.

My sequence is plain: group the paths requested by *-User agents, verify the bot claims against vendor lists, then set aside requests that return 403 or 429. The 984-versus-70 comparison is about the remaining live content fetches. It is not a tally of every string in a log that contains “AI.”

Dates need the same discipline. “Dated” does not mean “published yesterday.” In the SE Ranking figures cited here, 12.32% of AI Overview citations came from content published in the prior 30 days, compared with 28.76% from 2025 and 26.85% from 2024. Again, those are citations in Google AI Overviews, not observations from our ChatGPT and Claude log. They are a reason not to confuse a fresh URL with a useful update.

For a page that keeps answering the same dated question, maintain the answer and use an honest dateModified. Do not manufacture a new thin URL every time the calendar moves. Keep the useful page current; do not report raw crawler traffic as proof it worked.

What I would buy instead of another service-page rewrite

Stop making service-page rewrites the headline AI visibility deliverable. I have sold that work. Our log gives me little reason to keep putting it first: 70 live fetches for the service page against 984 for two dated changelogs. What the deck calls “AI content optimization” can amount to editing a brochure nobody asked the assistant to read.

I would commission question-shaped, dated pages instead: one page per real buyer prompt, with the date and relevant change clear near the top and the answer in the first 150 words. The draft examples are good shapes, not claims that these particular pages have been published: “2026 water heater code changes in [county]: what still passes inspection” for home services; “January 2026 [integration] pricing change: what breaks” for SaaS. Each gives a reader, and potentially a fetcher, a reason to open the page beyond learning the company’s name.

That is the kind of ongoing production groas offers through its SEO and AI Search service: new pages and technical fixes every day for a flat fee, with a named strategist responsible for the direction. The log does not prove any provider can reproduce 984 fetches for another client. It does show why I would pay for pages that answer specific questions before paying for another round of service-page adjectives.

Checklist: inspect the deliverable before you resell it

Use this before renewing a white-label contract or promising a client AI visibility. The first two items establish what the provider can actually measure; the rest test whether the work matches that measurement. A mention chart is not a substitute for a per-URL fetch report.

1. Verified fetches, not raw user-agent hits. Require reverse-DNS and IP-range verification so spoofed scanners do not inflate the count.
2. Live-answer fetches per URL. Show ChatGPT-User and Claude-User content requests separately from other bot hits; this is how you see a 984-versus-70 split.
3. Pages tied to named buyer prompts. Each proposed URL should answer one identifiable question, with dates and specifics where the question calls for them.
4. Permission checks and errors listed separately. Keep robots.txt requests, 403s and 429s out of the content-fetch total; Claude’s 1,071 checks are not 1,071 page reads.
5. Maintenance on existing pages. Show what changed and keep dateModified honest rather than substituting a pile of thin new URLs.
6. No guaranteed ChatGPT placement. A provider cannot ethically guarantee placement. Skip this check and the missed guarantee lands on your agency’s name.

The limit: one site and one month

This is groas.com, a site publishing dated change logs for an audience that asks dated search-marketing questions. A plumber in Dallas should not expect 577 live fetches from a Google Ads update post. A transactional query may not prompt a citation at all. The 14x is an observed split, not a multiplier to promise a client. What can transfer is the working method: answer a specific question, date the answer where the date matters, and inspect verified requests to that URL.

Service pages still have a job. They can hold proof, pricing and a contact path for someone deciding whether to buy. Our result does not say to delete them or stop improving them. It says not to grade their AI-search value by the same expectation you bring to a dated answer page, then bill for repeated rewrites as though the two jobs were interchangeable.

The log also stops at the fetch. It does not reveal whether the answer cited our page, persuaded a buyer or produced revenue. A provider should say that plainly. If it cannot show verified live fetches per URL, though, it cannot even show the narrower behavior that produced this comparison.

The white-label decision the numbers support

Agencies ask me who can handle SEO and AI visibility together, and who can get client pages into assistant answers. I would start with what nobody can honestly promise: placement in a finished answer. Then I would ask what the partner ships and what it measures. Audit software can produce an audit; fulfillment can produce pages. Neither earns a live fetch merely by appearing in a monthly report.

groas runs SEO and AI Search alongside paid search behind agencies under their brand, with new pages and technical fixes every day. That production model fits the behavior our log exposed better than a contract centered on polishing service pages. The evidence is the page-level split, not a guarantee that every new page will match it.

So buy the work you can inspect. Ask for dated pages tied to real buyer prompts, a monthly report of verified ChatGPT-User and Claude-User content fetches per URL, permission checks listed separately, and maintenance on pages that remain useful. If a provider cannot show that report, do not put your agency name on its AI SEO. If it can, send the report to the client with the limit stated clearly: these pages were fetched during live conversations; the log does not show the final answers. That is a deliverable worth reselling.