Docs

How scanning works

Client-side monitoring, server-side audits, and how results are de-duplicated.

Two ways to scan

Axeible scans in two complementary ways. Client-side monitoring runs axe-core in the browsers of real shoppers as they visit your store — near-free, continuous coverage of the pages people actually use. Server-side audits use a controlled headless browser for full-catalogue scans, on-demand checks, and any arbitrary URL you ask us to test.

Custom rules on a proven engine

axe-core is the industry-standard WCAG rules engine, and we build on it rather than reinventing it. On top of axe-core, Axeible runs its own WCAG 2.2 rules and an AI-shopper simulation to cover ground automated accessibility engines typically don't.

We don't re-scan what hasn't changed

Scanning every page every time would be slow and wasteful, so Axeible is aggressive about de-duplication:

  • Content hashing — unchanged pages are skipped and their stored results reused.
  • Template mapping — an issue found once on a template is mapped to every page built from it.
  • In-flight de-duplication — an identical scan already running is attached to, not duplicated.
  • AI-output caching — drafted alt text and fixes are cached by element, so we don't pay to redo them.

Rationed on purpose

Server-side scanning runs behind a concurrency cap and per-plan budgets. That keeps the service stable and your costs predictable — and it's why a manual URL scan that matches a recent result returns the cached result instantly.


Have a question this didn't answer? Contact us.