Visibility

People don't only Google you anymore. They ask ChatGPT. They ask Claude. They ask Perplexity.

Visibility (formerly the AI Visibility Engine) tracks how your brand shows up across AI answer engines, finds the questions you should own, ranks them by likely business impact, and writes research-grounded content to earn those answers — every piece routed through a review queue before it goes live.

What it does

Visibility works in two layers.

Layer one — visibility probing. Once a week, the fieldset asks the major AI answer engines the questions your customers ask and records whether — and how — your brand shows up. It covers Claude, ChatGPT, Gemini, Perplexity, and Google AI, then cross-references what it finds with your search data to spot the gap between where you rank in classic search and where you appear in AI answers.

Engine answers are collected through DataForSEO, a third-party data provider that queries the answer engines on our behalf. On Belay doesn't ask the engines directly — going through one measurement provider is what keeps a "Claude answer" and a "ChatGPT answer" comparable week over week, and it means you don't need your own account with any AI provider.

Layer two — content generation. From those gaps, the fieldset generates research-grounded content designed to be cited: full blog posts, FAQs, "quick takes," and SEO meta. It grounds each piece in your brand profile and product facts so the content is accurate and brand-true, not generic. Everything lands in a review queue first — nothing publishes automatically.

You can also seed your own topics. When you know a subject your brand should own that the system hasn't detected yet, use Seed a Topic to add it and generate content for it immediately, without waiting for the next probe cycle.

The fieldset's dashboard is organised into three tabs — Data (what's happening), Recommendations (what to do about it), and Actions (the queue of work you've accepted).

The guided tour

The first time an admin opens a fully set-up Visibility dashboard, a short guided tour offers itself — seven steps across the three tabs, explaining what each headline number counts and what it is a share of. That matters more than it sounds: the Data tab draws its figures from six different sources that cannot be compared with each other, and the two easiest numbers to confuse both use the word "read". The tour is there to stop you dividing one into the other.

You can reopen it any time from Guide in the header, next to Prompts and Questions — it is not a one-time thing. Esc closes it and keeps your place; Skip tour closes it and does not offer it again. Your choice is yours alone: dismissing the tour does not hide it from your colleagues, and it follows you between browsers and devices.

Who it's for

Brands that live or die by being found — and increasingly, by being recommended by an AI. If your customers research before they buy and you want to be the source the answer engines cite, this fieldset is built to measure and improve exactly that.

Prerequisites (required integrations)

Shopify — required. The content layer needs an active Shopify connection (this is where finished articles are published) and a completed Brand Intelligence run for your org. Connect Shopify at Dashboard → Integrations.
Google Search Console — strongly recommended. Your real query, impression, and ranking data is one of the signals used to rank gaps by impact; without GSC the probe still runs, but the ranking loses that comparison.
Cloudflare — optional, and only possible if your site is behind Cloudflare. This powers the AI-crawler feed; see Is AI reading your content? below.

If the prerequisites aren't met when you try to generate, On Belay tells you what's missing and points you to setup.

Setup (step-by-step)

Enable the fieldset. Go to Dashboard → Fieldsets, find Visibility, and enable it (admin only). You'll pass through the standard requirement check and consent step.
Connect Shopify at Dashboard → Integrations if it isn't already. Connecting it kicks off Brand Intelligence — a research pass that builds the brand profile every content prompt draws from. Give it a few minutes to complete.
Connect Google Search Console so your real search performance can feed the impact ranking.
Pick the blog you want to publish to. In Settings, choose which of your Shopify blogs approved posts land on. If you don't choose one, On Belay falls back to your store's first blog.
Review your prompts and topics. Open the fieldset's pages to check the seeded prompts and the question bank the prober uses. The fieldset ships with proven defaults; refine them to your brand and the topics you most want to own.

Configuration

Manage everything from the Visibility pages in the dashboard:

Questions ("Probe questions") — the list of questions the prober asks the answer engines. This is the core of the fieldset; see Probe questions below. Any member can view the list; admins can add, edit, and remove.
Prompts ("Writing instructions") — editable prompts per content type (blog post, FAQ, quick take, meta) that tune how the engine writes. The Prompts page is admin-only — members are sent back to the dashboard — as are saving, resetting, and reverting to an earlier version, in line with every other change that affects what gets published. This is a different control from Questions.
Settings — run options including the Shopify blog you publish to, your Slack delivery channel, and your Top products list.
Seed a Topic — the admin-only button to add a topic and generate all four content types for it on the spot.

Probe questions (the question bank)

Visibility runs on a list of probe questions — the natural-language buyer questions it sends to the answer engines (for example, "what's the best espresso machine for a home barista"). This question bank is the core of the fieldset, and it drives both layers:

Probing — once a week the prober sends every active question to Claude, ChatGPT, Gemini, Perplexity, and Google AI and records, for each question and each engine, whether your brand was mentioned, where it placed, and which competitors and citations showed up.
Content topics — the content generator drafts a piece for questions that don't have one yet, so the questions you're measured on are the same ones you create content to win.

Where the questions come from

When you enable the fieldset (after Brand Intelligence completes), On Belay generates an initial set of about 50 brand-specific questions from your brand profile — your name, site, differentiators, product categories, and competitors — each tagged with a category (comparison, buying guide, category intent, problem/solution, brand-specific) and a funnel stage (awareness, consideration, decision).
The pool tops itself up automatically with new AI-generated questions as the content generator works through it.
You can add your own at any time.

Managing the question list

Open Dashboard → Fieldsets → Visibility → Questions (the page is titled "Probe questions"). Any member can view the list; admins can add, edit, and remove questions.

Add and edit — questions are entered and edited inline; each is capped at 500 characters.
Remove — removing a question stops it being probed and used for content. It's a soft delete, so the visibility history already collected for that question stays intact.
Keep a healthy set — aim for at least 10 active questions; the prober needs a reasonable bank for meaningful results. The page shows a warning if you fall below five.

Using Seed a Topic also adds that topic to this list for future probing.

Gap intelligence (which gaps are worth your time)

A "gap" is a question where the answer engines name your competitors and not you. Finding them is the easy part — a busy brand will have hundreds. The useful part is knowing which ones to fix first.

Every gap is scored 0–100 for likely business impact, and the gap list is ranked by that score rather than by how often the gap fired. The score blends five things:

Demand — how much real search volume the question represents.
Commercial value — whether it's a buying question or idle curiosity, and whether it touches one of your best-selling products.
Winnability — how close you already are (a question you rank #4 for in classic search is far easier to win than one you don't rank for at all).
AI leverage — how many of the five engines the gap shows up on.
Gap severity — how often and how recently it fired.

Signals that aren't available simply drop out of the blend — no connected search data means the gap is still detected and still ranked, just on fewer signals. Nothing is ever invented to fill a hole.

Each ranked gap also carries a recommended next move, and gaps that are really the same underlying question are grouped so you don't write four articles for one problem. Open Recommendations on the dashboard, or "See all" to browse the full ranked list.

The Authority Plan

Some AI answer engines look things up when asked; others answer from what they already learned during training. That distinction decides what actually moves your visibility, and it's why publishing more of your own content sometimes changes nothing.

The Authority Plan, refreshed each probe cycle, reads your own measured results and tells you:

Which engines you win by retrieval and which you lose to memory — for example, strong on Google AI and Perplexity (they fetch and cite), near-zero on ChatGPT, Claude, and Gemini (they recall). Retrieval problems are fixable on your own site in weeks; memory problems only shift when third parties talk about you, and that takes months.
Ranked authority levers — the off-site surfaces the engines actually cite for your category (video, community, editorial, and so on), ordered by what would move your numbers, with the reasoning and the probe questions each lever addresses.
Concrete targets — specific pieces to create for each lever, plus the top handful of highest-leverage moves overall.

Every number in the plan comes from your own probe data. It explains real gaps rather than inventing them.

Top products

You can tell Visibility which of your products matter most, and it will mention your best-selling products by name in the content it generates. Find this at Dashboard → Fieldsets → Visibility → Settings → Top Products. It's optional — content still generates without it — and managing it is admin-only.

Synced automatically from your Shopify order history. On Belay builds your top 50 products by revenue and by units sold over the last 180 days from the order data it already syncs for you, and refreshes the lists weekly. This works on any Shopify plan — there's no Plus requirement and no extra call to Shopify. You'll see two tabs — by revenue and by units sold — and admins can click Sync now to refresh on demand. It's the same product leaderboard the BI Dashboard shows, so the two can't disagree.
A product's variants are counted together. If you sell a machine in three colourways, the list shows one entry with the combined sales of all three — not three entries repeating the same product name. Ranking is by that combined total, so a product that sells across several variants is no longer pushed down the list by a single-variant product that sold less overall.
Or upload a CSV. You can still supply the list yourself: open Upload product list, drag in a .csv (up to 500 KB), and save. The uploader reads Shopify's own "Total sales by product" export directly and keeps the top 50 by sales. A preview shows the first rows before you save.

If your store has no order history yet, you'll see an honest empty state rather than a made-up list. If you're not an admin, you'll see a note asking an admin to handle it.

How it runs (schedule)

Several cadences run in the background:

Visibility probing runs once a week, on Tuesdays (UTC) — probing Claude, ChatGPT, Gemini, Perplexity, and Google AI for your bank of questions. It's deliberately weekly: visibility doesn't move meaningfully day to day, and probing more often multiplies measurement cost without adding signal.
Gap scoring and the Authority Plan refresh off each probe cycle, so your ranked gaps and your plan reflect the latest week's results.
Content generation runs daily at 12:00 UTC for enrolled orgs, drafting content for detected gaps and seeded topics.
Writeback runs nightly around 2am UTC, publishing only the content you've approved.
Top products re-sync weekly.

You can trigger generation for a specific topic immediately with Seed a Topic rather than waiting for the next cycle.

"Can't compare to last month" — when we withhold the change figure

Alongside your headline share you'll usually see a change figure — +3 pts/30d beside the big number, and +3 vs last month on each engine card. Sometimes one or more of those is replaced by a neutral "Can't compare to last month" or "New way of asking", with a sentence explaining why.

That is deliberate, and it is not a data outage. It means we changed how we ask the AI engines somewhere between the two periods being compared — a new model version, or a change to where the answers come from. When that happens, the two periods aren't measuring the same thing, so subtracting one from the other would report a change you didn't make.

Three things worth knowing:

Your current share is unaffected. A change in how we measure doesn't make this period's number wrong — only the comparison against the previous one. The headline percentage keeps rendering as normal.
It's per engine. If we only changed how we ask ChatGPT, only ChatGPT's card withholds its change figure. The other engines keep theirs.
It corrects itself. Comparison resumes once the change date is a full period behind us. The date is named in the explanation, so you can tell when that will be.

We show the reason rather than simply hiding the figure, because a missing change figure looks exactly like a flat month — and those are very different facts.

Spending limits on a generation run

Each daily generation run has a spend ceiling, and so does each individual article. These are runaway protection, not a budget you're expected to bump into — a typical run costs a couple of dollars and a typical article well under one, so in normal operation you will never see either take effect.

If a run does approach its ceiling, it stops taking on new topics and finishes the ones already in progress cleanly, rather than being cut off mid-article. If a single article approaches its own ceiling, that article stops and the rest of the run carries on, so one problem topic can't consume the whole day's generation.

When this happens you'll see it, not guess at it:

The affected article shows its finished parts normally, and the parts that never ran are marked skipped rather than left looking queued forever.
A skipped article is not fact-checked — the fact check is part of what stops, so its verification shows as not run. It is never labelled as having passed a check that didn't happen.
The run itself records why it stopped short, and the daily run is reported as partial rather than as a clean success.

Topics a run declined aren't lost — they stay in the question bank and are picked up by the next run.

Review & approval

Generated content collects in the Review Content queue. Each draft — blog post, FAQ, quick take, meta — can be read, edited, and approved. Manually seeded posts carry a "Seeded" badge so you can tell them apart from auto-detected work. Regenerating and editing are unlimited. As with every On Belay fieldset, nothing reaches a live system without a human approval.

The queue also keeps your published history. Filter tabs are Ready to Review, Approved (approved and waiting for the nightly publish), Published, and All. Every article you have published stays listed with a green "Published" badge and a View live article link, so the queue is a full record of what the fieldset has produced rather than only what is outstanding. If you have no drafts waiting, the queue opens on All so you land on that history.

All means every post in your org. That includes posts still queued for generation ("Queued"), posts a reviewer flagged for regeneration, and posts whose generation failed — all three used to be missing from every tab, so a queue could hold posts you had no way to see or delete individually. They are listed under All. The content-type tabs — Blog Post, FAQ, Quick Take, SEO Meta — are narrower: a post shows under one of them only if that particular piece is neither queued nor failed. A flagged piece still shows under its own tab; a queued or failed piece shows under none. So a post whose four pieces are all queued, or all failed, appears under All and nowhere else. Wherever they are listed, each can be opened, selected for bulk rewrite, or deleted like any other unpublished post. They are not counted as work: Ready to Review and Approved still show only posts with content a human can act on, which is what the counts on the Actions tab refer to.

Published articles can't be regenerated. Once a post has gone live on your site, every rewrite path — the per-post Regenerate button, bulk rewrite, and the "rewrite existing drafts" offer on the Prompts page — skips it and tells you it did. This is deliberate: the engine publishes a post once, so rewriting a live article would replace your draft while leaving the published version on your site untouched and unreachable. To change something that's already live, edit the article in Shopify. To cover the topic again from scratch, seed it as a new topic.

They're read-only everywhere else too. In the queue a published article can't be selected for bulk actions and carries no Delete, Approve, Flag, or Schedule button. Opening one shows the article and what it cost, but the copy can't be edited — for the same reason, an edit here would never reach your store. Their status pills describe the live article rather than the draft it came from: each of the four pieces reads Published, or Not included if that piece was never produced, or Partial if it produced some content but did not finish. A published article is never labelled "Ready to review" or "Generation failed", whatever its internal status says. This reads the same in the queue and on the article page — open a published post and a piece that was never produced says Not included where its content would be, rather than claiming a generation is still in progress on an article that is already live. If that piece failed to generate, it says so: "Not included — this piece didn't generate before the article went live." The article itself is fine; that one piece is missing from it.

The Review Content queue is admin-only — a member who opens it is sent back to the dashboard — as is approving, the bulk Approve all ready action, and Clear queue.

Clear queue removes unpublished drafts only; published articles are never deleted. The button states how many posts it will delete — for example, Clear 65 queued posts — and that number is the org's full unpublished set, which is still wider than what any one filter tab lists. If nothing in your org is unpublished, no button appears.

The count is re-read when you click, before you're asked to confirm, so the number in the confirmation is current rather than whatever was true when the page loaded — generation and publishing both keep running while a page sits open. If everything was published in the meantime you're told there is nothing to clear instead of being asked to confirm a deletion of zero posts. After it runs you're told exactly how many posts were removed.

Most of Visibility is admin-only today: the main dashboard, Review Content, Fresh gaps, After publishing, Authority drilldowns, and Prompts all send members back to the dashboard. Questions, Brand Intelligence, and Settings are the exceptions — members can open those and see a read-only view. Per-fieldset access for specific groups is not built yet.

Duplicate-title protection

Approving a blog post is the point of no return: the nightly writeback publishes it with no further check. So On Belay blocks an approval that would put a second article with the same title on your store.

Approving one post. If another post in your org has the same title and is either already published or already approved and waiting to publish, the approval is stopped and you're told which post it collides with. If it really is a distinct piece you want anyway, confirm and it goes through — the block is a stop sign, not a locked door.
Approving in bulk. The bulk action doesn't fail because one post collides. It approves everything it can and holds back the duplicates, then tells you the split — for example, "3 approved, 2 skipped". The skipped drafts stay in your queue untouched, so you can edit, retitle, or delete them.
Duplicates inside the same batch. If you select five drafts that all share a title, exactly one is approved and the other four are skipped. You don't get five copies of the same article.
Scheduling is covered by the same check, since a scheduled post publishes on the same path.

Titles are compared ignoring case and punctuation, so "How To Brew!" and "how to brew" count as the same title.

What each article cost to generate

Every draft in the review queue shows what it cost in AI spend to produce, and the article detail page breaks that total down by generation stage — the article draft, FAQ, quick take, SEO meta, and the two verification passes. Typical articles land under a dollar.

Cost tracking for individual articles started partway through this fieldset's life, so you'll see three different things and they mean three different things:

A dollar figure — the spend actually recorded against that article.
"Not measured" — the article was written before per-article cost tracking began. Its generation did cost money; we simply weren't recording it per article at the time.
"No cost recorded" — tracking was running when the article was generated, but nothing was recorded against it. That's a gap in our records, not a free article.

An article whose cost wasn't recorded is never shown as $0.00. If you see a dollar amount, it was measured. On the detail page, an article where only some stages were recorded is labelled as a partial total rather than presented as complete.

Fact check

Every generated piece gets an automatic fact check before it reaches you, and the results appear inline in the review screen. It does two things:

Claim checking — factual claims in the draft are pulled out and checked against the research the piece was grounded in. Anything that can't be supported, or that contradicts your own brand and product facts, is flagged with the exact sentence highlighted.
Basic content checks — meta title and description length, whether your brand name actually appears, stray first-person voice, and links that point somewhere they shouldn't (a competitor's site, the wrong product, or a missing product link).

Fact-check flags are advisory. A flag never changes a draft on its own and never stops you approving — it tells you where to look. (Duplicate titles are the one thing that does stop an approval; see above. That check is about not publishing the same article twice, not about the quality of what a draft says.) A piece that was checked and came back clean is shown differently from one that hasn't been checked, so a silent failure can't masquerade as a clean bill of health.

Outputs & where they land

Approved articles are published as posts on the Shopify blog you choose in Settings (if you haven't chosen one, they go to your store's first blog), with the SEO title and body HTML the fieldset generated, tagged so they're easy to find later.
The approved excerpt is published as the article's teaser — the short summary shown alongside the post on your blog listing pages.
The approved meta description is written to the article's SEO description.
The FAQ is published as a structured custom.faq metafield on the article rather than pasted into the body, so your theme can render it as a proper FAQ block — which is also the form answer engines and search engines read most reliably.
Visibility results surface inside the fieldset — the probe log and visibility scorecard show how your brand is showing up across the AI answer engines over time.
Slack receives the fieldset's run and visibility summaries on the channel you configure in Settings.

When an action closes itself

Items on the Actions tab fall into two kinds, and they finish differently.

"Create content answering …" is work On Belay does on your site, so it closes itself. When the article written for that question is published to your blog, the action moves to Done on its own, with the date it completed. You don't need to mark it done, and it won't sit in your queue after the work has shipped.
"Earn a citation on <site>" and "Build authority on <site>" are work on someone else's website — a Reddit thread, a YouTube video, a roundup on a review site. On Belay can't see when you've done that, so these stay open until you mark them done yourself.

An action only closes when the post is genuinely live on your blog. A draft, a scheduled post, or an approved post that hasn't published yet all leave it open.

Did publishing actually work?

Publishing content is a bet. The outcomes view settles it.

For every published post written for one of your tracked questions, On Belay compares your brand's mention rate for that question before the post went live against the same question after — overall and engine by engine.

Read that difference as what changed around your post, not as what your post caused. Competitors publish, engines re-rank, and search behaviour shifts inside the same window. This is a before-and-after reading on a single question, not a controlled experiment, which is also why the view shows you how many questions improved, stayed the same, and declined rather than one averaged "lift" figure.

Two things make the number trustworthy:

It won't report a result too early. A post needs enough probes on both sides of its publish date, and enough elapsed time, before it's marked as measured. Until then it reads "not enough data yet" — never a fabricated zero.
It tells you how confident the match is. Posts are matched to the question they were written for; where that match is by text rather than an exact link, the view says so, and anything that can't be matched at all is reported as unmatched rather than quietly dropped.

Find it on the Data tab, with a full drill-down of every contributing post.

Why "named when read" is a different number from your headline score

On the Data tab, the "Where you lose the answer" tile can show an engine at 100% while the same engine sits at 14% in your headline score. Both are right. They are consecutive stages of one funnel, and every cell in the engine strip now prints all three so you can follow it end to end:

Answers measured — every AI answer we recorded for that engine, for your questions, in the window.
Read you — how many of those answers opened one of your own pages before replying, shown as a share of the answers measured (20% of 200 answers read you).
Named when read — of the answers that opened your page, how many actually said your name.

Your headline score is a close relative of stage 1 — it counts, across all your engines, how often your name appears in an answer at all. It is not arithmetically derivable from the three numbers in any one cell: an engine can name you from what it already knows, without opening your site, and the tile reports that separately in the line beginning "This covers …% of the times AI named you."

So an engine reading 100% with 20% of 200 answers read you is telling you something specific and useful: your pages work when AI opens them, and the problem is that it rarely opens them. That is a reach problem, not a writing problem. The tile's own button points you at the work — for this shape it sends you to the Recommendations tab, to the sources AI reaches for instead of yours. The reverse shape — a high read rate with a low "named when read" — is the writing problem, and the button changes accordingly.

Two limits on this, stated rather than hidden:

Gemini shows no read rate at all, and never a zero. Google routes Gemini's sources through its own service, so we cannot see whose page it opened. It still counts in your headline score.
When there are too few reads to give a percentage anywhere on the tile, the read rate prints as a plain ratio (22 of 400 answers read you) instead of a percentage. The finding is the same; we just won't quote a rate we haven't earned.

Is AI reading your content?

This panel counts something different from the funnel above, over a different stretch of time. Here, a "read" is one page fetch at your Cloudflare edge, generated by a real person using an AI assistant. In the funnel above, a "read" is one of our own weekly test answers that cited your site.

Three reasons you cannot divide one by the other:

Different populations. The funnel counts answers to questions we asked. This panel counts fetches caused by questions your customers asked. Our own tests do not show up in these logs — they run through a third party, not against your storefront.

Different windows. The funnel covers 30 days. This panel covers only the days your Cloudflare logs actually go back, which is often far fewer — the caption above the numbers always states the real span, and it is frequently a handful of days against the funnel's month.

Different units. Fetches, not answers. A single answer can cause several fetches, or none.

The fetch counts tell you AI is actively pulling your site. The funnel tells you what happens when it does. Both are real; neither is a check on the other.

AI crawlers — GPTBot, ClaudeBot, PerplexityBot, Google-Extended and the rest — are headless fetchers. They don't run JavaScript, which means Google Analytics, Microsoft Clarity, and every other browser-based analytics tool is structurally blind to them. Their visits only exist in your server's edge logs.

If your site is routed through Cloudflare, connect it and the fieldset will show you real, measured crawler traffic: which AI crawlers hit your site and how often. Every figure is a counted request at your Cloudflare edge — nothing modeled, nothing estimated.

If your site isn't behind Cloudflare, this panel can't show you anything, and it will say so rather than showing you a plausible-looking number. A store served purely by Shopify with no Cloudflare in front of it has no edge log On Belay can read — that's a limitation of where the data lives, not a setting you can switch on. Everything else in the fieldset works exactly the same either way.

Training vs retrieval — the distinction that decides what to write next

Not every AI crawler is doing the same job, and the difference matters commercially. The panel's answer is three numbers, side by side — never one.

To answer someone. Someone asked an assistant something and it fetched your page to answer them, right then. ChatGPT-User, Claude-User, Perplexity-User, DuckAssistBot, Google-NotebookLM, and the assistant apps. These engines can cite you back, so this is the number that reflects real demand for your content. It's shown first and largest, whatever its value.
To index. Indexing crawlers — OAI-SearchBot, Claude-SearchBot, Bingbot, Googlebot, Applebot, Amazonbot, YouBot. Not a live question, but this is what feeds an answer engine's index and ordinary search results.
To train a model. Bulk collection for model training — GPTBot, ClaudeBot, Bytespider, Google-Extended, meta-externalagent, and Common Crawl's CCBot. No one is waiting on an answer and these fetches never cite you back.

There is no combined total anywhere on the panel — not in a headline, not in a footer, not in a tooltip, and not as a trend line. A post fetched 400 times by a training crawler and a post pulled into 400 live AI answers would otherwise look identical, and only one of them is a reason to write more like it.

Underneath the three numbers is a bar for each group. All three bars share one scale, so their lengths are directly comparable: "training is twenty times retrieval" is a true and useful reading, while "16,961 AI reads" is not. A group with very few requests shows a small marker rather than an empty bar — the number beside it is always the exact figure.

Each group then lists its top three crawlers with each one's share of that group, plus a line counting everything else. The tail is always counted, so a group of twenty crawlers never reads as a group of three.

A large training number beside a small retrieval one is a normal, correct reading — not a bug. Bulk training crawlers are simply higher-volume than answer-time fetchers.

Why Googlebot is in the search group. Google's AI Overviews are served from Google's ordinary search index — the one Googlebot builds. They are not crawled by Google-Extended, which is Gemini training and tells you nothing about whether you appear in an AI Overview. Since AI Overview is one of the five engines this fieldset probes, leaving Googlebot out meant leaving out the crawler most responsible for that visibility. Expect it to be the largest number in the search group; it is the highest-volume crawler on the web, and it sits under a heading that says search index precisely so it can't be misread as someone asking an assistant a question.

Googlebot's image and video crawlers (Googlebot-Image, Googlebot-Video) are counted separately by Google and are not included in this figure. They build the image and video search indexes, not the web index AI Overviews are drawn from, so folding them in would inflate the number without telling you anything about AI visibility. On a typical store they are substantial — on one zone, image crawling alone was roughly a third of all Googlebot activity.

Only your storefront counts

Your Cloudflare zone probably serves more than your storefront — an account subdomain, a help site, mail. The panel reports your storefront hostname on its own, and shows the other hostnames in a separate section that is never added to it.

This is not cosmetic. Admin and account subdomains attract a lot of traffic that looks like AI crawlers: credential scanners requesting files like /.env while putting a bot name in their user-agent. Counting that as "AI reading your content" would badly overstate the number.

If Cloudflare isn't in front of your storefront, the panel says so instead of showing a zero. That's a specific and common situation: your zone can be reporting plenty of traffic for other hostnames while recording nothing at all for the storefront itself. A zero would read as "no AI is reading you", which is a completely different fact from "we can't see". The panel names the cause and the fix — the storefront record must be a proxied CNAME to shops.myshopify.com; a proxied A record pointing at a Shopify IP does not work, and neither does a DNS-only (grey cloud) record.

How far back the numbers go

Cloudflare keeps about 8 days of this data on non-Enterprise plans, and there is no way to backfill further. So the panel labels every count with the period it actually covers — a caption under the title reading yourstore.com · Aug 5 – Aug 10 · 6 days of data — rather than the window it looked at. Early on, that period will be short. History builds forward from the day you connect.

The count can also restart later, and that is not a fault. Your zone can only log a hostname from the moment traffic starts passing through it, so if the storefront record was changed — a grey-cloud record turned proxied, or a domain moved onto Cloudflare after the other subdomains — the storefront series begins on that day even though your account and help subdomains have weeks of history behind them. When that happens the caption will read a couple of days while other hostnames read a month. Read the caption, not the plan limit: the 8 days is a ceiling, not a promise, and this panel's real span is often much shorter than the funnel's 30 days.

When Cloudflare is connected, the panel is explicit about which state you're in: still collecting, no crawlers seen yet, a zone that isn't seeing your storefront, a sync that's failing and needs its API token checked, or real data. A measured zero and a stopped feed look different before you read a word — a real 0 means nobody fetched you, while a dash on a dashed outline means we lost the ability to tell. If the feed has stopped while numbers are still on screen, every figure is labelled at least, because it can only be read as a floor.

"We can't say why" — when a crawler name predates a change

Occasionally a group appears called We can't say why. Crawler names are stored with each day's counts and can't be rewritten later, so when we split or rename a crawler, the days already recorded keep the older name. Rather than guess which group those requests belong to, we show them on their own with the count intact. They're never dropped and never quietly folded into one of the three groups. They clear on their own as Cloudflare's ~8-day retention rolls the older days off.

Why there's no "verified" badge

Cloudflare can tell you whether it verified a given request came from the crawler its user-agent claims — but it decides that per request, not per crawler. On one store, the same crawler on the same page on the same day was verified 86 times and unverified 31 times. Any single "verified" tick next to that crawler would be a claim the data doesn't support, so the panel doesn't show one. What it says instead is where the count came from: measured at your Cloudflare edge, counted by user-agent — and user-agents can be spoofed, which is exactly why traffic to your other hostnames is kept separate.

Counts recorded before 12 August 2026 understate several crawlers, and some show zero. A defect in how we asked Cloudflare for the data meant certain crawler names were never requested at all — ChatGPT-User, OAI-SearchBot, Googlebot, CCBot and Bytespider among them. Those crawlers were visiting; we simply never fetched the records, so the stored figure for them was zero rather than low. It is fixed, and because the feed re-pulls a rolling few days, recent days repair themselves automatically. Anything older than Cloudflare's ~8-day retention cannot be recovered. If you see a large jump around that date, it is this fix landing — not a change in how much AI is reading you.

Which posts is AI actually reading?

The panel above answers "is anything reading my site?" for your whole storefront. Evidence → Per-post impact answers the harder question: which post, and who read it.

Each row of that table now carries three numbers in two different units:

Sessions — people. Google Analytics visits that started on that post's URL.
Retrieval — an engine fetched that post to answer someone's live question. There is a real person on the other end, mid-decision, being shown your content. This is the number that matters.
Training — a model crawled that post to learn from. Nobody is waiting, and a training crawl rarely sends anyone back. A large number here is not a win.

These three numbers do not add up, and the table will not let you add them

A session is a person. A retrieval is an HTTP request, and one AI answer can emit several. On top of that, the two halves of the row cover different periods: Google Analytics gives us 30 days, Cloudflare keeps about 8 with no way to backfill. So the two group headers state their own window — People · sessions · last 30 days beside AI · requests · last 7 days — and they will disagree, on purpose.

For the same reason there is deliberately no total, no percentage, and no "AI vs human" ratio anywhere on this table, and no way to sort by a combined figure. If you want to know which posts AI pulls up most, sort by Retrieval. If you want to know which posts earn, sort by Revenue. There is no single ranking that means both.

A dash and a zero are different facts

A 0 means we measured that post over the AI window and nothing fetched it. A dash (—) means we could not measure it. The table never shows one where it means the other, and while the AI columns are still filling forward, a would-be zero is shown as a dash — a zero counted over half a window isn't a measurement of quiet.

If the AI columns aren't there at all

The two AI columns disappear entirely rather than showing you zeros, in three situations, and a band above the table names which one you're in:

Cloudflare isn't connected. Nothing to read from.
Cloudflare is connected but your zone isn't seeing your storefront. This is the important one. Zone analytics only records your store when the DNS record for your storefront is a proxied CNAME to shops.myshopify.com — a proxied A record pointing at a Shopify IP returns nothing, because the requests never travel through your zone. We check this by measuring whether your zone serves any traffic at all for your domain, so we can tell "your DNS is wrong" apart from "nobody is reading you". They look identical otherwise, and getting them the wrong way round would be the worst thing this table could tell you.
We can't identify your storefront hostname. We won't guess — a wrong hostname produces confident numbers about the wrong site.

Empty columns would read as a measured comparison in which AI scored zero. Absent columns read as what they are: not measured here.

What isn't counted

General web-search crawlers — Googlebot, Bingbot, Applebot — are counted in neither AI column. They appear in the whole-site panel under "read to build a search index", where the heading is accurate. Putting them in a column headed "retrieval" would claim Googlebot fetched a specific article to answer someone's question, which isn't true.
Search-index crawlers belonging to answer engines — OAI-SearchBot and its equivalents — are currently in neither column for the same structural reason, so retrieval on this table runs low rather than high.
Assets and index pages. Only real article URLs count. Blog index pages, tag archives, scripts and images are excluded — one crawler on one measured day fetched 172 assets and exactly one actual page, and counting that as "AI read your content" is the exact mistake this table exists to avoid.
Traffic to your other hostnames. Only your storefront. Admin and account subdomains attract credential scanners that put bot names in their user-agent.

Because these two surfaces count different things — the whole-site panel includes every hostname, every page type and every asset; this table includes only real posts on your storefront — the numbers will not reconcile, and neither is wrong.

Only posts Visibility published appear here

The table lists posts this fieldset wrote and published. An article you wrote yourself won't have a row, even if AI is reading it heavily.

Why the revenue figures differ from Analytics → ROI

The Visibility page and the ROI card on Analytics → Overview both report revenue from AI, and they will not match. Neither is a correction of the other — they are two instruments answering two questions.

The Visibility page counts Google Analytics sessions. AI-referral revenue is sessions Google Analytics recorded as arriving from an AI assistant. AI-content revenue is sessions that started on a post the engine wrote and produced revenue in that same visit. Both use Google's own revenue figure, over the 30 days ending yesterday, recalculated each time you open the page.

The ROI card counts Shopify orders. Orders that started on an article counts an order when the buyer's first recorded visit landed on an article the engine wrote. Orders that came from an AI assistant counts an order when the buyer's first or last visit before ordering came from an AI assistant. Both are orders counted once each, on product revenue before tax and shipping.

For AI referrals specifically, the Visibility figure reads higher. There, the Visibility page counts Google Analytics sessions over a broader set of the same traffic the ROI card counts as orders, so the ordering follows from the method. That does not hold for the article pair: a session that started on an article and bought in the same visit is not a superset of an order whose first recorded visit landed on one, so neither of those two is reliably the larger. Compare like with like on period, too — the ROI card's per-year figures against its own per-year figures, its 30-day figures against the Visibility page's.

The ROI card reads below the live figures permanently. We take one reading of your data each night and keep it. Google Analytics carries on revising days we've already read — usually upward, as late conversions land. So the card sits a little below the Visibility page and stays there rather than catching up. That gap is the two methods working as intended, not a stale number.

Don't add the two Visibility figures together. One visit can both arrive from an AI assistant and land on a post the engine wrote, so it counts in both. We can't yet measure how much they overlap, which is why there's no combined total on that page. The ROI card reports both mechanisms in Shopify orders instead, counting each order once — that's where a combined figure exists, and it is smaller than its own two tiles added together for the same reason.

Every figure on both screens carries an info icon that names its source, unit, rule and window, and links to its counterpart.

Billing

Visibility is included in your On Belay plan — both the visibility probing and the content layer, with no per-fieldset, per-publish, or usage charges. Generate, revise, and publish freely; the only thing you pay for is your base plan tier, billed through Shopify Managed Pricing on top of your 14-day free trial. See Plans & billing for tier details.

Tips

Connect Search Console early. It's what turns "here are your gaps" into "here are the gaps worth your time" — real impressions and rankings are the strongest signal in the impact score.
Work the ranked list from the top. The gap list is ordered by likely business impact for a reason. Ten well-chosen pieces beat fifty scattered ones.
Read the Authority Plan before you write more blog posts. If your problem is memory engines rather than retrieval engines, more on-site content won't fix it — the plan tells you which it is.
Seed the topics you already know you should own. Don't wait for the prober to find every gap; if you know a question your brand should answer, seed it and generate now.
Tune the prompts to your voice. Research-grounded doesn't mean generic — the prompt editor is where the content starts sounding like you.
Watch the scorecard over weeks, not days. Visibility moves as your content earns citations; the weekly probe builds the trend that matters.
Take the guided tour before you compare any two numbers. The Data tab's figures come from six incomparable sources, and the arithmetic between them looks reasonable and means nothing. The tour names the unit behind each one. It's in the header under Guide.