Two Google Ads Posts Drew 972 AI Answer Fetches. Our Service Page Drew 69.

Two dated Google Ads posts drew 972 verified live-answer fetches in 30 days. Our /for-businesses service page drew 69. If I were choosing which page to write next for AI search, I would not start by polishing the sales pitch.

The combined total for those posts is roughly 14 times the service page’s total. That is not a controlled comparison: it is two pages against one, on one site, over one month. It is still a useful signal about what assistants reach for while assembling answers. A dated explanation of a specific change gives an assistant something to use. A page explaining why you should hire us usually does not.

I used to tell clients that a tighter service page would earn more citations. I was wrong to treat that as the obvious first move. Our logs cannot tell me which fetches became citations, but they can tell me which pages the live-answer bots requested. The difference is worth looking at before anyone rewrites another headline.

The 30-day count: verified fetches, not raw bot hits

Raw bot traffic is a poor starting point. Any requester can put GPTBot in a user-agent header. For this analysis, I counted requests from vendor-published IP ranges, following the distinction between claimed and verified AI crawlers. Then I separated live-answer fetches from visits by training crawlers. The table below covers verified requests by bots used for on-demand answers or search, not every request carrying an AI-looking name.

The source for those counts is our edge logs. The two posts drew 972 fetches combined; the service page drew 69. The homepage drew 815 live-answer fetches, 777 of them from ChatGPT-User. Those homepage requests deserve their own explanation, because treating every page hit as the same kind of interest would make the comparison less useful.

These are request counts, not unique assistants, people, prompts or citations. Nor do the logs tell us why each request happened. They show a striking difference in what got fetched. The argument for publishing reference pages starts there, not with a claim that every fetch produced a link.

Why an assistant needs a reference page mid-answer

Start with the one fact everything else follows from: an assistant cannot cite a page it has not fetched for that answer. The bot jobs matter because their requests do not mean the same thing. Training crawlers such as GPTBot and ClaudeBot gather material for future models. Search bots such as OAI-SearchBot and PerplexityBot support live discovery. On-demand bots such as ChatGPT-User and Claude-User request a URL in response to a user’s activity. That division of bot jobs is why I filter before I draw conclusions from the logs.

Take a question like what broke in GA4 in April 2026 for Google Ads tracking? An answer needs a date, a description of the problem and something the reader can check. A dated update post is built to supply those pieces. Our service page has another job: it explains who we help and what we run. Both pages can be useful to a person. Only one is a natural source for the specific factual answer in that example.

That is the first-principles case for leading an update with a short, direct answer and clear supporting detail. Article schema and an extractable answer can help make the page legible, but they do not make it true, relevant or certain to be cited. The example also has a limit: our edge logs do not include the prompt that caused a fetch. I can explain why that question calls for a reference page; I cannot claim it produced any particular request in our count.

The practical distinction is simple. Give the sales page the job of selling. Give the dated post the job of answering one question well.

The post-versus-service split: strong signal, narrow sample

Both high-fetch posts name a change in Google Ads or GA4, give it a date, and explain what broke and what to check. The /for-businesses page says who we help and what we run. When I managed accounts, I would have filed the first kind under reference and the second under sales. The bots’ requests split heavily toward the reference material.

I would not call the roughly 14-to-1 combined ratio a universal preference for blogs over service pages. We compared two update posts with one service page; the logs do not isolate page format from subject, timing or the questions people were asking. They do support a more useful editorial decision: when the answer requires a dated fact, publish the page that supplies it instead of expecting a general sales page to do that work.

The external citation figures point in a compatible direction, with a different measurement. A Perplexity citation analysis reports that about half its citations came from content published in 2025. It describes eligibility peaking at 0 to 7 days, falling about 40% at 30 to 90 days and about 65% past 90 days. It also estimates roughly 10 pages retrieved per query, with only 3 to 4 cited. Those are findings about that study’s citations and retrieval, not a formula for interpreting our fetch counts.

Still, the editorial implication is hard to miss. A page that says exactly what changed has a reason to enter a narrow answer. A page that says we run your ads around the clock has a reason to enter a buying conversation. I would write and maintain both. I would not ask the second page to substitute for the first.

Different bot behavior changes what a request means

The next split is not between pages. It is between bots. In the same 30-day edge-log window, Claude-User requested robots.txt 1,018 times. ChatGPT-User accounted for 777 of the homepage’s 815 verified live-answer fetches and barely touched robots.txt.

That is a behavior difference in our logs, not proof that either assistant cited the homepage. The access distinction fits the reported policies: Claude-User respects robots.txt, while ChatGPT-User may treat a user-initiated fetch differently. In plain English, Claude checks the door; ChatGPT may arrive because a user pointed it at the address. The analogy stops there. A robots.txt request is not a reading of an article, and a homepage fetch is not a citation.

The reported 11% domain overlap between Perplexity and ChatGPT citations on identical queries is another reason not to treat AI search as one audience. That figure comes from a citation comparison, not our site logs, and it does not tell us which of our posts either product cited. It does suggest a practical test: check access for each relevant bot, then measure appearances in each answer surface separately. The access checklist is a better first stop than another round of copy edits if the bot cannot reach the page.

Fake bot traffic is the easiest number to overreport

Our image, JavaScript and CSS paths also drew requests bearing AI user-agent strings. Almost all of that asset traffic was unverified. Those requests are a good reminder that a header is a claim, not an identity. One documented actor posed as about 32 AI bots while probing roughly 90 secret paths, including .env files and cloud keys. That example does not explain every unverified request in our logs. It shows why I will not call an unverified asset hit assistant interest.

For a client report, I would filter in this order:

1. Verify the requester against the relevant vendor-published IP ranges rather than trusting its user-agent string.
2. Separate bot jobs. Keep training crawlers out of a live-answer fetch total.
3. Count relevant pages. Article and service-page requests answer a different question from asset requests.
4. Label the metric honestly. A verified live-answer fetch is still not a citation.

Skipping that sequence makes a large bot-traffic chart easy to produce and hard to use. I have spent enough time reporting ad metrics that looked healthy while CPA went the other way. I do not want to repeat the exercise with crawler logs.

What the logs cannot prove

A fetch is not a citation. Our edge logs show that a verified bot requested a page. They do not show the full answer a reader saw, whether our domain appeared as a linked source, or which prompt caused the request. To measure citations, I need prompt-level observation in addition to request logs.

The sample has other limits. It covers one site, 30 days and a niche where platform changes arrive regularly. A plumber answering emergency water heater repair cost faces a different kind of freshness pressure from a site answering what broke in GA4? The 972-to-69 split is evidence about this site and these pages, not a forecast for the next industry or month.

It also says nothing directly about Gemini or AI Overviews. And it cannot establish that adding a date, schema or a changelog will cause a citation. Each may make a useful page easier to interpret or keep current; none turns our request counts into a controlled test. Use the logs to choose what to investigate next, not to declare victory.

Build the page a specific question needs

The content decision is narrower than “write more blog posts.” Start with a buyer question that requires a current, checkable answer. What changed in Google Ads match types last month? What should I check after a GA4 tracking change? Then make one reference page do that job. A broad post covering every possible update is harder to keep specific; a service page is trying to accomplish something else entirely.

My working structure would be:

1. Answer the question up front in 2 to 3 sentences, without making the reader hunt for the change.
2. State the date and the change so the answer has context.
3. List what to check in order when the question calls for a fix.
4. Keep the page current with a visible changelog when the underlying information changes.
5. Check access and extraction before assuming the writing is the problem.

That is a publishing plan, not a promise that a bot will cite every page. The direct-answer and schema playbook is useful for presentation; the page still has to answer the question. In my old account work, the pages that helped were rarely the clever ones. They were the dated checklists that let someone act without decoding a pitch.

Freshness needs maintenance rather than a new URL every time. If a question keeps coming up, update the existing page and show what changed. If it stops mattering, let the page age. The reported Perplexity drop after 30 to 90 days is a reason to review time-sensitive posts, not a reason to change a date on unchanged copy. Publish for the prompt, not just the keyword.

Access comes next. Allow the search bots you want to reach the page, including OAI-SearchBot, PerplexityBot and Claude-SearchBot. If you do not want training crawlers such as GPTBot and ClaudeBot, treat that as a separate decision rather than blocking every AI bot indiscriminately. Verify the requests that follow. Our Claude-User and ChatGPT-User counts are precisely why I would not assume every bot handles access in the same way.

Test citations with prompts, not with a fetch total

The next measurement should start where these logs stop. I would keep a short, fixed set of buyer questions: dated update questions, troubleshooting questions and a brand-oriented question as a contrast. Run the same wording each week across ChatGPT, Perplexity, Gemini and AI Overviews. Record whether the domain appears as a linked source, then note which reference pages were published or refreshed. Do not call a plain-text mention a citation.

That test also keeps the external freshness figures in perspective. The citation-age comparison reports that about 29% of ChatGPT citations came from 2022 or earlier, while Perplexity leaned more heavily on newer pages. It does not follow that one fixed refresh schedule wins everywhere. A lasting explainer and a dated update serve different questions; test each against the answers your buyers actually request.

At groas, that loop belongs alongside the new pages and technical fixes in our SEO & AI Search work. The point is not to present fetches as a win. It is to see whether a page built for a real question becomes a cited source, then keep the useful pages accurate. If you run the work in-house, the same small prompt list and citation log will tell you more than a rising total of bot requests.

Here is the decision the numbers support. If the next question is about a recent Google Ads change, publish the dated explanation and make sure the relevant bots can reach it; do not expect /for-businesses to answer it for you. In our 30-day logs, two update posts drew 972 verified live-answer fetches and that service page drew 69. That does not guarantee the next post a citation. It gives me a better place to put the next hour of work: write the page the assistant needs mid-answer, then check whether it actually gets cited.