Two Google Ads Posts Drew 984 Live AI Fetches. The Service Page Drew 70.

Two dated Google Ads changelog posts drew 984 verified live-answer fetches in 30 days. Our service page for businesses drew 70. The pages we wrote to explain a change were fetched far more often than the page we wrote to sell the service.

I expected the homepage and service page to dominate. They are the pages we polish, the ones meant to turn interest into a call. Instead, the two changelogs kept getting pulled when assistants looked for material to answer a question. They had dates and specifics. They did not have a sales pitch.

That does not mean they were cited 984 times. A server log records a fetch, not the answer a person saw. But it does show which pages reached the live-retrieval stage. Here is the count, what went into it, and where the evidence stops.

First, separate an answer-time fetch from a bot visit

Raw bot logs lie if you let them. I learned that the usual way: by counting too much first. One operator reviewing 34 days of Caddy logs found spoofers claiming names like GPTBot and ChatGPT-User while probing /wp-admin and landing on 404s. We counted successful page responses, not every request that wore a familiar user-agent string.

A 200 response is only the first filter. A user agent is not proof of identity; anyone can type ChatGPT-User into a request. We checked the requesting IP against operator-published ranges or used reverse and forward DNS verification. That keeps a scraper wearing an assistant’s name out of the live-fetch count. The same log-analysis example shows why that distinction matters.

We also kept provider-side fetches separate from human visits. When an assistant requests a page with a dedicated user agent, the provider fetched the content. When a browser arrives with an assistant as its referrer, a person clicked through. Those are different events, and origin logs can distinguish them. Neither event, on its own, tells you what the assistant wrote in its answer.

That is the counting rule for everything below: verified answer-time page fetches that returned HTTP 200, not training crawls, index crawls, asset requests, spoofed bots, or referred human visits.

The 30-day result: two changelogs, 984 fetches

We measured 30 of 30 days. The table groups verified live-answer fetches by page; it does not count citations or clicks.

The two posts add up to 984 fetches, or about 33 a day across the measured period. Post A averaged roughly 19 a day; post B, roughly 14. The service page averaged a little over two. These are our site’s counts, not a benchmark to apply to someone else’s pages.

The homepage complicates a neat content beats everything story: at 823 fetches, it was busy too. But a homepage fetch does not tell us whether the assistant used the homepage as background, considered citing it, or simply checked what the site was. I used to count that kind of hit as a visibility win. I would not do that now. Retrieval is an opportunity to inform an answer, not proof that the page became the answer.

What the table does show is narrower and more useful. Two pages about dated changes drew far more live fetches than the page built to convert a business prospect. That difference is worth understanding before spending another week rewriting a service-page headline for “AI visibility.”

Why a dated page gives an assistant something to retrieve

Start with one fact: a time-sensitive question needs time-specific material. An assistant can produce a general explanation without opening our site. A question about what changed in Google Ads in a particular month gives it a reason to look for a current, checkable page.

A live-answer fetch is that look at answer time. It differs from a training crawl, which gathers material for future models, and an index crawl, which builds a searchable store. The bot categories matter because their counts answer different questions. GPTBot and ClaudeBot are training bots; OAI-SearchBot and PerplexityBot serve search or indexing; ChatGPT-User and Claude-User are associated with live retrieval. Blocking these categories has different consequences. Across Cloudflare traffic to mid-2025, one breakdown put training at roughly 80%, search at 18%, and user fetches at 2%. That is not our site’s split. It explains why a grand total of “AI bot hits” can bury the small category this analysis cares about.

Take a running example. Someone asks what changed in Google Ads reporting in April 2026. The date makes an undated overview less helpful. An assistant retrieving candidate pages has a reason to inspect an entry that names the change, states when it happened, and explains the relevant setting. A service page saying we manage Google Ads around the clock serves a different purpose. It tells a prospective client what we do; it does not settle the dated question.

That model does not promise a citation. Another page might answer better, or the assistant might use an index rather than fetch from our origin during the prompt. It explains why a dated, specific page is a plausible retrieval candidate. I cover the broader process in how to get cited in ChatGPT and Perplexity. For this dataset, the practical point is simpler: write the page that resolves the question, not another description of your company.

Pattern 1: specificity beat the service pitch

The two most-fetched content pages share a job. Each records what changed in Google Ads, when it changed, and what someone should do next. The service page has another job: explain our offer to a person considering it. I would not replace one with the other. A business still needs a page that converts visitors who are ready to talk.

The wider citation data points in the same direction without proving why our pages were fetched. One study of 680 million citations reports 21.87 citations per Perplexity answer versus 7.92 for ChatGPT, with about 11% domain overlap. It also reports cited URLs as roughly 25.7% fresher than organic results: 1,064 days old versus 1,432. Those are figures from a separate study, not measurements of our two posts. They are a reminder that assistants do not all draw from the same set of pages, and that recency can matter when a question calls for it.

An independent 34-day site-log analysis also found assistants pulling thorough, single-topic pages. Again, it is another site. Our evidence is the table: the dated posts drew 984 fetches; the service page drew 70. If the question asks what changed, give it a page that says what changed.

Pattern 2: ChatGPT and Claude did not leave the same trail

The counts show what got fetched. The request patterns add a second distinction: ChatGPT-User and Claude-User did not behave alike in these logs. We saw repeated ChatGPT-User bursts on the changelog posts. Claude-User was lighter and slower, with a /robots.txt request before its page fetches.

Controlled probes documented similar differences in request behavior: ChatGPT-User/1.0 pulled several candidate pages in a burst, while Claude-User/1.0 checked /robots.txt before fetching a page. That external observation helps interpret the shape of the traffic. It does not let me read the model’s mind. A burst is consistent with an assistant examining candidates; the log alone does not reveal which one it trusted, cited, or showed to a person.

That limit matters when you set a goal. If bot protection breaks ChatGPT-User fetches, the assistant cannot read those pages through that route. If fetches rise, you have evidence of more retrieval, not necessarily more mentions. Keep bot access and answer appearance as separate measurements.

Pattern 3: asset hits make a busy site look visible

Image files, CSS, and JavaScript bundles collected thousands of incidental requests as bots and scrapers moved through the site. They are not page fetches for this analysis. Add them to the total and almost any page can look busy. Remove them and the result is easier to read: two changelog posts drew substantial live-retrieval traffic; the service page did not.

A conventional analytics view can miss the other side of the story. Most AI crawlers do not run JavaScript, so GA4 may not record those provider-side requests. Server or CDN logs are the place to count the requests; browser analytics serve a different purpose. If you judge answer-time fetching only in GA4, you may be grading a test the bots never sat.

What to publish instead of an “AI-optimized” brand page

Stop treating “optimize your brand for AI” as a content brief. It does not identify a question or tell a writer what evidence the page should contain. Our logs point to a more concrete choice: publish a page that answers one time-sensitive question you actually understand.

For a dated change, I would make the page easy for both a reader and a retriever to use:

• State the change and its date near the top.
• Put the direct answer in the first two paragraphs.
• Use headings for the specific questions the page resolves.
• Explain what the reader should check or do next.
• Show the author and update date so the page’s timing is clear.

Those are writing decisions, not a guaranteed citation recipe. The mechanism is that a page answering a narrow, dated question gives a retriever relevant material to inspect. Whether an assistant cites it remains a separate outcome.

This will not work for everyone. If buyers do not ask time-sensitive how-questions in your category, a changelog will not rescue your visibility. Find the buying question they do ask and answer it just as narrowly. Keep the service page for the person deciding whether to hire you.

Measure retrieval and citations in two separate columns

You do not need to buy a dashboard before you know what you want it to count. Start with two checks, kept apart:

1. Count verified fetches. Pull server or CDN logs weekly. Verify the provider, keep successful page requests, and group *-User fetches by page and bot. Exclude training crawls, index crawls, assets, spoofers, and human referral visits. One 34-day analysis found 1,907 live retrievals versus 6,096 indexing fetches. Those are not interchangeable counts. Our longer account of the raw-versus-verified distinction is only 26% verified on robots.txt.
2. Check the answers people see. Write 25 to 40 real buyer prompts. Use the same wording in ChatGPT, Gemini, Perplexity, and Google AI Overviews; record whether your business is named, linked, and described accurately, along with the cited URLs. Repeat weekly for a month. That separates presence, proof, and portrayal from a server-side fetch count.

Other reporting belongs in its own column too. The Search Console report for Google’s generative features describes impressions by page, country, device, and date, not the origin fetches counted here. Treat an impression as an impression. Do not fold it into a traffic-growth chart and call the result citations.

There are limits even with clean logs. This is one B2B search-marketing site over one month, on pages we chose to publish. It will not predict the split for a plumber or a Shopify store. Origin logs also miss retrieval paths that do not make an identifiable request during the prompt window. In controlled probes, Gemini answered from an index without an observed prompt-window fetch, while other assistants appeared under ordinary browser user agents. Our verified counts deliberately leave requests we cannot identify out.

Nor is one manual prompt check a permanent verdict. A separate analysis found AI Overviews had about a 70% chance of changing between checks. That is a reason to repeat the same prompts, not to turn a single favorable answer into a case study. Where our data runs out, it runs out: the logs tell us which pages were fetched, not which wording earned a citation or a click.

The decision the numbers support is plain. Publish a dated page when you can answer a real, time-sensitive buyer question; put the answer up front; and keep the service page for humans ready to consider the service. Then track verified live fetches beside the answers your prompt checks actually show. If the dated pages climb while the service page sits near the 70 fetches we saw in our month, that is not a reason to rewrite the service page as a changelog. Retrieval and conversion are two different jobs. Build for both, count them separately, and stop paying for advice that confuses one for the other. The related raw-versus-verified count of 13,774 hits and 3,482 verified requests shows why the counting rule comes first.