Tuesday, just after 1 a.m., I was staring at the edge logs for /post/google-ads-updates-2026. The same user agent kept appearing beside the same URL. ChatGPT-User had fetched that one page 580 times in 30 days.

I filtered the lines the way I used to filter search terms at 1 a.m.: cut the noise, keep what might matter. Of those 580 fetches, 378 verified clean. Within that set, 232 were live-answer reads. ChatGPT accounted for 228; other assistants accounted for the rest. The page was a dated Google Ads changelog, not a sprawling resource centre or a polished services page. It addressed changes people had reason to ask about that week.

Two clicks over in the same log file sat our category pages. Big, well-linked hubs, the kind every audit tells you to build. Crawlers fetched each of them close to 3,000 times that month. When I applied the same live-read filter, their count was zero. I checked the filter again before I let myself draw anything from that gap. A large fetch total is easy to admire, especially when it belongs to pages you have spent time building. Zero is harder to explain away.

Same domain. Same month. More crawling, no live reads.

The 580 fetches were not 580 citations

That was the first correction I had to make to my own reaction. A user agent in an edge log tells me an assistant requested a page. It does not show me the finished answer, much less prove that the answer quoted or linked to us. A live read is evidence of selection, not proof of a citation. Calling all 580 fetches citations would turn a useful signal into a vanity metric with a server bill.

The distinction starts with why a bot visits. GPTBot crawls for model training. OAI-SearchBot and PerplexityBot build search indexes that an assistant may use later. ChatGPT-User is different: it can fetch a page after a person asks a question. That third kind of visit is the one I wanted to isolate. Someone asks; the assistant looks for an answer; our page is among the pages it chooses to read. Whether we appear in the response is a separate question. Nor can I turn 228 reads into 228 different people asking. The log records requests, not the people or finished answers behind them.

This is why the category-page total stopped impressing me. Thousands of index fetches can mean a crawler knows where a page lives. They cannot tell me that the page helped answer someone that morning. In one operator’s 34-day log study, ChatGPT-User made 1,388 fetches against Googlebot’s 1,233. Those counts are worth examining precisely because they describe different jobs. A search-engine crawl and an assistant reading during an answer are not interchangeable visits.

So I kept the filter on the user-triggered reads and sorted by URL again. The same post stayed on top. The hubs stayed at zero. If I had stopped at the unfiltered fetch totals, I would have walked away with the opposite impression of which pages mattered in this log.

A dated answer beats a broad introduction

The changelog did not hide a trick in its markup. Each section named one change, gave the date it took effect and said who it affected. The answer came in the first two sentences; the detail followed. A reader arriving with a deadline did not have to work through a tour of everything groas knows about Google Ads to find the relevant line. The page gave that reader a place to land, a date to check and an answer to carry away.

The category pages made the opposite bargain. They covered more ground, but their introductions were broad and the useful fact sat farther down. That can work for someone browsing a subject. It is a poor fit for a narrow question about a particular change. The changelog put the date and the answer where a reader could find both immediately. The hubs asked for more patience than that question required.

That pattern appears outside our logs. In an analysis of 287 ChatGPT answers, the assistant searched the web for 68% of them. Nearly half of 894 cited links pointed to the brand’s own site, rising to 96% for pricing questions. Those figures do not prove why our post was read. They do show why I would rather publish a page that states a needed fact plainly than assume a broad hub will speak for the entire domain.

A laptop displaying edge logs, with one changelog URL highlighted

Freshness was another plausible part of the appeal. Across 17 million citations, AI-cited URLs averaged 1,064 days old, compared with 1,432 days for organic Google results. In a separate sample of 47,097 citations, three quarters of cited pages had been updated in the previous year. Our changelog had a current change to describe; the category pages had older, broader material. I cannot isolate freshness from specificity in our edge log. In this case, they arrived together. A current date without a useful answer would not have told the reader what to do. An answer without the date would have left the deadline in doubt.

I also checked the explanations that would have sent us back into a site-wide project. Schema was the tempting one. Yet in an Ahrefs test of 1,885 pages, adding JSON-LD moved ChatGPT citations by 2.2%, a difference indistinguishable from zero. Google rank was another: only 10.6% of ChatGPT citations in one analysis came from Google’s top 10 for the same query. Neither result proves what caused our split. Neither gives me a reason to start by rebuilding the hubs when the live reads are concentrated on one useful page.

The next place I looked was not the site’s overall authority. It was the sections of the post.

The old landing-page lesson returned

Years before I watched assistants read that changelog, I learned how quickly a landing-page swap could hurt a Google Ads account. The ad and keyword could stay put while the page they led to changed. A worse match on the page was enough to make yesterday’s tidy account look different today. It was a useful cure for staring too long at account-level numbers while the destination did the damage.

Optmyzr’s Quality Score explainer describes the familiar ingredients: expected clickthrough rate, ad relevance and landing-page experience. The visible score, from 1 to 10, is an aggregated diagnostic; auction quality is recalculated for each query. I used to talk to clients about Quality Score as though it were general account health. A swapped page taught me to look at the destination in front of the searcher.

The assistant logs brought that lesson back, though the systems are not the same. A domain can contain a category hub, a services page and a dated post. A person asks about a bidding deadline. The assistant has to choose something to read for that question, not issue a lifetime achievement award to the domain. Our logs showed repeated live reads of the dated post and none of the hubs during that month. The useful comparison was URL against URL, not one crawler total against another.

Other logs show how uneven those choices can be. In that 34-day study, Claude-User read one spam-detection post 233 times out of 519 total reads. In the same dataset, Perplexity-User made zero live fetches despite 103 PerplexityBot index hits. One assistant kept returning to a particular post; another indexed material without producing a live read in that window. Our 228 ChatGPT-User reads were a reason to inspect the changelog, not a licence to predict what every assistant would do next.

If Perplexity is the assistant you are trying to reach, the page-level advice is similarly concrete: allow PerplexityBot through robots.txt and the firewall, and put a self-contained answer beneath a question heading. I would check access before rewriting prose. After that, I would check whether the page answers the question near the top. It is hard to borrow an answer buried four scrolls down.

Our changelog passed that plain test. Date. Change. Who it hits. What to do before August 17. The hubs asked the reader to browse; the post let the reader get on with the day.

Back to the timestamps

I left the logs open and checked when the reads happened. They were not spread evenly across the month. They bunched in the mornings after Google confirmed the August 17 bidding target change, the change we had written up in the June 17 roundup. The questions were immediate: what happens to a tCPA or tROAS setup, and what needs attention before the cutoff? The post had the date in its headline and the answer near the top. Our services page did not.

The timing did not let me see anyone’s question or the answer they received. It did make the contrast more concrete. A general category page could explain the territory; the changelog dealt with the change people had a reason to ask about then. That is a different job. I could see it in the page before I saw it in the counts.

That is the part our old reporting playbook would have missed. Rank trackers could tell us how the hubs were doing in search. Search Console could show their impressions. Neither would show ChatGPT-User requesting a particular URL while working on someone’s question. The edge log recorded that visit at the minute it happened. It still could not show me the completed answer. Keeping those two limits in view made the signal more useful, not less.

A dated changelog page open on a monitor beside several larger hub pages

I had been tempted to ask how to make the whole site look more authoritative. The filter suggested a smaller job: find the page already getting live reads, then work out what question brought an assistant there. For our site, the gap was hard to miss. One post had 232 live-answer reads. The category pages had zero, despite all that crawling.

If you want to look for the same pattern, open the last 30 days of server logs and separate ChatGPT-User, Claude-User and Perplexity-User from training and index crawlers. Sort those live reads by URL. Do not label the total “citations” unless you have evidence of the answers themselves. Look at the pages that appear, then read them as someone with a specific question would. Can you find the answer before the introduction finishes? Can you tell when it applies and who it affects? Those are questions I can put to a page without pretending the log tells me what an assistant wrote. Our earlier edge-log postmortem shows the less flattering version: plenty of bot fetches and no live-answer reads.

From there, I would build beside the useful page, not rebuild every category hub on principle. Keep the date current when the information changes. Give each section one question and an answer before the background. If the next question is about pricing, a deadline or who a change affects, give that question its own clear answer. I keep our list of bot-log myths close because a lot of plausible-sounding site advice dissolves when I put it beside the URL-level counts.

The conclusion I can defend is narrower than “232 citations,” and more useful: getting chosen for a live read happened at the page level. The logs cannot promise a link in the final answer. They can show which page an assistant reached for when someone asked. That month, the assistants reached for the dated post, not the broad hubs.

I closed the laptop at 2:14 with the filter still on. The coffee had gone cold. On the screen, the changelog filled the results; beside it, the hub pages still showed zero.