---
title: "74% of Our robots.txt AI-Bot Hits Weren’t Verified. Why Are Agencies Reporting Raw Counts?"
description: "In 30 days of groas.com edge logs, just 26% of claimed AI-bot hits on robots.txt verified. A page-by-page look shows what agencies should report instead."
url: "https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver"
image: "https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/217fdf55-0e96-45ab-99e9-e0fe013de42e.png"
published: "2026-10-19T05:26:50.308Z"
modified: "2026-10-19T05:26:50.380Z"
---

October 19, 2026 · 10 min read

# 74% of Our robots.txt AI-Bot Hits Weren’t Verified. Why Are Agencies Reporting Raw Counts?

[Alexander PerelmanHead Of Product @ groas](https://groas.com/author/alexander-perelman)[LinkedIn](https://www.linkedin.com/in/alexander-433793253/)

![Cartoon doorman clicks a tally counter at a queue of raccoons, gnomes and vending machines all wearing 'HELLO I'M GPTBot' stickers; only one has a real pass.](https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/217fdf55-0e96-45ab-99e9-e0fe013de42e.png)

In this article

1. [What the 30-day log split can—and cannot—show](#what-the-30-day-log-split-canand-cannotshow)
2. [Finding 1: the icon folder exposes the raw-count problem](#finding-1-the-icon-folder-exposes-the-raw-count-problem)
3. [Finding 2: the busiest paths shrink under verification](#finding-2-the-busiest-paths-shrink-under-verification)
4. [Finding 3: the post and the index have opposite jobs](#finding-3-the-post-and-the-index-have-opposite-jobs)
5. [Why a domain-wide AI-visibility score misses the decision](#why-a-domain-wide-ai-visibility-score-misses-the-decision)
6. [What I would demand before white-labeling an AEO report](#what-i-would-demand-before-white-labeling-an-aeo-report)
7. [The decision these logs support](#the-decision-these-logs-support)

**Only 26% of claimed AI-bot hits on our robots.txt file were verified.** Over 30 days on groas.com, that file logged 15,515 raw hits from User-Agents claiming to be AI bots. Cloudflare verified 4,047. If an agency puts the first number in a client’s AI-visibility report without showing the second, the report is selling noise as attention.

The same split appeared elsewhere, though not at the same rate. The homepage had a 30% verified share. One blog post had a 97% verified share and 435 recorded live ChatGPT-User and Claude-User fetches. Treat those paths as one domain-wide bot-traffic number and you erase the useful part of the story.

A User-Agent is a claim, not an ID card. Any script can put GPTBot in a header. Cloudflare’s verification gives us a way to separate independently confirmed bots from requests identified only by their headers; filtering for `http.user_agent contains GPTBot` [alone does not do that](http://dev.to/lovedbyai/how-to-measure-ai-crawler-traffic-in-your-server-logs-and-why-the-average-lies-3fbg). The reporting question is not just _how many bots knocked?_ It is **which requests verified, and which pages did live-answer fetchers request?**

## What the 30-day log split can—and cannot—show

I am looking at groas.com edge logs, not GA4. Crawlers that fetch HTML without running analytics JavaScript will not appear as visits in that setup. To inspect their requests, you need server or CDN logs broken out [by path](https://kitbase.dev/blog/gptbot-explained).

For each path where the rollup allows it, I use three counts:

1. **Raw hits:** requests whose User-Agent claimed an AI-bot identity.
2. **Verified hits:** requests Cloudflare independently identified as coming from the claimed bot operator.
3. **Live-answer fetches:** requests from user-triggered fetchers, reported separately from bots that collect or index content.

Those counts answer different questions. A verified training crawler has really fetched a page, but that does not mean anyone saw the page in an answer. A live-answer fetch tells us the URL was requested in a user-triggered context; it does not prove the page was quoted, cited or responsible for pipeline. Nor does a raw count become more meaningful because someone gave it a polished chart.

GPTBot and ClaudeBot collect pages for later use. ChatGPT-User, Claude-User and Perplexity-User are the [live-fetcher distinction](https://optiseon.com/blog/robots-txt-ai-crawler-checker) that matters here. An agency report should not put them in the same bucket and call the sum _AI visibility_. That label skips the mechanism a client is paying to understand.

## Finding 1: the icon folder exposes the raw-count problem

Multiple SVG files each recorded hundreds of raw AI-bot hits and only single-digit verified hits. In that folder, roughly **98% of the claimed hits went unverified**. These were icon files, not the HTML pages someone would inspect to understand our content. They are a useful warning sign precisely because they are easy to overlook in a domain total.

I cannot tell from an unverified row who sent the request or why. I can tell that a report counting those rows as confirmed AI-crawler attention is claiming more than the data supports. A script can borrow a familiar User-Agent; an icon request does not become an answer-engine endorsement because the header says GPTBot.

A [separate controlled test](https://digimirror.io/your-bot-traffic-logs-are-lying-to-you/) illustrates the same identification problem: on a new, unpromoted domain, 6 of 33 claimed live-assistant fetches and 107 of 799 Googlebot claims verified. It also found claimed ChatGPT-User requests looking for `.env` and `config.json` rather than content. That test is not groas.com data, and I would not apply its rates to our logs. It does show why a User-Agent-only tally deserves scrutiny.

**Exclude static assets from the client-facing content total.** Keep them available for diagnosing traffic, but do not let repeated icon requests inflate a visibility claim.

## Finding 2: the busiest paths shrink under verification

| Path          | Raw claimed hits | Cloudflare-verified hits | Verified share | Recorded live-answer fetches |
| ------------- | ---------------: | -----------------------: | -------------: | ---------------------------: |
| `/robots.txt` |           15,515 |                    4,047 |        **26%** |    1,231 Claude-User fetches |
| `/` homepage  |            6,330 |                    1,916 |        **30%** |     740 ChatGPT-User fetches |

_Source: 30 days of groas.com edge logs. Verified share is verified hits divided by raw claimed hits for each path. The live-fetch column is a separate classification, not proof that every listed fetch also passed the verification check._

Both URLs invite broad traffic. Crawlers request `/robots.txt` to check rules. The homepage is the default place for a generic visitor or bot to start. That makes each path busy before we know who made the requests. On `/robots.txt`, 15,515 claimed hits become 4,047 verified ones. On the homepage, 6,330 become 1,916. **Raw volume is not a substitute for verified identity.**

The live-fetch column needs an even narrower reading. The logs record 1,231 Claude-User fetches of the rules file and 740 ChatGPT-User fetches of the homepage. A rules-file request does not mean Claude used `/robots.txt` as answer content. A homepage fetch does not establish that ChatGPT cited the homepage. Those rows tell us what the fetchers requested, not what appeared on a user’s screen.

I used to treat rising raw crawl volume as a sign of growing AI interest. I would not put that interpretation in a client report now. It tells us the server received more requests. Verification and page type have to come next.

## Finding 3: the post and the index have opposite jobs

| Path                            | Raw claimed hits | Cloudflare-verified hits | Verified share |                 Recorded live-answer fetches |
| ------------------------------- | ---------------: | -----------------------: | -------------: | -------------------------------------------: |
| `/post/google-ads-updates-2026` |              718 |                      697 |        **97%** | **435 ChatGPT-User and Claude-User fetches** |
| `/blog`                         |            1,160 | Not split in this rollup |        Unknown |                           **4 live fetches** |

_Source: the same 30-day groas.com edge-log rollup. The blog-index verification split is unavailable here; its raw count should not be read as a verified count._

The post is a dated explainer with named changes, tight sections and passages a fetcher can retrieve directly. The blog index is a list of links and excerpts. It can help a crawler find a URL, but it does not do the same job as the article at that URL. That distinction makes the path-level comparison more useful than the domain total: the post recorded 435 live fetches; the index recorded 4.

The post’s 697 verified hits out of 718 raw claims also show that low verification is not a universal condition across this site. Different URLs produced different mixes of requests. The rollup does not provide a verification cross-tab for the 435 live fetches, so I will not call all 435 _verified live fetches_. It records a strong verified share for the page and, separately, substantial live-fetch activity. That is enough to decide which URL deserves a closer look. It is not enough to declare 435 citations.

Report both paths as _bot traffic_ and the index looks busier: 1,160 raw hits against the post’s 718. **Report the available verification split and live fetches per page, and the post becomes the clear place to investigate.** The next content decision depends on that difference.

## Why a domain-wide AI-visibility score misses the decision

The reports I see from agencies tend to lead with whichever total looks largest: bot hits, mentions or share of voice across a set of engines. I understand the temptation. One number fits neatly at the top of a slide. It also lets unlike observations hide inside an average.

[Seer’s January 2026 discussion](https://www.seerinteractive.com/insights/ai-visibility-is-a-vanity-metric-prepare-your-execs) makes a related point about visibility scores: answers change with the prompt and the person, and engines do not publish rankings or prompt volume for this purpose. In its client interviews, 44% of real prompts already included brand names. A tracked mention may be worth examining, but the score alone does not tell a client what the reporting agency changed or what happened on the client’s site.

A [separate dataset covering 924 small-business sites from September 6 to October 5, 2026](http://dev.to/lovedbyai/how-to-measure-ai-crawler-traffic-in-your-server-logs-and-why-the-average-lies-3fbg) reported a median of 3.1 AI requests per Googlebot request and about 1,050 AI hits for the month. Its traffic breakdown was 11.3% live user-triggered fetches, 69.9% training and 18.8% search index traffic. Those are that dataset’s figures, not a rate I can apply to groas.com. Their value here is the separation: **a training request and a live request should not be sold as the same event.**

On our site, the distinction becomes concrete at the page level. We recorded 740 live fetches on the homepage, 435 on one post and 4 on the blog index. We also recorded 1,231 Claude-User requests for `/robots.txt`, which belong in a technical-traffic view rather than a list of content successes. Roll those together and the client gets a larger number with less meaning.

I would split a report by page cluster before writing a recommendation: content pages, the homepage, discovery pages such as the blog index, and technical paths such as the rules file. Then I would show raw and verified counts where both exist, followed by live fetches and the named fetcher. That layout makes it harder to mistake crawler housekeeping for interest in a page someone might actually read.

It also matters for bot controls. OpenAI operates separate bots, and [blocking GPTBot for training is not the same as blocking OAI-SearchBot for retrieval](https://kitbase.dev/blog/gptbot-explained). If a report cannot distinguish which bot fetched which path, it is a poor basis for deciding what to allow or block. **Keep bot identity and page purpose visible before you change a rule.**

Here is the test I would run before putting an agency logo on an AEO report:

1. Remove static assets from the content view.
2. Put raw and verified hits beside each other for every path with an available split; mark missing splits as unknown.
3. Sort content URLs by live-answer fetches, with the fetcher named.
4. Keep technical requests, especially `/robots.txt`, separate from pages that could supply answer content.

Our post’s 97% verified share, the homepage’s 30% and the icon folder’s roughly 2% tell three different stories. One domain average would bury all three.

![Chart comparing raw and verified AI-bot hits across groas.com paths](https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/f28c47c7-7b3d-443f-b61c-f85b26ab8bf5.png)

## What I would demand before white-labeling an AEO report

If an agency puts its logo on a number, it owns the interpretation. Before I would white-label a platform for client retainers, I would ask it to show the request-level evidence behind a page-level summary: the claimed bot, whether it verified, the URL fetched and whether the request came from a live user-triggered fetcher. Raw, verified and unverified requests should not silently collapse into one column.

I would also ask how the platform handles multiple client domains and prompt limits. The [pricing comparison in the draft’s source](https://aissist.io/insights/best-ai-visibility-tools) lists the following examples; tiers and included engines matter when comparing headline prices:

| Tool     | Listed starting price or plan detail                       |
| -------- | ---------------------------------------------------------- |
| Semrush  | $99 per month per domain for 25 prompts                    |
| Profound | $99 per month on a yearly plan for 50 ChatGPT-only prompts |
| Peec     | From $95                                                   |
| Otterly  | $29                                                        |
| Scrunch  | $250 yearly                                                |

Those figures are a buying checklist, not proof that any one tracker has the best data. If you manage 20 client domains, per-domain charges and prompt caps affect what you can profitably report. Ask what the quoted tier includes before building a client deliverable around it.

Prompt trackers can also disagree about the same brand because their prompt sets, sample sizes, engines and collection methods differ. Compare share of voice **within one tool over time**, not as though two tools measured an identical universe. An edge-log view belongs next to the tracker: one samples where a brand appeared; the other shows requests to pages the site served. Neither, by itself, proves a sale.

[groas for agencies](https://groas.com/for-agencies) pairs weekly Google and AI visibility tracking with content, technical fixes and citations, reported under the agency’s brand. I would still use one real client domain to inspect what a report exposes before putting that logo on it. If a platform shows only a score, I would not present the score as verified fetch evidence. The client deserves to know the difference.

![Ink cartoon of an agency sending a client a report inflated by unverified bot hits](https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/41770968-082a-4337-b631-2be077a27738.png)

## The decision these logs support

This is one 30-day rollup from groas.com, with a path list limited to the URLs that show the pattern. It is not a sitewide answer rate. Some paths lack a verification split in this rollup, and the live-fetch counts shown here are not cross-tabulated against verified status. Most importantly, **a fetch is not a citation**. I will not turn 435 live requests for one post into 435 appearances in answers.

The narrower conclusion is still decisive. On `/robots.txt`, 74% of claimed AI-bot hits did not verify. The homepage also lost most of its raw count under verification, while the post retained nearly all of its claimed hits and attracted far more live fetches than the blog index. Raw totals concealed those differences; page-level splits exposed them.

So I would stop sending clients a domain-wide raw bot-hit number as evidence of AI visibility. Send **verified hits and recorded live-answer fetches per page**, identify the fetcher, and separate content from technical paths. Mark what the logs cannot prove. For agencies choosing AEO reporting software, that is the filter: if it cannot make those distinctions, its biggest number is a vanity metric with a new name.

## Frequently Asked Questions

### On groas.com, how many of the claimed AI-bot hits on robots.txt actually verified?

Over 30 days, the robots.txt file logged 15,515 raw hits from User-Agents claiming to be AI bots, but Cloudflare verified only 4,047 of them. That is a 26% verified share, meaning roughly 74% of the claimed hits could not be independently confirmed as coming from the claimed bot operator.

### Can a request's User-Agent be trusted to prove it came from GPTBot or another AI crawler?

No. A User-Agent is only a claim, and any script can put GPTBot in a header. Cloudflare's verification independently confirms whether a request really came from the claimed bot operator, while filtering logs for the User-Agent string alone does not separate confirmed bots from faked or borrowed headers.

### Should icon and image files be counted when reporting AI crawler traffic to clients?

No, static assets should be excluded from the client-facing content total. On groas.com, multiple SVG icon files recorded hundreds of raw claimed AI-bot hits with only single-digit verified hits, meaning roughly 98% went unverified. Keep those requests available for diagnosing traffic, but do not let repeated icon requests inflate a visibility claim.

### If logs show ChatGPT-User fetched my homepage, does that mean ChatGPT cited it in an answer?

No. A recorded live-answer fetch means the URL was requested in a user-triggered context; it does not prove the page was quoted, cited or responsible for pipeline. On groas.com, 740 ChatGPT-User fetches of the homepage and 1,231 Claude-User fetches of robots.txt show what the fetchers requested, not what appeared on a user's screen.

### Which is more useful to investigate, a blog index or an individual blog post, based on AI bot traffic?

On groas.com, the blog index looked busier by raw count, with 1,160 claimed hits against the post's 718. But the post had a 97% verified share and 435 recorded ChatGPT-User and Claude-User live fetches, while the index recorded only 4 live fetches. Reporting the verification split and live fetches per page makes the post the clear place to investigate.

### How should an agency structure an AI visibility report instead of giving one domain-wide bot-hit number?

Split the report by page cluster (content pages, homepage, discovery pages like a blog index, and technical paths like robots.txt). For each path with an available split, show raw and verified hits side by side, mark missing splits as unknown, sort content URLs by live-answer fetches with the fetcher named, and remove static assets from the content view.

### Is blocking GPTBot the same as blocking OpenAI search retrieval?

No. OpenAI operates separate bots, and blocking GPTBot, which collects pages for training, is not the same as blocking OAI-SearchBot, which retrieves pages for search results. Keep bot identity and page purpose visible in the logs before changing any allow or block rule, since a report that cannot tell which bot fetched which path is a poor basis for that decision.

### What should I check in an AI visibility tool's pricing before using it for client reports?

Check the quoted tier's per-domain charges, prompt caps and included engines. Examples listed include Semrush at $99 per month per domain for 25 prompts, Profound at $99 per month yearly for 50 ChatGPT-only prompts, Peec from $95, Otterly at $29 and Scrunch at $250 yearly. If you manage 20 client domains, these caps directly affect what you can profitably report.

## Pay For Results, Not For Hours

Businesses buy the outcome, agencies resell it, and groas answers for it either way.

[See If You Qualify](https://groas.typeform.com/to/xC1bQNUT)

## Structured data

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://graph.groas.com/entity/groas","name":"groas","url":"https://groas.com/","logo":{"@type":"ImageObject","url":"https://groas.com/icon-512.png","width":512,"height":512},"sameAs":["https://www.linkedin.com/company/groas/"]},{"@type":"WebSite","@id":"https://groas.com/#website","name":"groas","url":"https://groas.com/","inLanguage":"en-US","publisher":{"@id":"https://graph.groas.com/entity/groas"}},{"@type":"WebPage","@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#webpage","url":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver","name":"74% of Our robots.txt AI-Bot Hits Weren’t Verified. Why Are Agencies Reporting Raw Counts?","description":"In 30 days of groas.com edge logs, just 26% of claimed AI-bot hits on robots.txt verified. A page-by-page look shows what agencies should report instead.","inLanguage":"en-US","isPartOf":{"@id":"https://groas.com/#website"},"about":{"@id":"https://graph.groas.com/entity/groas"},"primaryImageOfPage":{"@type":"ImageObject","url":"https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/217fdf55-0e96-45ab-99e9-e0fe013de42e.png"},"breadcrumb":{"@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#breadcrumb"},"dateModified":"2026-10-19T05:26:50.380Z","mainEntity":{"@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#article"}},{"@type":"BreadcrumbList","@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://groas.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://groas.com/blog"},{"@type":"ListItem","position":3,"name":"74% of Our robots.txt AI-Bot Hits Weren’t Verified. Why Are Agencies Reporting Raw Counts?","item":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver"}]},{"@type":"BlogPosting","@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#article","url":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver","mainEntityOfPage":{"@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#webpage"},"isPartOf":{"@id":"https://groas.com/blog#blog"},"headline":"74% of Our robots.txt AI-Bot Hits Weren’t Verified. Why Are Agencies Reporting Raw Counts?","description":"In 30 days of groas.com edge logs, just 26% of claimed AI-bot hits on robots.txt verified. A page-by-page look shows what agencies should report instead.","datePublished":"2026-10-19T05:26:50.308Z","dateModified":"2026-10-19T05:26:50.380Z","image":{"@type":"ImageObject","url":"https://pub-87da24ecbbfc4c3bad6875f3aa013712.r2.dev/generated-images/217fdf55-0e96-45ab-99e9-e0fe013de42e.png"},"author":{"@id":"https://groas.com/author/alexander-perelman#person"},"publisher":{"@id":"https://graph.groas.com/entity/groas"},"keywords":"verified, hits, robots txt, raw, fetches, robots, txt, ai-bot hits","wordCount":2125,"inLanguage":"en-US"},{"@type":"Person","@id":"https://groas.com/author/alexander-perelman#person","name":"Alexander Perelman","jobTitle":"Head Of Product @ groas","description":"My background includes Goldman Sachs and Stanford Computer Science.","image":"https://groas.com/media/blog/4f17cac3a81acc224cc1b2cfab8f94bbc295a3089d13e8421125771ef8d4064f.jpg","worksFor":{"@id":"https://graph.groas.com/entity/groas"},"sameAs":["https://www.linkedin.com/in/alexander-433793253/"]},{"@type":"FAQPage","@id":"https://groas.com/post/74-of-our-ai-bot-traffic-couldn-t-be-ver#faq","mainEntity":[{"@type":"Question","name":"On groas.com, how many of the claimed AI-bot hits on robots.txt actually verified?","acceptedAnswer":{"@type":"Answer","text":"Over 30 days, the robots.txt file logged 15,515 raw hits from User-Agents claiming to be AI bots, but Cloudflare verified only 4,047 of them. That is a 26% verified share, meaning roughly 74% of the claimed hits could not be independently confirmed as coming from the claimed bot operator."}},{"@type":"Question","name":"Can a request's User-Agent be trusted to prove it came from GPTBot or another AI crawler?","acceptedAnswer":{"@type":"Answer","text":"No. A User-Agent is only a claim, and any script can put GPTBot in a header. Cloudflare's verification independently confirms whether a request really came from the claimed bot operator, while filtering logs for the User-Agent string alone does not separate confirmed bots from faked or borrowed headers."}},{"@type":"Question","name":"Should icon and image files be counted when reporting AI crawler traffic to clients?","acceptedAnswer":{"@type":"Answer","text":"No, static assets should be excluded from the client-facing content total. On groas.com, multiple SVG icon files recorded hundreds of raw claimed AI-bot hits with only single-digit verified hits, meaning roughly 98% went unverified. Keep those requests available for diagnosing traffic, but do not let repeated icon requests inflate a visibility claim."}},{"@type":"Question","name":"If logs show ChatGPT-User fetched my homepage, does that mean ChatGPT cited it in an answer?","acceptedAnswer":{"@type":"Answer","text":"No. A recorded live-answer fetch means the URL was requested in a user-triggered context; it does not prove the page was quoted, cited or responsible for pipeline. On groas.com, 740 ChatGPT-User fetches of the homepage and 1,231 Claude-User fetches of robots.txt show what the fetchers requested, not what appeared on a user's screen."}},{"@type":"Question","name":"Which is more useful to investigate, a blog index or an individual blog post, based on AI bot traffic?","acceptedAnswer":{"@type":"Answer","text":"On groas.com, the blog index looked busier by raw count, with 1,160 claimed hits against the post's 718. But the post had a 97% verified share and 435 recorded ChatGPT-User and Claude-User live fetches, while the index recorded only 4 live fetches. Reporting the verification split and live fetches per page makes the post the clear place to investigate."}},{"@type":"Question","name":"How should an agency structure an AI visibility report instead of giving one domain-wide bot-hit number?","acceptedAnswer":{"@type":"Answer","text":"Split the report by page cluster (content pages, homepage, discovery pages like a blog index, and technical paths like robots.txt). For each path with an available split, show raw and verified hits side by side, mark missing splits as unknown, sort content URLs by live-answer fetches with the fetcher named, and remove static assets from the content view."}},{"@type":"Question","name":"Is blocking GPTBot the same as blocking OpenAI search retrieval?","acceptedAnswer":{"@type":"Answer","text":"No. OpenAI operates separate bots, and blocking GPTBot, which collects pages for training, is not the same as blocking OAI-SearchBot, which retrieves pages for search results. Keep bot identity and page purpose visible in the logs before changing any allow or block rule, since a report that cannot tell which bot fetched which path is a poor basis for that decision."}},{"@type":"Question","name":"What should I check in an AI visibility tool's pricing before using it for client reports?","acceptedAnswer":{"@type":"Answer","text":"Check the quoted tier's per-domain charges, prompt caps and included engines. Examples listed include Semrush at $99 per month per domain for 25 prompts, Profound at $99 per month yearly for 50 ChatGPT-only prompts, Peec from $95, Otterly at $29 and Scrunch at $250 yearly. If you manage 20 client domains, these caps directly affect what you can profitably report."}}]}]}
```