# [Insights: coverage findings with fixes](https://rebilder.com/help/console/console-insights)

> The findings Rebilder can honestly compute from your events (unserved agent routes, missing outcome wiring, protocol demand, verification readiness), each with one concrete fix.

Insights (a Pro surface) checks the last 30 days of your store’s recorded events and shows findings, each with its real observed counts, the window they cover, and at most one concrete fix. Findings are computed live from your events; nothing is a projection. If nothing needs attention, the page says exactly what was checked: “No coverage gaps detected in the last 30 days.”



## Search crawlers still get your real pages

The most common worry about putting anything in front of a website is search. This panel answers it from your own traffic: how many search-crawler requests arrived, and how many were answered with your canonical HTML.

The answer should always be all of them, and that is structural rather than lucky. A known crawler is classified as a crawler before any other rule can fire, so it gets HTML even if it asks for markdown; your own agent access policy cannot turn a crawler away; and the gateway never varies substance by requester. Serving a crawler something different from a person is what search engines call cloaking, and it is the thing this design exists to make impossible.

If the panel ever shows requests answered with anything else, that is a real problem rather than a statistic. Email support@rebilder.com and we will look at it with you.

## What the gateway costs your responses

This panel shows the milliseconds the gateway itself spent, measured on every single request rather than sampled. It is NOT your page load time, and the difference matters: on a human page view the gateway classifies the request and hands off before your page runs, so your page is not in the number at all.

Judge us on the pass-through row. That path is entirely our work, and it is the one the published edge budget (p95 under 50 milliseconds of compute) applies to. The markdown row includes your own source resolvers, so a slow number there is usually a slow database or API behind a resolver, not the gateway; the protocol row likewise includes your protocol handler.

If a store has no pass-through traffic yet, no verdict is shown at all. “Within budget” about zero requests would be a pass we had not earned.

## What agents asked for, and what they got

This panel counts your agent requests three ways: how many arrived, how many explicitly asked for markdown, and how many were served a machine format anyway. The middle number is usually very small and the third is usually close to the first. That gap is the gateway doing its job.

“Asked” means the request carried an explicit `text/markdown` range in its Accept header. A wildcard (`*/*`) does NOT count, even though ordinary content negotiation treats a wildcard as accepting everything: an agent sending a wildcard has expressed no preference, and counting that as asking would turn a real finding into a meaningless one. The same code that decides how to serve a request decides this number, so the panel cannot disagree with the gateway.

The table lists the most common Accept headers your agents actually sent. Where a store has a long tail, the remainder is folded into a single labelled row carrying the number of headers it stands for. Nothing is silently dropped.

## The finding catalog

| Finding | What it means | The fix |
| --- | --- | --- |
| Agent requests passing through unserved | Agents asked for your pages but received HTML instead of markdown because the gateway had no content source wired for those routes. The finding lists the top offending URLs with counts and last-seen times. | Wire a content source for those routes (the fix links to the sources docs). Once wired, those requests start getting clean markdown. |
| No orders reported | Agent traffic exists but zero orders have been reported, so the funnel cannot show whether any of it converts. | Wire the Shopify order webhook or the outcomes API; the fix links to the docs with both contracts. |
| Protocol demand at your endpoints | Requests were answered on the protocol path, which means transacting agents are probing your store’s protocol endpoints. | Wire `createProtocolHandler` so protocol requests get your live catalog instead of stubs. |
| Verified-agent readiness | How many of your agent requests carried no cryptographic verification (Web Bot Auth). Informational only. | Nothing to act on: verification is still rolling out across agent platforms, so unverified requests are expected. The card says so rather than inventing a fix. |

> The catalog is deliberately short: only findings the events can actually measure exist. A finding Rebilder cannot measure yet is absent rather than estimated.