I left the log export open in a second tab for three days before I looked at it properly. Thirty days of bot traffic on groas.com, every fetch stamped with a user agent and a path, sitting in a spreadsheet too wide to read without scrolling sideways twice.

I expected the category pages to be doing the work. They had the hits: 3,469, 3,309, and 3,057. Then I filtered for live fetches of real pages, the requests made while ChatGPT or Claude was putting together an answer for someone. All three category pages went to zero. The post at the top of that column, apart from the homepage, was /post/google-ads-updates-2026: a dated changelog with 182 live-answer fetches, 178 of them from ChatGPT-User.

I have made this mistake before. Back when I managed accounts by hand, I would open the crawl stats, see a tall bar, and feel good. Bots came, bots saw, therefore bots would cite us. The export made me separate three things I had been letting blur together: a request claiming to come from an AI crawler, a verified fetch of a page, and a live fetch made while an assistant answered a person. Even that last event does not prove the page appeared in the answer. It does show the page was retrieved at the moment an answer could use it. That is considerably more interesting than a tall bar.

The first distinction matters because user agents are easy to fake. In one 8-day sample of self-reported AI crawler traffic, 991 requests claiming to be AI crawlers were probing for .env files, and only 13% of requests claiming to be GPTBot verified as OpenAI. Behind Cloudflare, I check the verified flag and whether the path is a real page before treating a hit as evidence of anything useful. A fake bot requesting a file is still traffic. It is not an audience.

A laptop spreadsheet showing tall bot-hit counts beside zero live fetches

I clicked through to the changelog to remind myself what it actually is. The URL is /post/google-ads-updates-2026, and the page is what it sounds like: a running list of Google Ads changes with dates on them, one change per entry, each written the week it happened. No pillar-page introduction. No 2,000-word explanation of what Google Ads is. An entry says what changed, when it took effect, and who it hits.

That plainness gives a reader—or an assistant retrieving the page—a specific fact to find. The date distinguishes one change from another. The short entry makes it possible to pull the relevant passage without wading through a broad argument about advertising. I would not have put the page in a pitch deck. I would have pointed a client to it when they asked what changed.

The pattern has some support beyond our export, though it is not a promise that adding dates will get a page cited. In an analysis of 7,683 dated pages earning 47,097 citations from March to June 2026, Seer found that 75% of cited pages had been updated within the past year and 88% within two years. That describes the cited pages in the study; it does not tell us what would happen if we dated every page on our site. Our changelog offers something more concrete than a timestamp alone: a small, self-contained change an answer can use.

The second surprise sat two rows down. Our AI Max setup guide had 143 live-answer fetches. Its split ran the other way: 87 from Claude-User and 56 from ChatGPT-User. Same site, same month. The changelog recorded changes; the guide walked through settings in order. I cannot see the questions that caused every fetch in an edge log, so I cannot say exactly why the assistants chose them. I can say that both pages gave a requester something more precise than a category-page introduction.

The table that changed the story

I went back to the export and put the useful columns beside each other. These are our own 30 days of edge logs, not a public citation count. A dash means I am not reporting a figure for that cell; it does not mean zero.

PageTotal AI-user-agent hitsVerified page fetchesLive-answer fetches
/post/google-ads-updates-2026—292182 (178 ChatGPT-User)
AI Max setup guide——143 (87 Claude-User, 56 ChatGPT-User)
Category page A3,469—0
Category page B3,309—0
Category page C3,057—0
/ (homepage)——939 ChatGPT-User

The table has three different levels of evidence:

  1. Total hits count requests wearing an AI user agent. They do not establish who sent the request or what it wanted.
  2. Verified page fetches narrow that traffic to provider-verified requests for real pages. The changelog had 292.
  3. Live-answer fetches narrow the view to ChatGPT-User and Claude-User retrieving pages while responding to people. The changelog had 182. A fetch can contribute to an answer, but this log cannot tell me whether the page was named, linked, or quoted in the finished response.

That last limit is worth keeping in view. I originally wanted to call the 182 “citations” because it made for a cleaner sentence. It would have made for a worse report. The category pages’ zeroes are still striking: despite more than 3,000 AI-user-agent hits each, none showed a live fetch in this export. But the comparison is between observed requests, not between 182 confirmed citations and zero confirmed citations.

The outside verification sample shows why I would not stop at the first column. Only 39% of its ChatGPT-User claims and 32% of its OAI-SearchBot claims verified as OpenAI traffic. Its verified ClaudeBot traffic included requests for robots.txt as well as a handful of article fetches. That is useful context, not a correction factor I can apply to groas: it came from another site and another window of time. It tells me to inspect our own requests, not to multiply our hit totals by somebody else’s percentages.

Then I noticed the homepage. Nine hundred thirty-nine ChatGPT-User fetches to /. Not the changelog, not the setup guide. The front door.

It is tempting to say every one of those came from someone asking about groas by name. The log does not contain their prompts. It tells me ChatGPT-User came back to the homepage repeatedly while answering people, and nothing more specific about what it said afterward. I would rather keep that uncertainty than turn a server request into a testimonial.

The homepage row also showed why an analytics dashboard alone would miss much of this activity. In one team’s visibility comparison, GA4 recorded 4 AI Assistant users in a month while Ahrefs counted 121 AI citations to the same site. Those are different measures, not numbers that ought to match. A citation may never produce a click; a fetch may never produce a citation. Neither turns into a neat line labelled AI influence in GA4.

So I put two views next to each other rather than pretending either was complete. The logs show which pages assistants fetched live. A recurring set of customer questions, checked in ChatGPT, Perplexity, and AI Mode, shows which pages the finished answers actually name or cite. The visibility-tracking method uses 10 to 15 questions and repeats the check monthly alongside GA4. It is slower than staring at a hit total. It also answers a different question.

I reread the pages with zero live fetches

The three category pages looked fine at first glance. Big headers, broad paragraphs, advice intended to stay useful for a long time. They also read like the checklist in every how-to-get-cited article: unblock bots, put a short answer near the top, add an FAQ, refresh the page. The standard checklist is easy to recognize because so many pages repeat it. Ours had the same problem. They could introduce a subject, but I struggled to find a passage that would answer a narrow question better than the dated entry or the ordered setup guide.

That is not proof that every broad page fails, or that a category page has no job. Ours rank and convert in Google. I am not deleting them because another column says zero. But I had been treating their crawl counts as evidence that they were also working as AI citation assets. The live-fetch column gave me no support for that story.

The distinction between citation selection and answer absorption helped me articulate why. In the Seer analysis, selection means a page gets into the source list; absorption means its material shapes the answer’s wording. Neither is directly measured by our edge logs. Still, it made me look closely at what each page offered. The changelog had a date, a change, and an affected group in a compact entry. The AI Max guide had settings in the order someone would use them. The category pages spent more space explaining why the subject mattered. If I needed one passage to answer one question, I knew where I would look first.

That reread sent me back to the bots themselves. I used to tell clients to block training crawlers as a privacy win and leave it at that. I was wrong, or at least sloppy: “block the AI bots” collapses different jobs into one checkbox. OpenAI identifies GPTBot for training, OAI-SearchBot for search retrieval, and ChatGPT-User for live requests when a person asks (OpenAI crawler breakdown). Anthropic likewise distinguishes ClaudeBot, Claude-SearchBot, and Claude-User (Anthropic bot roles).

The robots.txt split is the practical part: if you want to refuse training access, configure that separately from the access used for search and live retrieval. Perplexity also distinguishes PerplexityBot and Perplexity-User. I fixed ours in an afternoon. It felt like negative-keyword hygiene: unglamorous and embarrassing to discover only after a month of looking at the wrong column.

Last week I put the export next to our content calendar. The category pages had each taken about a week across briefing, drafting, editing, design, and internal links. The changelog took an afternoon, much of it spent copying dates I already had in Slack. Time spent is not a measure of a page’s worth; the category pages do work elsewhere. But I had been proposing more of the expensive kind for AI visibility while the inexpensive, specific page was the one showing up in live fetches.

Say you spend $20k a month on ads and another $8k on content, and a report shows 9,835 AI bot hits across three pages. That number feels like coverage. In our month, those same three rows yielded no live fetches. I would want to know that before approving the next round of pages that look just like them.

I am not replacing every category page with a changelog, either. The content calendar now has a simpler test written at the top: take questions customers already ask, publish the answer in a form that makes the relevant date, fact, or ordered step easy to find, and check the live-fetch column after 30 days. Then check the answers themselves. A page with hits and no live fetches is not necessarily useless. It just has not earned the particular credit I was giving it.

Monday-morning version: export 30 days of edge logs, verify the providers, keep ChatGPT-User and Claude-User fetches of real URLs, and sort by page. Ask customer questions in ChatGPT and Claude, then record which of your pages the answers name. If you run on groas, the MCP connection for ChatGPT and Claude can answer that second part from your own data: which pages get cited, where visibility moved, and what changed last week.

I still have the export open. The category rows are at the bottom now, sorted by the column I should have read first. The changelog sits above them: dated entries, one change at a time.