One Changelog Drew 377 Live AI Fetches. Three Busy Hubs Drew Zero.

One dated changelog post drew 377 verified user fetches in 30 days. Three category hubs each drew more than 1,000 bot-labelled hits and not one verified user fetch. I did not expect that spread when we pulled groas’s edge logs. I trust a report that counts those outcomes as the same kind of “AI visibility” even less now.

The distinction matters because AI vendors run different kinds of bots. Training crawlers, search indexers and user-fetch agents do different jobs. A training crawl may feed a future model. An indexer may make a page eligible to be found. A user-fetch agent such as ChatGPT-User or Claude-User requests a page in response to a person’s activity. Those requests are closer to the answer than a general crawl, but a log entry still cannot prove the page was quoted, named or even used in the final response.

That is the argument in our numbers: measure verified user fetches by page, then check actual answers separately. Bot traffic alone hides the difference between a page an assistant might use and one a crawler merely walked through.

The dataset: 30 days of requests at the edge

We kept 30 days of requests to thisisgroas.com that claimed an AI bot user agent. We then checked the requesting IPs against the vendors’ published ranges: OpenAI’s files for GPTBot, OAI-SearchBot and ChatGPT-User; Anthropic’s feed; and Perplexity’s bot and user files. A request outside the relevant range remained in the raw total but did not enter the verified total.

That check is not administrative tidying. User-agent strings are easy to spoof. For OpenAI, the useful verification check is its published IP ranges, not a confident-looking name in the user agent. A raw bot count can therefore rise without telling us that more of the vendor’s bots visited.

Here is the vocabulary I use throughout this piece. The figures that follow come from our edge logs for this one 30-day window; the request-level dataset is not published here.

I originally called the last column live-answer hits. It is a convenient label and a misleading one: the logs show a fetch by a user-facing agent, not the finished answer. I will call them verified user-fetch hits here. That keeps the measurement useful without asking it to testify to something it cannot see.

On many paths, roughly 70% of bot-labelled traffic could not be verified as the bot it claimed to be. The IP might sit outside the published range; a changed range or an inconsistent network identifier can also complicate the check. Unverified does not automatically mean malicious. It does mean I will not count that request as a confirmed vendor visit. We examined the problem separately when 76.5% of claimed AI bot hits failed verification. If your report relies on user agents alone, start there before drawing a growth chart.

Permission checks beat content in raw attention

The most frequently fetched path in this window was not an article. It was /robots.txt, with 1,222 verified Claude-User fetches and a steady stream of ChatGPT-User checks. The homepage followed with 822 verified user-fetch hits, mostly from ChatGPT-User. Both counts come from our edge logs.

I would not put either figure in a slide titled “answers won.” A request for /robots.txt is a request for permission information, not a request for a quotable paragraph. The rules can also differ between indexing crawlers and user-triggered fetches. Collapsing those jobs into one bot total makes the busiest path look like our best piece of content. It is a text file about access.

The homepage count is more interesting, though it still has a limit. A user-facing agent requested the page repeatedly; our logs do not reveal which facts, if any, reached an answer. They do tell me that the homepage is not just a brochure people visit after discovering the brand. It is a page an assistant may fetch while assembling a response. Put clear brand facts where a raw page request can find them. Then use answer checks, not the fetch count, to learn whether those facts surfaced.

Three hubs cleared 1,000 raw hits apiece—and zero user fetches

Each of three category hubs passed 1,000 raw bot-labelled hits during the window. After IP verification, each had roughly 200 to 250 hits. None had a verified user-fetch hit. The changelog post went the other way: fewer raw hits than those hubs, a higher verified share and 377 verified user-fetch hits.

Source: groas edge logs, one 30-day window. The ranges and relative descriptions reflect the figures available for this analysis; they are not missing precise counts dressed up as precision.

The hubs did a hub’s job: they exposed links and drew crawler passes. They did not draw the user-fetch agents we could verify. I used to tell clients that crawl volume signalled AI interest. I was wrong about what that volume could establish. It tells you something visited. Without the agent type and IP check, it does not even reliably tell you who.

Nor does zero user fetches prove that no answer ever mentioned a hub or drew on information learned earlier. Logs cannot see that. It is still a useful editorial finding. If my goal is to give an assistant a specific page to retrieve during a live request, these three hubs are not doing what the changelog is doing. More links and more crawler traffic are not substitutes for that observation.

What the 377-fetch page gave an assistant to work with

The standout path was /post/google-ads-updates-2026. Our logs show 377 verified requests from user-fetch agents during the same window, chiefly ChatGPT-User and Claude-User. That is 377 requests, not 377 confirmed quotations or distinct answers. I cannot recover those outcomes from an edge log.

The page itself offers a plausible explanation for the gap. It has a year in the URL and a dated changelog format. It says what changed, who it affects and when; its sections address particular questions instead of sending the reader through a category menu. The answer appears early, where someone fetching the page can find it without assembling fragments from several links. Guidance on answer-first openings, self-contained facts, tables and lists describes much the same structure.

That is a mechanism, not a controlled test. We did not publish an otherwise identical undated changelog and measure the difference. We did not hold topic demand constant against the hubs. What I can say is narrower and more useful: the page with the clearest, most specific answer drew the verified user fetches; the three broad hubs did not. If I have to choose what to write next, I would rather test another page built around a dated, answerable change than commission another broad hub and hope its raw crawl count turns into mentions.

There is a second reason not to oversell the 377. A user-fetch agent can retrieve material and still omit it from the response. It can also find that a competing page says the same thing more cleanly. The request is evidence that our page was fetched at a useful moment. Whether we appeared in the answer requires a different measurement.

Product pages sat between the two extremes

Our product and service pages drew single-digit to low-double-digit verified user-fetch hits each, almost all from ChatGPT-User, alongside a few hundred verified crawler passes. Those numbers also come from the same edge-log window. They are small next to the changelog and nonzero next to the hubs.

The pages that drew live requests put concrete facts up front: priced tiers, named integrations, dated availability and tables of what is included. Pages leaning on “flexible solution for modern teams” language got crawled and skipped by the user-fetch agents we tracked. That pattern does not isolate copy as the cause. It does give me a sensible page-editing priority: replace a claim an assistant cannot repeat precisely with a fact a buyer can check.

Rendering belongs in that decision too. A bot fetching raw server HTML may not see content injected after JavaScript runs. If a price or date appears only after hydration, I would inspect what the initial response contains before rewriting the prose around it. Permission and rendering come before a clever heading; our technical-audit argument starts at that door. Make the facts available in the fetched page, then make them easy to extract.

Measure the fetch, then check the answer

I would build the same three-column sheet for any site before buying another report labelled “AI visibility.” The order matters:

1. Keep the raw request. Export a defined window of edge logs with the path, time, user agent and IP. Raw bot-labelled hits remain a useful record, not a verified audience.
2. Check the claimed identity. Match IPs to the relevant vendor’s published ranges and retain unmatched requests in a separate bucket. OpenAI publishes ranges by bot; a single generic “OpenAI” label throws away a distinction this analysis needs.
3. Split verified agents by job. Keep training and indexing passes apart from verified ChatGPT-User, Claude-User and Perplexity-User requests. Count those user-fetch requests by page, not just by domain.
4. Check a fixed set of answers. Run the same buyer prompts across the assistants you care about and record whether your brand or page is named. A prompt panel measures an outcome the logs cannot, though it cannot reconstruct every answer every user saw.

I run the log sheet beside that prompt panel. One tells me what was fetched. The other tells me what appeared in the answers I checked. If user fetches and mentions move together, I have a stronger reason to keep producing that page type. If verified crawler passes rise while the answer checks stay flat, I have evidence of crawling, not evidence of visibility. And if mentions rise without a corresponding fetch in my window, I do not pretend the logs captured every route by which the assistant found us.

The same restraint applies to a zero. Zero verified user fetches for a hub in this window means exactly that. It does not make the hub worthless for navigation, indexing or readers. It means I would stop using its raw bot hits to defend an AI-answer strategy. A hub can keep doing its original job without being the page I fund to answer a specific question.

The next page I would fund

I would not rewrite every hub to imitate a changelog. Hubs organise a site; a dated change post answers a narrower need. I would keep that distinction and put the next editorial effort where our logs show a useful opening: a specific, dated page that answers a buyer question early and plainly. Give it headings that say what changed, who it affects and when. Put relevant facts in the initial HTML. Use a table when the facts are easier to compare than to bury in a paragraph.

Then I would measure it the same way as this post: raw hits, verified hits and verified user-fetch hits over a defined window, followed by checks of the actual answers. No victory lap for a crawler pass. No claim of a citation because ChatGPT-User requested a URL.

These are numbers from one domain over one 30-day window, not a benchmark for yours. We cannot tell from them whether the changelog’s format, its topic or demand for that information did the most work. We can see which pages the verified user-fetch agents chose to request, and we can stop confusing that signal with bot-labelled traffic. On thisisgroas.com, three hubs looked busy until we asked who visited and for what job. The dated post looked less busy in raw hits and drew 377 user fetches. That is the page type I would test next—and the measurement I would use to decide whether the test worked.