Methodology

What we measure, per engine

SEO comes from your own Google Search Console data and is deterministic: the same data gives the same score. The last 28 days are compared with the 28 days before them. The interval (80%) shows week-to-week variation in 7-day blocks, because Search Console data is a census, not a sample.

AEO readiness comes from deterministic checks on your pages' HTML and HTTP responses, with no language model and no rubric. Every failed check carries evidence you can dispute.

GEO citation share is how often an AI engine lists your domain among its sources for a fixed set of prompts. Each of the 6 engines, and each language, is reported on its own and never averaged with the others.

The three scores are never merged into one number. The data type that holds them has no field for a combined score, and a test fails if anyone adds one.

Panel size and cadence

The language of a question and the choice of prompts move AI citations far more than asking the same question again. 2 runs per prompt is the minimum that still estimates run-to-run noise; running every day would multiply the cost without narrowing the interval. The trade-off is explicit: a change in citations is never detected in less than a week.

60 answers per engine and language give wide intervals, often too wide to separate two nearby shares. Sonar shows that width instead of hiding it.

How intervals are computed

Intervals come from a cluster bootstrap. The unit that is resampled is a prompt cluster, drawn with replacement together with all of its runs. Prompts on the same topic rise and fall together, so treating every answer as independent would make intervals look narrower than they are.

Each interval uses 2,000 bootstrap replicates at a 95% level, with the “expanded” percentile method. It was chosen because its coverage in simulation was the closest to nominal of the methods tested.

A GEO number is labelled measured only when every prompt ran at least 2 times and there is more than one prompt cluster to resample. Otherwise it is labelled indicative, with its sample size, and a single cluster gets the widest possible interval.

Random seeds are derived from the engine and the language, so the same data always reproduces the same interval.

Holdout design: why before/after is not proof

Traffic moves for reasons that have nothing to do with a change: seasons, holidays, search engine updates, a competitor's launch. A before/after comparison folds all of them into the result. So every impact claim Sonar makes compares the pages it changed with a holdout of similar pages it never touched, over the same days.

At least 10% of URLs, and at least 10% of prompt clusters, are held out. Membership is decided by a keyed hash, not by ranking, so adding pages never reshuffles existing members. Holdout members are never removed or retired.

Pages are randomised by search-query cluster, not one by one: pages that share top queries are assigned together, so a change on one page cannot take clicks from a control page. An experiment only opens when the largest cluster holds at most 30% of clicks and at least 10 clusters have clicks.

The estimator is difference-in-differences with a weekly seasonal model and a moving-block bootstrap (7-day blocks, 2,000 replicates). A Poisson floor keeps low-traffic sites from getting falsely narrow intervals. It needs 70 days of history before the change and a 28-day readout after it.

GOOD requires a probability of gain of at least 95% and a crossed sequential boundary; BAD requires a probability of harm of at least 90%; NEUTRAL requires at least 80% of the probability within ±3%, the smallest lift worth maintaining. The sequential boundary spends an error budget of 5% in each direction, so checking daily does not inflate false alarms. Everything else stays RUNNING or ends UNDERPOWERED, shown in grey and never in green.

Without a holdout, the impact report refuses to render. It is not replaced by a before/after number.

A/A test results

An A/A test changes nothing, so every GOOD or BAD verdict it produces is a false alarm. The full verdict pipeline, the same code that judges real experiments, was run on simulated sites whose arm splits and noise were calibrated to a real site.

0 false verdicts in 100 A/A runs across 5 traffic levels.

The table also shows the uncomfortable part: at low traffic, even a real lift is rarely detected, because a GOOD verdict demands more certainty than the textbook MDE formula assumes. That is why Sonar shows your MDE before an experiment starts, and why what it sells is gated on measured power.

These are simulations, recorded on September 24, 2026. An A/A on a real traffic series needs 98 days of final data and the lab site had 69 at the time. Enough final data has existed since October 20, 2026, but the real-series result has not been published yet, so the table above is still simulated.

Minimum detectable effect by traffic level

The minimum detectable effect (MDE) is the smallest lift an experiment can tell apart from noise, at a 5% two-sided significance level with 80% power. Sonar computes it for your site before any experiment starts.

An impact claim is sold only when the measured MDE is at most 12%. Between 12% and 25%, results are shown as indicative. Above 25%, no impact claim is made at all.

Planning figures assume independent days, a conservative overdispersion and the minimum holdout. The figure that binds is measured on your own data with the block bootstrap. In the A/A runs above it came out smaller than the planning figure, but on another site it can come out larger.

What we refuse to claim

Some numbers would sell better. Sonar does not show them.

• A single combined visibility score. SEO, AEO and GEO stay three separate numbers.
• Impact from a before/after comparison. Before/after charts carry the label “not proof of impact”.
• A GEO number without its interval, or a measured label on data that is only indicative.
• An impact claim for a site whose MDE is above 25%.
• A trend across an AI model version change. A new model version starts a new series.
• Results pooled from other customers before at least 3 different customers and 3 independent clusters contribute.
• Ratings, reviews, prices or testimonials that do not exist.

Safety loop

Sonar writes to live websites, so every write is bounded, checked and reversible.

Connections and what each can change

How Sonar applies fixes depends on how your site is connected. The table is generated from what each connection actually supports today.

• Edge (Cloudflare): the widest set of fixes, applied in front of your site. Works for any domain: point a hostname at Sonar with a CNAME at whatever DNS provider you use.
• WordPress: the Sonar plugin plus an application password. Titles, descriptions, FAQ sections and new pages.
• GitHub: Sonar opens pull requests against your repository, for sites built from files.
• Shopify: a custom app in your store. Meta tags and on-page blocks.
• Webflow: an API token. Page titles and descriptions only.
• Contentful, Sanity, Strapi (field mapping per content type), Wix, Squarespace and HubSpot: an API token. Titles and descriptions, plus canonical where the API has the field; everything else goes to export mode.

What you need

• Google Search Console: add the Sonar service account shown in the setup wizard as a restricted user of your property.
• Bing Webmaster Tools: ask the Sonar owner to add your site to the team's Bing account.
• Edge connection: access to your DNS settings to add one CNAME record (any DNS provider). If you cannot change DNS, use WordPress, Shopify, Webflow or GitHub instead.
• An authenticator app for the second factor, required to connect a site.
• At least two content languages for the business if you want the GEO citation panel.