It is the second question every merchant asks after the first scan comes back: how often should I be doing this? Most tools answer with a pricing tier — weekly on the cheap plan, daily on the expensive one — as if accessibility decays on a schedule. It does not. A WCAG violation does not appear because a week went by. It appears because something on the page changed: a deploy, a theme edit, a new product image, a third-party script update. The right scan cadence tracks your rate of change, not the calendar. This guide shows how to pick a frequency per site, why hourly is usually wasted, and why the cadence that actually catches regressions is the one tied to your deploys.

Pick the row that matches how often the site changes. Then add a scan on every deploy — that is where regressions are actually born.

The question is per-site, not per-account

The first mistake is treating scan cadence as one global setting. A merchant typically runs more than one property: a marketing homepage that changes quarterly, a Shopify storefront that gets edited weekly, and maybe a help centre that almost never moves. Forcing all three onto the same schedule either over-scans the static ones (wasted runs, noisy history) or under-scans the active one (regressions sit undetected for days).

Cadence is a property of the site, not the account. The site that ships a new theme version every Tuesday needs a different rhythm than the one-page landing that has not changed since launch. Good monitoring lets you set the frequency independently on each tracked site, with your plan defining the fastest cadence available rather than dictating a single rate for everything.

Tie cadence to change, not to a calendar

A scan is a measurement. Measuring the same unchanged page every hour produces the same report every hour — that is not monitoring, it is a loop. The value of a scan comes from the delta: what is different since the last clean run. So the useful cadence is whatever frequency keeps the delta small enough to act on without drowning you in identical reports.

Concretely, accessibility regressions enter a site through a handful of events:

Deploys. A developer ships a new component, a refactor changes the DOM, a dependency bump alters rendered markup. This is the single largest source of new violations.
Theme and template edits. On Shopify and similar platforms, a non-technical edit in the theme editor can break heading order, remove a label, or drop contrast below the threshold.
Content and catalogue changes. A new product with a missing alt text, a banner image with text baked in, a promo block pasted from a supplier.
Third-party scripts. A chat widget update, an A/B testing tool, an embedded video player — code you did not write, mutating your page at runtime.

Notice what is not on that list: the passage of time. Nothing about Tuesday becoming Wednesday introduces a contrast failure. This is why mapping cadence to your change rate — rather than picking the biggest number your plan allows — is the whole game.

Recommended cadences by site type

Use this as a starting point, then adjust based on what your scan history shows:

Static brochure or landing page — changes a few times a year. Monthly is plenty. The monthly run mostly proves nothing regressed, which is exactly the dated evidence you want for compliance anyway.
Active e-commerce store — weekly content and catalogue edits, occasional theme tweaks. Weekly keeps the delta small enough that any new violation is traceable to that week's changes.
High-velocity site — frequent deploys, seasonal promos, multiple editors. Daily. At this pace a week is too long; a daily baseline narrows any regression to a single day of changes.
Anything with continuous deployment — see the next section. The calendar cadence becomes a backstop; the deploy trigger does the real work.

Why hourly is usually overkill

Hourly scanning sounds thorough, and there are narrow cases for it — a high-traffic site during a launch window, or a page assembled from rapidly-changing third-party feeds. But for the overwhelming majority of e-commerce sites, hourly scanning measures the same unchanged page 24 times a day. WCAG conformance is not a metric that drifts hour to hour like CPU load; it steps when the markup steps. An hourly cadence on a site that deploys twice a week generates 333 identical reports for every one that actually shows a change.

That noise has a cost. A scan history full of identical runs makes it harder to spot the run that matters. The signal — the report where something broke — is buried under hundreds of green duplicates. We deliberately do not push hourly as the default recommendation, even though the top plan supports it, because for a normal store it trades a real benefit (a clean, readable history) for a theoretical one (catching a regression an hour sooner that a deploy-triggered scan would have caught instantly anyway).

Scan-on-deploy: the cadence that actually matters

If a scan should run when the site changes, and a deploy is the biggest source of change, then the highest-value trigger is obvious: scan on every deploy. Instead of hoping your daily timer happens to fire after a risky deploy, you wire the scan into the moment the change ships.

For teams with a CI pipeline, this is a single step: after the deploy job succeeds, hit the scan endpoint (or run an axe-core pass in CI directly) against the URLs that changed. The scan becomes part of the release, the same way a smoke test is. A regression is caught in the same pipeline run that introduced it — before a customer, a regulator, or a plaintiff firm ever sees it.

For merchants without a CI pipeline — most Shopify stores — the equivalent is a tight calendar cadence (daily or weekly) plus a manual scan after any theme publish or large catalogue update. The discipline is the same: scan when the site changes, not just when the clock ticks.

Scan-on-deploy also fixes the noise problem from the previous section. You no longer need an aggressive timer to feel safe, because the timer was never what caught regressions — the change trigger was. A weekly backstop scan plus a scan on every deploy beats an hourly timer on both coverage and signal.

What the delta tells you

Once cadence tracks change, your scan history becomes a changelog of your site's accessibility. Each run is a diff against the last: violations resolved, violations introduced, score moved. That history is more useful than any single report, because it answers the question that matters in a remediation programme — are we getting better or worse, and which change caused which?

This is also where the audit workflow and continuous monitoring meet. A one-shot audit gives you a baseline. Cadenced scanning turns that baseline into a trend line. When a violation reappears, the timestamp tells you which deploy or edit reintroduced it, which is half the work of fixing it.

Mapping cadence to your plan

Here is how the per-site model works in practice. Your plan sets the fastest cadence you can choose; you then set each site at or below that ceiling based on its change rate:

Starter — up to 5 sites, weekly ceiling. Set the active store to weekly, the brochure site to monthly. Good for a single merchant with a couple of properties.
Pro — up to 25 sites, daily ceiling. Set high-velocity sites to daily, steady stores to weekly, static pages to monthly. This is the typical agency or multi-store setup.
Business — many sites, hourly ceiling available. Use hourly only on the rare site that genuinely needs it; keep the rest on the cadence their change rate justifies.

The point of independent per-site cadence is that you are not paying the "scan everything daily" tax on sites that change twice a year. You spend frequency where change happens. See the plans and ceilings for the exact limits.

The compliance angle: dated evidence

There is a second reason cadence matters, beyond catching regressions: it produces a paper trail. The ADA and the European Accessibility Act both reward contemporaneous evidence — proof that you were actively monitoring and remediating, dated, before any complaint. A site scanned monthly with a clean history of dated reports is in a materially stronger position than one with a single scan from eighteen months ago.

Even a static site that "never changes" benefits from a monthly scan for this reason alone. The runs are nearly identical, but each one is a dated record that conformance held. That record is the artifact a corporate buyer asks for in a VPAT request, and the one plaintiff counsel cannot easily dispute.

How to set your cadence

List your sites and their change rate. Be honest: how often does each actually change? Most accounts have one active site and several near-static ones.
Match each site to the table above. Static to monthly, active to weekly, high-velocity to daily. Start conservative; you can always tighten it.
Add a deploy trigger where you can. If you have CI, wire a scan into the release. If you are on Shopify, scan manually after every theme publish.
Watch the first month of history. If every run is identical, you can loosen the cadence. If you see regressions you missed, tighten it — or improve your deploy trigger.
Keep the dated reports. They are your evidence trail, independent of whether they ever catch a regression.

If you have not set a baseline yet, start there: run a free WCAG 2.2 scan on any URL — full violation list, severity breakdown, no signup. Then walk the step-by-step audit on the findings, set a per-site cadence that matches how often the page changes, and let the deploy trigger do the heavy lifting. Cadence is not about scanning more. It is about scanning when it counts.

How Often Should You Run Accessibility Scans?