ChatGPT Fetched Two Dated Posts 920 Times. Our Service Page Got 41.

ChatGPT-User fetched two dated Google Ads update posts 920 times in 30 days. It fetched our main service page 41 times. If I had another month to spend polishing that service page, those are the numbers that would stop me.

The two posts accounted for about 53% of the ChatGPT-User content fetches across the four pages in the table below. This is one site, groas.com, in one 30-day window, measured from verified traffic at the edge. I can see which pages the assistant requested. I cannot see the question that prompted each request, whether the answer cited us, or what happened in Google AI Overviews. The useful finding is narrower: when ChatGPT sought live content, dated answers to specific questions drew far more requests than our business-description page.

That distinction matters because a crawler visiting your site is not necessarily an assistant consulting it for a person. Before getting to the page ranking, I had to separate those two jobs.

An index crawl is not a live-answer fetch

OAI-SearchBot crawls for ChatGPT search. ChatGPT-User can arrive later when someone asks a question and ChatGPT requests a page in response. OpenAI distinguishes ChatGPT-User requests from automatic crawling and notes that robots.txt may not apply to those requests; it lists OAI-SearchBot separately as its search crawler. One bot helps file the library. The other pulls a book off the shelf while someone is waiting.

I used to treat total bot hits as evidence that an account was visible to AI assistants. I was wrong. A background crawl and a live request answer different questions. The first tells me a crawler reached a page. The second tells me the page was requested in the course of answering someone. Another small-site log breakdown makes the same split between background crawls and user-initiated fetches. Count the two separately before you rank your pages.

Then verify the requester. Anyone can put ChatGPT-User in a user-agent header. I filtered the groas logs against published vendor IP ranges and reverse DNS rather than accepting the header at face value. OpenAI publishes crawler IP lists, including a separate ChatGPT-User list. The replicable log method groups requests by bot, path and status, then verifies the claimed bot.

This is not a fussy technical footnote. An EasyByte draft examining 16,548 requests across three small sites reported 49.5% verified traffic and 39.3% spoofed traffic. In its pooled ChatGPT-User count, 835 requests were verified and 878 were spoofed. Those are that study’s figures, not a correction factor for every site. In our logs, static-asset paths were around 2% verified while blog-post paths ran around 98%. The path you count can change the apparent story before you have read a single page.

Claude’s 974 permission checks were not page reads

One more filter changed the ranking. Claude-User requested our /robots.txt file 974 times without touching content on those visits. That is a permission check, not evidence that Claude read an article. Mix checks with page requests and Claude appears to read us far more often than it did.

I group requests by path and status before calling them content fetches. Requests for robots.txt or /.well-known/ go in an infrastructure bucket. A 403 or 429 goes in a blocked-request bucket. A 200 on a content path means the server returned the page; it does not prove the assistant quoted it. The log-method breakdown distinguishes successful responses from firewall blocks. If you skip this step, your most popular ‘page’ may be a permission file.

That is the practical rule for everything that follows: rank verified content requests, not every line with an AI-looking user agent.

The four-page ranking: 920 for the posts, 41 for the service page

After filtering, the homepage led the pages listed here with 781 verified ChatGPT-User content fetches. Two dated posts about Google Ads updates in 2026 followed at 546 and 374. Our main service page, which we had rewritten twice, drew 41. The source for this table is our 30-day edge-log count, not an estimate of citations.

The two posts total 920: about 53% of the 1,742 fetches among these four listed pages. That percentage is not a site-wide citation rate. It is a way to see the scale of the gap in this ranking.

The homepage complicates any tidy claim that assistants only want fresh posts. It drew 781 fetches, more than either post alone. When an assistant needs to introduce a company, the homepage is where it can look for plain facts: what the company does, whom it serves and what it costs. A separate small-site log breakdown found brand, home and portfolio pages drew 59 of 90 user fetches, compared with 12 for pricing and service hubs. That is another small window, not a benchmark for every business. It does reinforce a useful distinction: the homepage can answer an identity question even when a service page struggles to answer a timely one.

Our two posts were shaped for a different job. Each had a date in the title, a narrow question about what had changed in Google Ads, and specifics a reader could check: what a setting does now, where it lives and what to click. An assistant needing a current answer can use that material without extracting a dated fact from evergreen sales copy. The posts’ 546 and 374 fetches do not prove that mechanism caused every request. They do show where the requests landed.

There is a broader recency signal, with a limit attached. Seer Interactive found that nearly 65% of AI bot hits in its study went to content published in the past year, rising to 89% for content within three years. That study measures its own set of bot hits, not our citation outcomes. It supports taking publication date seriously; it does not mean adding a date to an empty page will make it useful.

The service page’s 41 fetches make more sense beside those figures. It explains what groas does, whom we help and why we are different. That is useful to a prospective customer, but it does not directly resolve a question about a particular Google Ads change. The page that describes your business is not automatically the page that answers the prompt.

ChatGPT and Perplexity also should not be collapsed into one behavior. One comparison reports 21.87 inline citations per Perplexity response against 7.92 for ChatGPT. Those are the comparison’s figures, not counts from our logs. I would not use our ChatGPT-User ranking to predict an equivalent Perplexity result. The question worth carrying across both is simpler: does this page contain a direct, checkable answer an assistant might need?

A 30-day log check you can run yourself

Here is the test I would run before buying an AI-visibility dashboard. Question: which pages do assistants request while answering live questions about your market? My expectation is that dated, specific answers will outrank service pages for timely questions, because they match the information those questions require. That is an expectation to test, not a result I am claiming for your site.

1. Set the window. Pull 30 days of raw access logs from your origin or CDN. Keep the window fixed so a busy publishing week does not quietly become the whole story.
2. Separate bot jobs. Find the user-fetch tokens ChatGPT-User, Claude-User and Perplexity-User. Keep the indexers OAI-SearchBot, Claude-SearchBot and PerplexityBot in a separate group.
3. Verify the claim. Check the user agent against the vendor’s published IP ranges and reverse DNS. A user-agent string alone does not establish who sent the request.
4. Separate paths and outcomes. Group by bot, path and status. Remove robots.txt and other access checks from the content ranking; keep blocked requests distinct from successful content responses.
5. Rank page types. Compare verified content fetches for home, dated posts, service pages, pricing pages and city pages. Read the page behind each count before deciding what the number means.

The controls are the point. Use the same window, verification rule and definition of a content fetch for every page type. Otherwise you can make a service page ‘lose’ by counting its blocked requests differently, or make a post ‘win’ because a spoofed scanner hammered its assets.

If dated answers lead, look at what questions they answer before commissioning more. If pricing pages lead, inspect the cost questions they address. If nothing receives verified live fetches, check access and discovery before treating publication volume as the fix. A blank log by itself does not tell you which of those is responsible.

This test measures requests, not citations or sales. It can tell you where an assistant sought content and whether your access rules allowed it through. It cannot show the answer a person saw. Use the result to choose what to inspect and publish next, not to declare an AI revenue lift.

What I would change on a business site this quarter

If a client spending $20k a month asked me where to start, I would not open with another service-page rewrite. I would publish a dated answer to a question buyers actually ask, put the answer near the top and keep the specifics current. I would also check whether the homepage states the basic business facts plainly. Our homepage’s 781 fetches are a good reason not to neglect that unglamorous work.

This is not an instruction to turn every page into a changelog. The earlier groas log cuts point in the same direction but have their own windows and counts: one reported 984 live AI fetches for two dated posts versus 70 for the service page, and another reported 972 answer fetches for two posts against 69 for the service page. They are supporting observations from our site, not independent proof that another site will get the same ratio.

I would check access rules before changing content, too. One-click AI bot-blocking lists can include search crawlers a site wants to reach. If the goal is to remain available for search while restricting training crawlers, treat those as separate choices. I approach this check at groas the same way I approach paid search: inspect what actually happened before trusting the dashboard story.

Publish the answer an assistant can use. Keep the brochure for humans who need it.

What these logs cannot prove

Three limits keep the decision honest:

• One site, one window. These are groas requests over 30 days, not an industry rate. An eight-day log analysis with 90 user fetches warned against treating its counts as trends. Publishing schedules can also change what a crawler encounters during a window.
• A fetch is not a citation. A verified content request shows that the assistant’s requester reached the page. We do not have the associated prompt or answer text, so we cannot say whether a user saw our name or clicked through.
• This is not a view of every assistant surface. The ranking is ChatGPT-User traffic, not Google AI Overviews or a Perplexity citation report. Claude’s permission checks show why even two assistants’ raw request totals cannot be compared without sorting the paths first.

The decision these numbers support is specific. In our 30-day window, ChatGPT-User requested two dated, specific Google Ads answers 920 times and our main service page 41 times; it also requested the homepage 781 times for reasons the logs cannot reveal. I would stop polishing the service page as my first citation tactic. I would publish accurate, dated answers to real questions, keep the homepage facts clear, and check the next 30 days of verified logs to see what gets requested. That is as far as this evidence takes me—and far enough to change what I would work on next.