An AI visibility dashboard can tell you that ChatGPT stopped citing a page. It cannot tell you why.
Maybe the page fell out of Bing. Maybe a crawler can fetch it but cannot reach it through an internal link. Maybe the model searched for a local phrase your content never uses. Maybe Google Business Profile has the wrong category. Maybe nothing changed at all and the chart is moving on four observations.
That gap is the useful comparison between Canonry and paid tools such as Profound, Otterly, Peec, Ahrefs Brand Radar, and Semrush. They all measure answers. The difference appears after the answer arrives.
I build Canonry, so the bias is obvious. The argument here is narrower than "open source is better." Paid tools are often better reporting products. Canonry is built for the investigation and execution that reporting creates.
The comparison starts after the score
AI visibility products share a basic loop. They run a prompt against one or more answer engines, save the response, extract brands and citations, then aggregate the results into a score.
That loop is useful. It answers whether a brand appeared, which competitors appeared with it, and which sources the model cited. A hosted vendor can run it across a large panel without asking the customer to configure provider keys or maintain infrastructure.
The limit is not the quality of the chart. It is the boundary of the system around it.
Capture the answer, citation, source, and provider call.
Join demand, crawl, entity, traffic, and authority evidence.
Publish, submit, notify, or prepare a bounded paid action.
Run the same instrument again and preserve the comparison.
Canonry is self-hosted and single-tenant. The dashboard is one client of the project API. The CLI and MCP adapter consume the same API, and schedules and webhooks operate against the same project record. The user's own agent can move through the loop without exporting a CSV or reconstructing context in another system.
This is why a conventional feature grid makes the products look more similar than they are. "Tracks ChatGPT" describes step one. It says nothing about the other three.
A citation loss is a systems problem
Take a simple incident. A model answers a commercial question, cites a competitor, and does not cite you.
The saved answer is only the first piece of evidence. Canonry keeps the provider payload, including the web searches the engine issued when it grounded the response. Those fan-out queries often reveal a narrower information need than the original prompt. It also records where a match occurred: answer text, cited domain, cited URL, search query, or the prompt itself. A mention and a citation are different outcomes.
Now the investigation can branch:
| Evidence | Question it answers |
|---|---|
| Provider payload | What did the engine search, answer, and cite? |
| Google Search Console | Is there first-party demand for the query or its variants? |
| Bing Webmaster Tools | Is the relevant URL known, indexed, and eligible on Bing-backed surfaces? |
| Technical crawl graph | Can a crawler reach the page through followable internal links? |
| Server traffic | Did an AI crawler or user-fetch agent actually request the page? |
| Google Business Profile | Does the local entity record match the market and intent? |
| Common Crawl and Bing backlinks | Is the competing source supported by an authority gap? |
These are not seven dashboard widgets. They are seven branches in one diagnosis.
If the URL is absent from Bing, Canonry can request indexing. If the page is orphaned, site-health path proves it and the crawl record shows the broken route. If the model searched for a phrase with real Search Console demand, that phrase becomes evidence for a content change. If the query is local, Business Profile keywords and the rendered Places listing can expose a category or entity mismatch.
The same model extends beyond organic visibility. Canonry ingests server-side traffic from Cloudflare, Cloud Run, Vercel, and WordPress because JavaScript analytics misses most crawlers. It connects OpenAI Ads Manager and keeps Google Ads and GTM snapshots read-only, so an operator can compare the growth recommendation with the conversion system that would measure it.
The point is not that every project needs every source. The point is that the source remains available when the evidence sends the investigation there.
MCP is a transport, not the product
Agent access is no longer a Canonry-only feature. Peec and Otterly expose hosted MCP servers. Profound has a hosted server and external connectors into the tools a marketing team already uses.
That is good progress. It also makes raw tool counts a weak comparison.
Peec and Otterly let an agent work with the monitoring model held in their clouds. Profound goes further by letting its platform act outward into CMS, project-management, and communication systems. That outward connector model is useful, and Canonry does not try to replace it.
Canonry takes the opposite boundary. canonry-mcp is a local adapter to the user's instance. It exposes the public project API, not a separate agent-only implementation. New capabilities gain CLI, REST, and MCP parity through the same contract. Credential setup and browser-session control remain outside the agent surface.
The useful question is therefore not "does it have MCP?" It is "what can the agent prove and what can it change?"
In Canonry, the answer spans stored evidence and bounded operations: inspect an answer, read Search Console demand, trace a crawl path, review server fetches, check a Business Profile location, generate JSON-LD, publish a WordPress draft, submit a sitemap, and schedule the next run.
Paid actions keep a harder boundary. OpenAI Ads entities are created paused. Activation requires an exact human approval grant naming the campaign tree, advertiser account, and executor key. Grant creation is not exposed as an MCP tool. The agent can prepare the work, but it cannot grant itself permission to spend.
This is the agent model behind Canonry: the agent reasons across evidence, the platform holds state and permissions, and the human approves consequential execution.
One website is often a portfolio
Most visibility tools start with a brand and a prompt list. That works until the domain represents forty clinics, two hundred hotel properties, six business units, or an agency portfolio.
At that point there are two common choices. Create a project for every market and multiply the metered prompt count, or keep one project and average unlike markets into one score. Both lose something important.
Canonry's Advanced Measurement model keeps the portfolio inside one project. A Property represents the thing being measured. Targets define its canonical pages, aliases, and approved URL patterns. A shared question can execute once, then be evaluated against every linked Target.
That separation matters when one answer cites a page for Detroit but not Phoenix, or when a competitor displaces only the hospitality business unit. A domain-level score hides both events.
URL credit is conservative. A cited URL is assigned automatically only when it maps to one Target. Overlapping and unmatched URLs remain visible instead of being forced into the nearest market.
The measurement plan is versioned too. An operator can compile and diff a draft without starting provider work, publish it, and keep every previous version readable. If a report crosses a plan change, the instrument change is part of the record rather than a footnote someone has to remember.
This is also where call-level storage becomes valuable. Paging evidence with shape=answers includes the measured answers in which a Property was not cited, together with the sources that were. The output is not just a visibility score. It is a market-specific work queue.
The number still needs a denominator
Owning the sampling design does not make answer engines deterministic. It only makes the tradeoff explicit.
An AI visibility rate is a proportion: the brand appeared in k of n measured answers. At small n, a precise-looking percentage can describe an enormous range of plausible reality. A Wilson 95% interval around a 30% mention rate looks like this:
| Observations | 95% interval | What it supports |
|---|---|---|
| 30 | 16.7% to 47.9% | Broad absence or presence |
| 100 | 21.9% to 39.6% | A directional baseline |
| 400 | 25.7% to 34.7% | A ten-point comparison against 40% |
At thirty observations, a reported 30% rate is still consistent with something close to 17% or 48%. A week-over-week chart built from one run per prompt has even less to say.
Paid plans meter some product of prompts, engines, locations, and cadence. Ahrefs calls the unit a check: one prompt, on one platform, in one location. That is the honest unit because every confidence claim starts with how many checks produced it.
Canonry does not meter checks, but measurement is not free. The operator supplies provider keys and pays the underlying grounding and token costs. The advantage is control: run a small weekly basket, or spend heavily for a short experiment that needs enough observations to settle a question.
visibility-compare is conservative about the output. It compares only query and provider pairs present in both periods, attaches confidence intervals, and returns within-noise when the intervals overlap. A model change produces a continuity warning instead of a directional claim.
That behavior is less exciting than a line chart. It is also easier to defend.
When buying is better
Self-hosting removes the subscription boundary and adds an operational one.
A hosted tool is the better choice when nobody wants to own provider keys, deployment, upgrades, or failed schedules. It is also better when the primary reader is an executive who needs a polished report rather than an API, or when procurement requires SSO, a support SLA, and a vendor security review.
The largest paid vendors also own data Canonry cannot recreate. Ahrefs can research a historical corpus across many brands and prompts. A managed browser fleet can capture consumer sessions across geographies. A continuous panel can show evidence from before a customer started measuring. A self-hosted instance cannot backfill observations it never made.
Those are architectural advantages, not packaging details.
Canonry asks more of its operator. It expects comfort with Node.js, provider credentials, and the responsibility that comes with connecting first-party systems. For a team that only needs a recurring share-of-voice report, that is unnecessary machinery.
How to choose
The shortest decision is this: decide whether the product you need ends at the report.
Buy a paid visibility tool when the job is to monitor answer engines, benchmark competitors, and distribute a clean dashboard with minimal operational work. Ask the vendor for the prompt list, sample count, geography handling, scoring formula, and raw evidence. If those are visible, the product is doing its job.
Run Canonry when the report starts the work. The case gets stronger when the site spans many markets, when local and Bing evidence matter, when technical and server-side proof must sit beside the answer, or when an agent needs to move from observation to a reviewable intervention without rebuilding context between tools.
Canonry is available on GitHub under FSL-1.1-ALv2, which converts to Apache 2.0 after two years.
npm install -g @canonry/canonry
cnry bootstrap
cnry serve
Paid tools tell you what the models said. Canonry is built for the morning after.